Der Prozess der Incidentanalyse
Ein wichtiger Teil einer Incidentanalyse ist die Erstellung einer freigegebenen exakten Chronologie, die die nichtlineare Natur eines Incidents widerspiegelt.
Nichtlinear bedeutet, dass Incidents fast nie einfach nur nach dem Schema „Das ist passiert und dann das, dann haben wir das gemerkt, dann haben wir etwas getan, und damit war das erledigt“ ablaufen. Menschen kommen dazu und gehen wieder, es wird Verschiedenes bemerkt und ausprobiert, davon funktioniert einiges und manches nicht. Wenn mehrere Personen gleichzeitig arbeiten, können diese Dinge auch gleichzeitig passieren. Es ist also etwas komplizierter.
Zum Erstellen einer Zeitachse wie dieser, auch einer komplexen, gibt es immer einen wichtigen ersten Schritt: Es werden Daten gesammelt.
Sammeln der Daten
Bevor Sie eine Incidentanalyse durchführen können, müssen Sie zuerst Daten sammeln. Insbesondere müssen Sie so viele Daten wie möglich aus der Konversation und dem Kontext (sowohl technische als auch nicht-technische) in Bezug auf das Ereignis sammeln, sodass Sie alle darin enthaltenen wichtigen Daten verwenden können. Die Konversation zwischen Teammitgliedern, die während des Ausfalls oder Incidents stattgefunden hat, ist eine Ihrer umfassendsten Informationsquellen.
Außerdem sollten Sie Daten von Ihrem Überwachungssystem und anderen Stellen erfassen, aus denen die an dem Incident beteiligten Personen den Kontext bezogen haben. Welche Informationen haben sie von Ihren Systemen erhalten, als der Incident eingetreten ist?
Schließlich wäre es hilfreich, wenn möglich, ein besseres Bild davon zu erhalten, was sich unmittelbar vor und während des Incidents geändert hat, da Änderungen häufig beeinflussende Faktoren sind, wenn ein Incident eintritt.
Wir sehen uns diesen Vorgang als drei separate Teile an:
- Erfassen Sie die Konversation: In anderen Modulen in diesem Lernpfad haben wir erwähnt, dass es wichtig ist, einen bestimmten Ort für die Kommunikation von Benutzern während eines Incidents zu ermitteln. Während des Incidents tauschen sich die Mitarbeiter im Idealfall darüber aus, was funktioniert und was nicht, wobei sie zögern, was sie in der Vergangenheit ausprobiert haben. Diese Konversation zwischen den Personen bei der Bearbeitung und Lösung des Problems ist die beste Quelle zum Lernen.
- Bestimmen Sie den Kontext: Die Menschen in einem Incident erhalten Signale von verschiedenen Orten. Ein primärer Ort ist das Überwachungssystem. In einem früheren Modul in diesem Lernpfad haben wir die Bedeutung eines soliden Überwachungssystems erläutert. Im Idealfall sollte das Überwachungssystem in der Lage sein, eine Momentaufnahme für den Zeitraum rund um oder in Bezug auf den Incident zu erstellen.
- Suchen Sie die Veränderungen: Hierzu können Sie Aktivitäts- und Überwachungsprotokolle verwenden.
Azure Tools zum Sammeln von Daten
Azure bietet eine Reihe von Tools, die Sie bei diesem Prozess unterstützen können:
Azure DevOps zum Speichern von Metadaten über den Incident
In einem vorangegangenen Modul in diesem Lernpfad haben wir die Verwendung von Azure Boards in der Azure DevOps-Suite als zentrale Stelle erläutert, an der alle Informationen über einen Incident erfasst werden können, beginnend mit der ersten Reaktion. Es hilft uns bei Fragen wie denen, wann ein Incident zum ersten Mal festgestellt wurde, wer auf Abruf war, wer dem Incident zugewiesen war und dergleichen. Sie können auch das Azure DevOps-Wiki als zentralisierte Methode zum Abrufen einiger Informationen über den Incident selbst und die Konversation, die während des Incidents stattgefunden hat, verwenden.
Microsoft Graph-API zum Extrahieren der Konversation
Microsoft Graph-API bietet eine programmgesteuerte Möglichkeit zum Suchen, Exportieren und Einbringen der Konversation, die innerhalb des Teams-Kanals gesammelt wurde. Die abgerufenen Daten enthalten außerdem Metadaten, die beim Erstellen einer Chronologie nützlich sind, unter anderem dazu, wer dem Kanal beigetreten ist (und wann) und zum Zeitstempel für einzelne Teile der Konversation.
Eine einfache Möglichkeit für die ersten Schritte mit der Microsoft Graph-API ist die Verwendung des Microsoft Graph-Explorers. Microsoft Graph Explorer ist ein webbasierter API-Browser, mit dem Sie die API-Aufrufe durch Auswahl von vorab ausgefüllten Optionen auswählen können. Das Fenster sieht so aus:
Wir werden eine Reihe von API-Aufrufen von „Microsoft Teams“ und „Microsoft Teams (Beta)“ durchgehen, um die Konversation abzurufen. In jedem Schritt wählen wir eine Abfrage aus, führen die Abfrage aus und wählen dann die Informationen aus der Antwort aus, die uns beim nächsten Schritt helfen. Anschließend verwenden wir diese Informationen, um die nächste Anforderung zu erstellen. Beispielsweise wird zunächst eine Liste mit Team-IDs abgefragt, um die Teams anzuzeigen, zu denen wir gehören. Wir wählen aus der Antwort die benötigte ID aus und fügen diese ID in die nächste Abfrage-URL ein, um eine Liste von Kanälen in diesem Team abzurufen.
Die folgenden Schritte sind erforderlich:
- Abrufen von „Meine verbundenen Teams“ (um die Team-ID des Teams zu finden, das wir verwenden)
- Abrufen von „Kanälen eines Teams, in dem ich Mitglied bin“ (um die Kanal-ID des Kanals zu finden, den wir für diesen Incident verwendet haben)
- Abrufen von „Nachrichten in einem Kanal“ (zum Abrufen der Konversation)
Wenn wir zu einem späteren Zeitpunkt ein Programm für die Ausführung der einzelnen Schritte erstellen möchten (und dies tatsächlich tun), gibt es im Anforderungsfenster Codeschnipsel, die Beispielcode für diese Abfrage in einer Reihe verschiedener Programmiersprachen darstellen.
Zielgerichtete Dashboards für die Kontextanzeige
Mithilfe von Dashboards in Azure können wir die Informationen aus Azure Monitor auf einer einzigen Seite zusammenfassen, die für die operative Kenntnis wichtig sind. Mithilfe der Benutzeroberfläche können Sie den anzuzeigenden Zeitraum auswählen, sodass Sie die Zeit „zurückdrehen“ und die Dashboardinformationen für den Zeitraum anzeigen können, der einem Incident zugeordnet ist (vorausgesetzt, die Informationen sind nicht so alt, dass sie nicht mehr in Azure Monitor gespeichert sind). Diese rekonstruierte Benutzeroberfläche kann hilfreich sein, wenn Sie feststellen möchten, was die Personen während des Incidents gesehen haben. Es ist jedoch erforderlich, dass die Person, die die Überprüfung des Incidents ausführt, den richtigen Zeitraum manuell sucht.
Eine Funktion von Dashboards in Azure, die häufig übersehen wird, ist die Möglichkeit, eine Vorlage eines beliebigen Dashboards, das in einer JSON-Datei angezeigt wird, mithilfe der Schaltfläche Herunterladen (Pfeil nach unten) zu sichern und mit der Schaltfläche Hochladen (Pfeil nach oben) wieder zu laden. Das bedeutet, dass Sie entweder manuell nach dem richtigen Zeitpunkt suchen können, das Dashboard in diesem Zustand herunterladen und die JSON-Datei für andere freigeben, oder einfach das aktuelle Dashboard herunterladen und den JSON-Code an unsere Spezifikation anpassen können. Wenn Sie in einer heruntergeladenen JSON-Dashboarddatei nach der Zeichenfolge „time“ suchen, wird ein Abschnitt angezeigt, der wie folgt aussieht:
"metadata": {
"model": {
"timeRange": {
"value": {
"relative": {
"duration": 24,
"timeUnit": 1
}
},
"type": "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
},
"filterLocale": {
"value": "en-us"
},
"filters": {
"value": {
"MsPortalFx_TimeRange": {
"model": {
"format": "utc",
"granularity": "auto",
"relative": "24h"
},
"displayCache": {
"name": "UTC Time",
"value": "Past 24 hours"
},
Ändern Sie diesen Abschnitt gemäß Ihrer Spezifikation und laden Sie ihn erneut hoch. Wenn Sie mit dem verwendeten Format nicht vertraut sind, können Sie das Dashboard manuell ändern, es herunterladen und das erforderliche Format anzeigen.
Überwachungsprotokolle und Log Analytics für die Untersuchung der Änderungen.
Ein Log Analytics-Arbeitsbereich kann Daten aus vielen Quellen aufnehmen, einschließlich des Azure-Aktivitätsprotokolls. Erstellen Sie zunächst einen neuen Log Analytics-Arbeitsbereich. Wechseln Sie dann zur Funktion „Aktivitätsprotokoll“ im Portal, und wählen Sie Diagnoseeinstellungen aus. Dadurch erhalten Sie die Möglichkeit, das Aktivitätsprotokoll für ein Azure-Abonnement an Ihren neuen Arbeitsbereich zu senden.
In kurzer Zeit können Sie das gesamte Leistungsspektrum der Kusto-Abfragesprache (KQL) verwenden, um ausführliche Informationen zu Änderungen abzurufen, die in diesem Abonnement durchgeführt wurden, seit Sie eine Verbindung mit der Datenquelle hergestellt haben.
Die folgende Abfrage zeigt beispielsweise Informationen zu Ressourcen an, die geändert wurden oder gelöscht wurden. Wir können die Zeitspanne für die Abfrage im Abfrage-Explorer so festlegen, dass sie sich genauer auf die Zeit kurz vor dem Incident eingrenzen lässt.
AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatus, Caller
| order by TimeGenerated nulls first
Eine kurze Anmerkung: Wenn Sie das Azure-Aktivitätsprotokoll als Datenquelle festlegen, werden die Informationen von diesem Zeitpunkt an den Log Analytics-Arbeitsbereich weitergeleitet. Sie können diesen Arbeitsbereich nicht rückwirkend nach Ereignissen abfragen, die vor der Verbindungserstellung stattgefunden haben.
Diese Tools sollten Ihnen einen guten Einstieg in das Sammeln von Informationen geben, die für die Verwendung einer Chronologie in einer erforderlichen Überprüfung nach dem Incident erforderlich sind. Bevor Sie sich direkt mit einer Incidentanalyse beschäftigen, möchten wir Sie vor einigen häufigen Fallstricken warnen. Das ist das Thema unserer nächsten Lektion.