Questions d'entretien pour Site Reliability Engineer — Plus de 30 questions et réponses d'experts

Glassdoor rapporte un salaire moyen de SRE de 169 680 $, le 75e percentile dépassant 213 000 $ annuellement [1]. Le rôle — né chez Google en 2003 et désormais adopté par toutes les grandes entreprises technologiques — se situe à l'intersection de l'ingénierie logicielle et de l'exploitation des systèmes, et le processus d'entretien reflète cette dualité [2]. Les entretiens SRE testent la conception de systèmes avec des contraintes de fiabilité, la programmation pour l'automatisation, la gestion d'incidents sous pression et l'état d'esprit spécifique de quantification de la fiabilité à travers les SLOs et les budgets d'erreur. Ce guide couvre les questions comportementales, techniques et situationnelles que vous rencontrerez, avec des réponses calibrées à la profondeur que les entreprises de premier plan attendent.

Points clés

• Les entretiens SRE comprennent généralement quatre à six tours : programmation, conception de systèmes, dépannage, gestion d'incidents et comportemental — répartis sur une journée complète ou plusieurs sessions [3].
• Le différenciateur central de l'entretien SRE est la conception de systèmes orientée fiabilité — vous devez concevoir des systèmes qui se dégradent gracieusement, pas seulement des systèmes qui passent à l'échelle [2].
• Les SLOs, SLIs, budgets d'erreur et la réduction du toil sont le vocabulaire spécifique SRE que les recruteurs attendent de vous maîtriser couramment.
• Les questions de programmation pour les rôles SRE mettent l'accent sur l'automatisation, l'outillage d'infrastructure et le scripting opérationnel plutôt que sur les problèmes purement algorithmiques [3].

Questions comportementales

1. Parlez-moi de l'incident le plus marquant que vous avez géré. Quel était votre rôle, et qu'a révélé l'analyse post-incident ?

Réponse d'expert : « J'étais le commandant d'incident lors d'une défaillance en cascade qui a mis hors service notre service d'authentification principal, affectant 2,3 millions d'utilisateurs actifs pendant 47 minutes. Un changement de configuration de routine sur notre limiteur de débit avait accidentellement fixé le seuil à 10 requêtes par seconde au lieu de 10 000. Le service d'authentification a atteint la limite, a renvoyé des erreurs 429, et la tempête de tentatives des clients a amplifié la charge de 50 fois. J'ai déclaré un P1, établi le canal d'incident, assigné les rôles (responsable communication, responsables techniques pour l'authentification et l'infrastructure) et coordonné la réponse. La solution consistait à annuler le changement de configuration, mais nous avons également dû drainer le retard de tentatives en augmentant temporairement la capacité. L'analyse post-incident a identifié trois causes profondes : aucune validation des valeurs de configuration du limiteur de débit, aucun déploiement canari pour les changements de configuration, et aucun disjoncteur sur les tentatives des clients. Nous avons implémenté les trois corrections et ajouté un canari synthétique qui teste le flux d'authentification toutes les 30 secondes. L'incident a consommé 40 % de notre budget d'erreur trimestriel, ce qui a déclenché un gel du développement de nouvelles fonctionnalités jusqu'à ce que les améliorations de fiabilité soient livrées. »

2. Décrivez une situation où vous avez éliminé une source significative de toil.

Réponse d'expert : « Nos ingénieurs d'astreinte passaient en moyenne 6 heures par semaine à mettre à l'échelle manuellement les répliques de lecture de base de données lors des pics de trafic — ils surveillaient les tableaux de bord, se connectaient en SSH aux instances et exécutaient des scripts de mise à l'échelle. C'était du toil typique : manuel, répétitif, automatisable et évoluant linéairement avec la croissance du service. J'ai construit un contrôleur de mise à l'échelle automatique utilisant un opérateur Kubernetes personnalisé qui surveillait les métriques de CPU et de latence des requêtes, calculait le nombre de répliques nécessaires à l'aide d'un modèle prédictif basé sur les schémas de trafic historiques, et mettait à l'échelle les répliques automatiquement. J'ai ajouté des garde-fous : nombres minimum et maximum de répliques, périodes de refroidissement pour éviter l'instabilité, et alertes PagerDuty lorsque la mise à l'échelle automatique atteignait 80 % de la capacité maximale (signalant une croissance organique nécessitant un investissement en infrastructure). Après le déploiement, les interventions de mise à l'échelle manuelles sont passées de 6 heures/semaine à 0, et notre charge d'astreinte a diminué de 30 %. Le projet a également amélioré notre latence P99 des requêtes de 15 % parce que la mise à l'échelle automatisée réagissait plus rapidement que les humains. »

3. Donnez un exemple de situation où vous avez contesté une exigence de fiabilité que vous jugiez trop agressive.

