„Incidents wie Dienstausfälle sind in der Technologiebranche leider unvermeidlich. Natürlich verbessern wir die Zuverlässigkeit der Microsoft Azure-Cloudplattform ständig. Für die Mehrheit der Kunden werden die SLAs (Service Level Agreements, Vereinbarungen zum Servicelevel) nicht nur erfüllt, sondern sogar übertroffen. Wir investieren dennoch weiterhin in Tools und Schulungen, damit Sie unternehmenskritische Systeme mühelos und zuverlässig entwerfen und betreiben können.

Trotz dieser Bemühungen sind wir uns der Realität bewusst, dass wir Ausfälle aufgrund des Umfangs unseres Betriebs und des Veränderungstempos niemals vollständig vermeiden können. In dieser besonderen Zeit möchten wir so offen und transparent wie möglich sein, damit betroffene Kunden und Partner die Situation nachvollziehen können. Für die Blogreihe Advancing Reliability habe ich den Principal Program Manager Sami Kubba gebeten, unseren Kommunikationsprozess für Ausfälle im Blick zu behalten, um die Investitionen aufzuzeigen, die wir in die Verbesserung dieser Incidents tätigen.“ —Mark Russinovich, CTO, Azure

---

 

In der Cloudbranche müssen wir dafür sorgen, unseren Kunden immer die neueste Technologie zugänglich zu machen, damit diese und unsere Plattform geschützt bleiben. Darüber hinaus muss die Kundenfreundlichkeit stets gewährleistet sein. Deshalb müssen an Azure viele Änderungen vorgenommen werden – und in seltenen Fällen führen genau diese Änderungen zu unbeabsichtigten Auswirkungen auf unsere Kunden. Wie wir bereits in vorherigen Blogbeiträgen dieser Reihe erwähnt haben, nehmen wir Änderungen sehr ernst und sorgen stets für einen systematischen Ansatz in Phasen, um diese so sorgfältig wie möglich zu implementieren.

Wir arbeiten fortlaufend daran, die inhärenten (und manchmal subtilen) Unvollkommenheiten in der komplexen Weise zu identifizieren, auf die unsere Architekturen, betrieblichen Prozesse, Hardwareprobleme, Softwarefehler und Mitarbeiter zu Dienstincidents führen, die auch als Ausfälle bezeichnet werden. Beeinträchtigungen durch Änderungen sind ein wesentliches Problem unserer Branche. In Bezug auf die Kommunikation bei Ausfällen sehen wir nicht andere Cloudanbieter als Konkurrenz, sondern eher die lokale Umgebung. Lokale Änderungsfenster werden von Administratoren gesteuert. Sie wählen den am besten geeigneten Zeitpunkt für Änderungen aus, verwalten und überwachen Risiken und machen die Änderungen rückgängig, falls Fehler auftreten.

Wenn ein Ausfall in einer lokalen Umgebung auftritt, haben Kunden und Partner das Gefühl, besser über die Situation in Kenntnis zu sein. Die Führungsebene wird sofort über den Ausfall informiert, der Support kann zur Problembehandlung kontaktiert werden, und es wird davon ausgegangen, dass das Team oder Partnerunternehmen einen vollständigen Post-Incident Report (PIR, zuvor Root Cause Analysis) erstellen kann, sobald das Problem nachvollzogen werden konnte. Obwohl unsere Datenanalyse die Hypothese stützt, dass ein Incident in der Cloud schneller als in einer lokalen Umgebung behoben werden kann, sind Cloudausfälle für Kunden belastender, da sie das Problem und ihre eigenen Möglichkeiten schlechter einschätzen können.

Einführung unserer Kommunikationsprinzipien

Bei vergangenen Cloudausfällen hatten Kunden oft das Gefühl, dass sie nicht umgehend informiert werden oder wichtige Updates verpassen und deshalb die Problemsituation und die Maßnahmen, um diese zukünftig zu verhindern, nicht vollständig verstehen. Aufgrund dieser Erkenntnisse arbeiten wir jetzt nach fünf Säulen, die unsere Kommunikationsstrategie stützen. Diese haben sich bereits positiv auf Azure Service Health im Azure-Portal ausgewirkt und lauten:

