Best Practices und Tipps für die Incident Response

1. Packe immer eine "Ersthilfetasche".

Eine "Ersthilfetasche" für Vorfallbearbeiter enthält alle kritischen Informationen, auf die Teams mit möglichst wenig Verzögerungen zugreifen können müssen. Dabei handelt es sich sehr wahrscheinlich um ein digitales Dokument, das idealerweise an einer zentralen Anlaufstelle für Vorfallbearbeiter aufbewahrt werden sollte.

Diese könnte eine Vielzahl von Informationen beinhalten, wie:

• Incident-Response-Pläne
• Listen mit Kontaktdaten
• Bereitschaftspläne
• Eskalationsrichtlinien ansehen
• Links zu Konferenztools
• Zugriffscodes
• Richtliniendokumente
• Technische Dokumentation & Runbooks

2. Habe keine Angst vor Runbooks.

Runbooks enthalten Anleitungen dazu, welche Schritte in einem bestimmten Szenario zu unternehmen sind. Sie sind besonders wichtig für Bereitschaftsteams, deren Personal regelmäßig wechselt und die daher nicht immer sofort einen Systemexperten verfügbar haben. Ein gut gepflegtes Runbook ermöglicht es Teams, schneller zu reagieren und eine gemeinsame Wissensdatenbank für Incident-Response-Praktiken aufzubauen.

3. Rechne mit Chaos und sorge für Stabilität.

Chaos Engineering ist eine Praxis für Systemexperimente. Dabei werden in diese Systeme wissentlich Fehler eingeschleust, um nachzuvollziehen, wie sie robuster gebaut werden können. Dazu wird beispielsweise das Tool Chaos Monkey verwendet, das ursprünglich von Netflix entwickelt wurde und zum Testen der Ausfallsicherheit von Netzwerken eingesetzt wird. Hierfür werden Produktionssysteme absichtlich offline genommen.

4. Denke über das NOC hinaus.

Früher dienten Network Operations Centers (NOCs) als Überwachungs- und Benachrichtigungszentrum für größere IT-Systeme. Moderne Vorfallmanagementtools ermöglichen eine deutliche Optimierung dieses Prozesses. Wenn Workflows zur Alarmbereitstellung basierend auf definierten Warnungstypen, Teamzeitplänen und Eskalationsrichtlinien automatisiert werden, kann die Gefahr von menschlichen Fehlern und/oder Verzögerungen vermieden werden.

5. Aggregieren, nicht verschlimmern.

Es gibt nichts Schlimmeres, als eine kontinuierliche Flut an Warnmeldungen zu erhalten, die von mehreren Überwachungstools stammen. Durch die Zentralisierung eingehender Warnmeldungen in einem einzigen Tool können Teams unwichtige Warnungen besser herausfiltern und sich schnell um Angelegenheiten kümmern, die ihre Aufmerksamkeit erfordern.

6. Denke daran: Wissen ist Macht.

Eine einfache Warnmeldung zeigt an, dass ein Problem vorliegt, aber nicht immer welches. Dies führt zu unnötigen Verzögerungen, weil Teams erst die Ursache untersuchen und feststellen müssen. Wenn Warnmeldungen mit den technischen Details zu ihrem Auslöser verknüpft werden, kann schneller mit der Problembehebung begonnen werden.

7. Richte Warnmeldungen für deine Warnungen ein.

Der lateinische Spruch "quis custodiet ipsos custodes" (Wer wird die Wächter selbst bewachen?) weist auf ein universelles Problem hin. Die von IT- und Entwicklerteams eingesetzten Überwachungstools sind ebenso anfällig für Vorfälle und Ausfallzeiten wie die Systeme, die sie schützen sollen. Ganzheitliche Alarmierungsprozesse stellen sicher, dass sowohl die Systeme als auch die Tools, die sie überwachen, kontinuierlich auf ihre Integrität überprüft werden.

8. Triff erste Maßnahmen.

Triageärzte wissen, dass sie einen größeren Schaden riskieren, wenn sie versuchen, alle eingehenden Fälle sofort selbst zu behandeln. Ihr Fokus liegt auf kurzfristigen Maßnahmen, um Patienten ausreichend zu stabilisieren, bis sie auf die Intensivstation kommen. Im Technologiebereich konzentrieren sich Eindämmungsmaßnahmen auf temporäre Lösungen (Isolierung eines Netzwerks, Neustart eines Build, Neustart von Servern usw.), die zumindest das Ausmaß des Vorfalls einschränken oder Systeme im Idealfall wieder online bringen.

