Un changement de votre équipe met la production à terre. Racontez-moi ce qui se passe ensuite.

Rétablir le service d'abord, enquêter ensuite. Mettez en place la mitigation sûre la plus rapide, en général un rollback sauf si revenir en arrière est plus risqué, gardez un commandant d'incident clair et un responsable de la communication distinct, et évitez à l'ingénieur concerné d'avoir à corriger et à expliquer en même temps. Ensuite, menez une rétrospective sans blâme qui cherche les faiblesses du système (garde-fous manquants, chemin de déploiement non sécurisé, tests trop légers) plutôt que la personne.

La mitigation d'abord. La seule question dans les cinq premières minutes, c'est quel est le moyen sûr le plus rapide de revenir à un état qui fonctionne, et c'est en général un rollback plutôt qu'un correctif inspiré sous pression. Je m'assure que quelqu'un est commandant d'incident et que quelqu'un d'autre porte la communication, parce que les pires incidents que j'ai vus étaient ceux où la personne qui tapait répondait aussi au dirigeant qui rejoignait l'appel toutes les dix minutes. Si l'ingénieur qui a livré le changement est le mieux placé pour le corriger, il le corrige, et je lui enlève toutes les autres conversations. Une fois que c'est stable, la rétrospective porte sur le système. Quand c'est arrivé dans mon équipe, un changement de configuration avait contourné la préproduction parce que le chemin de déploiement le permettait. L'ingénieur était le dernier domino, pas la cause. Les actions ont été un garde-fou sur ce chemin, un test pour cette défaillance précise, et de meilleures alertes, chacune avec un nom et une date. Et je dis à voix haute dans la rétrospective que le changement était raisonnable au vu des informations disponibles, parce que toute l'équipe regarde comment cette personne est traitée.