Vorfallmanagement im DevOps-Zeitalter

Anwendung der Grundsätze einer offenen Kommunikation ohne Schuldzuweisungen in Vorfallmanagementteams

Du kannst nicht überdenken, wie du Software erstellst, bereitstellst und betreibst, ohne auch zu überdenken, wie du auf Vorfälle reagierst.

In ihrem bahnbrechenden Vortrag aus dem Jahr 2009, "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr", skizzierten John Allspaw und Paul Hammond die Vision einer Welt, in der Entwickler und IT-Ops-Teams zusammenarbeiten und häufig ausliefern. Im Laufe des folgenden Jahrzehnts nahm diese Vision als DevOps-Bewegung Gestalt an.

Es liegt in der Natur von DevOps, auf Vorfälle mit neuen Methoden zu reagieren. Es ist also nicht verwunderlich, dass das Vorfallmanagement in Allspaws und Hammonds Vortrag so viel Aufmerksamkeit erregt hat. "Wir müssen uns unbedingt bewusst sein, dass Misserfolge unvermeidlich sind", sagte Hammond in diesem Vortrag. "Es stellt sich nicht die Frage, ob es dazu kommt, sondern, wann."

Anders als bei Frameworks wie ITIL gibt es kein "offizielles" Dokument mit Best Practices für ein DevOps-Team. Aber generell kann man sagen, dass es bei DevOps darum geht, den Geschäftswert eines Unternehmens zu steigern, indem man organisatorische Silos aufbricht, die Transparenz erhöht und eine offene Kommunikation zwischen Entwicklern und IT-Operations-Teams fördert.

Dieselbe Kultur der Transparenz, Sichtbarkeit und des schnellen Lernens wird auf das Vorfallmanagement ausgeweitet.

Warum? Bei den ersten und kritischsten Schritten im Vorfallmanagement wird untersucht, was schiefgelaufen ist, werden die richtigen Personen mit der Arbeit an dem Problem betraut und es wird eine Kultur ohne Schuldzuweisungen gefördert. 

Das DevOps-Vorfallmanagement erfordert eine offene Kommunikation ohne Schuldzuweisungen zwischen Entwicklern und IT-Operations-Teams. Darüber hinaus verbessert die Einführung leichtgewichtiger Prozesse die Zuverlässigkeit von IT-Services, erhöht die Kundenzufriedenheit und steigert den Geschäftswert. Ein DevOps-Entwickler kann dir dabei helfen, eine DevOps-Kultur und DevOps-Strategien umzusetzen. 

ITIL ist dagegen eine Zusammenstellung 26 vorgeschriebener Prozesse, Verfahren, Aufgaben und Checklisten, die konkrete Praktiken im IT-Service-Management verbessern sollen. ITIL konzentriert sich auf die Servicequalität und -konsistenz sowie die Verbesserung der Stabilität von Systemen.

Einer der Vorteile von ITIL besteht darin, dass Unternehmen, die ihr ITSM verbessern möchten, mit Best Practices aus bewährten Vorlagen beginnen können, anstatt das Rad neu zu erfinden. Und während einige glauben, dass ITIL sich am besten für große Unternehmen eignet, ist das Framework so flexibel, dass kleinere Unternehmen die Prozesse auswählen können, die für ihr Geschäft sinnvoll sind, und auf diese Weise ebenfalls profitieren.

Solltest du es eilig haben, Änderungen an deiner Incident Response vorzunehmen, besteht ein Nachteil von ITIL darin, dass ein formales Änderungsmanagement und ein Fachberater erforderlich sein können, was Verbesserungen verzögert.

Teams, die sofort loslegen möchten, hilft der DevOps-Ansatz für das Vorfallmanagement, sofort zusammenzukommen und Vorteile zu erzielen.

Der DevOps-Vorfallmanagementprozess

Der DevOps-Ansatz für die Verwaltung von Vorfällen unterscheidet sich nicht wesentlich von den bisherigen Schritten für ein effektives Vorfallmanagement. Beim DevOps-Vorfallmanagement kommt es jedoch vor allem darauf an, dass das Entwicklerteam – und der Bereitschaftsdienst – gleich am Anfang einbezogen und Aufgaben basierend auf Fachkenntnissen, und nicht auf der Berufsbezeichnung, zugewiesen werden.

1. Erkennung

Anstatt zu hoffen, dass Vorfälle niemals passieren (sie sind leider unvermeidlich), legen für die Incident Response zuständige DevOps-Teams großen Wert darauf, sich auf sie vorzubereiten. Sie arbeiten gemeinsam daran, ihre Reaktionen auf potenzielle Vorfälle zu planen, indem sie Schwachstellen in Systemen identifizieren. Sie richten Überwachungstools, Warnmeldungssysteme und Runbooks ein, damit jedes Teammitglied sofort weiß, an wen es sich wenden soll, wenn ein Vorfall erkannt wird, und was als Nächstes zu tun ist.

2. Reaktion

