Incident Management für 10+ funktionsübergreifende Teams

Dieser Artikel erschien ursprünglich auf dem Mews Entwickler-Blog.

Bei der Skalierung unserer technischen Organisation fand die größte Schicht bei etwa 20 Entwicklern statt. Davor hatten wir ein einziges Team Tech, das sich um alles kümmerte. In diesem Team wurde nur nach Funktionen unterschieden: Backend-Entwickler, Frontend-Entwickler, etc. Die verschiedenen Funktionen hatten unterschiedliche Methoden der Protokollierung, der Berichterstattung und der Leistungsüberwachung. Einige Werkzeuge wurden gemeinsam genutzt, andere waren spezialisiert. Die Verwaltung dieses Stapels war jedoch relativ einfach, da er endlich und fest ist. Mit der Umstellung auf mehrere funktionsübergreifende Teams (derzeit 13) geht es nicht mehr nur darum, die "Maschine" (das Produkt) zu bauen, sondern eine "Maschine" zu bauen, die "Maschinen" baut (Teams, die Produkte bauen).

Ein großer Teil dieser übergeordneten "Maschine" ist der Rahmen für das Incident Management. Für mich ist das einer der Indikatoren für die Reife der technischen Organisation und eine meiner Lieblingsfragen im Vorstellungsgespräch. Mit Vorfällen meine ich alle unbehandelten Ausnahmen, Fehler, Ausfälle, Leistungsprobleme, Sicherheitsprobleme und alles, was dir sonst noch einfällt. Nicht nur direkt im Produkt, sondern auch in den umgebenden Werkzeugen. Wie bei vielen anderen Firmen gab es auch bei uns einige typische Probleme:

• Nicht alle Vorfälle zu erfassen, blind zu sein und darauf zu warten, dass die Kunden sie berichten.
• Sie erfassen die Vorfälle, ignorieren sie aber aus verschiedenen Gründen.
• Nicht rechtzeitig auf die Vorfälle entsprechend ihrer Schwere reagieren.
• Das führt zu einer Vielzahl von Fehlalarmen.
• Mehrere Werkzeuge für die Suche nach Vorfällen zu haben.
• Nicht genügend Daten und Erkenntnisse darüber, wie groß ein Problem tatsächlich war.

In diesem Artikel beschreibe ich, wie wir unseren neuen Prozess für das Incident Management entwickelt, all diese Probleme angegangen und die technische Lösung implementiert haben.

Anforderungen

Bei der Gestaltung des neuen Workflows haben wir verschiedene Anforderungen und Einschränkungen definiert, die auf unseren bisherigen Erfahrungen und Problemen basieren. Unser erstes Ziel war es, dass die Vorfälle extrem zielgerichtet sind, d.h. dass die Probleme an die Personengruppe weitergeleitet werden, die am ehesten für sie verantwortlich ist und die die Macht und das Wissen hat, sie zu lösen. Wenn das nicht passieren würde, würde der Bystander-Effekt eintreten. Daher musste für jeden Vorfall das zugehörige Team und seine Funktion innerhalb des Teams festgelegt werden. Dadurch wurden die Empfänger von der gesamten Organisation auf einige wenige Personen eingegrenzt.

Jedes Team sollte eine zentrale Stelle haben, an der alle Vorfälle zu finden sind.

Die zweite wichtige Anforderung für uns war die Handlungsfähigkeit und Rückverfolgbarkeit. Vereinfacht gesagt, wollten wir nicht, dass die Vorfälle nur in einer Plattform, in Slack-Benachrichtigungen oder in E-Mails eingetragen werden, denn es gibt keine Garantie dafür, dass sich jemand die Vorfälle ansieht oder sie bearbeitet. Du kannst nicht einfach über ihre Anzahl, die Lösungszeit oder andere Faktoren berichten, wenn einige von ihnen länger als angemessen ungelöst sind, usw.

Die Rolle des technischen Leiters eines Teams ist eine der schwierigsten, deshalb wollten wir den Arbeitsablauf bei Vorfällen für sie sehr benutzerfreundlich gestalten. Letztendlich sind die Tech-Leads für die Behebung von Vorfällen innerhalb ihrer Teams verantwortlich. Und da unsere Teams bereichsübergreifend arbeiten, wollten wir nicht, dass der technische Leiter viele verschiedene Tools ausprobieren muss, um einen Überblick über die Vorgänge in seinen Teams zu bekommen.

Lagerung