Réponse d'expert : « Une équipe produit a demandé 99,999 % de disponibilité (cinq neuf) pour un nouveau service de notifications. J'ai calculé ce que cinq neuf signifient réellement : 5,26 minutes d'indisponibilité par an, ce qui nécessiterait un déploiement multi-régions actif-actif, un basculement automatisé en moins de 30 secondes, et essentiellement une tolérance zéro pour les changements de configuration sans déploiements canari. Le coût d'ingénierie était estimé à 6 mois et 400 000 $ d'infrastructure supplémentaire. J'ai alors demandé à l'équipe produit : "Que se passe-t-il pour les utilisateurs quand les notifications sont retardées de 5 minutes ?" La réponse était "rien — les notifications ne sont pas critiques en termes de temps." J'ai proposé 99,9 % de disponibilité (8,76 heures d'indisponibilité par an), ce que notre infrastructure existante pouvait atteindre avec des améliorations mineures. L'équipe produit a accepté après avoir vu la courbe coût-fiabilité. C'est la discipline SRE : la fiabilité est une fonctionnalité, et comme toutes les fonctionnalités, elle a un coût qui doit être justifié par l'impact utilisateur [2]. »

4. Parlez-moi d'une situation où vous avez amélioré la surveillance ou l'observabilité d'un service critique.

Réponse d'expert : « Notre service de paiement avait une surveillance qui ne suivait que les vérifications de santé basiques — les réponses HTTP 200 et l'utilisation du CPU. Après une défaillance silencieuse où le service renvoyait des 200 mais avec des données en cache périmées pendant 3 heures, j'ai repensé notre pile d'observabilité. J'ai défini des SLIs liés à l'expérience utilisateur : taux de réussite des paiements (objectif 99,95 %), latence de traitement des paiements au P99 (objectif 2 secondes), et fraîcheur des données (péremption du cache sous 60 secondes). Je les ai implémentés comme métriques Prometheus, créé des tableaux de bord Grafana avec des alertes de taux de consommation SLO (multi-fenêtre : 5 minutes pour la consommation rapide, 1 heure pour la consommation lente), et ajouté du traçage distribué avec Jaeger pour suivre les flux de paiement à travers 7 microservices. L'approche d'alerte multi-fenêtre a réduit les faux positifs de 60 % tout en détectant le type de défaillance silencieuse qui avait initialement motivé le projet. Nous sommes passés de "le service est-il actif ?" à "le service délivre-t-il de la valeur aux utilisateurs ?" »

5. Décrivez comment vous avez équilibré la vélocité de développement de fonctionnalités avec le travail de fiabilité.

Réponse d'expert : « J'ai implémenté une politique de budget d'erreur où le travail de fiabilité et le développement de fonctionnalités étaient gouvernés par la même métrique. Quand notre budget d'erreur mensuel était au-dessus de 50 %, l'équipe de développement avait pleine vélocité sur les fonctionnalités. Quand il descendait sous 50 %, nous répartissions 50/50 entre fonctionnalités et améliorations de fiabilité. En dessous de 25 %, tout l'effort d'ingénierie se déplaçait vers la fiabilité jusqu'à ce que le budget se rétablisse. Ce n'était pas une règle rigide — c'était un accord négocié entre SRE et l'équipe produit, documenté dans notre charte d'équipe. L'insight clé est que les budgets d'erreur rendent la fiabilité concrète : au lieu de débattre pour savoir si la fiabilité "compte", nous pouvions pointer des données montrant que nous avions consommé 80 % de notre budget d'erreur et devions investir dans la stabilité. Sur un an, cette approche a réduit notre taux d'incidents P1 de 45 % tandis que l'équipe produit livrait 12 % de fonctionnalités en plus que l'année précédente — parce qu'elle passait moins de temps en réponse aux incidents et en correctifs d'urgence. »

6. Comment abordez-vous les rotations d'astreinte, et comment avez-vous amélioré l'expérience d'astreinte pour votre équipe ?

Réponse d'expert : « Je considère l'astreinte comme un problème d'ingénierie, pas un problème de personnel. Quand j'ai rejoint l'équipe, les ingénieurs d'astreinte étaient alertés en moyenne 14 fois par semaine, avec 40 % des alertes non exploitables ou en doublon. J'ai implémenté trois changements. Premièrement, l'optimisation des alertes : j'ai revu chaque alerte sur 30 jours, supprimé les alertes qui ne s'étaient pas déclenchées ou qui étaient systématiquement non exploitables, et consolidé les alertes en doublon en utilisant le regroupement d'alertes dans PagerDuty. Deuxièmement, l'automatisation des runbooks : pour les 5 alertes exploitables les plus fréquentes, j'ai écrit des scripts de remédiation automatisés (déclenchés par les webhooks PagerDuty) qui géraient les actions de première réponse et n'alertaient un humain que si la remédiation automatique échouait. Troisièmement, les améliorations de passation d'astreinte : j'ai introduit un document de passation structuré (incidents ouverts, changements récents, risques connus) et une réunion de passation synchrone de 15 minutes entre l'astreinte sortante et entrante. Les alertes sont passées de 14/semaine à 4/semaine, et le score de satisfaction de l'enquête d'astreinte s'est amélioré de 2,1/5 à 4,3/5. »

Questions techniques

1. Expliquez les SLOs, SLIs et budgets d'erreur. Comment sont-ils liés ?

Réponse d'expert : « Un SLI (Service Level Indicator) est une métrique quantitative qui mesure un aspect spécifique de la qualité de service — par exemple, la proportion de requêtes HTTP qui reviennent avec succès dans les 200 ms. Un SLO (Service Level Objective) est une valeur cible pour un SLI — par exemple, 99,9 % des requêtes devraient réussir dans les 200 ms sur une fenêtre glissante de 30 jours. Le budget d'erreur est l'inverse du SLO : si votre SLO est 99,9 %, votre budget d'erreur est 0,1 % — vous pouvez tolérer 0,1 % de défaillances sur la fenêtre de mesure. Pour un service traitant 1 million de requêtes par jour, un SLO de 99,9 % signifie que vous pouvez vous permettre 1 000 défaillances par jour. Le budget d'erreur crée un langage commun entre les équipes SRE et produit : tant que vous êtes dans le budget, livrez des fonctionnalités de manière agressive. Quand le budget est consommé, investissez dans la fiabilité. Cela remplace les arguments subjectifs sur la fiabilité par des décisions objectives basées sur les données [2]. »

2. Concevez un système de surveillance et d'alerte pour une architecture microservices avec 50 services.

Réponse d'expert : « Je construirais le système en trois couches. Collecte de données : instrumenter chaque service avec des bibliothèques clientes Prometheus exportant des métriques RED (Rate, Errors, Duration) plus des métriques métier personnalisées. Utiliser une hiérarchie de fédération Prometheus — des instances Prometheus par cluster alimentant un Thanos ou Mimir central pour le stockage à long terme et les requêtes inter-clusters. Agrégation de logs via Loki ou Elasticsearch pour le logging structuré. Traçage distribué via Jaeger ou Tempo avec propagation de contexte à travers les 50 services. Alerte : définir des SLOs pour les parcours utilisateurs critiques de chaque service, pas seulement les points d'entrée individuels. Implémenter l'alerte multi-fenêtre sur le taux de consommation : une fenêtre de 5 minutes sur un seuil d'1 heure attrape les consommations rapides ; une fenêtre de 30 minutes sur un seuil de 6 heures attrape les consommations lentes. Router les alertes via PagerDuty avec routage par équipe et politiques d'escalade. Tableaux de bord : construire des tableaux de bord de signaux dorés par service (latence, trafic, erreurs, saturation), un tableau de bord SLO de niveau supérieur montrant la consommation de budget des 50 services, et des cartes de dépendances de services générées à partir des données de traçage. Principes de conception critiques : alerter sur les symptômes (impact utilisateur), pas les causes (CPU élevé), et s'assurer que chaque alerte a un runbook lié dans les métadonnées de l'alerte. »

3. Un service répond lentement. Guidez-moi à travers votre approche de dépannage.

Réponse d'expert : « Je commence par l'impact utilisateur : quelle est la latence P50/P99 par rapport à la normale, et quel pourcentage d'utilisateurs est affecté ? Ensuite je suis la méthode USE (Utilization, Saturation, Errors) et la méthode RED (Rate, Errors, Duration) systématiquement. Premièrement, vérifier le service lui-même : CPU, mémoire, pauses GC (pour les services JVM), saturation du pool de threads, épuisement du pool de connexions. Deuxièmement, vérifier les dépendances en aval : latence des requêtes de base de données (requêtes lentes ? contention de verrous ? index manquant ?), taux de hits du cache (le cache a-t-il démarré à froid ou évincé des clés chaudes ?), latence d'API externe (un service tiers est-il dégradé ?). Troisièmement, vérifier le réseau : y a-t-il des pertes de paquets, des délais de résolution DNS, ou un overhead de handshake TLS ? J'utilise le traçage distribué pour identifier quel span dans le chemin de requête contribue le plus à la latence — cela localise le goulot d'étranglement dans le système distribué. S'il s'agit d'une dégradation graduelle, je vérifie les fuites de ressources (mémoire, connexions, descripteurs de fichiers) ou la croissance du trafic dépassant la capacité. Si c'est soudain, je vérifie les déploiements récents, les changements de configuration, ou les changements de schémas de trafic en amont. »

4. Comment concevriez-vous un système pour atteindre 99,99 % de disponibilité sur plusieurs régions ?

Réponse d'expert : « 99,99 % de disponibilité autorise 52,6 minutes d'indisponibilité par an, ce qui signifie que chaque composant doit être soit redondant, soit tomber en panne indépendamment. Architecture : déploiement actif-actif sur au moins 3 régions (pas actif-passif, qui gaspille de la capacité et introduit des risques de basculement). Équilibrage de charge global (Cloudflare, AWS Global Accelerator) avec redirection du trafic pilotée par les vérifications de santé — si une région échoue aux vérifications de santé, le trafic se redirige automatiquement vers les régions saines en 30 secondes. Couche de données : réplication synchrone au sein des régions pour la cohérence, réplication asynchrone entre régions avec résolution de conflits (CRDTs ou last-writer-wins selon le modèle de données). Accepter que les écritures inter-régions ont un overhead de latence. Déploiement : déploiements canari par région — déployer dans une région, observer pendant 30 minutes, puis déployer dans les régions restantes. Cela empêche un mauvais déploiement de mettre hors service toutes les régions simultanément. Modes de défaillance à prévoir : défaillance d'une seule région, basculement du primaire de base de données, délais de propagation DNS, expiration de certificats et défaillances de dépendances. Tests : chaos engineering régulier — injecter des défaillances mensuellement avec des outils comme Gremlin ou Litmus pour vérifier que le basculement fonctionne comme conçu, pas seulement comme documenté. »

5. Quelle est la différence entre la mise à l'échelle horizontale et verticale, et quand préférez-vous chacune ?

Réponse d'expert : « La mise à l'échelle verticale augmente les ressources d'une seule instance (plus de CPU, RAM, disque plus rapide). La mise à l'échelle horizontale ajoute plus d'instances derrière un répartiteur de charge. Je préfère la mise à l'échelle horizontale pour les services sans état (serveurs web, serveurs API, workers) parce qu'elle offre une croissance de capacité linéaire, une tolérance aux pannes (perdre une instance est mineur), et un alignement avec les schémas d'infrastructure cloud. J'utilise la mise à l'échelle verticale pour les composants avec état où la mise à l'échelle horizontale introduit de la complexité — un primaire de base de données qui a besoin de plus de mémoire pour son ensemble de travail, ou un pipeline de traitement mono-thread qui est limité par le CPU. La décision pratique dépend de trois facteurs : la gestion de l'état (les services avec état sont plus difficiles à mettre à l'échelle horizontalement), l'efficacité des coûts (la mise à l'échelle verticale atteint des rendements décroissants et des plafonds matériels), et le rayon d'impact des défaillances (une grande instance qui tombe est catastrophique ; une instance sur vingt qui tombe est gérable). En production, je combine typiquement les deux : mettre à l'échelle verticalement la base de données à la plus grande instance pratique, puis mettre à l'échelle horizontalement avec des répliques de lecture pour les charges de travail intensives en lecture. »

6. Expliquez l'Infrastructure as Code (IaC) et comment vous l'avez utilisée pour améliorer la fiabilité.

Réponse d'expert : « L'Infrastructure as Code traite la configuration d'infrastructure comme du logiciel : versionnée, revue, testée et reproductible. J'utilise Terraform pour le provisionnement des ressources cloud (VPCs, bases de données, répartiteurs de charge, politiques IAM) et Ansible ou Puppet pour la gestion de configuration au sein des instances. Avantages pour la fiabilité : reproductibilité (je peux reconstruire n'importe quel environnement à partir du code en minutes, éliminant les serveurs uniques), auditabilité (git log montre qui a changé quoi, quand et pourquoi), et testabilité (j'exécute terraform plan dans la CI pour détecter les changements cassants avant l'application, et j'utilise Terratest pour les tests d'intégration des modules d'infrastructure). Un exemple concret : quand notre environnement de staging avait dérivé de la production et qu'un changement testé en staging a causé un incident en production, j'ai reconstruit les deux environnements à partir des mêmes modules Terraform avec des variables spécifiques à l'environnement. La dérive est devenue impossible parce que le code est la source unique de vérité. J'ai également implémenté des politiques Sentinel dans Terraform Cloud pour appliquer des garde-fous de sécurité — pas de buckets S3 publics, pas de groupes de sécurité avec 0.0.0.0/0 en entrée. »

7. Comment abordez-vous la planification de capacité pour un service en croissance rapide ?

Réponse d'expert : « J'utilise un cadre en quatre étapes. Premièrement, établir un modèle de charge : identifier les principaux facteurs de ressources (requêtes par seconde, connexions simultanées, volume de données) et les corréler avec les métriques d'infrastructure (CPU, mémoire, E/S disque, bande passante réseau). Cela me donne un coût par "unité de travail" — par exemple, "chaque requête API consomme 2 ms de CPU et 0,5 Mo de mémoire." Deuxièmement, modéliser la croissance : utiliser les données historiques pour projeter la croissance du trafic (linéaire, exponentielle, saisonnière). Pour un service en croissance rapide, je projette au moins 6 mois à l'avance et applique un facteur de sécurité de 2x. Troisièmement, identifier les ressources goulots d'étranglement : la ressource qui atteint sa capacité en premier détermine votre déclencheur de mise à l'échelle — ce pourrait être le CPU sur les nœuds de calcul, les IOPS sur la base de données, ou la bande passante sur le réseau. Quatrièmement, automatiser la réponse : implémenter la mise à l'échelle automatique pour les ressources élastiques (calcul, caches) et établir un approvisionnement tenant compte des délais pour les ressources non élastiques (mises à niveau d'instances de base de données, capacité réservée). Je revois les plans de capacité mensuellement, comparant les projections aux réalités, et ajuste le modèle quand la croissance réelle dévie de plus de 20 % par rapport à la projection. »

Questions situationnelles

1. Le budget d'erreur de votre service est épuisé avec deux semaines restantes dans le trimestre. L'équipe produit veut livrer une fonctionnalité majeure. Que faites-vous ?

Réponse d'expert : « Selon notre politique de budget d'erreur, l'épuisement du budget déclenche un gel de fiabilité — aucun déploiement de fonctionnalités jusqu'à ce que le budget se rétablisse ou que le trimestre se réinitialise. Je présenterais les données à l'équipe produit : "Notre SLO est de 99,9 %, et nous avons consommé 100 % de notre budget d'erreur avec 14 jours restants. Déployer une fonctionnalité majeure introduit un risque de déploiement qui pourrait nous pousser davantage dans la violation de SLO." J'offrirais des alternatives : pouvons-nous déployer la fonctionnalité derrière un feature flag avec un déploiement graduel (1 % -> 10 % -> 100 %) pour minimiser le rayon d'impact ? Pouvons-nous prioriser une amélioration de fiabilité spécifique qui rétablirait le budget plus rapidement ? Y a-t-il un moyen de déployer d'abord dans un sous-ensemble de régions ? La politique de budget d'erreur existe précisément pour cette situation — sans elle, nous négocierions au cas par cas, ce qui sape tout le cadre SLO. Mais je serais aussi flexible : si la fonctionnalité est critique pour le revenu et que la violation de SLO est mineure, la direction pourrait accepter le risque avec une visibilité complète sur le compromis [2]. »

2. Le changement d'un ingénieur junior a causé un incident de production. Comment gérez-vous l'analyse post-incident ?

Réponse d'expert : « Le principe fondamental est l'absence de blâme — l'analyse post-incident examine ce qui s'est passé et pourquoi le système l'a permis, jamais qui est en faute [2]. Je dirigerais l'analyse post-incident en établissant les faits chronologiques : quel changement a été fait, quand, quel a été l'impact immédiat, quand a-t-il été détecté, comment a-t-il été résolu ? Ensuite je me concentrerais sur les causes systémiques : pourquoi le processus de gestion des changements a-t-il permis un changement dangereux ? Y avait-il une revue de code insuffisante, des tests automatisés manquants, un déploiement canari inadéquat, ou un manque de capacité de retour en arrière ? Les actions doivent améliorer le système, pas punir l'ingénieur : ajouter une validation automatisée qui aurait détecté l'erreur, améliorer la parité de l'environnement de staging pour que le problème aurait fait surface avant la production, ajouter une surveillance qui détecte le mode de défaillance plus rapidement. J'indiquerais explicitement dans le document d'analyse post-incident : "L'ingénieur a suivi le processus documenté. Le processus était insuffisant, et ces améliorations préviendront la récurrence." Une culture de blâme pousse les ingénieurs à cacher les erreurs ; une culture sans blâme pousse les ingénieurs à les signaler et les corriger. »

3. Vous héritez d'un système legacy sans surveillance, sans documentation et sans tests. Par où commencez-vous ?

Réponse d'expert : « Je prioriserais par rayon d'impact. Semaine 1 : ajouter une surveillance de santé basique — le service répond-il ? Quel est le taux d'erreur ? Quelle est l'utilisation des ressources ? Je déploierais un exporteur Prometheus pour les métriques système et instrumenterais les points d'entrée pour les métriques au niveau des requêtes. Cela me donne de la visibilité avant de toucher à quoi que ce soit. Semaine 2-4 : documenter l'architecture du système en lisant le code, en traçant les flux de requêtes et en cartographiant les dépendances. Je créerais un graphe de dépendances montrant avec quoi le système communique et ce qui communique avec lui. Mois 2 : ajouter des tests d'intégration pour le chemin critique — le seul parcours utilisateur qui, s'il est cassé, génèrerait une alerte. Cela me donne un filet de sécurité pour les changements futurs. Mois 3 : implémenter CI/CD pour que les changements passent par des tests automatisés et un déploiement par étapes plutôt que du SSH-et-déploiement manuel. Tout au long, je suivrais le toil : quelles opérations manuelles ce système nécessite-t-il ? Cela informe la priorisation du travail d'automatisation. Le principe clé est : ne pas réécrire, stabiliser. Un système legacy qui tourne depuis des années a survécu à d'innombrables cas limites — le remplacer introduit de nouveaux risques. »

4. Votre surveillance montre une fuite de mémoire lente en production. Le service plante et redémarre toutes les 72 heures. Comment abordez-vous cela ?

Réponse d'expert : « D'abord, je quantifierais l'impact : les redémarrages causent-ils des erreurs visibles pour les utilisateurs ? Si le redémarrage est gracieux (drainage des connexions, le répartiteur de charge marque l'instance comme non saine avant le plantage), l'impact utilisateur immédiat pourrait être minimal. S'il est non gracieux (kill OOM, connexions abandonnées), c'est un P2 qui nécessite une attention rapide. Pour l'investigation : j'activerais le profilage de tas (pprof pour Go, JVisualVM pour Java, memory_profiler pour Python) sur une instance de production avec un trafic réduit. Je prendrais des instantanés de tas à intervalles réguliers (toutes les heures) et comparerais les comptages et tailles d'objets pour identifier quels types d'objets croissent. Causes courantes : mise en cache sans éviction, fuites de goroutines/threads, épuisement du pool de connexions sans nettoyage approprié, ou accumulation d'écouteurs d'événements. Pour l'atténuation à court terme, je mettrais en place un CronJob ou une sonde de vivacité qui redémarre gracieusement le service toutes les 48 heures pendant les fenêtres de trafic faible — gagnant du temps pendant que la cause profonde est investiguée. Pour la correction à long terme, une fois le type d'objet qui fuit identifié, je corrigerais la cause profonde, ajouterais un SLI d'utilisation mémoire à notre surveillance, et créerais une alerte quand le taux de croissance de la mémoire dépasse les normes historiques. »

5. La direction vous demande de réduire les coûts d'infrastructure de 30 % tout en maintenant les niveaux de fiabilité actuels. Comment abordez-vous cela ?

Réponse d'expert : « J'identifierais les opportunités de réduction des coûts dans quatre catégories. Dimensionnement correct : auditer les types d'instances par rapport à l'utilisation réelle — d'après mon expérience, 40-60 % des instances cloud sont surdimensionnées. Utiliser les recommandations des fournisseurs cloud (AWS Compute Optimizer, GCP Recommender) et valider avec les données réelles d'utilisation CPU/mémoire. Capacité réservée : convertir les charges de travail de base prévisibles du à la demande vers des instances réservées ou des plans d'économie (typiquement 30-50 % d'économies). Instances spot/préemptives : identifier les charges de travail tolérantes aux pannes (traitement par lots, runners CI/CD, workers sans état) qui peuvent tolérer l'interruption et les déplacer vers la tarification spot (60-90 % d'économies). Optimisation d'architecture : identifier et éliminer le gaspillage — ressources inutilisées, données sur-répliquées, logging coûteux que personne ne lit, et environnements de développement tournant 24/7 qui pourraient être éteints les nuits et weekends. Je présenterais chaque initiative avec les économies projetées, l'effort d'implémentation et le risque de fiabilité. La contrainte est claire : la fiabilité n'est pas négociable. La réduction des coûts vient de l'efficacité, pas de la suppression de la redondance ou de la dégradation de la qualité de service. »

