La moitié de vos services se mettent à expirer en même temps et rien n'a été déployé. Comment menez-vous cet incident ?

Déclarez l'incident, nommez un commandant d'incident, et séparez l'investigation de la communication. Puis traquez la dépendance partagée : authentification, DNS, une base de données, un certificat, le plan de contrôle du service mesh, ou une zone cloud. Regardez ce qui a changé en dehors des déploiements, c'est-à-dire les poussées de configuration, les feature flags, les enregistrements DNS, les certificats expirés et l'état du fournisseur. Atténuez avant de diagnostiquer en délestant, en basculant ou en désactivant le flag suspect, puis vérifiez avec les SLI vus par l'utilisateur.

Large et simultané sans déploiement, ce ne sont presque jamais dix bugs indépendants, c'est une seule chose en dessous de tous. Donc je monte la structure d'incident immédiatement, un commandant et une personne à la communication, puis j'attaque la liste des couches partagées : service d'authentification, DNS, base de données principale, plan de contrôle du mesh, certificats, et état du fournisseur cloud. En parallèle, je demande ce qui a changé et qui n'est pas du code, parce que les poussées de configuration et les feature flags sont des changements que les gens oublient de compter. On a eu exactement ce motif une fois, et il s'est avéré que c'était un renouvellement d'autorité de certification interne qui avait discrètement laissé expirer un intermédiaire, si bien que toutes les poignées de main TLS mutuelles ont commencé à échouer à la même minute. L'indice, c'était que les échecs étaient au niveau connexion et pas au niveau applicatif. Pendant que cette investigation tourne, je veux un levier d'atténuation prêt, en général délester le trafic non essentiel ou basculer sur la région secondaire, parce que je préfère être dégradé et stable que complètement cassé pendant qu'on réfléchit. Ensuite je vérifie avec de vraies métriques utilisateur, pas juste des pods verts.