Ce qu’il faut faire lors d’une interruption de service Azure

Microsoft s’engage à déployer tous les efforts nécessaires pour vous garantir en permanence la disponibilité de ses services quand vous en avez besoin. Cependant, des interruptions de service non planifiées se produisent. Cet article explique ce qui se passe quand elles se produisent.

Microsoft fournit un contrat de niveau de service (SLA) pour un grand nombre de ses services à titre d’engagement quant au bon fonctionnement et à la connectivité. Le contrat de niveau de service des différents services Azure se trouve à la page Contrats de niveau de service Azure.

Comprendre l’étendue d’un incident

En cas d’incident, si vous comprenez l’étendue de celui-ci, vous pouvez déterminer les meilleures actions à entreprendre.

Pour comprendre l’étendue d’un incident, procédez comme suit :

1. Accédez à Azure Service Health, qui fournit les éléments suivants :

   • Informations sur les problèmes ou les événements susceptibles d’avoir un impact sur vos services.

   • Alertes de mise à jour automatique des incidents, qui vous permettent d’être averti automatiquement des mises à jour de l’état des incidents. Quand Microsoft comprend l’étendue d’un incident, nous mettons à jour l’état de celui-ci. Vous pouvez configurer ces mises à jour d’état pour accéder à un groupe d’actions Azure Monitor, qui peut envoyer des alertes à différents endroits, comme à une adresse e-mail ou à votre propre système de gestion des incidents.

2. Si vous rencontrez des problèmes d’accès au portail Azure, accédez à État d’Azure.

   Remarque

   État d’Azure montre seulement les problèmes généraux qui répondent à certains critères. Comme la page État Azure n’a pas connaissance des abonnements et des locataires que vous gérez, elle ne peut pas fournir une vue précise des problèmes plus restreints susceptibles d’avoir un impact sur vos services.

3. Si vous rencontrez des problèmes avec la page d’état, recherchez les billets de @AzureSupport sur la plateforme du réseau social X.

Incidents dans les zones de disponibilité et les centres de données

De nombreux problèmes sont limités à une seule zone de disponibilité. Les zones de disponibilité représentent des centres de données ou des groupes de centres de données isolés d’autres zones de disponibilité au sein de la même région. Quand une zone de disponibilité rencontre un problème, l’impact que vous voyez dépend de la façon dont un service est déployé :

• Les services zonaux qui sont rattachés à la zone de disponibilité affectée peuvent être affectés.
• Les services redondants interzones sont peu susceptibles d’être affectés. Vous n’avez pas besoin d’effectuer une action de correction pour les ressources redondantes interzones.
• Les services régionaux (non zonaux) peuvent être affectés, car ils peuvent utiliser la zone de disponibilité affectée.

Pour en savoir plus sur la prise en charge des zones de disponibilité dans les services Azure, et sur les différences entre les services zonaux, redondants interzones et régionaux (non zonaux), consultez Services Azure avec prise en charge des zones de disponibilité.

S’il existe des problèmes avec des ressources zonales ou régionales déployées dans la zone de disponibilité affectée, envisagez de lancer vos plans de continuité d’activité et de reprise d’activité (BC/DR).

Zones de disponibilité logiques et physiques

Chaque abonnement Azure voit une liste de zones de disponibilité différente. Les zones logiques utilisées par chaque abonnement peuvent correspondre à différentes zones physiques. Vous pouvez établir une correspondance entre vos zones logiques et les zones physiques pour voir quelles ressources s’exécutent dans la zone de disponibilité physique affectée. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

Incidents à l’échelle d’une région

Occasionnellement, les problèmes affectent une région entière. Des problèmes à l’échelle d’une région peuvent se produire quand une région n’a pas de zones de disponibilité. Quand un incident à l’échelle d’une région se produit, il peut être nécessaire d’envisager de lancer votre plan de récupération d’urgence. Votre plan peut inclure le basculement vers une autre région.

Donner la priorité à la continuité d’activité

En cas d’incident, la priorité absolue est de maintenir les activités de votre entreprise. Un effort trop important pour isoler ou traiter la cause d’un problème peut vous empêcher de vous consacrer à la restauration des opérations de votre solution et au maintien de la continuité d’activité.

