Warum Sie einen schriftlichen Plan brauchen
Während eines Vorfalls arbeitet Ihr Gehirn nicht mit voller Kapazität. Stress verengt Ihren Fokus. Sie vergessen Schritte. Sie überspringen Kommunikation. Sie beheben das Symptom, aber nicht die Ursache.
Ein schriftlicher Incident-Response-Plan nimmt das Denken aus den ersten 10 Minuten. Sie folgen einer Checkliste. Sie wissen, was zu tun ist und in welcher Reihenfolge. Der Plan handhabt den Prozess, damit Ihr Gehirn das Debugging handhaben kann.
Diese Vorlage ist für kleine Teams (2-10 Personen) konzipiert. Sie geht davon aus, dass Sie kein dediziertes SRE-Team oder eine Bereitschaftsrotation mit 15 Personen haben. Sie geht davon aus, dass die Person, die alarmiert wird, auch die Person ist, die das Problem behebt.
Der Incident-Response-Plan
Schritt 1: Erkennen
Ihr Überwachungstool alarmiert Sie. Sie erhalten eine Benachrichtigung: „Monitor [Name] ist ausgefallen. 3 aufeinanderfolgende Fehler. HTTP 500.”
Keine Panik. Nehmen Sie sich 30 Sekunden zur Überprüfung. Überprüfen Sie die Seite selbst. Überprüfen Sie Ihr Überwachungs-Dashboard auf andere Alarme. Ein einzelner ausgefallener Monitor könnte ein Fehlalarm sein. Mehrere ausgefallene Monitore bedeuten einen echten Vorfall.
Wenn Sie PingWatchdog verwenden, werden Vorfälle automatisch erstellt, wenn Monitore ausfallen. Sie erhalten eine Zeitleiste, was wann passiert ist. Dies ist Ihr Ausgangspunkt für das Debugging.
Schritt 2: Deklarieren
Wenn dies ein echter Vorfall ist (kein Fehlalarm oder geplantes Ereignis), deklarieren Sie ihn. Informieren Sie Ihr Team. Informieren Sie Ihre Benutzer.
Für Ihr Team: Posten Sie in Ihrem designierten Vorfallkanal (Slack, Discord, Teams). Geben Sie an, was Sie wissen: welche Monitore ausgefallen sind, wann sie ausgefallen sind, welche Fehler Sie sehen. Markieren Sie alle, die möglicherweise einbezogen werden müssen.
Für Ihre Benutzer: Aktualisieren Sie Ihre Statusseite. Posten Sie ein „Untersuchung läuft”-Update. Sie müssen die Ursache nicht kennen. Sie müssen nur das Problem bestätigen. „Wir untersuchen Berichte über erhöhte API-Fehler. Nächstes Update in 15 Minuten.”
Ihre Statusseite sollte sich automatisch aus Ihren Überwachungsdaten aktualisieren. Wenn ein Monitor ausgefallen ist, sollte die Statusseite dies zeigen. Das manuelle Update sagt den Benutzern, dass Sie dran sind.
Schritt 3: Untersuchen
Beginnen Sie mit der einfachsten Erklärung. Haben Sie kürzlich deployed? Hat sich eine Abhängigkeit geändert? Hatte ein Drittanbieterdienst einen Vorfall?
Überprüfen Sie Ihre Überwachungsdaten. Welche Fehler melden die Sonden? Verbindungsverweigerung? DNS-Fehler? Timeout? HTTP 500 mit einer spezifischen Fehlermeldung? Die Sondendaten zeigen, was die Außenwelt sieht.
Überprüfen Sie Ihre Logs. Anwendungslogs, Datenbanklogs, Webserver-Logs. Suchen Sie nach Fehlern, die etwa zur gleichen Zeit begannen, als der Monitor ausfiel.
Überprüfen Sie Ihre Infrastruktur. Läuft der Server? Akzeptiert die Datenbank Verbindungen? Steigt die Speicher- oder Festplattennutzung sprunghaft an? Ist die CPU-Auslastung abnormal?
Schritt 4: Eindämmen
Sobald Sie wissen, was falsch ist, stoppen Sie die Blutung. Dies muss nicht die dauerhafte Lösung sein. Das ist in Ordnung. Das Ziel ist, den Dienst zuerst wiederherzustellen, dann die Ursache zu beheben.
Häufige Eindämmungsmaßnahmen:
- Rollback durchführen: Wenn ein kürzlicher Deploy das Problem verursacht hat, rollen Sie zur vorherigen Version zurück. Stellen Sie den Fix nach der Lösung des Vorfalls bereit.
- Dienst neustarten: Datenbank-Verbindungspools, Cache-Server und Nachrichtenwarteschlangen benötigen manchmal einen Neustart. Starten Sie den Dienst neu und überwachen Sie die Wiederherstellung.
- Ressourcen hochskalieren: Wenn das Problem Ressourcenerschöpfung ist (CPU, Arbeitsspeicher, Verbindungen), skalieren Sie hoch. Sie können nach dem Vorfall wieder herunterskalieren.
- Failover: Wenn ein einzelner Server oder eine Region betroffen ist, leiten Sie den Datenverkehr woanders hin.
Schritt 5: Kommunizieren
Während der Eindämmung posten Sie ein weiteres Status-Update. „Problem als Erschöpfung des Datenbank-Verbindungspools identifiziert. Wir rollen einen Fix aus.”
Nachdem der Fix bereitgestellt ist, posten Sie erneut. „Fix bereitgestellt. Überwachen der Wiederherstellung.”
Nach Bestätigung der Wiederherstellung posten Sie das finale Update. „Dienst wiederhergestellt. Vorfallsdauer: 23 Minuten.”
Lassen Sie nicht mehr als 30 Minuten ohne Update vergehen, selbst wenn das Update lautet: „Untersuchen noch. Wir haben das Problem auf die Datenbankebene eingegrenzt.” Schweigen schafft Unsicherheit. Updates schaffen Vertrauen.
Schritt 6: Auflösen
Warten Sie, bis Ihre Monitore die Wiederherstellung bestätigen. Erklären Sie den Vorfall nicht aufgrund einer schnellen manuellen Überprüfung für gelöst. Lassen Sie die automatisierten Prüfungen verifizieren, dass der Dienst stabil ist.
PingWatchdog löst Vorfälle automatisch auf, wenn Monitore für einen anhaltenden Zeitraum auf „up” zurückkehren. Dies stellt sicher, dass Sie einen Vorfall nicht vorzeitig schließen.
Schritt 7: Post-Mortem
Schreiben Sie innerhalb von 24 Stunden nach dem Vorfall ein kurzes Post-Mortem. Dies muss kein formelles Dokument sein. Eine Slack-Nachricht oder ein kurzes Doc reicht. Beantworten Sie diese Fragen:
- Was ist passiert? Beschreiben Sie den Vorfall in einfacher Sprache.
- Was waren die Auswirkungen? Wie lange waren Dienste betroffen? Welche Dienste? Wie viele Benutzer?
- Was war die Ursache? Was hat den Ausfall konkret ausgelöst?
- Wie wurde es erkannt? Hat die Überwachung es erfasst? Hat ein Benutzer es gemeldet?
- Wie wurde es gelöst? Welche Schritte wurden zur Behebung unternommen?
- Was verhindert ein erneutes Auftreten? Welche Aktionspunkte ergeben sich daraus?
Das Ziel des Post-Mortems ist nicht, Schuld zuzuweisen. Es geht darum, zu lernen und sich zu verbessern. Jeder Vorfall ist eine Chance, Ihr System zuverlässiger zu machen.
Einrichten Ihres Vorfall-Toolkits
Um diesen Plan auszuführen, benötigen Sie einige Dinge, bevor ein Vorfall eintritt:
Überwachung: Uptime-Überwachung, SSL-Überwachung und Heartbeat-Überwachung. Sie müssen über Probleme Bescheid wissen, bevor Benutzer sie melden. Richten Sie PingWatchdog-Überwachung ein.
Alarmierung: Alarme, die an die richtigen Kanäle weitergeleitet werden. Kritische Monitore gehen an PagerDuty oder Telefonbenachrichtigungen. Unkritische gehen an Slack. Alarmkanäle konfigurieren.
Statusseite: Eine öffentliche Statusseite, auf der Benutzer den Dienstzustand überprüfen können. Updates während Vorfällen sollten schnell und ehrlich sein. Richten Sie eine Statusseite ein.
Incident-Management: Automatisch erstellte Vorfälle mit Zeitleisten. Wenn ein Vorfall beginnt, sollten Sie nicht manuell ein Ticket erstellen müssen. Das Überwachungstool sollte es für Sie tun. Erfahren Sie mehr über Incident-Management.
Kommunikationskanäle: Ein designierter Slack-Kanal, Discord-Raum oder Teams-Kanal für Vorfälle. Jeder weiß, wohin er während eines Vorfalls gehen muss.
Üben Sie den Plan
Führen Sie eine Feuerwehrübung durch. Wählen Sie einen unkritischen Dienst. Nehmen Sie ihn absichtlich vom Netz. Befolgen Sie den Plan. Stoppen Sie, wie lange jeder Schritt dauert.
Die meisten Teams stellen fest, dass der schwierigste Teil nicht die technische Lösung ist. Es ist die Kommunikation. „Ich habe das Problem in 5 Minuten behoben, aber 15 Minuten damit verbracht, herauszufinden, was ich auf der Statusseite sagen soll.” Übung macht die Kommunikation schneller.
Beginnen Sie mit dem Aufbau Ihres Plans
Die obige Vorlage funktioniert wie sie ist. Passen Sie die Kanalnamen, die Eskalationspfade und die Tool-Referenzen für Ihr Team an. Halten Sie es kurz. Wenn der Plan länger als eine Seite ist, wird Ihr Team ihn während eines Vorfalls nicht lesen.
Starten Sie kostenlos mit der Überwachung mit PingWatchdog. Jeder Tarif enthält Incident-Management mit automatisch erstellten und automatisch gelösten Vorfällen.