Für die Reaktion auf alle Vorfälle in einem Bereitschaftsplan ist nicht nur ein einzelner Bereitschaftstechniker verantwortlich. DevOps-Vorfallmanagementteams benennen mehrere Teammitglieder, die für Eskalationen zur Verfügung stehen. Kann der vorgesehene Bereitschaftstechniker einen Vorfall nicht selbstständig beheben, kann er ein Runbook als Leitfaden nutzen. Ferner hat der Bereitschaftstechniker die Möglichkeit, geeignete Personen hinzuzuziehen, um die Auswirkungen und den Schweregrad des Problems zu beurteilen und es an die richtigen Verantwortlichen zu eskalieren.

3. Behebung

Bei der Reaktion auf einen Vorfall können DevOps-Vorfallmanagementteams oft schnell zur Lösung kommen. Dies liegt daran, dass sie insgesamt besser mit der Anwendung oder dem Systemcode vertraut sind – weil sie ihn nämlich selbst geschrieben haben! In Kombination mit einer gründlichen Vorbereitung und guten Kommunikationssystemen können sie den Vorfall gemeinsam schneller beheben als ein Reaktionsteam aus Dritten, die den Code noch nie zuvor gesehen haben.

4. Analyse

DevOps-Vorfallmanagementteams schließen einen Vorfall mit einem Post-Mortem-Analyseprozess ohne Schuldzuweisungen ab. Sie setzen sich zusammen, um Informationen, Metriken und Erkenntnisse auszutauschen mit dem Ziel, die Widerstandsfähigkeit ihrer Systeme kontinuierlich zu verbessern und zukünftige Vorfälle schnell und effizient zu beheben.

5. Bereitschaft

Sobald ein Vorfall behoben ist, alle Behebungsschritte abgeschlossen sind und das System wiederhergestellt ist, nehmen die DevOps-Vorfallmanagementteams etwas Abstand, um zu beurteilen, wie gut sie auf den nächsten Vorfall vorbereitet sind. Sie aktualisieren mit den Erkenntnissen ihrer Post-Mortem-Analyse ihre Runbooks und nehmen alle notwendigen Anpassungen an Überwachungstools und Warnmeldungssystemen vor. Der Fokus von DevOps auf kontinuierliche Verbesserung gilt auch für die Mitarbeiter und das Team, nicht nur für die Technologie. Nach einem Vorfall ist jedes Teammitglied besser auf den nächsten vorbereitet.

Best Practices für effektive DevOps-Vorfallmanagementteams

Die Einführung eines DevOps-Ansatzes für die Incident Response kann zu einer verbesserten Kommunikation zwischen Entwicklungs- und IT-Operations-Teams, einer schnelleren Reaktion und Behebung von Vorfällen sowie zu einem widerstandsfähigeren System führen.

Prozesse und Workflows automatisieren

Integriere Servicedesk, Überwachung, Ticketsystem, CMDB/Asset-Management und Chattools miteinander, um Warnmeldungen zu IT-Vorfällen und Workflows zu rationalisieren und sicherzustellen, dass die richtigen Personen die Informationen erhalten, die sie benötigen, um an einer Lösung zu arbeiten. Richte Runbooks mit vordefinierten Workflows ein, damit die Mitarbeiter gut vorbereitet auf einen Vorfall reagieren können.

Zwischen Teams kommunizieren

Stelle sicher, dass Mitglieder deiner Teams mit Echtzeit-Chattools im gesamten Unternehmen kommunizieren können. Verwende Tools, die eine Dokumentation des Vorfalls erstellen, damit jeder jederzeit einsteigen und sich darüber informieren kann, was passiert ist und was getan wird.

Keine Schuld zuweisen

Nachdem der Vorfall behoben ist, setzt ihr euch im Team zusammen, um in einer Post-Mortem-Analyse ohne Schuldzuweisungen den Vorfall rückblickend zu besprechen. Sucht nicht nach Schuldigen, sondern konzentriert euch auf einen nutzbringenden Informationsaustausch, um die Arbeit der einzelnen Teammitglieder und die Zuverlässigkeit des Systems zu verbessern.

Das Geschäftsergebnis identifizieren und den Fokus darauf richten

Der DevOps-Ansatz zur Incident Response ist mehr als ein Mittel zur besseren Kommunikation. Mit ihm kann sichergestellt werden, dass Entwickler- und Operations-Teams zusammenarbeiten, um einen echten Geschäftswert zu erzielen. Verfolge Metriken wie die mittlere Zeit bis zur Erkennung (MTTD), die mittlere Zeit bis zur Reparatur (MTTR) und die mittlere Zeit zwischen Ausfällen (MTBF), um die Verbesserungsrate deines Teams nachzuvollziehen.

Bereitschaftspläne nutzen, um Entwickler und Systemadministratoren als SREs zu positionieren

In DevOps-Teams verschwimmt die Grenze zwischen Entwicklern und Systemadmins, und diejenigen, die häufig auf Vorfälle reagieren, werden zu Site Reliability Engineers (SRE). Dennoch haben die einzelnen Mitarbeiter wahrscheinlich spezialisierte Kenntnisse entweder über Anwendungs- oder über Infrastrukturcode. Richte deinen Bereitschaftsplan so ein, dass Mitarbeiter mit unterschiedlichen Fachkenntnissen eingeteilt sind, damit sie erfolgreich auf Vorfälle reagieren können.

Erfahre mehr darüber, wie Jira Service Management ein auf DevOps ausgerichtetes Vorfallmanagement unterstützen kann.