Stufe 5: Reagieren und lernen

Die Art und Weise, wie Ihre Anwendung auf störende Ereignisse reagiert, beeinflusst ihre Zuverlässigkeit. Es ist auch wichtig, aus Erfahrungen zu lernen und zu erfahren, wie Ihre Anwendung in der Vergangenheit auf Störungen reagiert hat, um ihre Zuverlässigkeit zu verbessern. 

Die Phase „Reagieren und Lernen“ konzentriert sich auf Methoden, die Sie implementieren können, um besser auf störende Ereignisse in Ihren Anwendungen reagieren zu können. Sie umfasst auch Methoden, die Ihnen helfen, aus den Erfahrungen Ihrer Betriebsteams und Techniker den größtmöglichen Lernerfolg zu ziehen.

Erstellung von Berichten zur Analyse von Vorfällen

Wenn ein Vorfall eintritt, besteht die erste Maßnahme darin, weitere Schäden für Kunden und das Unternehmen so schnell wie möglich zu verhindern. Nach der Wiederherstellung der Anwendung besteht der nächste Schritt darin, zu verstehen, was passiert ist, und Maßnahmen zu identifizieren, um ein erneutes Auftreten zu verhindern. Diese Analyse nach dem Vorfall wird in der Regel in Form eines Berichts erfasst, in dem die Ereignisse, die zu einer Beeinträchtigung der Anwendung geführt haben, sowie die Auswirkungen der Unterbrechung auf die Anwendung, die Kunden und das Unternehmen dokumentiert werden. Solche Berichte werden zu wertvollen Lernartefakten und sollten unternehmensweit verbreitet werden.

Anmerkung

Es ist wichtig, Vorfälle ohne Schuldzuweisung zu analysieren. Gehen Sie davon aus, dass alle Betreiber aufgrund der ihnen zur Verfügung stehenden Informationen die beste und geeignetste Vorgehensweise gewählt haben. Verwenden Sie in einem Bericht nicht die Namen von Bedienern oder Technikern. Wenn menschliches Versagen als Grund für die Beeinträchtigung angeführt wird, müssen Teammitglieder möglicherweise vorsichtig sein, um sich selbst zu schützen, was zur Erfassung falscher oder unvollständiger Informationen führen kann.

Ein guter Bericht zur Vorfallanalyse, wie er im Amazon Correction of Error (COE) -Prozess dokumentiert ist, folgt einem standardisierten Format und versucht, die Bedingungen, die zu einer Beeinträchtigung der Anwendung geführt haben, so detailliert wie möglich zu erfassen. Der Bericht beschreibt eine Reihe von Ereignissen mit Zeitstempel und erfasst quantitative Daten (häufig Kennzahlen und Screenshots aus Monitoring-Dashboards), die den messbaren Status der Anwendung im Laufe des Zeitrahmens beschreiben. In dem Bericht sollten die Denkprozesse der Bediener und Techniker, die Maßnahmen ergriffen haben, sowie die Informationen, die sie zu ihren Schlussfolgerungen geführt haben, erfasst werden. In dem Bericht sollte auch die Leistung der verschiedenen Indikatoren detailliert beschrieben werden, z. B. welche Alarme ausgelöst wurden, ob diese Alarme den Status der Anwendung genau widerspiegelten, wie viel Zeit zwischen den Ereignissen und den daraus resultierenden Alarmen vergeht und wie lange es dauert, bis der Vorfall behoben ist. In der Zeitleiste werden auch die Runbooks oder Automatisierungen erfasst, die initiiert wurden, und wie sie dazu beigetragen haben, dass die Anwendung wieder in einen brauchbaren Zustand zurückversetzt wurde. Diese Elemente des Zeitplans helfen Ihrem Team dabei, die Effektivität automatisierter und operativer Reaktionen zu verstehen, einschließlich der Frage, wie schnell das Problem behoben wurde und wie wirksam sie zur Minimierung der Störung beigetragen haben.

