Close

Der Weg zu einem besseren Vorfallmanagement beginnt hier

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 DevOps-Incident-Response-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 einer Bereitschaftsschicht ist nicht nur ein einzelner Bereitschaftsmitarbeiter verantwortlich, sondern DevOps-Vorfallmanagementteams benennen mehrere Teammitglieder, die für Eskalationen zur Verfügung stehen. Kann der designierte Bereitschaftsmitarbeiter einen Vorfall nicht selbstständig beheben, kann er ein Runbook als Leitfaden nutzen. Darüber hinaus hat der Bereitschaftsmitarbeiter die Möglichkeit, geeignete Personen hinzuzuziehen, um die Auswirkungen und den Schweregrad des Problems zu beurteilen und es an die richtigen Mitarbeiter zu eskalieren.

3. Behebung
Bei der Reaktion auf Vorfälle 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 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 zuvor noch nie gesehen haben.

4. Analyse
DevOps-Vorfallmanagementteams schließen einen Vorfall mit einer Post-Mortem-Analyse 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. Vorbereitung
Sobald ein Vorfall behoben ist, alle Behebungsschritte abgeschlossen sind und das System wiederhergestellt ist, gehen die DevOps-Vorfallmanagementteams einen Schritt zurück, 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.

Automatisierung von Prozessen und Workflows
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. Erstelle Runbooks mit vordefinierten Workflows, damit die Mitarbeiter bei einem Vorfall direkt loslegen können.

Kommunikation zwischen Teams
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 Schuldzuweisungen
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 hilfreichen Informationsaustausch, um die Arbeit der einzelnen Teammitglieder und die Zuverlässigkeit des Systems zu verbessern.

Fokus auf das Geschäftsergebnis
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 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.

Bereitschaftsplanung zur Platzierung von Entwicklern und Systemadministratoren als SREs
In DevOps-Teams verschwimmt die Grenze zwischen Entwicklern und Systemadministratoren, und diejenigen, die häufig auf Vorfälle reagieren, werden zu Site Reliability Engineers (SRE). Dennoch haben die einzelnen Mitarbeiter wahrscheinlich entweder spezialisierte Kenntnisse im Anwendungscode oder im Infrastrukturcode. Richte deinen Bereitschaftsdienst so ein, dass immer die richtige Mischung an Fachwissen vorhanden ist, um auf Vorfälle zu reagieren.

Weiter geht's
SRE