Ich hatte das Glück, zu sehen, wie sich unser Incident-Management-Prozess bei FloQast im Laufe der Jahre weiterentwickelt hat. Als ich 2016 anfing, hier als Softwareingenieur zu arbeiten, war es meiner Meinung nach nur eine Frage von Tagen, bis sich ein Vorfall ereignete. Damals könnte ein Vorfall damit begonnen haben, dass ein Benutzer uns einen Screenshot einer berüchtigten Fehlermeldung per E-Mail geschickt hat:

Zu diesem Zeitpunkt begann unser „Incident-Management-Prozess“. Ich könnte mich irren, aber ich denke, das waren die formellen Schritte

Unser COO teilte dem CTO, der neben ihm am Schreibtisch saß, mit, dass die App ausgefallen sei.
Unser CTO beeilte sich, sich bei der Heroku-Konsole anzumelden und entweder einen Server neu zu starten oder einen neuen Dyno bereitzustellen.

In einem bestimmten Zusammenhang hatte unser Unternehmen zu diesem Zeitpunkt insgesamt etwa 15 bis 20 Mitarbeiter. Dazu gehörten 6 Mitarbeiter der Forschungs- und Entwicklungsabteilung, darunter 0 QE-Ingenieure und 0 DevOps-Ingenieure. Trotz des Mangels an Mitarbeitern war es für unseren Incident-Management-Prozess eine viel einfachere Zeit. Unsere gesamte Bewerbung war ein relativ einfach „Monolith“ und unser gesamter Code befand sich in einem einzigen Repository. Infolgedessen stellte sich selten die Frage, was kaputt war oder an welcher Stelle sich der Code befand, der repariert werden musste. Es ging wirklich nur darum, wer mit der Lösung des Problems beauftragt werden sollte. Erwähnenswert ist auch, dass unser gesamtes Team direkt nebeneinander im selben Raum saß, sodass die Kommunikation keine Herausforderung darstellte.

Incident Management im Jahr 2021

Ein größeres Team mit größeren Problemen

Schneller Vorlauf zu heute. Unsere Abteilung sieht ein bisschen anders aus:

Unsere F&E-Mitarbeiterzahl beträgt über 80.
Wir haben QE-Ingenieure, DevOps-Ingenieure, Sicherheitsingenieure, Produktmanager und Produktsupport-Mitarbeiter. Früher hatten wir nichts davon!!!
Keiner von uns sitzt nebeneinander. Wir arbeiten alle aus der Ferne.
Wir haben viel mehr Produkte, die kaputt gehen können (und es auch tun)
Was auch immer es wert ist, Heroku ist eine ferne Erinnerung, und man kann mit Sicherheit sagen, dass wir die Zeiten, in denen wir den gesamten Code in einem Repo hatten, weit hinter uns haben.

Als das Team von 6 auf 80 Personen wuchs, entwickelten wir einen formelleren Incident-Management-Prozess. Es gab keinen bestimmten Tag, an dem sich alles änderte. Einige Komponenten unseres Prozesses entwickelten sich auf natürliche Weise, als wir neue Mitarbeiter in neuen Rollen hinzufügten, wohingegen andere Komponenten sehr gezielte Veränderungen und Übungen erforderten. Aber keine Sorge, die Dinge gehen immer noch kaputt, und das bringt viele Möglichkeiten mit sich, unseren Incident-Management-Prozess zu verbessern.

Ein Beispiel für einen Vorfall heute

Heute könnte ein Vorfall in etwa so aussehen:

Eine Handvoll Kunden berichten von einem ähnlichen Defekt in unserer Anwendung.
Ein „Mitarbeiter des Produktsupports“ (d. h. Kundensupport) ist betroffen. Das sieht nach einem neuen Problem aus, und zwar nach einem ernsten.
Der Mitarbeiter des Produktsupports veröffentlicht eine Nachricht (wahrscheinlich mit einigen Screenshots) in unserem #engineering -support Slack-Kanal. Unser Unternehmen nutzt diesen Kanal speziell für eskalierende Mängel an unsere Konstruktions- und Produktteams.
Ein Techniker überprüft den Slack-Beitrag und stimmt zu, dass das Problem besorgniserregend ist. Ein Produktmanager oder technischer Manager stimmt zu, dass das Problem schwerwiegend genug ist, um die Durchführung unseres Incident-Management-Prozesses zu rechtfertigen.
Ein „Incident Controller“ (auch bekannt als „IC“, in der Regel ein technischer Manager) übernimmt die Verantwortung für den Vorfall. Das IC erstellt einen Slack-Channel, um den Vorfall zu verfolgen, und lädt alle relevanten Parteien ein, daran teilzunehmen.
Der IC hat nicht die Aufgabe, das Problem tatsächlich zu beheben, sondern leitet stattdessen die gesamte Kommunikation und informiert den Kanal regelmäßig über Updates, bis das Problem behoben ist.
Schließlich plant das IC nach Abschluss des Vorfalls eine Obduktion und führt sie durch, idealerweise innerhalb weniger Tage nach Ende des Vorfalls.