Questions à poser au recruteur

1. Quels sont les SLOs pour les services que cette équipe gère, et comment les budgets d'erreur sont-ils gérés ? Révèle si l'équipe pratique les principes SRE ou utilise juste le titre.

2. À quoi ressemble la rotation d'astreinte — combien d'ingénieurs, quel est le volume d'alertes, et quelle est la politique d'escalade ? Impacte directement votre qualité de vie et indique la santé opérationnelle de l'équipe.

3. Comment l'équipe équilibre-t-elle le travail de projet (améliorations de fiabilité) avec le travail opérationnel (réponse aux incidents, toil) ? Montre si l'équipe a la capacité pour du travail d'ingénierie ou est coincée en mode pompier.

4. Quelle est la relation de l'équipe avec les équipes de développement — le SRE est-il intégré ou centralisé ? Détermine votre modèle de collaboration quotidien et votre influence.

5. Quelle est l'approche de l'équipe en matière d'analyses post-incident — sont-elles sans blâme, et quel pourcentage des actions est complété ? Révèle la culture d'apprentissage des incidents de l'équipe — une équipe qui écrit des analyses post-incident mais ne complète jamais les actions a un problème de culture.

6. Quelle infrastructure et quels outils l'équipe gère-t-elle — fournisseurs cloud, orchestration de conteneurs, pile d'observabilité ? Question pratique sur l'environnement technique.