1. Geschwindigkeit
2. Granularität
3. Erkennbarkeit
4. Parity
5. Transparenz

Geschwindigkeit

Wir müssen betroffene Kunden so schnell wie möglich benachrichtigen. Das ist unser wichtiges Ziel bei der Kommunikation zu Ausfällen. Alle betroffenen Azure-Abonnements sollen bei einem Ausfall innerhalb von 15 Minuten informiert werden. Wir wissen, dass wir das nicht allein mit menschlicher Leistung realisieren können. Bis ein Engineer damit beauftragt wurde, eine Überwachungswarnung zu untersuchen, um die Beeinträchtigung zu bestätigen, vergeht zu viel Zeit. Dabei müssen vor allem die richtigen Engineers beauftragt werden, was unter anderem zu komplizierten Vernetzungen führen und Drittanbieter einschließen kann. Bei einer verzögerten Kommunikation fragt der Kunde sich, ob das Problem an ihm oder an Azure liegt. Dadurch verbringen die Kunden möglicherweise unnötig Zeit damit, in ihren Umgebungen nach Problemen zu suchen. Wenn wir uns jedoch dafür entscheiden, aus Vorsicht über jede potenzielle Beeinträchtigung zu informieren, würden die Kunden zu viele falsch positive Meldungen erhalten. Noch wichtiger ist sogar, dass diese bei einem Problem mit ihrer Umgebung denken könnten, dass es mit von der Plattform gesendeten falschen Warnungen zusammenhängt. Es ist von entscheidender Bedeutung, dass unsere Investitionen zu einer schnellen und genauen Kommunikation führen.

Im letzten Monat haben wir unsere fortwährenden Investitionen erläutert, um die Dienstqualität von Azure mit künstlicher Intelligenz zu steigern: AIOps. Dazu zählt auch die Verbesserung der automatischen Erkennung, der Mobilisierung zuständiger Mitarbeiter und der Behebung von Cloudausfällen. Einige Elemente des umfassenderen AIOps-Programms werden bereits in der Produktion verwendet, um Kunden über Ausfälle zu informieren, die sich auf ihre Ressourcen auswirken können. Diese automatischen Benachrichtigungen stellten mehr als die Hälfte unserer Ausfallkommunikation im letzten Quartal dar. Bei vielen Azure-Diensten werden automatische Benachrichtigungen in weniger als 10 Minuten über Service Health an betroffene Kunden gesendet. Diese können über das Azure-Portal aufgerufen werden oder konfigurierte Service Health-Warnungen auslösen.

Durch die Investitionen in diesem Bereich konnte die Kundenfreundlichkeit bereits verbessert werden. Wir erweitern jedoch die Szenarios, in denen Kunden in weniger als 15 Minuten nach Auftreten der Beeinträchtigung benachrichtigt werden, ohne dass diese von Mitarbeitern bestätigt werden muss. Wir befinden uns auch in einer frühen Phase der Erweiterung des Einsatzes von KI-basierten Vorgängen, um ähnliche betroffene Dienste automatisch zu erkennen und nach der Behebung so schnell wie möglich Mitteilungen zur Behebungen (für unterstützte Szenarios) zu senden.

Granularität