Dieses detaillierte Bild eines historischen Ereignisses ist ein wirksames Lehrmittel. Teams sollten diese Berichte in einem zentralen Repository speichern, das dem gesamten Unternehmen zur Verfügung steht, damit andere die Ereignisse überprüfen und daraus lernen können. Dies kann die Intuition Ihrer Teams dafür verbessern, was in der Produktion schief gehen kann.

Eine Sammlung detaillierter Vorfallberichte wird auch zu einer Quelle für Schulungsmaterial für Bediener. Teams können einen Zwischenfallbericht als Inspiration für einen Spieltag am Tisch oder live nutzen, an dem die Teams Informationen erhalten, die den Zeitplan wiedergeben, der im Bericht aufgezeichnet ist. Die Bediener können das Szenario anhand von Teilinformationen aus der Zeitleiste durchgehen und beschreiben, welche Maßnahmen sie ergreifen würden. Der Moderator für den Spieltag kann dann anhand der Aktionen des Operators erläutern, wie die Anwendung reagiert hat. Dadurch entwickeln sich die Fähigkeiten der Bediener zur Problembehebung, sodass sie Probleme leichter antizipieren und beheben können.

Ein zentrales Team, das für die Zuverlässigkeit der Anwendungen verantwortlich ist, sollte diese Berichte in einer zentralen Bibliothek verwalten, auf die das gesamte Unternehmen zugreifen kann. Dieses Team sollte auch für die Pflege der Berichtsvorlage verantwortlich sein und die Teams darin schulen, wie der Bericht zur Vorfallanalyse auszufüllen ist. Das Zuverlässigkeitsteam sollte die Berichte regelmäßig überprüfen, um Trends im gesamten Unternehmen zu erkennen, denen durch Softwarebibliotheken, Architekturmuster oder Änderungen der Teamprozesse begegnet werden kann.

Durchführung betrieblicher Überprüfungen

Wie in Phase 4: Operate erörtert, bieten Betriebsüberprüfungen die Gelegenheit, aktuelle Funktionen, Vorfälle und Betriebskennzahlen zu überprüfen. Die operative Überprüfung bietet auch die Gelegenheit, Erkenntnisse aus neuen Funktionen und Vorfällen mit der gesamten technischen Community in Ihrem Unternehmen zu teilen. Während der operativen Überprüfung überprüfen die Teams die Bereitstellung von Funktionen, für die ein Rollback vorgenommen wurde, die aufgetretenen Vorfälle und die Art und Weise, wie sie behandelt wurden. Dies gibt Technikern im gesamten Unternehmen die Möglichkeit, aus den Erfahrungen anderer zu lernen und Fragen zu stellen.

Stellen Sie Ihre Betriebsbeurteilungen der technischen Community in Ihrem Unternehmen zur Verfügung, damit diese mehr über die IT-Anwendungen, die das Unternehmen betreiben, und über die Arten von Problemen, auf die sie stoßen können, erfahren können. Sie nehmen dieses Wissen mit, wenn sie andere Anwendungen für das Unternehmen entwerfen, implementieren und bereitstellen.

Überprüfung der Alarmleistung

Alarme können, wie in der Betriebsphase beschrieben, dazu führen, dass Warnmeldungen im Dashboard angezeigt, Tickets erstellt, E-Mails gesendet oder Bediener angerufen werden.  Für eine Anwendung werden zahlreiche Alarme konfiguriert, um verschiedene Aspekte ihres Betriebs zu überwachen. Im Laufe der Zeit sollten die Genauigkeit und Wirksamkeit dieser Alarme überprüft werden, um die Alarmgenauigkeit zu erhöhen, Fehlalarme zu reduzieren und doppelte Warnmeldungen zu konsolidieren.

Präzision der Alarme

Alarme sollten so spezifisch wie möglich sein, um den Zeitaufwand für die Interpretation oder Diagnose der spezifischen Störung, die den Alarm ausgelöst hat, zu reduzieren. Wenn als Reaktion auf eine Beeinträchtigung der Anwendung ein Alarm ausgelöst wird, müssen die Bediener, die den Alarm empfangen und darauf reagieren, zunächst die Informationen interpretieren, die der Alarm übermittelt. Bei den Informationen kann es sich um einen einfachen Fehlercode handeln, der einer Vorgehensweise wie einem Wiederherstellungsverfahren entspricht, oder sie können Zeilen aus Anwendungsprotokollen enthalten, die Sie überprüfen müssen, um zu verstehen, warum der Alarm ausgelöst wurde. Wenn Ihr Team lernt, eine Anwendung effektiver zu bedienen, sollte es diese Alarme verfeinern, um sie so klar und präzise wie möglich zu gestalten.