7. Quels sont les plus grands défis de fiabilité auxquels l'équipe fait face actuellement ? Donne un aperçu des problèmes que vous résoudriez et s'ils sont intéressants.

Format de l'entretien et à quoi s'attendre

Les entretiens SRE dans les grandes entreprises technologiques s'étendent typiquement sur 4-6 heures dans un cycle complet [3]. Le tour de programmation teste la maîtrise de Python/Go/Java avec des problèmes axés sur l'automatisation, le traitement de données ou l'outillage système — attendez-vous à des problèmes comme « écrire un parseur de logs qui identifie les schémas d'erreur » plutôt que du LeetCode pur. Le tour de conception de systèmes vous demande de concevoir des systèmes distribués avec des contraintes de fiabilité explicites — « concevez un raccourcisseur d'URL qui sert 99,99 % des requêtes en moins de 100 ms. » Le tour de dépannage présente un scénario de production (dégradation de service, défaillance en cascade, alertes mystérieuses) et évalue votre méthodologie diagnostique. Le tour comportemental évalue l'expérience d'astreinte, la gestion d'incidents, la collaboration inter-équipes et la réduction du toil. Certaines entreprises ajoutent un tour de fondamentaux Linux/réseau couvrant des sujets comme la gestion des processus, les opérations sur le système de fichiers, TCP/IP et la résolution DNS. Le processus complet du screening recruteur à l'offre prend typiquement 3-6 semaines.