Bei einem Ausfall müssen Kunden genau wissen, welche Ressourcen betroffen sind. Eines der wichtigsten Verfahren zum Überprüfen der Integrität bestimmter Ressourcen sind Resource Health-Signale. Ein Resource Health-Signal überprüft, ob eine Ressource (z. B. eine VM, eine SQL-Datenbank oder ein Speicherkonto) fehlerfrei ausgeführt wird. Kunden können auch Resource Health-Warnungen erstellen, die Azure Monitor nutzen, um den zuständigen Mitarbeitern mitzuteilen, ob bei einer bestimmten Ressource Probleme vorliegen – unabhängig davon, ob es sich um ein plattformweites Problem handelt. Ein wichtiger Hinweis: Eine Resource Health-Warnung kann ausgelöst werden, wenn eine Ressource in einen fehlerhaften Zustand übergeht (z. B., wenn die VM innerhalb des Gasts neu gestartet wird), was nicht notwendigerweise mit einem Plattformereignis wie einen Ausfall in Zusammenhang steht. Kunden werden die zugehörigen Resource Health-Prüfungen nach Ressourcentyp angezeigt.

Wir bauen auf dieser Technologie auf, um die einzelnen Kundenressourcen, die in einen fehlerhaften Zustand übergegangen sind, in Service Health zu analysieren und mit Plattformausfällen zu korrelieren. Wir untersuchen auch, wie wir die betroffenen Ressourcen in unsere Kommunikationsnutzlasten einbeziehen können, damit sich Kunden nicht bei Service Health anmelden müssen, um nachzuvollziehen, welche Ressourcen betroffen sind – das sollte für alle Benutzer programmgesteuert möglich sein.

Dadurch wissen Kunden mit vielen Ressourcen genauer, welche Dienste von einem Ausfall betroffen sind, ohne zuerst eine Untersuchung auf ihrer Seite durchführen zu müssen. Noch wichtiger ist, dass Kunden Warnungen erstellen und Antworten auf diese Ressourcenintegritätswarnungen mithilfe nativer Integrationen mit Logic Apps und Azure Functions veranlassen können.

Erkennbarkeit

Obwohl wir Push- und Pullansätze für die Kommunikation bei Ausfällen unterstützen, sollten Kunden relevante Warnungen konfigurieren, damit die korrekten Informationen automatisch an die richtigen Mitarbeiter und Systeme weitergeleitet werden. Unsere Kunden und Partner sollten nicht selbst herausfinden müssen, ob wichtige Ressourcen von einem Ausfall betroffen sind, sondern die von uns über ein Medium ihrer Wahl gesendeten Nachrichten nutzen können und entsprechend auf diese reagieren. Trotzdem stellen wir immer wieder fest, dass Kunden die Azure-Statusseite aufrufen, um die Integrität von Azure-Diensten nachzuprüfen.

Vor der Einführung des authentifizierten Service Health-Features im Portal waren bekannte Plattformprobleme nur auf der Statusseite ersichtlich. Mittlerweile wird die öffentliche Statusseite nur noch verwendet, um weitreichende Ausfälle (z. B., wenn mehrere Regionen und/oder Dienste betroffen sind) bekanntzugeben, damit diese für Kunden übersichtlicher ist, die nach potenziell relevanten Probleme suchen. Da der Rollout von Plattformänderungen so sicher wie möglich erfolgen soll, betreffen die meisten Probleme (wie Ausfälle) nur einen geringen Anteil der Kundenabonnements. Bei diesen Incidents, die über 95 % aller Incidents ausmachen, werden betroffene Kunden im Portal direkt über Service Health kontaktiert.

Kürzlich haben wir auch das Feature „Neu auftretende Probleme“ in Service Health integriert. Wenn ein Incident auf der öffentlichen Statusseite vorhanden ist und die betroffenen Kunden noch ermittelt und benachrichtigt werden müssen, werden diese Informationen den Benutzern im Portal über Service Health angezeigt, sodass sie nicht die Statusseite aufrufen müssen, um alle relevanten Informationen zu erhalten. Wir empfehlen allen Azure-Benutzern, sich ausschließlich in Service Health über Dienstincidents zu informieren, damit nur die Probleme angezeigt werden, von denen sie betroffen sind, sowie die betroffenen Abonnements und Ressourcen. So können keine falschen Schlüsse gezogen werden, wie es der Fall sein kann, wenn ein Incident auf der Statusseite veröffentlicht wird, der sie jedoch nicht betrifft.