Les facteurs suivants caractérisent des situations où vous n’avez pas nécessairement besoin de faire quoi que ce soit pour préserver la continuité d’activité :

• L’impact réel du problème sur vos ressources de production, et sur vos utilisateurs ou vos charges de travail. Par exemple, un problème qui se produit en dehors des heures d’ouverture standard peut ne pas vous obliger à faire quoi que ce soit immédiatement.

• L’étendue de l’incident. Pour des problèmes isolés dans une seule zone de disponibilité, vous n’avez peut-être pas besoin de faire quoi que ce soit si vous utilisez des ressources redondantes interzones ou si les ressources que vous utilisez se trouvent dans une zone de disponibilité physique non affectée.

• Le temps de résolution estimé, s’il est disponible. Microsoft s’efforce de fournir des chronologies claires pour la récupération dès que c’est possible. Si l’exécution de vos procédures de récupération va durer un certain temps, déterminez s’il est possible que le problème soit résolu au moment où elles vont se terminer.

• Les objectifs de niveau de service (SLO) établis avec les utilisateurs de votre charge de travail impactée, si vous en disposez. Les objectifs de niveau de service sont là pour guider la prise de décision dans ce genre de situation. Par exemple, dans certaines situations, vous pouvez passer à des opérations manuelles jusqu’à ce que vos services soient à nouveau sains, et cette décision peut être reflétée dans votre objectif de niveau de service pour le système. Pour en savoir plus sur les objectifs de niveau de service et comment les définir, consultez Recommandations pour définir des cibles de fiabilité dans Azure Well-Architected Framework.

Cependant, si la continuité d’activité nécessite une certaine forme d’action et que vous disposez d’un plan de récupération d’urgence, l’étape suivante consiste à déterminer s’il faut lancer ce plan.

Considérer votre plan de récupération d’urgence

Un plan de récupération d’urgence explique ce que vous devez faire en cas d’incident majeur. Les plans de récupération d’urgence incluent généralement des actions telles que les suivantes :

• Pour une panne isolée au sein d’une zone de disponibilité, effectuez un scale-out de la ressource si vous le pouvez.
• Pour une panne d’une zone de disponibilité quand vous utilisez des services zonaux, déployez dans une autre zone de disponibilité et basculez vers une autre zone de disponibilité.
• Pour une panne d’une zone de disponibilité quand vous utilisez des services redondants interzones, il se peut que vous n’ayez rien à faire. Si vous observez des problèmes de performances, envisagez d’effectuer un scale-out de votre ressource pour que les instances dans les zones restantes puissent traiter l’augmentation du trafic qu’ils reçoivent.
• Pour une panne régionale, déployez dans une autre région et basculez vers cette région.

Important

N’entreprenez aucune action sans bien y réfléchir. Les décisions prises à la hâte peuvent parfois faire empirer les choses. Si vous avez déjà développé un plan de récupération d’urgence qui couvre le scénario, il est généralement préférable de l’utiliser au lieu de créer un plan sur le moment.

Un basculement peut être un processus complexe. Vous ne devez déclencher un basculement que quand vous pouvez en justifier les coûts et les risques. Dans certaines situations, il peut entraîner une perte de données, par exemple si des modifications récentes n’ont pas été répliquées entre les régions avant le début d’un temps d’arrêt. Vous pouvez également rencontrer des temps d’arrêt, en particulier si vous avez devez rediriger le trafic vers un déploiement dans une autre région. Selon la façon dont votre solution est conçue, il peut être nécessaire de mettre à jour les enregistrements DNS et d’attendre qu’ils se propagent.

Basculement initié par Microsoft

Certains services Azure basculent automatiquement vers d’autres régions en cas d’incident. Microsoft gère le processus de basculement pour ces services. Cependant, le basculement lancé par Microsoft est généralement effectué en dernier recours et après que beaucoup de temps a été passé sur les tentatives de récupération. En général, la stratégie de Microsoft est de réduire la perte de données, même si cela signifie un temps de récupération plus long. Vous ne devez pas vous appuyer exclusivement sur les basculements lancé par Microsoft pour vos propres solutions, en particulier si vous devez réduire au minimum le temps de récupération. Si vous le pouvez, utilisez un basculement lancé par le client pour des services comme Stockage Azure.