Comment se préparer

• Étudiez le livre Google SRE. Les chapitres sur les SLOs, les budgets d'erreur, le toil et la gestion d'incidents sont fondamentaux et fréquemment référencés dans les entretiens [2].
• Pratiquez la conception de systèmes avec des contraintes de fiabilité. Concevez des systèmes avec des objectifs de disponibilité explicites, des modes de défaillance et des stratégies de dégradation gracieuse.
• Préparez des récits d'incidents. Ayez 3-5 récits d'incidents détaillés avec votre rôle, la chronologie, la cause profonde, la résolution et les améliorations systémiques.
• Révisez les fondamentaux Linux. Gestion des processus, opérations sur le système de fichiers, commandes réseau (ss, tcpdump, dig, traceroute), et outils de performance système (top, vmstat, iostat, sar).
• Pratiquez la programmation pour l'automatisation. Écrivez des scripts qui parsent des logs, interagissent avec des APIs, gèrent l'état d'infrastructure et gèrent gracieusement les cas d'erreur.
• Connaissez votre pile d'observabilité. Soyez prêt à discuter de Prometheus, Grafana, Jaeger/Tempo, ELK/Loki, PagerDuty, et comment vous les avez utilisés en production.

Erreurs courantes en entretien

1. Concevoir pour l'échelle sans concevoir pour la défaillance. Les entretiens SRE testent spécifiquement comment votre système gère la défaillance — décrire un système qui « suppose que tout fonctionne » est un signal d'alerte [2].
2. Ne pas quantifier la fiabilité. Dire « le système devrait être hautement disponible » au lieu de « le système devrait atteindre un SLO de disponibilité de 99,95 % mesuré par le taux de requêtes réussies » montre que vous n'avez pas intériorisé les principes SRE.
3. Traiter les incidents comme des problèmes purement techniques. Ne pas discuter de la communication, de la coordination et des processus d'analyse post-incident lors des récits d'incidents suggère que vous manquez d'expérience en gestion d'incidents.
4. Ignorer le toil. Les entretiens SRE demandent fréquemment des exemples de réduction du toil. Ne pas avoir d'exemples de travail opérationnel manuel que vous avez automatisé est une lacune.
5. Sur-ingénierer les solutions. Proposer une architecture cinq-neuf pour un service non critique démontre un mauvais jugement. Le SRE porte sur la fiabilité appropriée, pas la fiabilité maximale [2].
6. Ne pas comprendre le modèle de budget d'erreur. Si vous ne pouvez pas expliquer comment les budgets d'erreur créent l'alignement entre les équipes SRE et produit, vous n'avez pas étudié le cadre SRE.
7. Ne pas démontrer de capacité en programmation. Les SREs sont des ingénieurs, pas des opérateurs. Avoir du mal avec un problème de programmation signale que vous pourriez ne pas être capable de construire l'automatisation et l'outillage qui définissent le rôle [3].