Sie können nicht alle möglichen Störungen einer Anwendung vorhersehen. Daher wird es immer allgemeine Alarme geben, die von einem Bediener analysiert und diagnostiziert werden müssen. Ihr Team sollte daran arbeiten, die Anzahl der allgemeinen Alarme zu reduzieren, um die Reaktionszeiten zu verbessern und die mittlere Reparaturzeit (MTTR) zu verkürzen. Idealerweise sollte ein one-to-one Zusammenhang zwischen einem Alarm und einer automatisierten oder von Menschen ausgeführten Reaktion bestehen.  

Falsch positive Ergebnisse

Alarme, bei denen kein Eingreifen des Bedieners erforderlich ist, sondern Warnmeldungen in Form von E-Mails, Seiten oder Tickets generiert werden, werden von den Bedienern im Laufe der Zeit ignoriert.  Überprüfen Sie in regelmäßigen Abständen oder im Rahmen einer Vorfallanalyse die Alarme, um festzustellen, welche Alarme häufig ignoriert werden oder keine Maßnahmen seitens der Bediener erfordern (Fehlalarme).  Sie sollten daran arbeiten, entweder den Alarm zu entfernen oder den Alarm so zu verbessern, dass er eine umsetzbare Warnung an die Bediener ausgibt.

Falsch negative Ergebnisse

Während eines Vorfalls können Alarme, die so konfiguriert sind, dass sie während des Vorfalls warnen, fehlschlagen, möglicherweise aufgrund eines Ereignisses, das sich unerwartet auf die Anwendung auswirkt.  Im Rahmen einer Vorfallanalyse sollten Sie die Alarme überprüfen, die hätten ausgelöst werden sollen, aber nicht ausgelöst wurden. Sie sollten daran arbeiten, diese Alarme so zu verbessern, dass sie die Bedingungen, die sich aus einem Ereignis ergeben könnten, besser widerspiegeln. Alternativ müssen Sie möglicherweise zusätzliche Alarme erstellen, die derselben Störung zugeordnet sind, aber durch ein anderes Symptom der Störung ausgelöst werden.

Doppelte Warnmeldungen

Eine Störung, die Ihre Anwendung beeinträchtigt, verursacht wahrscheinlich mehrere Symptome und kann zu mehreren Alarmen führen.  In regelmäßigen Abständen oder im Rahmen einer Vorfallanalyse sollten Sie die ausgegebenen Alarme und Warnmeldungen überprüfen.  Wenn Bediener doppelte Warnmeldungen erhalten haben, erstellen Sie aggregierte Alarme, um sie in einer einzigen Warnmeldung zusammenzufassen.

Durchführung von Überprüfungen von Kennzahlen

Ihr Team sollte betriebliche Kennzahlen zu Ihrer Anwendung erheben, z. B. die Anzahl der Vorfälle nach Schweregrad pro Monat, die Zeit bis zur Erkennung des Vorfalls, die Zeit bis zur Identifizierung der Ursache, die Zeit bis zur Behebung und die Anzahl der erstellten Tickets, gesendeten Benachrichtigungen und aufgerufenen Seiten. Überprüfen Sie diese Kennzahlen mindestens einmal im Monat, um zu verstehen, mit welcher Belastung das Betriebspersonal konfrontiert ist, mit welchem signal-to-noise Verhältnis es zu tun hat (z. B. informative und umsetzbare Warnmeldungen) und ob das Team seine Fähigkeit verbessert, die von ihnen kontrollierten Anwendungen zu betreiben. Anhand dieser Übersicht können Sie sich ein Bild von Trends in den messbaren Bereichen des Betriebsteams machen. Bitten Sie das Team um Ideen zur Verbesserung dieser Kennzahlen.  

