Der Nachbewertungsprozess nach dem Vorfall

Ein wichtiger Bestandteil einer Überprüfung nach einem Vorfall ist der Aufbau einer freigegebenen, genauen Chronologie, die den nichtlinearen Charakter eines Vorfalls 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. Und wenn mehrere Personen gleichzeitig arbeiten, können diese Dinge auch gleichzeitig passieren, so dass es etwas komplizierter ist.

Um eine Zeitachse wie diese zu erstellen, selbst eine komplexe, gibt es immer einen wichtigen ersten Schritt: das Sammeln der Daten.

Sammeln der Daten

Bevor Sie eine Überprüfung nach dem Vorfall durchführen können, müssen Sie zuerst Daten sammeln. Insbesondere müssen Sie so viele Unterhaltungen und Kontext (sowohl technische als auch nicht technisch) um das Ereignis herum sammeln, so wie möglich, damit Sie alle wichtigen Daten verwenden können, die darin enthalten sind. Die Unterhaltung zwischen Teammitgliedern, die während des Ausfalls oder Vorfalls aufgetreten sind, ist eine Ihrer reichsten Informationsquellen.

Sie sollten auch Daten aus Ihrem Überwachungssystem sowie aus anderen Quellen sammeln, aus denen die Personen, die am Vorfall beteiligt sind, Kontext gewonnen haben. Welche Informationen erhielten sie von Ihren Systemen, als der Vorfall ausgeführt wurde?

Und schließlich wäre es hilfreich, wenn es Ihnen möglich ist, ein besseres Bild davon zu erhalten, was sich vor und während des Vorfalls geändert hat, da Änderungen häufig beitragende Faktoren sind, wenn ein Vorfall auftritt.

Wir können diesen Prozess als drei separate Teile betrachten:

• Sammeln Sie die Unterhaltung: In anderen Modulen in diesem Lernpfad haben wir erwähnt, dass es wichtig ist, einen bestimmten Ort zu pflegen, an dem Personen während eines Vorfalls kommunizieren können. Im Laufe des Vorfalls teilen sich im Idealfall Menschen, was funktioniert hat und was fehlgeschlagen ist, was sie zögerlich ausprobieren möchten, was sie in der Vergangenheit versucht haben. Diese Unterhaltung zwischen den Menschen, während sie durcharbeiten und das Problem lösen, ist Ihre beste Lernquelle.
• Ermitteln Sie den Kontext: Die Personen in einem Vorfall empfangen Signale von verschiedenen Orten. Ein primärer Ort ist Ihr Überwachungssystem. Wir haben uns mit der Bedeutung eines soliden Überwachungssystems in einem vorherigen Modul in diesem Lernpfad befasst. Im Idealfall sollten wir in der Lage sein, das Überwachungssystem zu betrachten, um eine Point-in-Time-Momentaufnahme für den Zeitraum um oder im Zusammenhang mit dem Vorfall zu erstellen.
• Suchen Sie die Änderungen: Sie können dies über Aktivitäts- und Überwachungsprotokolle tun.

Azure Tools zum Sammeln der Daten

Azure bietet eine Reihe von Tools, die ihnen bei diesem Prozess helfen können:

Azure DevOps zum Halten von Metadaten zum Vorfall

In einem vorherigen Modul in diesem Lernpfad haben wir die Verwendung von Azure Boards in der Azure DevOps Suite als einen Ort diskutiert, an dem alle Informationen zu einem Vorfall gesammelt werden, beginnend mit der ersten Antwort. Es hilft uns bei Fragen, wann ein Vorfall zum ersten Mal deklariert wurde, wer anrufte, wer dem Vorfall zugewiesen wurde usw. Sie können auch das Azure DevOps Wiki als zentrale Möglichkeit verwenden, um einige der Informationen über den Vorfall selbst und die Unterhaltung, die während des Vorfalls aufgetreten ist, abzurufen.

Microsoft Graph-API zum Extrahieren der Unterhaltung

Microsoft Graph-API bietet eine programmgesteuerte Möglichkeit zum Abrufen der Unterhaltung, die im Teams-Kanal gesammelt wurde, der diesem bestimmten Vorfall gewidmet ist. Die abgerufenen Daten umfassen Zeitstempel, Autorschaft, Bearbeitungen, Antworten und einige Systemmeldungen, die beim Erstellen einer Chronologie hilfreich sein können.

