Recommandations pour la conception d’une stratégie d’intervention d’urgence

S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :

Ce guide décrit les recommandations relatives à la conception d’une stratégie d’intervention d’urgence. Certains problèmes qui surviennent au cours du cycle de vie d’une charge de travail sont suffisamment critiques pour justifier leur déclaration d’urgence. Vous pouvez implémenter des processus et procédures étroitement contrôlés et ciblés que votre équipe peut suivre pour vous assurer qu’un problème est géré de manière calme et ordonnée. Les situations d’urgence augmentent naturellement les niveaux de stress de tout le monde et peuvent entraîner un environnement chaotique si votre équipe n’est pas bien préparée. Pour réduire le stress et la confusion, concevoir une stratégie de réponse, partager la stratégie de réponse avec votre organisation et effectuer une formation régulière en réponse aux urgences.

Stratégies de conception

Une stratégie d’intervention d’urgence doit être un ensemble ordonné et bien défini de processus et de procédures. Chaque processus et procédure doit avoir des scripts pour vous assurer que chaque étape progresse votre équipe vers la résolution rapide et sécurisée d’un problème. Pour développer une stratégie d’intervention d’urgence, tenez compte de la vue d’ensemble suivante :

• Prérequis
  • Développer une plateforme d’observabilité
  • Créer un plan de réponse aux incidents
• Phases d’incident
  • Détection
  • Endiguement
  • Tri
• Phases post-incident
  • Analyse de la cause racine (RCA)
  • Analyse post-mortem
• Activité en cours
  • Exercices d’intervention d’urgence

Les sections suivantes fournissent des recommandations pour chacune de ces phases.

Pour avoir une stratégie robuste d’intervention d’urgence, vous devez disposer d’une plateforme d’observabilité robuste en place. Votre plateforme d’observabilité doit avoir les caractéristiques suivantes :

• Surveillance holistique : veillez à surveiller soigneusement votre charge de travail du point de vue de l’infrastructure et de l’application.

• Journalisation détaillée : activez la journalisation détaillée pour vos composants pour faciliter les enquêtes lorsque vous triez un problème. Structurez les journaux afin qu’ils soient faciles à gérer. Envoyez automatiquement des journaux aux récepteurs de données à préparer pour l’analyse.

• Tableaux de bord utiles : créez des tableaux de bord basés sur des modèles d’intégrité adaptés à chaque équipe au sein de votre organisation. Différentes équipes sont responsables de différents aspects de l’intégrité de la charge de travail.

• Alertes actionnables : créez des alertes utiles pour vos équipes de charge de travail. Évitez les alertes qui ne nécessitent pas d’action de vos équipes. Un trop grand nombre d’alertes de ce type peut entraîner l’ignorance ou le blocage des notifications d’alerte.

• Notifications automatiques : assurez-vous que les équipes appropriées reçoivent automatiquement des alertes qui nécessitent une action de leur part. Par exemple, votre équipe de support technique de niveau 1 doit recevoir des notifications pour toutes les alertes, tandis que vos ingénieurs de sécurité doivent uniquement recevoir des alertes pour les événements de sécurité.

Pour plus d’informations, consultez Recommandations pour la conception et la création d’une infrastructure d’observabilité.

Créer un plan de réponse aux incidents

La base d’une stratégie de réponse d’urgence est un plan de réponse aux incidents. Comme un plan de récupération d’urgence, définissez clairement et minutieusement les rôles, responsabilités et procédures d’un plan de réponse aux incidents. Le plan doit être un document contrôlé par la version soumis à des révisions régulières qui garantissent qu’il est à jour.

Définissez clairement les composants suivants dans votre plan.

Rôles

Identifiez un gestionnaire de réponse aux incidents. Cette personne possède l’incident de l’initiation à la correction de l’analyse de la cause racine. Un gestionnaire de réponse aux incidents garantit que les processus sont suivis et que les parties appropriées sont informées au fur et à mesure que l’équipe de réponse effectue son travail.

Identifiez un leader postmortem. Cette personne garantit que les postmortems sont effectués peu après la résolution de l’incident. Ils produisent un rapport qui vous aide à appliquer les résultats qui sortent de l’incident.

Processus et procédures