Der wichtigste Punkt in Bezug auf die Erkennbarkeit ist jedoch, dass Service Health-Kunden eigene Service Health-Warnungen erstellen können, bei denen es sich um Pushbenachrichtigungen handelt, die die Integration mit Azure Monitor nutzen. So können Kunden und Partner relevante Benachrichtigungen auf Grundlage der relevanten Empfänger und der Benachrichtigungsmethode konfigurieren. Zu diesen zählen E-Mails, SMS, LogicApp und/oder ein Webhook, der in Dienstverwaltungstools wie ServiceNow, PagerDuty oder Opsgenie integriert werden kann.

Beim Einrichten einfacher Warnung sollten Sie darauf achten, dass alle Benachrichtigungen per E-Mail an eine einzelne Verteilerliste weitergeleitet werden. Anschließend sollten Sie unterschiedliche Service Health-Warnungen für verschiedene Anwendungsfälle konfigurieren. Produktionsprobleme könnten eine Benachrichtigung an ServiceNow auslösen, Probleme in der Entwicklungs-, Test- oder Präproduktionsphase könnten per E-Mail an das zuständige Entwicklerteam gesendet werden, und bei Problemen mit bestimmten Abonnements könnten die Zuständigen per SMS benachrichtigt werden. Die Optionen sind vollständig anpassbar, sodass sichergestellt wird, dass die richtigen Personen über die richtigen Kanäle informiert werden.

Parity

Allen Azure-Kunden sollte Service Health als zentrale Anlaufstelle für Ereignisse bekannt sein, die Dienste beeinträchtigen. Zunächst einmal stellen wir sicher, dass der Ablauf für alle Azure-Dienste gleich ist, da einheitlich Service Health verwendet wird, um über Probleme zu informieren. Das klingt zwar ganz einfach, doch wir arbeiten immer noch an einigen besonderen Szenarios, die dies komplex gestalten. Die meisten Benutzer von Azure DevOps verwenden das Azure-Portal beispielsweise nicht. Da es für DevOps kein eigenes, authentifiziertes Service Health-Feature gibt, können betroffene Kunden bei geringfügigen DevOps-Ausfällen, die nicht für die Statusseite infrage kommen, nicht direkt über Updates benachrichtigt werden. Für solche Szenarios haben wir die Azure DevOps-Statusseite eingerichtet, auf der die DevOps-Community direkt über geringfügige DevOps-Ausfälle informiert wird.

Außerdem wurde Service Health so entworfen, dass alle beeinträchtigenden Ereignisse direkt über Azure kommuniziert werden. Das gilt für Wartungsereignisse, die Außerbetriebnahme von Diensten oder Features, weitreichende Ausfälle und isolierte Aussetzer, die nur ein Einzelabonnement betreffen. Es ist unerlässlich, dass der Ablauf bei jeder Beeinträchtigung (ob potenziell, bereits vorliegend oder bevorstehend) für Kunden einheitlich und für alle Azure-Dienste ein vorhersagbarer Aktionsplan vorhanden ist.

Schließlich arbeiten wir daran, unsere Philosophie hinter dieser Säule auch auf andere Microsoft-Cloudprodukte auszuweiten. Wir wissen, dass die unterschiedlichen Cloudprodukte wie Azure, Microsoft 365 und Power Platform sich manchmal wie Technologien von drei verschiedenen Unternehmen anfühlen. Für die Zukunft planen wir, diese erstklassigen Produkte zu vereinheitlichen, damit die Bedienung konsistenter wird.

Transparenz

In der Blogreihe „Advancing Reliability“ wurde bereits mehrfach erwähnt, dass Vertrauen verdient und gepflegt werden muss. Wenn Ausfälle auftreten, ist es äußerst wichtig, transparent zu vermitteln, welche Situation vorliegt, was bekannt ist und was noch in Erfahrung gebracht werden muss. Die Cloud sollte sich nicht wie eine Blackbox anfühlen. Bei Dienstproblemen werden betroffene Kunden und Partner auf dem Laufenden gehalten. In den frühen Phasen der Untersuchung eines Problems enthalten diese Updates möglicherweise erst detaillierte Informationen, wenn wir mehr über die Geschehnisse wissen. Eigentlich sollten unsere Updates jedoch aussagekräftig und nicht spekulativ sein, da wir wissen, dass unsere Kunden Geschäftsentscheidungen auf Grundlage dieser Updates während Ausfällen treffen.

