Empfehlungen für die Entwicklung einer Notfallstrategie

Gilt für die Empfehlungen dieser Power Platform Well-Architected Operational Excellence-Checkliste

Diese Anleitung enthält Empfehlungen für die Entwicklung einer Notfallstrategie. Einige Ihrer Workloads können unternehmenskritisch sein, und Probleme, die im Laufe des Lebenszyklus einer Workload auftreten, können schwerwiegend genug sein, um sie zu Notfällen zu erklären. Sie können streng kontrollierte und fokussierte Prozesse und Verfahren implementieren, an die sich Ihr Team halten kann, um sicherzustellen, dass ein Problem ruhig und geordnet behandelt wird. Notfälle erhöhen natürlich den Stresspegel aller und können zu einer chaotischen Atmosphäre führen, wenn Ihr Team nicht gut vorbereitet ist. Um Stress und Verwirrung zu minimieren, entwerfen Sie eine Reaktionsstrategie, geben Sie diese an Ihre Organisation weiter und führen Sie regelmäßig Schulungen zum Thema Notfallmaßnahmen durch.

Wichtige Designstrategien

Eine Notfallstrategie sollte aus einem klar definierten Satz von Prozessen und Verfahren bestehen. Jeder Prozess und jedes Verfahren sollte Skripte enthalten, um sicherzustellen, dass Ihr Team mit jedem Schritt ein Problem schnell und sicher lösen kann. Beachten Sie bei der Entwicklung einer Notfallstrategie die folgende Übersicht:

• Voraussetzungen
  • Überwachungssystem entwickeln
  • Erstellen Sie einen Vorfallreaktionsplan
• Vorfallphasen
  • Detektion und Eindämmung
  • Selektierung
• Nachvorfallphasen
  • Ursachenanalyse (RCA)
  • Obduktion
• Laufende Aktivität
  • Notfallmaßnahmen Übungen

Die folgenden Abschnitte enthalten Empfehlungen für jede dieser Phasen.

Systemüberwachung

Um eine robuste Notfallstrategie zu haben, müssen Sie über ein robustes Überwachungssystem oder eine Observability-Plattform verfügen. Ihre Observability-Plattform sollte die folgenden Eigenschaften aufweisen:

• Ganzheitliche Überwachung: Stellen Sie sicher, dass Sie Ihre Workload aus Konfigurations- und Anwendungsperspektive gründlich überwachen, und schließen Sie eine Infrastrukturüberwachung ein, wenn Komponenten Ihrer Workload in der Cloud oder lokal gehostet werden. Stellen Sie sicher, dass alle Komponenten Ihrer Workload von Ihrer Überwachungsstrategie abgedeckt werden. Wenn Ihre Workload beispielsweise mit Azure-Ressourcen oder einem lokalen System interagiert, beziehen Sie diese Komponenten in Ihre Überwachung ein.

• Ausführliche Protokollierung: Aktivieren Sie die ausführliche Protokollierung für Ihre Komponenten, um die Untersuchungen bei der Einstufung eines Problems zu erleichtern. Strukturieren Sie Protokolle so, dass sie einfach zu verwalten sind. Senden Sie Protokolle automatisch an Datensenken, um sie für die Analyse vorzubereiten.

• Nützliche Dashboards: Erstellen Sie auf der Grundlage Ihres Integritätsmodells Dashboards, die auf jedes Team in Ihrer Organisation zugeschnitten sind. Verschiedene Teams sind für unterschiedliche Aspekte der Arbeitslastintegrität verantwortlich.

• Umsetzbare Warnungen: Erstellen Sie Warnungen, die für Ihre Workload-Teams nützlich sind. Vermeiden Sie Warnungen, die keine Aktion Ihrer Teams erfordern. Zu viele Warnungen dieser Art können dazu führen, dass Benutzer Warnbenachrichtigungen ignorieren oder blockieren.

• Automatische Benachrichtigungen: Stellen Sie sicher, dass die entsprechenden Teams automatisch Warnungen erhalten, die eine Aktion ihrerseits erfordern. Beispielsweise sollte Ihr Tier-1-Supportteam Benachrichtigungen für alle Alarme erhalten, während Ihre Sicherheitsingenieure nur Alarme für Sicherheitsereignisse erhalten sollten.