Votre équipe de charge de travail doit définir et comprendre les critères d’urgence. Lorsque votre équipe détermine qu’un cas est grave, vous pouvez déclarer un sinistre et lancer le plan de récupération d’urgence. Dans les cas moins graves, le problème risque de ne pas répondre aux critères d’une catastrophe. Mais vous devez toujours tenir compte de la question d’une urgence, ce qui nécessite de lancer le plan d’intervention d’urgence. Les urgences peuvent être des problèmes internes à votre charge de travail, ou ils peuvent être le résultat d’un problème avec une dépendance de votre charge de travail. L’équipe de support technique doit être en mesure de déterminer si un problème signalé par des utilisateurs externes répond aux critères d’urgence, même s’ils n’ont aucune visibilité sur le problème sous-jacent.

Définissez précisément les plans de communication et d’escalade. En fonction du type de notification d’alerte qu’ils reçoivent, assurez-vous que votre support de niveau 1 peut facilement contacter les équipes appropriées pour résoudre les problèmes. Assurez-vous qu’ils savent quel type de communication convient aux parties internes et externes. Dans les plans de communication et d’escalade, incluez une liste de la planification et du personnel à l’appel.

Dans le plan global, incluez les scripts de confinement et de triage. Les équipes suivent ces procédures pas à pas lorsqu’elles effectuent leurs fonctions d’isolement et de triage. Incluez une description de ce qui définit une fermeture d’incident.

Autres éléments à inclure

Documentez tous les outils standard qui seront utilisés pendant les incidents pour la communication interne, comme Microsoft Teams, et pour le suivi des activités au cours de l’incident, tels que les outils de gestion des tickets ou les outils de planification du backlog.

Documentez vos informations d’identification d’urgence, autrement appelées comptes de secours. Incluez un guide pas à pas qui décrit comment ils doivent être utilisés.

Créez des instructions d’extraction de réponse d’urgence et conservez un enregistrement du moment où des exercices ont été effectués.

Documentez toutes les mesures légales ou réglementaires nécessaires, par exemple la communication de violations de données.

Agir sur les déclencheurs d’observabilité

Lorsque vous disposez d’une plateforme d’observabilité bien conçue qui surveille les anomalies et les alertes automatiquement sur celles-ci, vous pouvez rapidement détecter les problèmes et déterminer leur gravité. Si la question est considérée comme une urgence, le plan peut être lancé. Dans certains cas, l’équipe de support technique n’est pas avertie via la plateforme d’observabilité. Les clients peuvent signaler des problèmes à prendre en charge à l’aide d’avenues de communication de l’équipe de support. Ou ils peuvent contacter des personnes avec lesquelles ils travaillent régulièrement, comme les cadres de compte ou les fournisseurs de services virtuels. Quelle que soit la façon dont l’équipe de support technique est avertie, elle doit toujours suivre les mêmes étapes pour valider le problème et déterminer la gravité. L’écart par rapport au plan de réponse peut ajouter du stress et de la confusion.

Définir des procédures de confinement

La première étape de la correction du problème consiste à contenir le problème pour protéger le reste de votre charge de travail. Une stratégie de confinement dépend du type de problème, mais elle implique généralement de supprimer le composant affecté des chemins de flux de charge de travail. Par exemple, vous pouvez arrêter une ressource ou la supprimer des chemins d’accès de routage réseau. Les administrateurs système, les ingénieurs et les développeurs supérieurs doivent collaborer pour concevoir des stratégies de confinement. L’endiguement doit limiter le rayon d’explosion des problèmes et maintenir la fonctionnalité de charge de travail dans un état détérioré jusqu’à ce que le problème soit résolu. Si un composant affecté doit être accessible pour effectuer le triage, il est essentiel que son accès au reste de la charge de travail soit bloqué. Autant que possible, vous devez uniquement accéder au composant via un chemin séparé de la charge de travail et du reste des systèmes.

Définir des procédures de triage

