Nachverfolgung von Incidents
- 7 Minuten
Vorfälle haben einen Lebenszyklus. Um am effektivsten zu reagieren, müssen Sie in der Lage sein, die Entwicklung des Vorfalls selbst und die Entwicklung Ihrer Reaktion darauf von Anfang an zu verfolgen.
Bewerten, was Sie wissen
Eine gute Möglichkeit, Ihr Vorfallverfolgungsverfahren mithilfe eines bestimmten Vorfalls zu bewerten, besteht darin, sich eine Reihe von Fragen zu stellen:
- Wann wussten Sie zuerst über das Problem? Wenn Ihr Ziel darin besteht, die Zeit für die Wiederherstellung von Vorfällen zu reduzieren, müssen Sie mit der Erfassung von Informationen beginnen, sobald Sie sich über die Probleme informieren.
- Wie haben Sie von dem Problem erfahren? Hat Ihr Überwachungssystem Sie über den Vorfall benachrichtigt? Haben Sie zuerst von Ihren Kunden davon gehört, die sich entweder direkt oder in sozialen Medien beschwerten?
- Wenn Sie gerade von dem Problem erfahren, sind Sie die Erste, die davon erfährt? Wenn ja, wer muss sie benachrichtigen? Wenn nicht, wer kennt das Problem?
- Wenn andere wissen, was (wenn etwas) darüber getan wird? Geht jeder davon aus, dass sich jemand anderes darum kümmert, oder hat bereits jemand begonnen, Maßnahmen zu ergreifen, um das Problem zu lösen?
- Wie schlecht ist es? Wir haben möglicherweise keine Vorstellung von Schweregrad oder Auswirkungen, und es gibt keinen Ort, um herauszufinden, wie schlecht das Problem wirklich ist und wer betroffen ist.
Diese Fragen können schwierig zu beantworten sein, wenn nichts nachverfolgt wird.
Standardisieren, wo Vorfallinformationen nachverfolgt werden
Es gibt viele mögliche Orte, an denen Sie Ihre Liste der Vorfälle (aktiv oder anderweitig) und alle aktuellen Informationen zu diesen Vorfällen aufbewahren und freigeben können. Dies kann so einfach wie ein freigegebener Dateibereich mit Word Dokumenten und so komplex wie hochspezialisierte Software und Dienste zur Verfolgung von Vorfällen sein. Zwischen diesen beiden Extremen liegen Ticket- und Arbeitsüberwachungssysteme, die von Ihnen für diese Aufgabe verwendet werden können. Welches System Sie auswählen, ist eigentlich weniger wichtig als die Verwendung. Unabhängig davon, welches System Sie verwenden, muss jeder, der überhaupt eine Verbindung zu Vorfällen hat (Techniker, Kundendienst, Verwaltung, Öffentlichkeitsarbeit, Rechtswesen usw.), wissen, wo das System gefunden werden soll, wie man einen Vorfall auslösen kann und wie man gegebenenfalls auf die Daten zugreifen kann. Eine sichere Möglichkeit, mit der Vorfallverfolgung fehlzuschlagen, besteht darin, dass die Personen, die es unterstützt, nicht wissen, wie sie zum System gelangen können ("was war die URL für unser System erneut?"), wenn sie es benötigen.
In diesem Modul verwenden wir die Arbeitsaufgabenfunktionalität von Azure DevOps für unser Beispiel-Tracking-System.
Bauen Sie eine Dialogbrücke.
Um einige der Fragen im vorherigen Abschnitt "Bewerten" zu beantworten und den Vorfallreaktionsprozess zu starten, müssen Sie über eine Möglichkeit verfügen, mit anderen über den Vorfall zu kommunizieren. Im Idealfall wird hierfür ein elektronisches Kommunikationsmittel für die Zusammenarbeit im Team verwendet. Die Verwendung von Telefonkonferenzsystemen ist allerdings auch möglich. Telefonkonferenzen/Telefonkonferenzbrücken werden weniger gerne genutzt, da es schwieriger ist, die Kommunikation hinsichtlich des Vorfalls nachträglich zu überprüfen. Aus diesem Grund gibt es die zuvor erwähnte Rolle des "Scribe".
Unabhängig davon, welches Medium Sie wählen, sollten Sie sicher sein, einen einzigartigen Kanal zu pflegen, der streng darauf beschränkt ist, über diesen Vorfall und nichts anderes zu diskutieren. Es ist wichtig, irrelevante Diskussionen aus diesem Kanal herauszuhalten, da Sie in der Lage sein müssen, die Daten zu übernehmen und später in Ihrer Überprüfung nach dem Vorfall zu analysieren.
In diesem Modul verwenden wir Microsoft Teams als Unsere Vorfallkommunikationsmethode.
Automatisieren des Starts der Vorfallverfolgung
Lassen Sie uns also die Teile überprüfen, die wir bisher zusammengestellt haben. Sie verfügen nun über:
- Einen Dienstplan mit den Personen, die Bereitschaft haben (und ein definierter Übergabeplan für diese Personen).
- Rolle, die wir den Personen zuweisen können, die an einem Vorfall arbeiten.
- Spezifischer Ort, an dem wir den Vorfall deklarieren und nachverfolgen.
- Eindeutiger Kanal für die Personen, die an diesem Vorfall arbeiten, um darüber zu kommunizieren.
Sie können und sollten das Erstellen und Verwalten all dieser Dinge so weit wie möglich automatisieren. Wenn ein dringendes Problem auftritt, möchten Sie nicht alle Schritte zurückrufen, die zum Melden eines Vorfalls erforderlich sind, die richtigen Personen hinzuzuziehen und ihn zu verfolgen. Sie möchten einfach nur das Startsignal geben können, damit sofort mit der Bearbeitung des Problems begonnen werden kann.
Verwenden von Logik-Apps für die codelose Automatisierung
Eine Möglichkeit zum Automatisieren Ihrer ersten Antwort ist die Verwendung von Logik-Apps, die die Planung, Automatisierung und Orchestrierung von Aufgaben, Geschäftsprozessen und Workflows vereinfachen können.
Logic Apps ist ein Azure Clouddienst zum Erstellen von Integrationslösungen. Es verwendet Connectors zum Erstellen automatisierter Workflows. Trigger starten die Logik-App, wenn ein bestimmtes Ereignis auftritt oder wenn Daten bestimmte Kriterien erfüllen. Aktionen sind die Vorgänge, die dann im Logik-App-Workflow ausgeführt werden.
In unserem Beispiel verwenden wir die folgenden Logik-App-Connectors für die Nachverfolgung von Vorfällen:
- Azure DevOps, mit dem Sie Arbeitsaufgaben für Vorfälle in Azure Boards erstellen und nachverfolgen können.
- Azure Table Storage, in dem Sie Informationen zu anrufenden Personen speichern und abrufen können, damit Sie die richtigen Personen benachrichtigen können, um auf den Vorfall zu reagieren. In unserem Beispiel wird es als einfacher schemaloser Schlüssel-/Attributspeicher für Anruflistendaten verwendet.
- Microsoft Teams, mit dem Sie einen neuen, eindeutigen Vorfallkanal erstellen können, um die Unterhaltungen Ihrer Entwicklungsteams in Echtzeit nachzuverfolgen, während sie über bestimmte Vorfälle kommunizieren. Auf diese Weise können Sie die Interaktionen im Verhältnis zur Zeitachse von Ereignissen später beibehalten, wenn Sie eine Überprüfung nach einem Vorfall durchführen.
Lassen Sie uns dies nun mit einer Logik-App verknüpfen. Sehen Sie sich zunächst die vollständige App an, wie im Logik-Apps-Designer gezeigt, und dann werden wir schritt für Schritt durch die App geführt.
Hinweis
Die Logik-Apps-Designer-Schnittstelle wurde seit dem Erstellen dieser Screenshots aktualisiert. Die Workflowkonzepte bleiben unverändert, obwohl Aktionsnamen, aktuelle V2-Aktionen, Konfigurationsbereiche und visuelles Layout in Ihrer Umgebung unterschiedlich sein können.
Der erste Schritt ist die Behandlung eines Triggers, der von uns erwähnten HTTP-Anforderung. Eine HTTP POST-Anforderung wird an unsere Logik-App gesendet, die eine JSON-Nutzlast mit Informationen über den Vorfall enthält, den wir deklarieren möchten. Diese Nutzlast wird analysiert und eine Empfangsbestätigung zurückgesendet:
Mithilfe dieser Informationen erstellen wir eine neue Arbeitsaufgabe in unserer Azure DevOps Organisation, die diesen Vorfall darstellt.
Anschließend wird ein neuer Teams-Kanal für den Vorfall erstellt:
Nachdem der Kanal erstellt wurde, wird die Arbeitsaufgabe, die wir vor einem Moment erstellt haben, mit einem Link zum neuen Kanal aktualisiert. Dadurch werden alle Informationen an demselben Ort (der Arbeitsaufgabe) beibehalten und es den Benutzern ermöglicht, später zu wissen, wo sie hingehen sollen, wenn sie diesem Kanal beitreten möchten.
Jetzt ist es an der Zeit, die Anrufperson in das Bild zu bringen. Wir fragen Azure Table Storage nach dem Listeneintrag ab, der den aktuellen On-Call-Techniker identifiziert. Dadurch wird eine JSON-Antwort zurückgegeben, die dann analysiert wird.
Da unsere Abfrage eine Liste zurückgeben kann, müssen wir jedes übereinstimmende Element als nächsten Schritt durchlaufen. Verwenden Sie diese Daten in einem Produktionsworkflow, um einen primären Vorfallbesitzer und alle Sicherungen zu identifizieren. Der primäre Responder kann der Azure DevOps Arbeitsaufgabe zugewiesen werden, während zusätzliche Antwortende über verknüpfte Aufgaben, Kommentare oder Benachrichtigungen nachverfolgt werden können.
Anschließend senden wir als letzten Schritt eine Nachricht an den Teams-Kanal mit einem Zeiger zurück auf die Arbeitsaufgabe für Personen, die dem Kanal beitreten, und möchten wissen, wo die autoritativen Informationen für diesen Vorfall gespeichert sind.
Das ist nur ein Beispiel dafür, wie wir das Einrichten der Mechanismen für die Überwachung und Kommunikation von Vorfällen automatisieren können. In der nächsten Einheit werden wir ein wenig tiefer in Aspekte der Kommunikation um einen Vorfall eintauchen.