Weitere Informationen finden Sie unter Empfehlungen zum Entwerfen und Erstellen eines Überwachungsframeworks.

Vorfallreaktionsplan

Die Grundlage einer Notfallstrategie ist ein Vorfallreaktionsplan. Wie bei einem Disaster Recovery-Plan sollten Sie Rollen, Verantwortlichkeiten und Verfahren für die Reaktion auf einen Vorfall klar und gründlich definieren. Der Plan sollte ein versionskontrolliertes Dokument sein, das regelmäßig überprüft wird, um seine Aktualität sicherzustellen.

Definieren Sie die folgenden Komponenten in Ihrem Plan klar.

Rollen

Bestimmen Sie einen Vorfallreaktionsmanager. Diese Person ist für den Vorfall vom Beginn über die Behebung bis hin zur Ursachenanalyse verantwortlich. Ein Incident Response Manager stellt sicher, dass Prozesse befolgt und die entsprechenden Parteien informiert werden, während das Response-Team seine Arbeit ausführt.

Identifizieren Sie einen Post-Mortem-Leiter. Diese Person stellt sicher, dass Post-Mortem-Analysen zeitnah nach der Lösung des Vorfalls durchgeführt werden. Sie erstellen einen Bericht, der Ihnen hilft, die Erkenntnisse aus dem Vorfall anzuwenden.

Prozesse und Vorgehensweisen

Ihr Workload-Team sollte Notfallkriterien definieren und verstehen. Wenn Ihr Team feststellt, dass es sich um einen schwerwiegenden Fall handelt, können Sie den Katastrophenfall ausrufen und den Notfallwiederherstellungsplan in die Wege leiten. In weniger schwerwiegenden Fällen erfüllt das Problem möglicherweise nicht die Kriterien einer Katastrophe, aber Sie sollten das Problem dennoch als Notfall betrachten, was die Einleitung eines Notfallplans erfordert. Notfälle können entweder intern auf Ihre Workload zurückzuführen sein, z. B. auf Fehler in Ihrem Anwendungscode oder das Ergebnis eines Problems mit einer Abhängigkeit Ihrer Workload, wie die Nichtverfügbarkeit einer API oder einer Datenbank. Ein Notfall kann auch durch einen Ausfall Ihres Lieferanten verursacht werden (z.B. ein Problem mit der Microsoft Entra ID oder Power Platform). Das Supportteam muss in der Lage sein, festzustellen, ob ein Problem die Notfallkriterien erfüllt, auch wenn das Team keinen Einblick in das zugrunde liegende Problem hat.

Definieren Sie Kommunikations- und Eskalationspläne präzise. Stellen Sie je nach Art der Benachrichtigung, die sie erhalten, sicher, dass die Mitglieder Ihres Tier-1-Supportteams bei eskalierenden Problemen problemlos die entsprechenden Teams kontaktieren können.

Weitere einzuschließende Elemente

Dokumentieren Sie alle Standardtools, die bei Vorfällen für die interne Kommunikation wie Microsoft Teams verwendet werden und zur Verfolgung der Aktivitäten im Verlauf des Vorfalls, wie Ticketing-Tools oder Backlog-Planungstools.

Dokumentieren Sie Ihre Notfallanmeldeinformationen, auch bekannt als Break-Glass-Konten. Fügen Sie eine Schritt-für-Schritt-Anleitung bei, die die Verwendung beschreibt.

Erstellen Sie Anweisungen für Notfallübungen, und führen Sie Aufzeichnungen darüber, wann Übungen durchgeführt werden.

Dokumentieren Sie alle erforderlichen rechtlichen oder behördlichen Maßnahmen, wie z. B. die Mitteilung von Datenschutzverletzungen.

Erkennung und Eindämmung von Vorfällen