Une fois que vous avez réussi à contenir le problème, vous pouvez commencer le triage. Les étapes que vous suivez pendant le tri dépendent du type de problème. L’équipe pour un certain domaine de support de charge de travail doit créer des procédures pour les incidents liés à leur équipe. Par exemple, les équipes de sécurité doivent trier les problèmes de sécurité et suivre les scripts qu’elles développent. Il est important que les équipes suivent des scripts bien définis au fur et à mesure qu’elles travaillent dans leurs efforts de triage. Ces scripts doivent être des processus pas à pas qui incluent des processus de restauration pour annuler les modifications inefficaces ou peuvent entraîner d’autres problèmes. Utilisez les outils d’agrégation et d’analyse des journaux hors étagère pour examiner efficacement les problèmes nécessitant une analyse approfondie. Une fois le problème résolu, suivez les processus bien définis pour rétablir en toute sécurité le composant concerné dans les chemins de flux de charge de travail.

Générer des rapports d’incident RCA

Les contrats de niveau de service (SLA) à vos clients peuvent dicter que vous devez émettre des rapports RCA dans un certain délai après la résolution de l’incident. Le propriétaire de l’incident doit créer les rapports RCA. Si cela n’est pas possible, une autre personne ayant travaillé en étroite collaboration avec le propriétaire de l’incident peut créer les rapports RCA. Cette stratégie assure une comptabilisation précise de l’incident. En règle générale, les organisations ont un modèle RCA défini avec des instructions sur la façon dont les informations sont présentées et quels types d’informations peuvent ou ne peuvent pas être partagés. Si vous devez créer votre propre modèle et recommandations, vérifiez qu’ils sont examinés et approuvés par les parties prenantes.

Maintenir les postmortems de l’incident

Un individu impartial devrait mener des postmortems sans blâme. Dans les sessions postmortems, chacun partage ses résultats d’un incident. Chaque équipe impliquée dans la réponse aux incidents doit être représentée par des personnes qui ont travaillé sur l’incident. Ces personnes devraient venir à la séance préparée avec des exemples des domaines qui ont réussi et des domaines qui peuvent être améliorés. La session n’est pas un forum pour attribuer la responsabilité à l’incident ou aux problèmes susceptibles d’être rencontrés pendant la réponse. Le leader postmortem doit laisser la session avec une liste claire d’éléments d’action qui se concentrent sur l’amélioration, par exemple :

• Améliorations apportées au plan de réponse. Les processus ou procédures doivent peut-être être réévalués et réécrits pour mieux capturer les actions appropriées.

• Améliorations apportées à la plateforme d’observabilité. Les seuils doivent peut-être être réévalués pour intercepter le type spécifique d’incident précédemment, ou une nouvelle surveillance peut être implémentée pour intercepter le comportement qui n’a pas été pris en compte.

• Améliorations apportées à la charge de travail. L’incident peut exposer une vulnérabilité dans la charge de travail qui doit être traitée comme une correction permanente.

À propos de l’installation

Une stratégie de réponse excessivement agressive peut entraîner des fausses alarmes ou des escalades inutiles.

De même, l’implémentation agressive de la mise à l’échelle automatique ou d’autres actions d’auto-guérison pour répondre aux violations de seuil peut entraîner des dépenses inutiles et un fardeau de gestion. Vous ne connaissez peut-être pas les seuils exacts à définir pour les alertes et les actions automatiques telles que la mise à l’échelle. Effectuez des tests dans des environnements inférieurs et en production pour vous aider à déterminer les seuils appropriés pour vos besoins.

Facilitation Azure

Azure Monitor est une solution complète pour collecter, analyser et répondre aux données de surveillance à partir d’environnements cloud et locaux. Il inclut une plateforme d’alerte robuste que vous pouvez configurer pour les notifications automatiques et d’autres actions, telles que la mise à l’échelle automatique et d’autres mécanismes de réparation automatique.

Utilisez Monitor pour intégrer le Machine Learning. Automatisez et optimisez le tri des incidents et les mesures proactives. Pour plus d’informations, consultez AIOps et Machine Learning dans Monitor.

Log Analytics est un outil d’analytique robuste intégré à Monitor. Vous pouvez utiliser Log Analytics pour exécuter des requêtes sur des journaux agrégés et obtenir des insights sur votre charge de travail.

Microsoft offre une formation sur la préparation aux incidents liés à Azure. Pour plus d’informations, consultez Présentation de la préparation aux incidents Azure et de la préparation aux incidents.

Liens connexes

• Recommandations pour la conception et la création d’un framework d’observabilité
• Recommandations pour la conception d’une stratégie de surveillance et d’alerte fiable
• Recommandations en matière d’auto-guérison et de préservation de soi

Liste de contrôle d’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.