Comment définissez-vous un SLO, et en quoi est-ce différent d'un SLA ?

Un SLI est la mesure réelle, par exemple le pourcentage de requêtes qui aboutissent avec succès en moins de 300 millisecondes. Un SLO est l'objectif interne que l'on fixe pour ce SLI, disons que 99,9% des requêtes respectent ce seuil sur une fenêtre glissante de 30 jours. Un SLA est différent par nature, pas seulement par degré : c'est un engagement externe, souvent contractuel, envers un client, généralement avec des conséquences financières ou de réputation en cas de non-respect, et il est en général fixé plus large que le SLO interne pour donner de la marge à l'équipe. Je traite le SLO comme le chiffre qui pilote réellement les décisions au quotidien, et je réserve la conversation sur le SLA à ce que l'on communique aux clients et au juridique, car confondre les deux pousse les équipes soit à surinvestir dans une fiabilité que personne ne finance, soit à sous-investir et risquer de rompre un vrai contrat.

Qu'est-ce qu'un error budget, et comment l'utilisez-vous pour prendre des décisions ?

L'error budget est simplement 1 moins le SLO, exprimé comme une quantité de défaillance acceptable sur une fenêtre de temps. Si notre SLO est de 99,9% sur 30 jours, l'error budget est de 0,1%, ce qui sur un service à fort trafic se traduit en un nombre concret de minutes d'indisponibilité ou de requêtes en échec que l'on peut se permettre. Je l'utilise comme un outil de décision, pas seulement une métrique de reporting : quand le budget est sain, l'équipe a de la marge pour aller plus vite et prendre plus de risques, y compris des mises en production plus risquées ou des changements d'infrastructure. Quand le budget approche de l'épuisement, on recentre l'effort sur la fiabilité et on ralentit ou suspend les nouvelles fonctionnalités jusqu'à ce qu'il se reconstitue. L'intérêt de ce cadre est qu'il transforme la question « est-ce sûr de déployer » d'un débat subjectif en un chiffre partagé que l'ingénierie et le produit peuvent regarder ensemble et accepter.

Comment abordez-vous l'équilibre entre travail de fiabilité et vitesse de livraison des fonctionnalités ?

Je traite l'error budget comme le mécanisme qui résout cette tension plutôt que d'essayer de la régler à coups de réunions de négociation. Tant que le budget est sain, produit et ingénierie peuvent avancer à pleine vitesse, puisque les données montrent que le service peut absorber ce niveau de risque. Une fois que le budget commence à s'épuiser, cela devient un signal automatique et convenu à l'avance pour prioriser le travail de fiabilité : corriger les causes racines des incidents récents, réduire le toil, ou renforcer une dépendance fragile, avant d'ajouter plus de risque fonctionnel. Je suis aussi le toil séparément, le temps passé sur du travail opérationnel manuel et répétitif, car un toil élevé érode discrètement la vélocité même quand le SLO a l'air bon sur le papier. Bien calibrer cet équilibre dépend d'abord de fixer le SLO avec rigueur : un SLO trop strict épuise toute l'équipe à poursuivre une fiabilité que personne ne demande vraiment, et un SLO trop lâche laisse s'accumuler de vrais problèmes de fiabilité sans qu'on s'en aperçoive.

Comment utilisez-vous l'IA dans votre travail de SRE ?

J'utilise des outils d'observabilité avec détection d'anomalies pour repérer des schémas inhabituels de latence ou de taux d'erreur avant qu'ils ne franchissent un seuil d'alerte, ce qui donne à l'équipe de l'avance sur les problèmes émergents. Pendant un incident actif, j'ai utilisé la synthèse de logs assistée par IA pour extraire rapidement les lignes pertinentes d'un volume énorme de bruit, ce qui accélère les dix premières minutes quand tout le monde essaie de comprendre le périmètre. Certains de nos runbooks proposent maintenant des prochaines étapes suggérées par IA en fonction de l'alerte déclenchée, même si je traite toujours cela comme une hypothèse de départ, pas une instruction à suivre aveuglément. Ce qui reste entièrement humain, c'est le rôle d'incident commander et l'analyse du post-mortem : décider ce qui s'est réellement passé, ce qui y a contribué, et quels changements valent la peine d'être faits nécessite un jugement sur le contexte organisationnel et les compromis que les outils ne peuvent pas voir.

Parlez-moi d'un incident important que vous avez dirigé ou auquel vous avez contribué à résoudre. Détaillez-moi le déroulé.

