Comprendre ce qu’il faut faire et ce à quoi s’attendre pendant un incident
Quand nous parlons d’« incident », nous faisons référence en particulier à un problème du côté de Microsoft/Azure, un problème côté plateforme qui impacte vos services. Au cours de ces problèmes rares, mais inévitables, notre objectif est d’assurer une transparence maximale en fournissant des mises à jour régulières directement de nos ingénieurs. Nous nous efforçons d’informer les bonnes personnes en utilisant les bons canaux et de partager autant de détails que possible.
Bien que, généralement, nous ne partageons pas la partie spéculation ou les travaux internes des étapes de résolution des problèmes, nous partageons tout ce que nous savons sur l’incident. Il n’y a aucun délai dans les messages (même pour les messages détaillés, qui dépendent de la taille ou du segment du client, de l’état du partenaire ou du plan de support), de sorte que les organisations partenaires Microsoft et les équipes de compte Microsoft sont averties en même temps et des mêmes mises à jour que les clients impactés qu’ils représentent.
Pendant un incident
Consultez Azure Service Health dans le portail Azure pour connaître les dernières mises à jour de nos ingénieurs.
Si vous remarquez un problème et que vous avez besoin de savoir « si c’est de notre côté ou du côté d’Azure », votre premier réflexe doit être de consulter Azure Service Health dans le portail. Même s’il est important que vous sachiez où obtenir des informations, vous ne devez pas avoir besoin de les rechercher de manière réactive si vous avez configuré les alertes d’intégrité de service pertinentes au préalable. En cas de problème connu, ces alertes d’intégrité de service se déclenchent et sont communiquées sur le canal de communication choisi.
Remarque
N’oubliez pas de configurer une alerte Service Health pour recevoir une notification des communications du portail sur le canal de votre choix (e-mail, SMS, webhook)
Si vous rencontrez des problèmes pour accéder à Service Health ou au portail lui-même, consultez la page d’état Azure publique.
Dans le cas peu probable où un problème de service vous empêche d’accéder à Service Health dans le portail Azure, azure.status.microsoft est utilisé pour publier les mises à jour des problèmes. Cette page est utilisée uniquement pour les problèmes qui perturbent le chemin de communication habituel ou pour des problèmes généralisés rares.
Rappelez-vous que le site azure.status.microsoft sert vraiment de sauvegarde pour Azure Service Health. La plupart de nos communications sur les problèmes de service sont fournies sous forme de notifications ciblées envoyées directement aux abonnements ou locataires impactés. Celles-ci sont fournies via Azure Service Health dans le portail Azure, et déclenchent toutes les alertes Azure Service Health qui ont été configurées. La page d’état publique (azure.status.microsoft) est utilisée uniquement pour communiquer sur les problèmes de service dans trois scénarios spécifiques :
Scénario 1 - Impact étendu impliquant plusieurs régions, zones ou services - Un problème de service a un impact étendu/significatif sur les clients p plusieurs services pour une région complète ou plusieurs régions. Dans ce cas, nous vous informons parce que la résilience configurée par le client, comme la haute disponibilité ou la récupération d’urgence, peut ne pas être suffisante pour éviter l’impact.
Scénario 2 - Portail Azure / Service Health non accessible - Un problème de service vous empêche d’accéder au portail Azure ou à Azure Service Health, et a donc affecté notre chemin de communication de panne standard décrit précédemment.
Scénario 3 - Impact sur le service, mais incertitudes quant aux clients affectés - Le problème de service a un impact étendu/significatif sur le client, mais nous ne sommes pas encore en mesure de confirmer les clients, régions ou services affectés. Dans ce cas, nous ne sommes pas en mesure d’envoyer des communications ciblées. Nous fournissons donc des mises à jour publiques.
En cas de problèmes avec la page d’état, consultez @AzureSupport sur X pour voir s’il y a des mises à jour.
À quelques reprises seulement dans l’histoire d’Azure, il y a eu des problèmes techniques empêchant la publication des mises à jour des incidents sur azure.status.microsoft. Dans ces circonstances extraordinaires, nous publions les mises à jour des incidents sur X sur @AzureSupport. Quel que soit le problème, les clients ne doivent pas hésiter à contacter @AzureSupport pour toute question relative aux problèmes potentiels constatés ou pour des questions de support. L’équipe @AzureSupport répond généralement en moins de 5 minutes (nous en sommes très fiers !). Toutefois, sachez qu’en cas de problèmes connus (par exemple, une panne listée dans Service Health), l’incident est déjà traité par les ingénieurs appropriés, et l’équipe @AzureSupport ne sera potentiellement pas d’une grande aide, à part diriger les clients vers les mises à jour officielles des ingénieurs traitant le problème.
Si votre impact/problème ne correspond pas à l’incident (ou qu’il persiste après l’atténuation), contactez le support.
Il s’agit de la note la plus importante qui explique aux clients ce qu’il faut faire (ou ne pas faire) en cas d’incident. Comme mentionné ci-dessus, en cas de problèmes connus (par exemple, une panne listée dans Service Health), l’incident est déjà traité par les ingénieurs appropriés. Par conséquent, les clients n’ont pas besoin de contacter le support pour connaître les mises à jour. Ils recevront des mises à jour régulières via Service Health (et leurs alertes Service Health) et les ingénieurs du support n’ont pas accès à plus de détails que ce qui est fourni aux clients impactés. Si les clients ont lu les mises à jour des ingénieurs, mais ont besoin d’un support pour répondre à l’incident (par exemple, pour implémenter leurs plans de basculement), ils peuvent et doivent ouvrir un ticket de support.
De même, si les symptômes qu’ils observent ne semblent pas s’« aligner » sur les symptômes décrits dans les mises à jour du problème (par exemple, un problème connu avec un cache Redis dans USA Est alors qu’ils voient des problèmes avec un cache Redis dans USA Est 2), le problème rencontré n’est peut-être pas lié et les clients peuvent et doivent ouvrir un ticket de support. Enfin, si un problème de service est résolu/atténué mais que le client voit toujours des problèmes avec ses services, les ingénieurs du support peuvent l’aider à vérifier s’il se passe quelque chose de particulier avec ses ressources et, dans ce cas, le client peut et doit ouvrir un ticket de support.