Vorfallmanagement für High-Velocity-Teams
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.
Einrichten eines Bereitschaftsplans mit Opsgenie
In diesem Tutorial erfährst du, wie du einen Bereitschaftsplan einrichtest, Regeln für Außerkraftsetzungen anwendest, Bereitschaftsbenachrichtigungen konfigurierst und vieles mehr – und das alles in Opsgenie.
Dieses Tutorial ansehenBest Practices für die Kommunikation rund um Vorfälle
Unter Vorfallkommunikation versteht man den Prozess für die Benachrichtigung von Benutzern, wenn ein Service ausfällt oder nicht mit der gewohnten Leistung arbeitet.
Diesen Artikel lesen