9. Mach keine Alleingänge.

Die "Heldenkultur" in IT- und DevOps-Teams stirbt allmählich aus. Der Techniker, der endlose Abende und Wochenenden arbeitet, weil er der Einzige ist, der Systeme wieder zum Laufen bringen kann, ist aus der Mode gekommen. Stattdessen arbeiten Teams jetzt auch wie ein solches. Eine Kette ist schließlich nur so stark wie ihr schwächstes Glied – deshalb solltet du dein gesamtes Team fördern, nicht nur einzelne Überflieger.

10. Sei transparent.

Wenn Benutzer von einer Serviceunterbrechung betroffen sind, wird dieser Vorfall normalerweise wenig später publik gemacht. Um dem zuvorzukommen, sollten die Teams einen Plan zur Kommunikation von Vorfällen parat haben. Die Vorgehensweise soll Vertrauen bei den Kunden aufbauen, indem das Vorliegen einer Störung öffentlich bestätigt und versichert wird, dass Schritte zu ihrer Behebung unternommen werden. Tools wie Statuspage eignen sich hervorragend, um Informationen wie diese zu verbreiten.

11. Lerne aus deinen Fehlern.

Ein sehr großer Teil der IT- und DevOps-Teams gibt an, dass sie sich nur Zeit nehmen, um die "größten Ausfälle" nachzuverfolgen. Das ist ein passabler Ansatz, mit dem allerdings kleinere Vorfälle übersehen werden können, die möglicherweise spätere Auswirkungen nach sich ziehen. Vielleicht ist nicht für alle Vorfälle ein umfassender Bericht erforderlich, aber eine Post-Mortem-Analyse lohnt sich immer.

12. Finde die Hauptursache (es gibt keine Hauptursache!).

Oder doch? Bei der Analyse eines Vorfalls findet sich selten eine einzige erkennbare Hauptursache.Systeme sind oft viel zu komplex und zu stark voneinander abhängig, als dass eine einzige Hauptursache für einen Vorfall ermittelt werden könnte. Selbst wenn die Hauptursache offensichtlich erscheinen mag (zum Beispiel ein Fehler beim Tastenanschlag, der eine Anwendung abstürzen lässt), gibt es normalerweise Beweggründe dafür, nachzuforschen, welche externen Faktoren die Anwendung zum Absturz gebracht (oder diesen nicht verhindert) haben. Suche nach mehreren Hauptursachen, um einen besseren Einblick in deine Vorfälle zu gewinnen.

13. Macht euch nicht gegenseitig Vorwürfe.

Mit jeder Post-Mortem-Analyse eines Vorfalls sollte nachvollzogen werden, was schiefgelaufen ist und was getan werden kann, um ähnliche Vorfälle zukünftig zu vermeiden. Nutze diesen Prozess jedoch nicht dazu, Schuld zuzuweisen. Denn Teams, die sich bei Vorfällen auf einen Schuldigen konzentrieren und nicht auf den Auslöser, lassen sich zu sehr von Emotionen leiten und werden dadurch kaum verstehen können, was passiert ist.

Und noch etwas

In modernen Vorfallmanagementumgebungen gibt es dauernd Veränderungen. Und das bedeutet, dass Systeme ständig auf neue und unterschiedliche Weise überstrapaziert werden. Teams, denen diese Tatsache bewusst ist, verstehen auch Folgendes: Es stellt sich nicht die Frage, ob ein System ausfällt, sondern wann. Die Vorbereitung auf derartige Ausfälle sollte als eine kritische Maßnahme betrachtet werden, um nachhaltigen Erfolg sicherzustellen, und jedem Entwicklungsteam eingebläut werden.

Eine Vorfallmanagementlösung wie Jira Service Management unterstützt dich bei jedem dieser 13 Punkte – von der Organisation der Bereitschaftsplanung, über Warnmeldungen und die Zentralisierung von Teams für bessere Zusammenarbeit bis hin zur Durchführung von Post-Mortem-Analysen von Vorfällen.