Notre base de données principale a connu un problème d'épuisement du pool de connexions qui a mis le paiement hors service pendant environ 22 minutes lors d'un pic de trafic promotionnel. J'étais incident commander : mon premier réflexe a été de déclarer l'incident formellement et de mobiliser un spécialiste base de données et un ingénieur backend plutôt que d'essayer de déboguer seul. Nous avons mitigé d'abord, pas cherché la cause racine d'abord : nous avons augmenté la limite du pool de connexions et redémarré les instances du service concerné, ce qui a rétabli le paiement en environ huit minutes, puis passé le reste de l'incident à confirmer la stabilité. J'ai publié une mise à jour de statut toutes les dix minutes dans notre canal d'incident, même sans nouvelle information, car un silence côté parties prenantes est pire qu'une mise à jour répétée du type « toujours en cours d'investigation ». Une fois le service stabilisé, j'ai transmis l'investigation de la cause racine au spécialiste base de données et clôturé l'incident actif, car garder un incident ouvert au-delà de la mitigation ajoute de la charge de process sans aider les utilisateurs.

Décrivez un post-mortem sans recherche de coupable que vous avez mené ou auquel vous avez contribué. Qu'est-ce qui l'a rendu efficace ?

Après qu'une panne du pipeline de déploiement a causé un retard de deux heures dans un correctif de sécurité critique, j'ai mené le post-mortem et posé la règle de base dès le départ : nous nommons les facteurs contributifs dans le système et le processus, pas la personne qui a cliqué sur déployer. Nous avons construit la chronologie ensemble en groupe plutôt que moi la présentant seul, ce qui a fait remonter un détail que j'aurais manqué : l'alerte qui aurait dû détecter la panne avait été mise en sourdine trois semaines plus tôt pendant une session de débogage sans rapport et jamais réactivée. Chaque action a reçu un responsable nommé et une échéance dès la même réunion, sans rester un suivi vague, et nous avons d'abord revu les actions du post-mortem précédent pour confirmer qu'elles avaient réellement été réalisées. Le post-mortem a fonctionné parce que personne n'a dépensé d'énergie à se défendre : l'ingénieur qui avait mis l'alerte en sourdine a spontanément partagé ce détail une fois qu'il est devenu clair que la salle cherchait des causes, pas un coupable.

Parlez-moi d'une fois où vous avez dû vous opposer au déploiement d'une fonctionnalité pour un risque de fiabilité.

Le produit voulait déployer une refonte majeure du paiement deux semaines avant notre période de trafic la plus chargée de l'année, et notre error budget pour ce service était déjà tombé à environ 15% restant pour le mois après quelques semaines difficiles en incidents. Je n'ai pas simplement dit non. J'ai apporté les données de l'error budget à la réunion de planification et présenté cela comme une décision de risque partagée : déployer maintenant, avec un chemin de code non testé, pendant le pic de trafic, avec presque plus de budget, était un risque précis et chiffré, pas une inquiétude vague. J'ai proposé de déployer la refonte sur un petit pourcentage du trafic immédiatement, de surveiller le SLO pendant une semaine, et de ne généraliser que si cela tenait, plutôt qu'un lancement complet juste avant le pic. Le produit a accepté une fois le risque présenté en chiffres plutôt qu'en prudence générale, et le déploiement progressif a détecté une fuite mémoire sous charge qui aurait causé un vrai incident pendant le pic de trafic si nous avions déployé intégralement selon le calendrier initial.

Comment décidez-vous ce qu'il faut mesurer : quelles métriques, logs et traces comptent pour un service ?

J'ancre mes métriques autour des quatre golden signals : latence, trafic, taux d'erreur et saturation, car ensemble ils couvrent l'essentiel de ce qui indique qu'un service est en bonne santé sans noyer l'équipe sous le bruit. Pour un seul service, ces informations viennent des métriques, mais dès qu'on a une chaîne d'appels à travers plusieurs services, les métriques seules ne suffisent plus, et c'est là que le tracing distribué justifie son coût : une trace montre exactement quel maillon d'une requête a ajouté de la latence au lieu de simplement dire que l'ensemble a ralenti. Je garde les logs structurés, avec des champs cohérents comme l'ID de requête et le nom du service, spécifiquement pour qu'ils puissent être corrélés avec une trace pendant un incident au lieu d'être parcourus manuellement. Je suis délibéré sur l'échantillonnage sur les services à fort volume, car capturer 100% des traces devient coûteux rapidement et apporte rarement plus de valeur qu'un taux d'échantillonnage bien conçu combiné à une capture complète de tout ce qui génère une erreur.

Comment identifiez-vous et réduisez-vous le toil dans votre travail quotidien ?