Points clés

• Les entretiens SRE testent un état d'esprit d'ingénierie spécifique : quantifier la fiabilité, faire des compromis basés sur les données, et traiter l'exploitation comme des problèmes d'ingénierie logicielle.
• Les SLOs, SLIs, budgets d'erreur et le toil sont le vocabulaire du SRE — utilisez-les couramment et démontrez une expérience pratique avec chacun.
• Préparez des récits d'incidents détaillés qui mettent en valeur votre méthodologie diagnostique, vos compétences en communication et votre réflexion sur les améliorations systémiques.
• Les réponses de conception de systèmes doivent inclure des modes de défaillance explicites, des stratégies de dégradation gracieuse et des objectifs de disponibilité.

Vous voulez vous assurer que votre CV vous amène jusqu'à l'entretien ? Essayez le vérificateur de score ATS gratuit de ResumeGeni pour optimiser votre CV de Site Reliability Engineer avant de postuler.

FAQ

Quelle est la différence entre SRE et DevOps ?

SRE est une implémentation spécifique des principes DevOps avec des pratiques prescriptives : SLOs, budgets d'erreur, budgets de toil, et un modèle d'engagement défini avec les équipes de développement. DevOps est un mouvement culturel plus large mettant l'accent sur la collaboration entre développement et exploitation. SRE fournit le cadre concret — SLOs, budgets d'erreur, et la règle de 50 % de temps d'ingénierie — qui rend les principes DevOps actionnables. Beaucoup d'entreprises utilisent les termes de manière interchangeable, mais dans les entretiens chez les entreprises qui pratiquent SRE formellement (Google, LinkedIn, Dropbox), la distinction compte [2].