Dieser Prozess folgt nicht immer genau diesen Schritten, aber zumindest möchten wir Folgendes sehen:

Jemand sollte die Verantwortung für den Vorfall übernehmen (z. B. der Incident Controller)
Es sollte einen Ort geben, an dem die Kommunikation konsolidiert werden kann (heute verlassen wir uns stark auf Slack)
Regelmäßige Updates sollten bereitgestellt werden, bis der Vorfall behoben ist
Nach Abschluss des Vorfalls sollte eine Obduktion durchgeführt werden

Herausforderungen mit unserem Incident-Management-Prozess

Ich denke, unser derzeitiger Prozess zeichnet sich durch drei Herausforderungen aus:

Feststellen, ob tatsächlich ein „Vorfall“ vorliegt
Die richtigen Leute einbeziehen
Das Beste aus einer Obduktion herausholen

Ich werde auf jede dieser Herausforderungen etwas näher eingehen und darauf, wie wir versuchen, sie zu bewältigen.

Herausforderung #1: Feststellen, ob es tatsächlich einen „Vorfall“ gibt

Wir machen es uns nicht zur Gewohnheit, unsere Techniker zu unterbrechen. Alle unsere Entwicklungsteams folgen einer agilen Entwicklungsmethodik. Zwischenfälle können Sprintziele und die Dynamik des Teams zerstören. Mehrere Vorfälle in einem kurzen Zeitrahmen können zu einem Burnout im Team führen. Im Idealfall vermeiden wir es, unseren Incident-Management-Prozess wegen eines Fehlers mit niedriger Priorität auszulösen. Wir fanden es hilfreich, eine klare Definition für einen Vorfall zu erstellen. An dieser Stelle haben wir einen technischen Vorfall ausdrücklich als „alles, was unseren normalen Geschäftsprozess unterbricht“ definiert. Mit anderen Worten, unsere Systeme befinden sich in einem Fehlerzustand, der unsere Kunden daran hindert, einen wichtigen Teil unserer Anwendung zu verwenden. Die Realität ist, dass dies manchmal immer noch Urteilsvermögen erfordert. Wir möchten immer mindestens die folgenden Faktoren berücksichtigen, bevor wir einen Vorfall eröffnen:

Wie weit verbreitet ist das Problem?
Wie schwerwiegend ist das Problem?

Leider haben wir festgestellt, dass wir, egal wie spezifisch unsere Definition eines Vorfalls sein mag, immer noch in Situationen geraten werden, in denen wir uns nicht sicher sind, ob es sich lohnt, einen Defekt als Vorfall zu behandeln. In solchen Situationen kommt es zu einem kurzen Gespräch zwischen dem Produktmanager, dem technischen Leiter und dem technischen Leiter des Teams, das für den Defekt zuständig ist. Wenn nicht jeder für ein Treffen verfügbar ist, können diejenigen, die verfügbar sind, die endgültige Entscheidung treffen. An dieser Stelle gehen wir gerne auf Nummer sicher. Wenn also Ungewissheit über den Schweregrad besteht, ziehen wir es vor, einen Defekt als Zwischenfall zu behandeln, auch wenn das bedeutet, dass ein Sprint unterbrochen wird.

Herausforderung #2: Die richtigen Leute einbeziehen

Warum ist das schwierig?

Manchmal ist das einfach nicht einfach. In einem bestimmten Kontext verfügt unser Unternehmen über viele Produkte, die im Wesentlichen in eine einzige Webanwendung eingebettet sind. So sehr wir uns auch wünschen, dass diese Produkte wirklich unabhängig voneinander sind, profitieren unsere Kunden — nicht überraschend — in erheblichem Maße davon, dass unsere Produkte miteinander interagieren können. In den meisten Fällen sind Vorfälle eindeutig auf einen Teil unserer Anwendung beschränkt. Auf den ersten Blick fallen mir mindestens zwei Arten von Vorfällen ein, bei denen es nicht trivial ist, die richtigen Personen einzubeziehen:

Fehler in Teilen unserer Anwendungsbenutzeroberfläche, die von mehr als einem unserer Produkte (und Entwicklungsteams) gemeinsam genutzt werden
Leistungsbezogene Probleme (z. B. Benutzer, die melden, dass die App langsam geladen wird). Diese könnten auf Anwendungscodefehler zurückzuführen sein, die unseren Softwareingenieuren gehören, oder auf Infrastrukturprobleme, die unserem DevOps-Team gehören.

Wie lösen wir das?

