Décrivez votre pire incident de production et les 30 premières minutes.

Question

IT Interview Practice · Accepted Answer

**Une bonne réponse montre comment vous avez réduit l’impact client, décidé malgré des informations incomplètes et empêché une récidive.** Expliquez votre rôle personnel sans vous attribuer tout le travail de l’équipe.

Choisissez un incident réellement vécu. Le scénario suivant est fictif et illustre la structure ; en entretien, remplacez-le par vos actions réelles et des résultats vérifiés. Les périodes indiquées sont des exemples, pas des délais universels de réponse aux incidents.

## 1. Présenter la situation et votre responsabilité

Supposons que je sois responsable backend d’astreinte lorsque les échecs de commande augmentent peu après un déploiement. Les clients peuvent consulter les produits, mais certains ne peuvent plus commander. À ce stade, la proximité temporelle fait du déploiement une hypothèse, pas une cause démontrée.

J’expliquerais ma responsabilité : coordonner le rétablissement technique, répartir l’enquête et informer le responsable d’incident. Si je dirigeais également l’incident, je le préciserais et déléguerais la communication ou l’investigation pour ne pas devenir un point de blocage.

## 2. Cinq premières minutes : confirmer l’impact et organiser la réponse

Examinez erreurs de commande, latence et commandes réussies pour identifier les clients touchés et confirmer que le problème continue. Ouvrez un canal unique, attribuez les responsabilités, suspendez les changements sans rapport et commencez une chronologie des observations et actions.

Cette organisation a une raison pratique : des modifications indépendantes par plusieurs personnes peuvent masquer la cause ou aggraver l’incident. Chaque point de situation doit séparer faits confirmés et hypothèses, puis annoncer la prochaine mise à jour. Voir les [conseils Google sur la réponse aux incidents](https://sre.google/workbook/incident-response/).

## 3. Dix minutes suivantes : choisir une réduction sûre de l’impact

Supposons que l’enquête révèle une saturation des connexions à la base et un nouveau chemin de génération de rapports coûteux. Je comparerais un retour arrière à la désactivation temporaire de ce chemin, tout en préservant les commandes.

- Vérifier la compatibilité du retour arrière avec les changements de schéma ou de données déjà appliqués. L’ancienne application n’est pas automatiquement compatible avec la base actuelle.
- Si un mécanisme testé permet de désactiver les rapports facultatifs, l’utiliser pour réduire la charge et observer l’amélioration des commandes.
- Confier la pression sur les connexions à une personne et la vérification du rétablissement à une autre, afin de poursuivre l’enquête sans retarder une mesure raisonnable.

La décision doit suivre les preuves disponibles et la possibilité de revenir en arrière. Je n’attendrais pas une certitude complète sur la cause pendant que les clients restent bloqués, mais je noterais pourquoi l’action choisie devait aider.

## 4. Jusqu’à trente minutes : vérifier le retour d’un service utile

Une baisse du CPU ne suffit pas. Confirmez que de vraies commandes aboutissent, que la latence redevient acceptable et que le travail en attente se résorbe sans créer une nouvelle pression. Continuez à observer après la mesure au lieu d’annoncer le rétablissement après une seule requête réussie.

Pour les paiements au résultat ambigu, rapprochez les informations du système de paiement avant de relancer une facturation. Un délai dépassé peut masquer un paiement effectué. Communiquez ce qui fonctionne, ce qui reste incertain et les actions attendues des clients, sans inventer une heure de rétablissement non étayée.

## 5. Après le rétablissement : modifier les conditions de la panne

Dans ce scénario fictif, l’enquête pourrait montrer que rapports et commandes partageaient un budget de connexions et que les rapports n’avaient aucune limite de travail efficace. Les suites doivent traiter ce mécanisme, et pas se limiter à « faire plus attention ».

- Borner le travail et la concurrence des rapports pour éviter qu’une fonctionnalité consomme toute la ressource partagée.
- Évaluer l’isolation des ressources et tester rapports et commandes ensemble sous charge représentative.
- Alerter sur la réussite et la latence des commandes, puis répéter la procédure d’atténuation ou de retour arrière.
- Donner à chaque correction un responsable, une échéance et un moyen de vérifier sa réalisation.

En entretien réel, terminez par le résultat effectivement obtenu et les preuves issues des tests ou de l’exploitation ultérieure. Si une mesure manque, dites-le plutôt que d’inventer un chiffre impressionnant. La leçon doit se rattacher directement à un changement que vous avez aidé à livrer et à vérifier.

1. Présenter la situation et votre responsabilité

2. Cinq premières minutes : confirmer l’impact et organiser la réponse

3. Dix minutes suivantes : choisir une réduction sûre de l’impact

4. Jusqu’à trente minutes : vérifier le retour d’un service utile

5. Après le rétablissement : modifier les conditions de la panne

Questions connexes