Zudem ist ein Ausfall nicht vorbei, nur weil die Beeinträchtigung auf Kundenseite behoben wurde. Wir finden möglicherweise anschließend noch mehr über die komplexen Ursachen des Problems heraus. Manchmal stellen die Meldungen während oder nach einer Behebung also eine rudimentäre Zusammenfassung der Situation dar. Schwerwiegenden Incidents folgt in der Regel innerhalb von drei Tagen ein PIR, sobald die verursachenden Faktoren näher bekannt sind.

Bei Incidents, die sich auf weniger Abonnements ausgewirkt haben, können Kunden und Partner über Service Health einen PIR anfordern, um weitere Informationen zu erhalten. Wir haben in der Vergangenheit Feedback erhalten, dass die PIRs transparenter sein sollten. Deshalb haben wir unsere Incident Manager und Communication Manager angewiesen, so viele Informationen wie möglich aufzunehmen – auch über die Auswirkung des Problems und die nächsten Schritte, um zukünftige Risiken zu vermeiden. So kann diesen idealerweise versichert werden, dass diese Probleme zukünftig unwahrscheinlicher auftreten und/oder geringere Auswirkungen haben.

Unsere Branche ist zwar niemals vollständig gegen Dienstausfälle gewappnet, doch wir nutzen jede Chance, Incidents aus ganzheitlicher Perspektive zu betrachten und unsere Erkenntnisse weiterzugeben. Eine der wichtigsten zukünftigen Investitionsbereiche ist, wie wir Kunden optimal über den Fortschritt auf dem Laufenden halten, den wir bei den Versprechen machen, die wir in den nächsten Schritten der PIR geben. Indem wir interne Reparaturschritte mit externen Verpflichtungen in den nächsten Schritten verknüpfen, können Kunden und Partner den Fortschritt unserer Engineeringteams bei der Umsetzung der Korrekturmaßnahmen verfolgen.

Die Kommunikation für diese Szenarios (Ausfälle, Wartung, Außerbetriebnahme von Diensten, Integritätsempfehlungen) wird immer weiter verbessert, je mehr wir dazulernen und in die Programme investieren, die diese fünf Säulen stützen.

Zuverlässigkeit als gemeinsame Verantwortung

Während Microsoft für die Zuverlässigkeit der Azure-Plattform zuständig ist, sind unsere Kunden und Partner für die Zuverlässigkeit ihrer Cloudanwendungen zuständig. Das schließt die Umsetzung von bewährten Architekturmethoden je nach Workloadanforderungen ein. Die Entwicklung einer zuverlässigen Cloudanwendung unterscheidet sich von der herkömmlichen Anwendungsentwicklung. Früher haben Kunden möglicherweise redundante, höherwertige Hardware erworben, um das Risiko des Ausfalls einer gesamten Anwendungsplattform zu minimieren. In der Cloud wird von vornherein mit Ausfällen gerechnet. Wie bereits erwähnt, können Ausfälle nie vollständig vermieden werden. Microsoft versucht zwar, Fehler zu verhindern, doch Sie sollten bei der Entwicklung zuverlässiger Cloudanwendungen darauf achten, dass die Auswirkungen einzelner fehlerhaften Komponenten so minimal wie möglich sind.

Zu diesem Zweck haben wir kürzlich das Microsoft Azure Well-Architected Framework veröffentlicht, das verschiedene Grundsätze umfasst, mit denen die Qualität einer Workload verbessert werden kann. Zuverlässigkeit ist neben Kostenoptimierung, optimalem Betrieb, Leistungseffizienz und Sicherheit eine der fünf Säulen für herausragende Architektur. Wenn Sie bereits eine Workload in Azure ausführen und die Übereinstimmung mit den bewährten Methoden in einem oder mehreren dieser Bereiche bewerten möchten, können Sie das Microsoft Azure Well-Architected Review testen.