Um Handlungsfähigkeit und Rückverfolgbarkeit zu gewährleisten, haben wir schon früh beschlossen, dass alle Vorfälle in unserem Problemverfolgungssystem YouTrack gesteuert und gespeichert werden müssen. Bei den meisten Vorfällen handelt es sich um Probleme, die noch nicht von einem Benutzer gemeldet wurden. Es macht also keinen Sinn, sie von den berichteten Fehlern getrennt zu halten. Außerdem haben wir auf der Grundlage von YouTrack ziemlich leistungsfähige Workflows, Warnmeldungen und Berichte erstellt, die wir wiederverwenden wollten. Indem wir die Vorfälle dort verfolgen, erhalten wir genauere Daten darüber, womit die Teams ihre Zeit verbringen. Außerdem geht auf Slack nichts im Spam verloren oder wird übersehen, und die Entwickler haben einen einzigen Ort, an dem sie nach ihren Posten suchen können. Das Weiterleiten aller Vorfälle in eine Fehlerverfolgungssoftware kann anfangs etwas beängstigend sein, vor allem, wenn du viele davon hast. Deshalb empfehlen wir eine sanfte Einführung, die den Teams etwas Zeit gibt, sich auf den Zustrom vorzubereiten.

Es wäre jedoch nicht klug, alle Vorfälle direkt an die Software zur Problemverfolgung zu senden, da es zum Beispiel keine Rate-Limits gibt. Deshalb setzen wir Sentry als "Waschbecken" für alle Vorfälle ein, das vor YouTrack steht und es vor Überflutung schützt. Wir nutzen vor allem die Vorteile der Deduplizierung, der Ratenbegrenzung und der Alarmierungsregeln. Es macht keinen Sinn, jedes einzelne Auftreten desselben Fehlers zu berichten, und auch nicht, das erste Auftreten einer Warnung zu melden. Dies steuern wir durch Warnregeln, die auf der Art des Vorfalls (Fehler, Warnung, schwerwiegender Fehler), der Umgebung (Produktion, Staging, Entwicklung), der Anzahl der Veranstaltungen und anderen Kriterien basieren.

Speicherung von Vorfällen in Sentry und Eskalation zum Issue Tracker.

Für jede Kombination aus Team, Funktion und, optional, Produkt gibt es ein Sentry-Projekt. Du kannst ganz einfach auswählen, welche Projekte dich interessieren, und dann nach diesen Dimensionen unterteilen und "Ansichten" für den Teamleiter (Auswahl aller Projekte, an denen das Team beteiligt ist) oder den Funktionsleiter (Auswahl aller Projekte, z. B. Frontend) erstellen. Der Grund für diese Granularität ist, dass wir dort auch Installierungen und Produktversionen nachverfolgen, um zu erkennen, wenn eine Installierung eine Welle von Fehlern verursacht. Sentry erlaubt dies auf einer projektbezogenen Basis, was uns dazu zwingt, es abzutrennen, auch wenn dies zu einem gewissen Betriebsabläufen führt.

Erfassung

Es gibt zwei Hauptquellen für Vorfälle: unsere Anwendungen und unsere anderen Tools und Systeme. Das Sammeln von Vorfällen aus unseren Anwendungen ist ziemlich einfach. Sentry bietet SDKs für die meisten Plattformen. Unsere Arbeit besteht darin, das Team, die Funktion und das Produkt eines Vorfalls zu bestimmen. Funktion und Produkt sind einfach, denn es ist klar, in welcher App der Vorfall seinen Ursprung hat und welche Funktion dafür verantwortlich ist.

Sammlung von Vorfällen aus verschiedenen Quellen.

Das Team ist kniffliger, vor allem, wenn mehrere Teams eine einzige Anwendung betreuen. Wir haben eine monolithische Backend-Anwendung, an der die meisten Teams beteiligt sind, daher mussten wir uns mit diesem Problem auseinandersetzen :) Unsere Lösung bestand darin, alle Transaktionen im System auf Code-Ebene mit dem verantwortlichen Team zu kennzeichnen. Wenn der Code ausgeführt wird, ist also klar, welches Team der Eigentümer ist. Der Reservierungsinhaber kann für größere Bereiche definiert werden, z. B. für Module oder ganze APIs, was den anfänglichen Vertrieb der Reservierungsinhaber erleichtert. Die Teams tüfteln dann im Laufe der Zeit weiter an den Zuweisungen, so dass sich die Besitzverhältnisse zu einem stabilen Zustand hin entwickeln. Natürlich nur, bis ein Team wieder aufgeteilt wird.

Umweg 1: Unsere monolithischen Anwendungen sind eigentlich ziemlich modular aufgebaut und jede einzelne Zeile des ausführbaren Codes ist klar zugeordnet. Wir versuchen, die besten Aspekte beider Ansätze zu übernehmen: die Einfachheit und Leistung von Monolithen mit der klaren Verantwortlichkeit und Isolation von Microservices. Die Transaktionseigenschaft wird nicht nur für Vorfälle verwendet, sondern auch für die Leistungseigenschaft oder größere Refactoring-Initiativen, wenn wir fragen: "Wer sollte diesen Endpunkt refaktorisieren?"