Support Azure

Si l’incident du service est déjà communiqué dans Azure Service Health, les dernières informations y sont fournies et il n’est pas nécessaire d’ouvrir une demande de support.

Cependant, vous pouvez envisager d’ouvrir un cas de support quand :

• Vous voyez des problèmes qui ne sont pas couverts dans la description de l’incident sur Azure Service Health.

• Vous avez besoin d’une aide de Microsoft dans le cadre de vos efforts de récupération.

  Conseil

  Si vous êtes affecté par une interruption de service, vous serez en mesure d’ouvrir un ticket de support gratuit jusqu’à 72 heures après l’atténuation du problème pour obtenir l’aide dont vous pouvez avoir besoin pour les étapes nécessaires à la récupération.

Quand vous ouvrez un cas de support, expliquez clairement les ressources qui sont affectées et l’impact du problème. Spécifiez l’ID d’abonnement Azure et la région qui rencontre un problème. Définissez la gravité du cas de support en fonction de l’impact sur votre activité. Notez que de nombreux clients peuvent contacter le support Azure en réaction aux problèmes pendant une interruption de service Azure en dehors de ces conditions décrites. Cette charge supplémentaire pesant sur les ressources de support Azure peut malheureusement retarder la réponse à vos besoins de support.

Après un incident

1. Pour comprendre ce que Microsoft a appris de l’incident, lisez l’examen post-incident (PIR) dans le volet Historique des états d’Azure Service Health ou prenez en connaissance via les alertes Service Health configurées par le client. Différents incidents peuvent aboutir à différents types d’examens post-incident. Les examens post-incident préliminaires sont généralement publiés quelques jours après un incident, et des examens post-incident plus complets suivent quelques semaines plus tard.

2. Pour les incidents majeurs qui sont listés dans notre page des états publics, rejoignez un livestream Azure Incident Retrospective pour obtenir des réponses à toutes les questions ou regardez l’enregistrement.

3. Si vous pensez être éligible à un crédit SLA, créez une demande de support avec le type de problème « Demande de remboursement » et incluez l’ID de suivi de l’incident.

4. Tenez compte de ce que vous pouvez apprendre de l’incident pour améliorer votre propre résilience et vos propres processus. Prenez en compte des questions comme celles-ci :

   • Dans quelle mesure votre plan de récupération d’urgence a-t-il fonctionné ? Y a-t-il des améliorations que vous pourriez apporter ? Pour plus d’informations, consultez Aide d’Azure Well-Architected Framework sur les stratégies de récupération d’urgence.

   • Votre réponse à l’incident était-elle appropriée pour sa gravité ? Si ce n’est pas le cas, y a-t-il des moyens d’être mieux informé et de prendre de meilleures décisions ?

   • Existe-t-il des guides de fiabilité des services Azure pour les services que vous utilisez ? Les guides de fiabilité fournissent des informations sur le nombre de services Azure qui peuvent être configurés pour répondre à vos exigences de résilience.

   • Y a-t-il un compromis en termes de conception que vous pouvez faire afin d’améliorer votre résilience à l’avenir pour ce type de problème ? Pour plus d’informations, consultez le Pilier Fiabilité d’Azure Well-Architected Framework.

   • L’objectif de niveau de service (SLO) ou le contrat de niveau de service (SLA) est-il toujours approprié pour vos utilisateurs maintenant que vous avez fait l’expérience de cette panne non planifiée ? C’est le moment approprié pour revoir les engagements que vous avez pris auprès de votre base d’utilisateurs pour aligner les attentes sur ce que vous avez appris de cet incident.

   • Devez-vous configurer des alertes Azure Service Health pour être averti automatiquement des incidents futurs ?

5. Si vous avez des commentaires sur la façon dont nous pouvons améliorer notre réponse aux incidents, faites-le nous savoir via votre représentant Microsoft attitré ou via le site de retour d’expérience sur Azure.