Donnerstag, 18. Mai 2023

SRE - Reaktion auf Vorfälle (Incident Response)

 


Während die Einführung des Monitorings hauptsächlich eine technische Übung ist, besteht die Reaktion auf Vorfälle fast ausschließlich aus Prozessen und Menschen. Die Reaktion auf Vorfälle baut auf der Datenwelt auf, die wir mit der Überwachung aufgebaut haben, und setzt eine Feefback-Schleife in Gang, die uns hilft, die Überwchung unserer Dienste zu finden und zu verbessern. Das zeigt uns, worauf es ankommt, denn wenn wir keine Warnung erhalten und uns jemand mitteilt, dass unser Dienst nicht funktioniert , dann haben wir nicht die richtigen Dinge überwacht.

Was ist ein Vorfall?

Ein Zwischenfall liegt vor, wenn etwas Bedeutendes passiert, das Sie dazu zwingt, Ihren Weg und ihre normalen Handlungen zu ändern.

In der Softwarebranche können Zwischenfälle ähnlich verlaufen. In der Regel handelt es sich um einen Fehler, der auf eine Änderung im System (entweder im System selbst oder in den Eingaben, die das System erhält) oder auf eine Änderung in der Umgebung, in der das System läuft, zurückzuführen ist. Das System selbst ändert sich in der Regel durch die Bereitstellung von Code oder durch eine Änderung des Umgangs, in dem das System arbeitet.

Die Tatsache dass die Welt aus ständigem Chaos besteht, bedeutet, dass der Wandel aus jeder Richtung kommen kann. Zwischenfälle sind oft der Beweis dafür, dass wir Menschen nicht allmächtig sind. Wir schreiben die Software und wissen nicht alles, so dass Ereignisse eintreten, die wir nicht eingeplant haben, was oft dazu führen kann, dass die Software auf eine Art und Weise agiert, die uns nicht zusagt.

Was ist die Reaktion auf Vorfälle?

Die Reaktion auf einen Vorfall besteht in der Regel aus einer Reihe von Maßnahmen:

=> Bemerken, dass etwas nicht in Ordnung ist.

=> Kommunizieren, dass etwas nicht in Ordnung ist

=> Etwas tun, um die Dinge in Ordnung zu bringen


Alarmierung

Die Alarmierung ist ein umstrittene Thema. Es ist umstritten, weil niemand gewarnt werden möchte. Eine Warnung ist eine Warteschlange , die sie zur Arbeit zwingt. 

Wann sollten Sie sich melden?


Dies alles führt zu der Frage, wann man Alarm schlagen sollte. Was ist die Abfrage, die jemanden dazu zwingt, benachrichtigt zu werden, dass etwas nicht in Ordnung ist? Wir beginnen mit dieser Frage und nicht mit der Frage, wen wir benachrichtigen oder wie wir benachrichtigen, weil die Frage bei Monitoring  gestellt worden ist ob der Dienst funktioniert.

Wenn die Antwort auf diese Frage oft nein lautet, dann sollte dies die ernsthafteste aller Warnungen hervorrufen. Sie wollen, dass jemand Bescheid weiß und reagiert. Oft bedeutet dies, dass ein Kunde betroffen ist. Unter einem schwerwiegenden Vorfall verstehe ich in der Regel etwas, das ein Kunde sieht und das ihn dazu veranlasst , sich mit uns in Verbindung zu setzen, weil unser Produkt defekt ist. 

Wie das Monitoring ist auch die Alarmierung eine Sache , die sich ständig ändert. Hüten Sie sich davor, zu oft zu alarmieren, da Sie damit die Wirksamkeit für die Empfänger der Warnung verringern. Es ist eine ständige Bewertung erforderlich , um sicherzustellen, dass die Warnmeldungen nützlich sind und dass richtig darauf reagiert wird.

Wie schlagen Sie Alarm?


Sobald Sie festgelegt haben, wann Sie eine Warnung ausgeben wollen , müssen Sie entscheiden , wohin die Warnungen gehen und wie sie die Personen erreichen sollen.
Sie können sie auf viele Arten versenden. Einige gängige Möglichkeiten zur Benachrichtigung von Personen sind:

=> Ein Anruf
=> Eine SMS
=> Eine spezielle App , die laute Geräusche macht
=> Eine Gruppenchat-Nachricht
=> Eine E-Mail
=> Eine laute Sirene in einem Büro