Quels langages de programmation devrais-je connaître pour les entretiens SRE ?

Python et Go sont les langages les plus couramment utilisés en SRE. Python pour le scripting, l'automatisation et l'outillage opérationnel. Go pour l'outillage système critique en performance (beaucoup d'outils de l'écosystème Kubernetes, Prometheus et les outils d'infrastructure internes sont écrits en Go). Certaines entreprises utilisent Java ou Ruby. Vous devriez maîtriser au moins un langage compilé et un langage de scripting [3].

Quel salaire devrais-je attendre en tant que Site Reliability Engineer ?

Les salaires vont de 128 842 $ (moyenne PayScale) à 169 680 $ (moyenne Glassdoor), avec le 75e percentile à 213 272 $ [1]. Les SREs seniors dans les entreprises FAANG peuvent gagner 300 000-500 000 $+ en incluant la compensation en actions. La rémunération varie selon le niveau de l'entreprise, la localisation et la spécialisation. Le SRE commande typiquement une prime de 10-20 % par rapport aux rôles d'ingénierie logicielle générale dans la même entreprise.

Quelle est l'importance du livre Google SRE pour la préparation aux entretiens ?

Très importante. Le livre Google SRE (« Site Reliability Engineering: How Google Runs Production Systems ») définit les concepts que la plupart des entretiens SRE testent : SLOs, budgets d'erreur, toil, gestion d'incidents et le modèle d'engagement SRE [2]. Même si vous passez un entretien dans une entreprise qui ne suit pas exactement les pratiques de Google, le livre fournit le vocabulaire et les cadres que les recruteurs utilisent.