Je définis le toil comme du travail manuel, répétitif, tactique, qui croît linéairement avec la croissance du service plutôt que d'apporter une valeur d'ingénierie durable, des choses comme redémarrer manuellement une tâche bloquée ou modifier à la main une configuration pour chaque nouveau client intégré. La première étape consiste à le mesurer avec précision : je suis la part du temps d'astreinte réellement consacrée au toil par rapport à la vraie réponse aux incidents, car les équipes sous-estiment systématiquement cela tant qu'elles ne l'ont pas mesuré pendant quelques semaines. Tout ce qui revient plus qu'une poignée de fois passe un test clair : est-ce que cela peut être automatisé avec un effort d'ingénierie raisonnable, et est-ce que le supprimer libère assez de temps pour justifier cet effort. J'ai automatisé des choses comme le renouvellement de certificats et le nettoyage de ressources obsolètes de cette façon, ce qui a retiré du vrai toil de l'astreinte de façon permanente plutôt que de simplement rendre chaque occurrence un peu plus rapide. Je protège aussi du temps sur la roadmap spécifiquement pour ce travail, car la réduction du toil perd toujours face à la pression fonctionnelle si elle n'est pas explicitement planifiée.

Expliquez-moi comment vous aborderiez la planification de capacité pour un service qui anticipe une forte hausse de trafic.

Je pars du chiffre de croissance réel attendu par le produit, pas d'un vague « beaucoup plus de trafic », et je le convertis en un objectif précis de taux de requêtes. Je regarde les tendances de croissance historiques d'événements similaires passés pour vérifier si la projection est réaliste, puis je lance des tests de charge sur un environnement de staging configuré pour ressembler le plus possible à la production, car tester sur un environnement sous-dimensionné donne une fausse confiance. Je fixe un objectif de marge, en général en prévoyant sensiblement plus que le pic projeté, pas juste de quoi l'atteindre exactement, car le trafic réel est plus en pics qu'une projection lissée ne le suggère. Je vérifie spécifiquement les limites d'autoscaling, car un service peut avoir une capacité théorique confortable mais échouer quand même si le nombre maximal d'instances de l'autoscaler ou la limite de connexions d'une dépendance en aval le plafonne en dessous du besoin. Le coût fait aussi partie de la conversation : je présente un plan avec la marge que je recommande et son coût, pour que la décision d'accepter plus de risque contre un coût plus faible soit prise explicitement par l'entreprise, pas par défaut.

Site Reliability Engineer

Les entretiens pour un poste de Site Reliability Engineer évaluent votre capacité à considérer la fiabilité comme un objectif mesurable et négocié plutôt qu'un but abstrait. Les recruteurs veulent voir votre aisance avec les SLO, les error budgets et l'observabilité, ainsi que votre façon de gérer la réponse aux incidents et les post-mortems sans chercher de coupable. Ce guide couvre les questions les plus fréquentes et les réponses qui font la différence.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Aller plus loin

Réussir l'entretien comportemental (méthode STAR)Comment se préparer à un entretien technique

Questions d'entretien courantes pour Site Reliability Engineer

Questions comportementales pour les postes Site Reliability Engineer

Questions techniques pour les candidats Site Reliability Engineer

Ce que les recruteurs recherchent pour un poste Site Reliability Engineer

Ce que les recruteurs cherchent vraiment chez les candidats Site Reliability Engineer :

Une aisance avec les SLI, les SLO et les error budgets comme outils de décision, pas seulement comme vocabulaire. Les bons candidats décrivent comment ces chiffres ont réellement influencé une décision concrète.
Une séparation nette entre mitigation et cause racine pendant les incidents. Les candidats qui confondent les deux prolongent généralement les pannes sans raison.
Une vraie expérience du post-mortem sans recherche de coupable. Cherchez un détail précis, comme quelqu'un qui reconnaît une erreur sans qu'on le lui demande, comme preuve que la culture est réelle et pas seulement affichée.
Une approche chiffrée du toil. Les candidats capables de dire combien de temps le toil coûte réellement à l'équipe ont mesuré leur propre travail, pas seulement s'en être plaints.
Une aisance à négocier avec le produit à partir de données plutôt que d'autorité. Les SRE qui ne savent que dire non finissent par être contournés.

Questions à poser à votre interlocuteur

→Quel est le SLO actuel pour le service principal, et à quelle fréquence l'équipe consomme-t-elle réellement l'error budget ?
→Comment l'astreinte est-elle organisée, et à quoi ressemble la charge d'incidents typique par rotation ?
→Comment les post-mortems sont-ils menés ici, et que deviennent les actions ensuite ?
→Quelle part du temps de l'équipe est consacrée au toil par rapport au nouveau travail d'ingénierie ?
→Comment l'équipe équilibre-t-elle en pratique le travail de fiabilité et la pression de la roadmap produit ?

Entraînez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit sur votre premier poste suivi.

Métiers similaires

Disponible dans d'autres langues

English Español