Die zweite Kategorie von Incident-Produzenten sind andere Tools und Systeme wie New Relic, Azure Monitor, Azure DevOps, Rapid7 InsightOps, etc. Solche Tools unterstützen in der Regel nicht die Beschriftung der Warnmeldungen mit Sonderlösungen, daher verwenden wir Namenskonventionen, um das Team und andere Attribute zu unterscheiden. Da diese Tools in der Regel nicht direkt in Sentry integriert sind, steuern wir die Webhooks über eine einheitliche "Middleware", die in Sentry integriert ist. Zapier die wir als einfache FaaS nutzen. Dort wandeln wir alle proprietären Webhook-Formate in ein einheitliches Format um, extrahieren Team, Funktion und Produkt aus dem Alarmnamen und leiten den Vorfall an Sentry weiter.

Benachrichtigungen

Der letzte, einfachste, sichtbarste (und für manche Leute auch nervigste) Teil ist das Benachrichtigungssystem. Wenn ein Problem in unserer Problemverfolgungssoftware gemeldet oder eskaliert wird, nimmt ein Workflow es auf und sendet einen Webhook an Zapier. Dort verteilen wir die Meldungen nach verschiedenen Kriterien auf unterschiedliche Channels. Immer an einen Slack Channel des Teams, das die Probleme hat, manchmal an einen allgemeineren Channel und bei schwerwiegenden Vorfällen an PagerDuty.

Benachrichtigung Teil des Workflows.

Umweg 2: Du hast vielleicht bemerkt, dass wir Zapier intensiv nutzen. Das ist kein Zufall, und auch wenn zwei unserer Tools direkt integriert sind, steuern wir die Kommunikation stattdessen über Zapier. So können wir an einem einzigen Ort die Kommunikation zwischen all unseren Systemen untersuchen, was uns bei der Fehlersuche in fortgeschrittenen Arbeitsabläufen enorm hilft. Nicht alle Tools haben einen guten Überblick über die ausgehenden Webhooks, ihren Verlauf oder die Gründe, warum einige fehlgeschlagen sind. Zapier hat das. Du kannst die Payloads, die Transformationen, die Antworten der Empfänger usw. untersuchen. Das Schreiben einer einfachen JavaScript-Funktion, die von einem Webhook ausgelöst wird und auf der Grundlage der eingehenden Daten eine Aktion durchführt, ist ein Kinderspiel. Zapier kann als Anbieter, IDE und Debugger für solche Funktionen verstanden werden. Ich bin mir nicht sicher, ob das die ursprüngliche Absicht der Autoren war, aber für uns funktioniert dieser Anwendungsfall sehr gut.

Ergebnisse

Wir haben bereits viele Ideen, was wir in jedem Schritt des Arbeitsablaufs verbessern können. Von schöneren Problembeschreibungen und intelligenteren und granulareren Alarmierungsregeln bis hin zu besseren Benachrichtigungen mit noch enger eingegrenzten Empfängern mit Eskalationsregeln und Lösungszeit-SLOs. Aber auch ohne diese Vergünstigungen brachte der "Basis"-Workflow für Vorfälle unserer Organisation mehrere Vorteile:

• Wir haben jetzt klare, konsolidierte und vollständige Daten über unsere Vorfälle, die es uns ermöglichen, datengestützte Entscheidungen zu treffen.
• Die Art und Weise, wie wir über Fehler oder unbehandelte Ausnahmen berichten, wird immer besser. Die Teams entduplizieren Vorfälle, reduzieren False Positives und führen neue Vorfälle ein, die bisher ignoriert wurden.
• Dank einer einzigen Quelle der Wahrheit können wir schnell erkennen, wenn ein Team mit einem Übermaß an Vorfällen zu kämpfen hat und Hilfe organisieren.
• Wir haben einen viel besseren Einblick in die Qualität unserer Installierungen, indem wir die Vorfälle mit ihnen in Beziehung setzen.
• Der Workflow ist für alle Teams und Funktionen vorkonfiguriert und wird als Service der Plattform bereitgestellt. Es dauert etwa 5 Minuten, wenn ein neues Team eingeführt oder umbenannt wird.
• Es ist leicht erweiterbar, indem du neue Incident Collectors für neue Tools in Zapier implementierst.
• So geht kein Vorfall "in der Übersetzung verloren", was zu einer besseren Produktqualität und schnelleren Lösungszeiten führt und unsere Vision von technischer Exzellenz unterstützt.

Ein Blick aus dem Hubschrauber auf den gesamten Arbeitsablauf.

Ich hoffe, dieser Überblick gibt dir einige Anregungen, was du an deinem Incident Management verbessern kannst. Umgekehrt würden wir gerne erfahren, was du besser machst oder was wir verbessern können. Wenn du möchtest, dass ich einen Teil des Artikels noch weiter ausführe, kannst du mir das ebenfalls mitteilen!