Obwohl wir es vorziehen, unsere Techniker nicht zu stören, ist es wichtig, dass wir eher früher als später herausfinden, wer die Ursache des Vorfalls ist. Das Letzte, was wir wollen, ist, dass ein Team einen Tag damit verbringt, ein Problem zu untersuchen, nur um herauszufinden, dass es sich um Code handelt, der einem völlig anderen Team gehört. Kurzfristig haben wir eine Reihe von Verfahren eingeführt, um sicherzustellen, dass die richtigen Personen an jedem Vorfall beteiligt sind, um dieses Problem zu lösen:

Wir verwenden einen Slack-Kanal, den ich oben erwähnt habe (#engineering -support), in dem unser Produktsupport-Team bei Problemen, die in unserer Anwendung festgestellt wurden, eskalieren kann. Dieser Kanal ist heute glücklicherweise nicht sehr laut. Wenn also etwas Mehrdeutiges auftaucht, können Ingenieure aus verschiedenen Teams zusammenarbeiten, um herauszufinden, welches Team im Allgemeinen verantwortlich ist.
Sobald wir tatsächlich einen offiziellen Incident eröffnen, erstellen wir einen separaten Slack-Kanal (z. B. #incident -41-slow-app-load-times) und veröffentlichen in unserem Hauptslack-Kanal für Forschung und Entwicklung eine Ankündigung, dass ein neuer Vorfall im Gange ist, mit einem Link zum neuen Incident-Slack-Kanal. Auf diese Weise wird niemand versehentlich ausgeschlossen und es gibt keine „versteckten Vorfälle“.

Langfristig zu denken, ist es auch wichtig, dass wir uns fragen, warum die Teamverantwortung nicht von vornherein offensichtlich war. Wenn es an der Zeit ist, einen Vorfall nach dem Tod zu melden, haben wir normalerweise einen Aktionspunkt zur Verbesserung unseres Systemüberwachung/Fehlermeldung damit das zugrunde liegende Problem beim nächsten Mal offensichtlicher wird.

Herausforderung #3: Das Beste aus einer Obduktion herausholen

Für diejenigen, die es nicht wissen, ist ein Vorfall nach dem Tod ein Meeting, das ein Team nach Abschluss eines Vorfalls abhält. Während des Treffens denkt das Team über die eigentliche Ursache des Vorfalls nach und entscheidet, ob es in Zukunft Maßnahmen ergreifen muss. Es sollte sich von selbst verstehen, dass Vorfälle stressig sind. Sie bringen unerwartete, aber dringende Arbeit mit. Wie bereits erwähnt, beeinträchtigen Zwischenfälle auch die Sprintziele und die Teamdynamik. Manchmal ist das Letzte, was jeder will andere Treffen. Angesichts der enormen potenziellen Vorteile einer Obduktion ist es wichtig, alles in Ihrer Macht Stehende zu tun, um das Meeting zum Erfolg zu führen. Wir haben festgestellt, dass die folgenden Verfahren die Qualität unserer Obduktionen verbessern:

Wir führen unsere Obduktionen so schnell wie möglich nach Abschluss eines Vorfalls durch, damit der Kontext aktuell ist. Wenn der aktuelle Sprint zum Scheitern verurteilt ist, dann sei es eben so. Das Team sollte einfach sein Sprintziel anpassen.
Zu Beginn unserer Obduktion überprüft der Incident Controller den Zeitplan der Ereignisse während des Vorfalls. Manchmal verbringen wir so viel Zeit damit, darüber nachzudenken, wie wir den Vorfall lösen können, dass wir vergessen, wie er überhaupt entstanden ist. Die Überprüfung des Zeitplans ist eine großartige Möglichkeit, das gesamte Team über die Reihenfolge der Ereignisse nachdenken zu lassen. Dadurch kann jeder kritischer über die Ursache des Vorfalls nachdenken.
Erstellen Sie während des Meetings Aktionspunkte. Normalerweise läuft das darauf hinaus, dass wir JIRA-Tickets ganz oben im Backlog unseres Teams erstellen. Wenn du während der Obduktion keine Aktionspunkte erstellst, wirst du es wahrscheinlich nie tun.
Zeige Dankbarkeit. Sie sollten stolz darauf sein, dass das Team zusammenarbeiten konnte, um ein Problem zu lösen. Auch wenn sich der Vorfall selbst negativ auf das Unternehmen ausgewirkt hat, ist es wichtig, die Reaktion auf Vorfälle als Erfolg, nicht als Misserfolg.

Danke fürs Lesen!

Ich hoffe, Ihnen hat dieser Blick hinter die Kulissen unseres Incident-Management-Prozesses gefallen. Wir haben im Laufe der Jahre einen langen Weg zurückgelegt, und wir müssen in Zukunft sicherlich noch viel verbessern. Auf kaputte Dinge!

Incident Management im Laufe der Jahre bei FloQast