Eine einfache Möglichkeit, mit Microsoft Graph-API zu beginnen, besteht darin, den Microsoft Graph Explorer zu verwenden. Microsoft Graph Explorer ist ein webbasierter API-Browser, in dem Sie API-Aufrufe aus einer Sample-Abfragen auswählen und diese interaktiv ausprobieren können.

Stellen Sie vor dem Ausführen der Abfragen sicher, dass der von Ihnen verwendete Benutzer oder die verwendete App über die erforderlichen Berechtigungen und Zustimmungen für den ausgewählten Zugriffsmodus verfügt. In delegierten Szenarien wird `Team.ReadBasic.All` zum Auflisten verknüpfter Teams verwendet, `Channel.ReadBasic.All` zum Auflisten von Kanälen und `ChannelMessage.Read.All` zum Lesen von Kanalnachrichten. Wenn Sie den Workflow später mit GET /users/{id | user-principal-name}/joinedTeams Nur-App-Zugriff automatisieren, verwenden Sie /me/joinedTeams anstelle des nur-delegierten /me/joinedTeams Aliases mit der Team.ReadBasic.All Anwendungsberechtigung. Für die kanalspezifischen Leseschritte sind ChannelSettings.Read.Group die App-Optionen mit den geringsten Privilegien für das Auflisten von Kanälen und ChannelMessage.Read.Group für das Lesen von Nachrichten, beide mit ressourcenspezifischer Zustimmung.

Wir durchlaufen eine Reihe von Microsoft Graph v1.0 "Microsoft Teams"-API-Aufrufen zum Abrufen der Unterhaltung. (Kanalnachrichten wurden vor mehreren Jahren von Beta zu v1.0 verschoben, sodass die Beta-Endpunkte für dieses Szenario nicht mehr erforderlich sind.) 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 hilft. Anschließend verwenden wir diese Informationen, um die nächste Anforderung zu erstellen. Beispielsweise fragen wir zuerst eine Liste von Team-IDs ab, um die Teams anzuzeigen, zu der wir gehören. Wir wählen das aus der Antwort benötigte aus, und fügen diese ID in die nächste Abfrage-URL ein, um eine Liste der Kanäle in diesem Team abzurufen.

Hier sind unsere Schritte, die als Microsoft Graph v1.0-Endpunkte angezeigt werden:

1. GET /me/joinedTeams (um die Team-ID des Teams zu finden, das wir in einem delegierten Szenario verwenden) oder GET /users/{id | user-principal-name}/joinedTeams (um dasselbe in einem Nur-App-Szenario zu tun).
2. GET /teams/{team-id}/channels (um die Kanal-ID des Kanals zu finden, den wir für diesen Vorfall verwendet haben).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (zum Abrufen des verschachtelten Gesprächsverlaufs).
4. Folgen Sie @odata.nextLink und replies@odata.nextLink nach Bedarf, oder verwenden Sie GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies, um durch größere Threads zu navigieren.

Wenn Sie einen freigegebenen Kanal verwendet haben, beachten Sie, dass die joinedTeams API das Hostteam für einen freigegebenen Kanal nicht zurückgibt, bei dem der Benutzer ein direktes Mitglied ist. Diese Einschränkung gilt unabhängig davon, ob Sie anrufen GET /me/joinedTeams oder GET /users/{id | user-principal-name}/joinedTeams. Beginnen Sie in diesem Fall mit den bekannten Team- und Kanal-IDs, oder verwenden Sie die zugehörigen Team-APIs, um das Hostteam zu finden.

Im Graph-Explorer können Sie diese URLs entweder direkt eingeben oder die entsprechenden Einträge aus den integrierten Sample-Abfragen bereich unter Microsoft Teams auswählen.

Wenn wir später ein Programm erstellen möchten, um jede dieser Schritte auszuführen (und tatsächlich tun wir), gibt es eine Codeausschnittoption im Anforderungsfenster , in der Beispielcode für diese Abfrage in einer Reihe verschiedener Programmiersprachen dargestellt wird.

Je nachdem, wie Ihr Team Teams verwendet, kann der Nachrichtenverlauf auch Systemnachrichten enthalten, die erläutern, wann Mitglieder hinzugefügt oder entfernt wurden. Wenn Sie jedoch einen autoritativen Überwachungspfad der Kanalmitgliedschaft oder Zugriffsänderungen benötigen, ergänzen Sie diese Daten mit Microsoft 365 Überwachungsprotokollen.