Wenn Sie über ein gut konzipiertes Überwachungssystem verfügen, das auf Anomalien achtet und automatisch Warnungen ausgibt, können Sie Probleme schnell erkennen und deren Schweregrad bestimmen. Wenn das Problem als Notfall eingestuft wird, kann der Plan in die Tat umgesetzt werden. In einigen Fällen wird das Supportteam nicht über das Überwachungssystem benachrichtigt. Benutzer können dem Support Probleme melden, indem sie die Kommunikationswege des Supportteams nutzen. Oder sie wenden sich an Personen, mit denen sie regelmäßig zusammenarbeiten oder von denen sie wissen, dass sie mit Power Platform zusammenarbeiten, z. B. Ihre Power Platform Dienstadministratoren oder das Center of Excellence-Team. Unabhängig davon, auf welchem Weg das Supportteam benachrichtigt wird, sollte es immer dieselben Schritte befolgen, um das Problem zu validieren und den Schweregrad zu bestimmen. Abweichungen vom Reaktionsplan können zu Stress und Verwirrung führen.

Selektierung

Der erste Schritt bei der Problembehebung besteht darin, die Komponente der Arbeitslast zu identifizieren, die das Problem verursacht. Die Schritte, die Sie während der Triage befolgen, hängen von der Art des Problems ab. Das Team für einen bestimmten Bereich der Workload-Unterstützung sollte Verfahren für Vorfälle erstellen, die mit seiner Arbeit zusammenhängen. Beispielsweise sollten Sicherheitsteams Sicherheitsprobleme priorisieren und den von ihnen entwickelten Skripts folgen. Es ist wichtig, dass die Teams bei der Durchführung ihrer Triage-Bemühungen klar definierten Skripten folgen. Bei diesen Skripts sollte es sich um Schritt-für-Schritt-Anleitungen handeln, die Rollback-Prozesse enthalten, um Änderungen rückgängig zu machen, die unwirksam sind oder andere Probleme verursachen können. Nachdem das Problem behoben wurde, befolgen Sie klar definierte Prozesse, um die betroffene Komponente sicher wieder in die Workload-Flusspfade zu integrieren.

Ursachenanalyse-Berichterstellung

Der Eigentümer des Vorfalls oder jemand, der eng mit ihm zusammengearbeitet hat, sollte die Berichte zur Ursachenanalyse (RCA) erstellen. Diese Strategie gewährleistet eine genaue Darstellung des Vorfalls. Normalerweise verfügen Organisationen über eine definierte RCA-Vorlage mit Richtlinien zur Präsentation von Informationen und dazu, welche Arten von Informationen weitergegeben werden dürfen und welche nicht. Wenn Sie Ihre eigenen Vorlagen und Richtlinien erstellen müssen, stellen Sie sicher, dass die Stakeholder diese überprüfen und genehmigen.

Obduktion von Vorfällen

Eine unparteiische Person sollte eine Obduktion durchführen, bei der keine Schuld auffällt. In Post-Mortem-Sitzungen teilt jeder seine Erkenntnisse zu einem Vorfall mit. Jedes Team, das an der Reaktion auf den Vorfall beteiligt war, sollte durch Personen vertreten werden, die an dem Vorfall gearbeitet haben. Diese Personen sollten mit Beispielen für die erfolgreichen Maßnahmen und Bereiche, die verbessert werden können, vorbereitet in die Sitzung kommen. Die Sitzung ist kein Forum für Schuldzuweisungen für den Vorfall oder Probleme, die während der Reaktion auftreten könnten. Der Leiter der Post-Mortem-Sitzung sollte am Ende eine klare Liste mit verbesserungswürdigen Maßnahmen vorlegen, beispielsweise:

• Verbesserungen am Reaktionsplan. Um geeignete Maßnahmen besser zu erfassen, müssen Prozesse oder Verfahren möglicherweise neu bewertet und umgeschrieben werden.
• Verbesserungen am Überwachungssystem. Möglicherweise müssen die Schwellenwerte neu bewertet werden, um den spezifischen Vorfalltyp früher zu erfassen, oder es muss eine neue Überwachung implementiert werden, um nicht berücksichtigtes Verhalten zu erfassen.
• Verbesserungen der Arbeitsbelastung. Der Vorfall könnte eine Schwachstelle in der Arbeitslast aufdecken, die im Rahmen einer dauerhaften Behebung behoben werden muss.

Überlegungen

