Un déploiement est parti il y a une heure et le taux d'erreurs grimpe depuis. Que faites-vous ?

Revenez en arrière d'abord et enquêtez ensuite, sauf si le déploiement contenait une migration de base de données qui rend le retour arrière dangereux. Confirmez que la chronologie colle au déploiement, vérifiez si les erreurs se concentrent sur les instances de la nouvelle version, puis revenez à l'artefact précédent ou rebasculez le trafic. Une fois le taux d'erreurs redescendu, gardez le build fautif disponible dans un environnement de staging pour pouvoir diagnostiquer sans que les utilisateurs en paient le prix.

Par défaut, retour arrière. Une heure d'erreurs qui montent, ce n'est pas un mystère à résoudre en direct, c'est une hémorragie à arrêter, et l'artefact précédent est connu comme bon. Avant d'appuyer sur le bouton je fais deux vérifications rapides. Un, est-ce que la courbe d'erreurs démarre vraiment à l'heure du déploiement, ou est-ce qu'elle montait déjà avant, parce que si ça a commencé plus tôt le déploiement est une coïncidence et revenir en arrière fait perdre dix minutes. Deux, est-ce que cette release contenait une migration de schéma, parce que si oui il faut que je sache si l'ancien code fonctionne encore avec le nouveau schéma. Si on a fait expand and contract correctement, oui, et le retour arrière est sûr. Si quelqu'un a supprimé une colonne, le retour arrière devient l'option dangereuse et je pars sur un correctif en avant ou un feature flag. Une fois les erreurs redescendues, je garde le mauvais build déployé en staging pour qu'on puisse reproduire sans impliquer les clients. Après coup, la question sur laquelle j'insisterais, c'est pourquoi un canary n'a pas attrapé ça, parce qu'une heure d'impact veut dire que le déploiement ne surveillait pas le taux d'erreur par rapport à une référence.