Ai-je besoin d'expérience d'astreinte pour obtenir un rôle SRE ?

L'expérience d'astreinte est fortement préférée mais pas toujours requise pour les postes SRE de niveau débutant. Si vous n'avez pas d'expérience formelle d'astreinte, démontrez des compétences équivalentes : des systèmes de surveillance que vous avez construits, des incidents auxquels vous avez répondu (même dans des environnements de staging ou de développement), et de l'automatisation que vous avez créée pour réduire les opérations manuelles. Montrez que vous comprenez la réalité opérationnelle de l'exploitation de systèmes en production.

Quelles certifications sont utiles pour les entretiens SRE ?

Google Cloud Professional Cloud DevOps Engineer, AWS DevOps Engineer Professional et Certified Kubernetes Administrator (CKA) sont les certifications les plus pertinentes. Cependant, les entretiens SRE dans les entreprises de premier plan accordent beaucoup plus de poids à l'expérience pratique et à la capacité de résolution de problèmes qu'aux certifications. Les certifications peuvent vous aider à passer le filtrage de CV, mais elles ne vous porteront pas à travers un entretien technique.

En quoi un entretien SRE diffère-t-il d'un entretien d'ingénierie logicielle ?

Les entretiens SRE incluent la conception de systèmes avec des contraintes de fiabilité explicites (SLOs, modes de défaillance, dégradation gracieuse), des tours de dépannage (diagnostic de scénarios de production), et des questions comportementales sur la gestion d'incidents et l'expérience d'astreinte. Les entretiens d'ingénierie logicielle se concentrent davantage sur la programmation algorithmique, la conception de systèmes au niveau applicatif et la réflexion produit. Les questions de programmation SRE tendent à être plus pratiques et orientées automatisation que les problèmes d'algorithmes purs [3].

Citations : [1] Glassdoor, "Site Reliability Engineer: Average Salary & Pay Trends 2026," https://www.glassdoor.com/Salaries/site-reliability-engineer-salary-SRCH_KO0,25.htm [2] Google, "Site Reliability Engineering: How Google Runs Production Systems," https://sre.google/sre-book/table-of-contents/ [3] InterviewBit, "SRE (Site Reliability Engineer) Interview Questions (2025)," https://www.interviewbit.com/sre-interview-questions/ [4] Exponent, "Site Reliability Engineer Interview Questions Explained (Updated 2026)," https://www.tryexponent.com/questions?role=sre [5] Wiz, "Site Reliability Engineer Interview Questions Explained," https://www.wiz.io/academy/cloud-careers/site-reliability-engineer-interview-questions [6] NovelVista, "50 Site Reliability Engineer (SRE) Interview Questions 2026," https://www.novelvista.com/blogs/devops/top-sre-interview-question-answer [7] MindMajix, "Top 50 Site Reliability Engineer (SRE) Interview Questions 2025," https://mindmajix.com/sre-interview-questions [8] Coursera, "Site Reliability Engineer Salary Guide 2026," https://www.coursera.org/articles/site-reliability-engineer-salary