Bereitstellung von Schulungen und Befähigungsmaßnahmen

Es ist schwierig, eine detaillierte Beschreibung einer Anwendung und ihrer Umgebung zu erfassen, die zu einem Vorfall oder unerwartetem Verhalten geführt haben. Darüber hinaus ist es nicht immer einfach, die Widerstandsfähigkeit Ihrer Anwendung zu modellieren, um solche Szenarien zu antizipieren. Ihr Unternehmen sollte in Schulungs- und Schulungsmaterial investieren, damit Ihre Betriebsteams und Entwickler an Aktivitäten wie Resilienzmodellierung, Störfallanalysen, Spieltagen und Experimenten zur Chaostechnik teilnehmen können. Dadurch werden die Genauigkeit der von Ihren Teams erstellten Berichte und das von ihnen erfasste Wissen verbessert. Die Teams werden auch besser in der Lage sein, Ausfälle zu antizipieren, ohne sich auf eine kleinere, erfahrenere Gruppe von Technikern verlassen zu müssen, die ihre Erkenntnisse im Rahmen von geplanten Überprüfungen einbringen müssen.

Aufbau einer Wissensdatenbank zu Vorfällen

Ein Vorfallbericht ist eine Standardausgabe einer Vorfallanalyse. Sie sollten denselben oder einen ähnlichen Bericht verwenden, um Szenarien zu dokumentieren, in denen Sie ein ungewöhnliches Anwendungsverhalten festgestellt haben, auch wenn die Anwendung nicht beeinträchtigt wurde. Verwenden Sie dieselbe standardisierte Berichtsstruktur, um die Ergebnisse von Chaosexperimenten und Spieltagen zu erfassen. Der Bericht stellt eine Momentaufnahme der Anwendung und ihrer Umgebung dar, die zu einem Vorfall oder einem anderen unerwarteten Verhalten geführt haben. Sie sollten diese standardisierten Berichte in einem zentralen Repository speichern, auf das alle Techniker im Unternehmen zugreifen können.  

Betriebsteams und Entwickler können dann diese Wissensdatenbank durchsuchen, um zu verstehen, was in der Vergangenheit zu Störungen bei Anwendungen geführt hat, welche Arten von Szenarien zu Störungen geführt haben könnten und was die Beeinträchtigung von Anwendungen verhindert hat. Diese Wissensdatenbank beschleunigt die Verbesserung der Fähigkeiten Ihrer Betriebsteams und Ihrer Entwickler und ermöglicht es ihnen, ihr Wissen und ihre Erfahrungen auszutauschen. Darüber hinaus können Sie die Berichte als Schulungsmaterial oder als Szenarien für Spieltage oder Chaosexperimente verwenden, um die Intuition und Fähigkeit des operativen Teams zu verbessern, Störungen zu beheben.

Anmerkung

Ein standardisiertes Berichtsformat vermittelt den Lesern zudem ein Gefühl der Vertrautheit und hilft ihnen, die Informationen, nach denen sie suchen, schneller zu finden.

Umfassende Umsetzung von Resilienz

Wie bereits erwähnt, wird eine fortgeschrittene Organisation mehrere Maßnahmen ergreifen, um auf einen Alarm zu reagieren. Es gibt keine Garantie dafür, dass eine Reaktion wirksam ist. Durch die Kombination mehrerer Antworten ist eine Anwendung also besser darauf vorbereitet, fehlerhaft auszufallen. Wir empfehlen, für jeden Indikator mindestens zwei Antworten zu implementieren, um sicherzustellen, dass eine einzelne Reaktion nicht zu einer einzigen Fehlerquelle wird, die zu einem DR-Szenario führen könnte.  Diese Ebenen sollten in serieller Reihenfolge erstellt werden, sodass eine aufeinanderfolgende Reaktion nur dann ausgeführt wird, wenn die vorherige Reaktion unwirksam war. Sie sollten nicht mehrere mehrschichtige Antworten auf einen einzelnen Alarm ausführen. Verwenden Sie stattdessen einen Alarm, der anzeigt, ob eine Reaktion nicht erfolgreich war, und wenn ja, die nächste mehrschichtige Reaktion einleitet.