Eine Änderung deines Teams legt Produktion lahm. Erklär mir, was als Nächstes passiert.

Erst den Service wiederherstellen, dann untersuchen. Bring die schnellste sichere Mitigation rein, meist ein Rollback, außer der Rollback ist riskanter, halt einen klaren Incident Commander und einen separaten Kommunikationsverantwortlichen, und schütz den beteiligten Engineer davor, gleichzeitig fixen und erklären zu müssen. Danach eine schuldfreie Nachbetrachtung, die die Systemschwächen findet (fehlende Leitplanken, unsicherer Deploy-Pfad, dünne Tests) statt die Person.

Mitigation zuerst. Die einzige Frage in den ersten fünf Minuten ist, was der schnellste sichere Weg zurück in einen funktionierenden Zustand ist, und das ist meist ein Rollback statt eines genialen Fixes unter Druck. Ich sorge dafür, dass jemand Incident Commander ist und jemand anderes die Kommunikation verantwortet, denn die schlimmsten Incidents, die ich gesehen habe, waren die, in denen die tippende Person gleichzeitig der Führungskraft antwortete, die immer wieder in den Call kam. Wenn der Engineer, der die Änderung ausgeliefert hat, am besten fixen kann, fixt er, und ich nehme ihm jedes andere Gespräch ab. Sobald es stabil ist, geht es in der Nachbetrachtung ums System. Als das in meinem Team passierte, ist eine Config-Änderung an Staging vorbeigelaufen, weil der Deploy-Pfad das erlaubte. Der Engineer war der letzte Dominostein, nicht die Ursache. Die Maßnahmen waren eine Leitplanke auf diesem Pfad, ein Test für genau diesen Fehler und besseres Alerting, jeweils mit Namen und Datum. Und ich sage in der Nachbetrachtung laut, dass die Änderung mit den vorliegenden Informationen vernünftig war, denn das ganze Team schaut zu, wie diese Person behandelt wird.