Einige Übermittlungsmethoden sind besser als andere. Die Wahl der Übermittlungsmethode hängt von der Häufigkeit und Lautstärkke Ihrer Warnungen ab und auch davon, wie die Menschen auf eine Warnung reagieren sollen. Bei einem kleinen Software-Startup würde eine laute Sirene wahrscheinlich dazu führen, dass alle kündigen, aber bei einer Software, die einen Atomreaktor betreibt, ist eine laute Sirene vielleicht keine schlechte Idee.

Es gibt unterschiedliche Systeme für die Alarmierung. Der Schlüssel zu all diesen Systemen ist, ein System zu finden, das erschwinglich und zuverlässig ist und das von den Empfängern der Warnmeldungen auch gelesen wird. Wenn niemand auf Ihrer Arbeit seine E-Mails liest, dann schicken Sie ihm auch keine Warnmeldungen.

Wie schon bei den Monitoringsystemen erwähnt, handelt es sich auch bei den Warnsystemen um Software, die nicht immer zuverlässig ist. Wie zuverlässig sie sind, hängt von Ihnen und Ihrem Team ab. Wie gefährlich ist es, wenn eine Meldung Sie nicht erreicht? Sie können Ihre Alarmierungstools diversifizieren, um die Wahrscheinlichkeit zu erhöhen, dass ein Alarm zugestellt wird. Das Nachrichtensystem könnte so eingerichtet werden, dass bei einem Ausfall einer Nachricht eine andere für den Ausfall einspringen kann. Es kommt ganz darauf an, was man wählt , aber oft arbeiten Warnsysteme mit „Master Election“ oder „Leader Election“. Dabei handelt es sich um einen Prozess, der in der Regel auf den Paxos- oder Raft-Algorithmen aufbaut und bei dem eine Reihe identischer Server darüber entscheidet , wer die Führungsrolle übernimmt und die eigentliche Arbeit erledigt.

Was gehört in eine Warnmeldung?


Das erste, woran man denken sollte , ist der Anfangstext. Dies ist oft der Betreff der E-Mail, die erste Nachricht in einem Chat oder die Kopfzeile der Warnmeldung. Er sollte kurz und beschreibend sein.
Tim Pope, ein Software-Entwickler in der Vim Open-Source-Gemeinschaft, hat einige Formatierungsvorschläge für Commit-Nachrichten in Git, einem Versionskontrollsystem, die auch für Alerts sinnvoll sind. Die meisten seiner Ratschläge sind sehr spezifisch für Git, aber es gibt einige Dinge, die wir mitnehmen können und die sehr nützlich sind:

=> Die Betreffe sollten weniger als 50 Zeichen umfassen. So lässt sich schnell erkennen, warum die Person ausgeschrieben wird.

=> Verwenden Sie den Imperativ. Dies ist vor allem deshalb wichtig, weil Sie oft Anweisungen geben wollen, was zu tun ist, wenn dieser Fehler auftritt. Zum Beispiel: „ Gehen Sie zur AWS-Konsole und beenden Sie die Instanz i-1234567890“.

=> Geben Sie eine zusätzliche Erklärung nach dem Betreff. Wenn Ihr Alarmierungsdienst dies zulässt, fügen Sie Live-Details wie Diagramme oder Auswertungen von Metriken hinzu. Fügen sie auch Links zu Dokumentationen ein, die für die Person, die auf die Warnmeldung reagiert , nützlich sein könnten.

Wen alarmieren Sie?


Jetzt , da wir leicht verständliche Warnmeldungen versenden, müssen wir entscheiden, wer unsere Warnmeldungen erhalten soll. Erinnern Sie sich, dass Warnmeldungen ein umstrittenes Thema sind?
Der Grund dafür ist, dass viele Menschen zwar eine Benachrichtigung wünschen, aber nicht die Person sein wollen, die die Benachrichtigung erhält.

Eine Warnung ist per Definition ein Störfaktor. Die Notwendigkeit, auf einen Zwischenfall zu reagieren, ist nur selten etwas, von dem man weiß, dass es kommt, so dass man gezwungen ist, alles sofort zu unterbrechen. Oft ist die Reaktion auf einen Zwischenfall auch kein Hauptbestandteil der Arbeit einer Person, so dass diese auch Fristen verschieben und ihre Arbeit unterbrechen muss.


Voriges Thema:

https://einsiedlerkreps.blogspot.com/2023/05/sre-monitoring.html


Auskopplung vom Post:

https://einsiedlerkreps.blogspot.com/2023/05/sre-die-nachste-stufe-von-devops-teil.html

Keine Kommentare:

Kommentar veröffentlichen