Ihre Notfallstrategie sollte eng auf Ihre allgemeine Power Platform Supportstrategie abgestimmt sein. Arbeiten Sie mir Ihren Power Platform Administratoren und dem Center of Excellence-Team zusammen, um Support- und Notfalloptionen und -prozesse zu diskutieren, die möglicherweise bereits definiert sind.

Beim Definieren Ihres Supportprozesses und Eskalationspfads ist es wichtig, die erstellten Lösungen nach Kritikalität zu kategorisieren. Auf diese Weise können Sie Prozesse einrichten, die sicherstellen, dass kritische Anwendungen über die notwendigen Schutzmaßnahmen verfügen, um sie zu unterstützen, ohne die Innovation von Produktivitätsszenarien zu behindern oder Ihre Incident-Response-Teams zu überfordern. Denken Sie bei der Definition Ihrer Unterstützungsmodelle auch an einen Abschlussweg. Eine Lösung kann zunächst nur Support auf Produktivitätsebene erfordern, aber an Funktionalität oder Benutzerbasis zunehmen und ein höheres Maß an Support erfordern. Legen Sie fest, wie Ersteller formelleren Support anfordern und eine Lösung auf unterstützte Umgebungen umstellen können.

Power Platform: schnellere Durchführung

Power Platform ist Teil des Application Insights, einen Teil des Azure Monitor-Ökosystems. Verwenden Sie diese Integration für Folgendes:

• Empfangen Sie Telemetriedaten zu Diagnose und Leistung, die von der Dataverse-Plattform in Application Insights erfasst werden. Sie können abonnieren, um Telemetriedaten zu Vorgängen zu erhalten, die Anwendungen in Ihrer Dataverse-Datenbank und in Modellgesteuerten Apps ausführen. Diese Telemetrie stellt Informationen bereit, mit denen Sie Probleme im Zusammenhang mit Fehlern und Leistung diagnostizieren und beheben können.

• Verbinden Sie Ihre Canvas-Apps mit Application Insights. Mithilfe dieser Analysen können Sie Probleme diagnostizieren und verstehen, was Benutzer mit Ihren Apps machen. Sie können Informationen sammeln, um bessere Geschäftsentscheidungen zu treffen und die Qualität Ihrer Apps zu verbessern.

• Konfigurieren Sie die Power Automate Telemetrie, die in die Application Insights einfließen sollen, z. B. um Cloud-Flow-Ausführungen zu überwachen und Warnungen für fehlgeschlagene Cloud-Flow-Ausführungen zu erstellen.

• Erfassen Sie Telemetriedaten von Ihrem Microsoft Copilot Studio Agent für die Verwendung in Azure Application Insights. Sie können diese Telemetrie verwenden, um protokollierte Nachrichten und Ereignisse zu überwachen, die an und von Ihrem Agent gesendet werden, Themen, die während Benutzerunterhaltungen ausgelöst werden sollen, und benutzerdefinierte Telemetrieereignisse, die von Ihren Themen gesendet werden können.

Application Insights ist eine umfassende Lösung zum Sammeln, Analysieren und Reagieren auf Überwachungsdaten aus Cloud- und lokal-Umgebungen. Es umfasst eine robuste Warnplattform, die Sie für automatische Benachrichtigungen und andere Aktionen konfigurieren können.

Das Power Platform Automation Kit besteht aus einer Reihe von Tools, die die Verwendung und die Unterstützung von Power Automate für Desktop für Automatisierungsprojekte beschleunigen. Das Kit bietet Tools, mit denen Sie Automationsprojekte verwalten und überwachen können, um die eingesparten Kosten und den Return on Investment (ROI) abzuschätzen. Teil des Automation-Kits ist das Control Center, das die vorhandene Funktion Desktop-Flowausführungen überwachen ergänzt. Der Schwerpunkt des Kontrollzentrums liegt auf einer Orchestrator-Ansicht für Support-Analysten und Organisationen, um bei Bedarf zu überwachen, Maßnahmen zu ergreifen und Warnungen auszugeben.

Verwandte Informationen

• Empfehlungen für die Konzeption und Erstellung eines Überwachungssystems
• Empfehlungen für die Entwicklung einer zuverlässigen Überwachungs- und Warnstrategie
• Benutzer und Ersteller-Supportstrategie

Nächste Schritte,