Die Säule „Zuverlässigkeit“ beschreibt insbesondere sechs Schritte für die Erstellung einer zuverlässigen Azure-Anwendung. Definieren Sie Verfügbarkeits- und Wiederherstellungsanforderungen auf der Grundlage zerlegter Workloads und geschäftlicher Anforderungen. Verwenden Sie bewährte Architekturmethoden, um potenzielle Schwachstellen in der vorgeschlagenen oder vorhandenen Architektur zu ermitteln, und finden Sie heraus, wie die Anwendung auf Fehler reagiert. Verwenden Sie Simulationen und erzwungene Failover, um die Erkennung und Wiederherstellung bei verschiedenen Fehlern zu testen. Stellen Sie die Anwendung konsistent mithilfe zuverlässiger und wiederholbarer Prozesse bereit. Überwachen Sie die Anwendungsintegrität, um Fehler zu ermitteln, überwachen Sie Indikatoren für potenzielle Fehler, und bestimmen Sie die Integrität Ihrer Anwendungen. Schließlich müssen Sie auf Fehler und Notfälle reagieren, indem Sie anhand der etablierten Strategien die geeigneten Gegenmaßnahmen auswählen.

Nun wenden wir uns wieder dem Kernthema zu, der Kommunikation bei Ausfällen. Wir arbeiten daran, relevante Inhalte des Well-Architected-Leitfadens in unsere PIRs zu integrieren, die nach einem Dienstincident erstellt werden. Kunden, die kritische Workloads ausführen, können sich so informieren, welche Schritte die Zuverlässigkeit so verbessern können, dass die Beeinträchtigung durch diesen Ausfall vermieden oder verringert wird. Wenn ein Ausfall beispielsweise nur Ressourcen in einer Verfügbarkeitszone betroffen hat, wird das in den PIRs erwähnt, und Kunden wird empfohlen, ihre kritischen Workloads zonenredundant zu gestalten.

Blick in die Zukunft

Wir haben erläutert, welchen Ansatz Azure bei der Kommunikation während und nach Dienstincidents wie Ausfällen verfolgt. Unsere fünf Säulen der Kommunikation sollen transparent sein, damit Sie den aktuellen Fortschritt und die Bereiche kennen, in die wir weiterhin investieren. Genau wie unsere Engineeringteams von jedem Incident lernen, die Zuverlässigkeit der Plattform zu verbessern, lernen unsere Kommunikationsteams, transparenter zu agieren, damit Kunden und Partnern die richtigen Informationen vorliegen, um fundierte Entscheidungen zu treffen. So werden diese auch in schwierigen Situationen bestmöglich unterstützt.

Wir sind zuversichtlich, dass diese Investitionen zu Verbesserungen in diesem Bereich führen. Dennoch schätzen wir Feedback zu unserer Kommunikation weiterhin. Am Ende jedes veröffentlichten PIR finden Sie eine Umfrage zu Azure-Incidents. Wir bemühen uns, jede Antwort zu lesen, um von unseren Kunden und Partnern zu lernen. Zudem können wir so auswerten, ob wir uns auf die richtigen Bereiche konzentrieren und weitere Verbesserungen vornehmen.

Wir arbeiten fortlaufend daran, die inhärenten (und manchmal subtilen) Unvollkommenheiten in der komplexen Weise zu identifizieren, auf die unsere Architekturen, betrieblichen Prozesse, Hardwareprobleme, Softwarefehler und Mitarbeiter zu Ausfällen führen. Da Vertrauen verdient und gepflegt werden muss, möchten wir so transparent wie möglich sein – insbesondere in Bezug auf diese seltenen, aber unvermeidlichen Dienstprobleme.