Verstehen, an wen Sie sich wenden können und was während eines Vorfalls zu erwarten ist
Wenn wir über einen „Vorfall“ sprechen, sprechen wir speziell über ein Problem auf unserer Microsoft/Azure-Seite – ein plattformseitiges Problem, das sich auf Ihre Dienste auswirkt. Bei diesen seltenen, aber unvermeidlichen Problemen möchten wir Ihnen so viel Transparenz wie möglich bieten, indem wir Sie regelmäßig direkt von unseren Ingenieuren informieren. Wir bemühen uns, die richtigen Personen über die richtigen Kanäle zu informieren und so viele Details wie möglich zu teilen.
Obwohl wir im Allgemeinen keine Spekulationen oder das Vorgehen bei der Fehlerbehebung preisgeben, teilen wir alles, was wir über den Vorfall wissen. Es gibt keine Verzögerungen bei der Benachrichtigung - auch nicht bei detaillierten Mitteilungen - je nach Kundengröße oder -segment, Partnerstatus oder Supportplan. So werden Microsoft-Partnerorganisationen und sogar Microsoft-Kundenteams zur gleichen Zeit und mit den gleichen Updates benachrichtigt wie die betroffenen Kunden, die sie vertreten.
Während eines Incidents
Überprüfen Sie Azure Service Health im Azure-Portal auf die neuesten Updates unserer Techniker.
Wenn Sie ein Problem bemerken und herausfinden müssen, „ob es an uns oder an Azure liegt“, sollten Sie als erstes die Azure Service Health im Portal überprüfen. Obwohl Sie diese Anlaufstelle kennen sollten, sollten Sie nicht reaktiv nach Informationen suchen müssen, wenn Sie zuvor die entsprechenden Warnmeldungen für den Dienstzustand konfiguriert haben. Während eines bekannten Problems werden diese Dienststatuswarnungen ausgelöst, und sie werden über ihren ausgewählten Kommunikationskanal benachrichtigt.
Hinweis
Als Erinnerung richten Sie die Dienstintegritätswarnung ein, um über den Kanal Ihrer Wahl benachrichtigt zu werden (E-Mail, SMS, Webhook)
Wenn Probleme beim Zugriff auf den Dienststatus oder das Portal selbst auftreten, überprüfen Sie die öffentliche Azure-Statusseite.
Für den unwahrscheinlichen Fall, dass ein Dienstproblem den Zugriff auf Service Health im Azure-Portal verhindert, wird azure.status.microsoft verwendet, um Problem-Updates zu veröffentlichen. Diese Seite wird nur für Probleme verwendet, die den üblichen Kommunikationspfad unterbrechen, oder für seltene, weit verbreitete Probleme.
Es ist wichtig, Sie daran zu erinnern, dass azure.status.microsoft wirklich als Sicherung für Azure Service Health dient. Die meisten unserer Mitteilungen zu Dienstproblemen werden als gezielte Benachrichtigungen direkt an die betroffenen Abonnements oder Tenants gesendet. Diese Bekanntmachungen werden im Azure-Portal über Azure Service Health bereitgestellt und lösen alle konfigurierten Azure Service Health-Warnungen aus. Die öffentliche Statusseite (azure.status.microsoft) wird nur für die Kommunikation über Dienstprobleme in drei spezifischen Szenarien verwendet:
Szenario 1: weitläufige Auswirkungen auf mehrere Regionen, Zonen oder Dienste: Ein Dienstproblem hat weitläufige bzw. erhebliche Auswirkungen für Kunden, da mehrere Dienste in einer gesamten Region oder mehreren Regionen betroffen sind. In diesem Fall benachrichtigen wir Sie, da die vom Kunden konfigurierte Ausfallsicherheit wie Hochverfügbarkeit oder Notfallwiederherstellung möglicherweise nicht ausreicht, um Auswirkungen zu vermeiden.
Szenario 2: Das Azure-Portal oder Service Health ist nicht zugänglich: Ein Dienstproblem verhindert, dass Sie auf das Azure-Portal oder Azure Service Health zugreifen können und hat somit den zuvor beschriebenen Standardkommunikationspfad bei Ausfällen außer Kraft gesetzt.
Szenario 3: Es gibt Dienstauswirkungen, aber Sie sind nicht sicher, wer genau betroffen ist: Das Dienstproblem hat weitläufige bzw. erhebliche Kundenauswirkungen. Wir können jedoch noch nicht bestätigen, welche Kunden, Regionen oder Dienste betroffen sind. In diesem Fall können wir keine gezielte Kommunikationen senden und stellen daher öffentliche Bekanntmachungen bereit.
Wenn es Probleme mit der Statusseite gibt, suchen Sie nach Updates über @AzureSupport auf X.
Nur wenige Male in der Geschichte von Azure gab es technische Probleme, die das Veröffentlichen von Vorfallupdates auf azure.status.microsoft verhindern ‒ in diesen außergewöhnlichen Umständen veröffentlichen wir Vorfallupdates über X unter @AzureSupport. Unabhängig vom Problem sollten sich die Kunden bei Fragen zu möglichen Problemen oder bei Supportanfragen an @AzureSupport wenden. Das @AzureSupport-Team antwortet in der Regel in weniger als 5 Minuten (darauf sind wir sehr stolz!), aber es ist wichtig zu wissen, dass bei bekannten Problemen (z. B. wenn ein Ausfall in Service Health aufgeführt ist) der Vorfall bereits von den richtigen Technikern bearbeitet wird, so dass das @AzureSupport-Team möglicherweise nicht viel tun kann, um zu helfen, abgesehen davon, dass es die Kunden auf die offiziellen technischen Updates verweist.
Wenn Ihre Auswirkungen/Probleme nicht mit dem Vorfall übereinstimmen (oder wenn diese nach der Entschärfung beibehalten werden), wenden Sie sich an den Support.
Dies ist der wichtigste Hinweis für Kunden, um zu verstehen, was während eines Vorfalls zu tun ist (oder nicht zu tun). Wie bereits erwähnt, wird bei bekannten Problemen (z. B. wenn ein Ausfall in Service Health aufgeführt ist) der Vorfall bereits von den richtigen Technikern bearbeitet, sodass Kunden den Support nicht für Updates kontaktieren müssen. Sie erhalten regelmäßige Updates über den Dienststatus (und ihre Dienststatus-Warnungen) und Supporttechniker haben keinen Zugriff auf detailliertere Informationen als die, die betroffenen Kunden bereitgestellt werden. Wenn Kunden die Updates von den Technikern gelesen haben, aber Support benötigen, um auf den Vorfall zu reagieren (z. B. um ihre Failover-Pläne umzusetzen), können und sollten sie ein Support-Ticket erstellen.
Ähnlich verhält es sich, wenn die festgestellten Symptome nicht mit den Symptomen übereinstimmen, die in den Problem-Updates beschrieben werden (z. B. wenn es ein bekanntes Problem mit dem Redis Cache in USA, Osten gibt, aber Probleme mit einem Redis Cache in USA, Osten 2 festgestellt werden), dann kann es sein, dass es keinen Zusammenhang gibt, und Kunden können und sollten ein Supportticket erstellen. Wenn ein Dienstproblem gelöst/behoben ist, der Kunde aber immer noch Probleme mit seinen Diensten hat, können die Support-Techniker ihm dabei helfen, herauszufinden, ob etwas Besonderes mit seinen Ressourcen im Gange ist, sodass der Kunde ein Supportticket erstellen kann und sollte.