Dashboards und Arbeitsmappen für die Kontextanzeige

Azure Dashboards und Azure Monitor Arbeitsmappen können beide dazu beitragen, den Kontext zu rekonstruieren, den Operatoren während eines Vorfalls gesehen haben. Dashboards sind nützlich für einen schnellen Überblick über die betrieblichen Abläufe von Azure-Diensten. Arbeitsmappen eignen sich in der Regel besser für die Vorfallanalyse, da sie umfangreichere Abfragen, Parameter, Drilldowns und narrativen Text zusammen mit Diagrammen unterstützen.

Wenn Sie bereits über ein Dashboard oder eine Arbeitsmappe verfügen, das die richtigen Signale erfasst, legen Sie ihren Zeitraum auf den Zeitraum um den Vorfall fest, und verwenden Sie es, um zu diesem Zeitpunkt zu rekonstruieren, was die Personen gesehen haben. Dies kann besonders hilfreich sein, wenn Metriken, Protokolle und Warnungen über mehrere Ressourcen hinweg korreliert werden.

Freigegebene Dashboards sind Azure Ressourcen und können weiterhin als JSON aus dem Portal exportiert werden. Dieser Export-/Importpfad ist nützlich, wenn Sie ein Dashboard versions- oder templatisieren möchten. Bei den meisten Szenarien für die Untersuchung nach dem Vorfall sind Arbeitsmappen jedoch das flexiblere Tool, da Sie Visualisierungen, KQL-Abfragen und erläuternden Text in einem einzelnen Artefakt kombinieren können.

Aktivitätsprotokolle, Ressourcenprotokolle und Log Analytics für die Änderungssuche

Ein Log Analytics Arbeitsbereich kann Daten aus vielen Quellen aufnehmen, darunter Azure Aktivitätsprotokoll, Azure Ressourcenprotokolle und dienstspezifische Diagnosen. Erstellen Sie zunächst einen neuen Log Analytics Arbeitsbereich. Öffnen Sie dann im Azure-Portal Monitor → Aktivitätsprotokoll, und wählen Sie Exportieren von Aktivitätsprotokollen oben im Bereich aus. Dadurch wird eine Diagnoseeinstellung geöffnet, mit der Sie das Aktivitätsprotokoll für ein Azure-Abonnement an Ihren Arbeitsbereich senden können.

In kurzer Zeit können Sie kusto Query Language (KQL) verwenden, um detaillierte Informationen zu Änderungen abzurufen, die in diesem Abonnement vorgenommen wurden, seit Sie die Datenquelle verbunden haben.

Die folgende Abfrage zeigt beispielsweise Informationen zu Ressourcen an, die geändert oder gelöscht wurden. Wir können den Zeitraum in der Protokollanzeige so einstellen, dass wir genauer auf den Zeitraum kurz vor dem Vorfall fokussieren können.

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc

Diese Abfrage ist nützlich für Änderungen auf der Verwaltungsebene, aber beachten Sie, was nicht angezeigt wird. AzureActivity erfasst Steuerungsebenenvorgänge wie Erstellen, Aktualisieren, Löschen und Richtlinienaktionen. Es erfasst keine Datenebenen- oder Anwendungsebenenänderungen innerhalb eines Diensts. Um diese Zu untersuchen, koppeln Sie diese Abfrage mit Azure Ressourcenprotokollen, dienstspezifischen Überwachungsprotokollen, Bereitstellungsverlauf und CI/CD- oder Quellcodeverwaltungsdatensätzen.

Eine kurze Notiz: Wenn Sie das Azure Aktivitätsprotokoll exportieren, werden die Informationen von diesem Zeitpunkt an in den Log Analytics Arbeitsbereich fließen. Sie können diesen Arbeitsbereich nicht rückwirkend nach Ereignissen abfragen, die ausgeführt wurden, bevor Sie die Verbindung hergestellt haben.

Diese Tools sollten Ihnen einen guten Einstieg in das Sammeln von Informationen geben können, die für eine Chronologie erforderlich sind, um sie in einer Überprüfung nach dem Vorfall zu verwenden. Bevor Sie direkt in eine Überprüfung nach dem Vorfall eintauchen, möchten wir Sie vor einigen gängigen Fallen warnen. Das ist das Thema unserer nächsten Einheit.