Partager via

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

  • Article

S’applique à cette recommandation de liste de contrôle d’excellence opérationnelle Azure Well-Architected Framework :

OE :08 Développer une pratique efficace des opérations d’urgence. Assurez-vous que votre charge de travail émet des signaux d’intégrité significatifs dans l’infrastructure et le code. Collectez les données obtenues et utilisez-les pour générer des alertes actionnables qui mettent en œuvre des réponses d’urgence via des tableaux de bord et des requêtes. Définissez clairement les responsabilités humaines, telles que les rotations sur appel, la gestion des incidents, l’accès aux ressources d’urgence et les post-mortem en cours d’exécution.

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 des procédures étroitement contrôlés et ciblés que votre équipe peut suivre pour vous assurer qu’un problème est traité de manière calme et ordonnée. Les urgences augmentent naturellement le niveau 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, concevez une stratégie d’intervention, partagez la stratégie d’intervention avec votre organization et effectuez une formation régulière en cas d’urgence.

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 s’assurer que chaque étape progresse dans 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, considérez 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
    • Containment
    • 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.

Observabilité

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

  • Supervision 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 afin de faciliter les investigations lorsque vous triez un problème. Structurez les journaux afin qu’ils soient faciles à gérer. Envoyer 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 de votre organization. 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 la part 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é.

Plan de réponse aux incidents

La base d’une stratégie d’intervention d’urgence est un plan de réponse aux incidents. À l’instar d’un plan de récupération d’urgence, définissez clairement et complètement les rôles, les responsabilités et les procédures d’un plan de réponse aux incidents. Le plan doit être un document à version contrôlée qui fait l’objet de révisions régulières qui garantissent qu’il est à jour.

Définissez clairement les composants suivants dans votre plan.

Rôles

Identifier un gestionnaire de réponse aux incidents. Cette personne est propriétaire de l’incident de l’initiation à la correction jusqu’à l’analyse de la cause racine. Un gestionnaire de réponse aux incidents s’assure que les processus sont suivis et que les parties appropriées sont informées à mesure que l’équipe d’intervention effectue son travail.

Identifier un leader post-mortem. Cette personne s’assure que les post-mortems sont effectués peu après la résolution de l’incident. Ils produisent un rapport qui vous aide à appliquer les résultats 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 peut ne pas répondre aux critères d’un sinistre. Mais vous devez toujours considérer le problème comme une urgence, ce qui nécessite l’lancement du plan d’intervention d’urgence. Les urgences peuvent être des problèmes internes à votre charge de travail ou être le résultat d’un problème lié à une dépendance de votre charge de travail. L’équipe de support 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 faire remonter les problèmes. Assurez-vous qu’ils savent quel type de communication est approprié pour les parties internes et externes. Dans les plans de communication et d’escalade, incluez une liste de l’horaire d’appel et du personnel.

Dans le plan global, incluez les scripts de confinement et de triage. Les équipes suivent ces procédures pas à pas lorsqu’elles exécutent leurs fonctions de confinement et de triage. Incluez une description de ce qui définit la fermeture d’un 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 tout au long de l’incident, comme les outils de création de tickets ou les outils de planification du backlog.

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

Créez des instructions de forage d’intervention d’urgence et conservez un enregistrement de la date d’exécution des exercices.

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

Détection des incidents

Lorsque vous disposez d’une plateforme d’observabilité bien conçue qui surveille les anomalies et les alertes automatiquement, vous pouvez rapidement détecter les problèmes et déterminer leur gravité. Si le problème est considéré 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 au support à l’aide des voies de communication de l’équipe de support technique. Ils peuvent également contacter des personnes avec lesquelles ils travaillent régulièrement, comme des responsables de compte ou des 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.

Containment

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 la suppression du 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 expérimentés doivent collaborer pour concevoir des stratégies de confinement. Le confinement doit limiter le rayon d’explosion des problèmes et maintenir les fonctionnalités 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é. Dans la mesure du possible, vous devez uniquement accéder au composant via un chemin d’accès séparé de la charge de travail et du reste des systèmes.

Tri

Une fois que vous avez correctement contenu le problème, vous pouvez commencer le travail de triage. Les étapes que vous suivez pendant le triage dépendent du type de problème. L’équipe pour un certain domaine de prise en charge de la charge de travail doit créer des procédures pour les incidents liés à son é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 à mesure qu’elles effectuent leurs efforts de triage. Ces scripts doivent être des processus pas à pas qui incluent des processus de restauration pour annuler les modifications inefficaces ou susceptibles de provoquer d’autres problèmes. Utilisez des outils d’agrégation et d’analyse de journaux prêts à l’emploi pour examiner efficacement les problèmes qui nécessitent une analyse approfondie. Une fois le problème résolu, suivez des processus bien définis pour ramener en toute sécurité le composant affecté dans les chemins de flux de charge de travail.

Création de rapports RCA

Les contrats de niveau de service (SLA) de vos clients peuvent dicter que vous devez émettre des rapports RCA dans un certain laps de temps après la résolution de l’incident. Le propriétaire de l’incident doit créer les rapports RCA. Si ce n’est pas possible, une autre personne qui a travaillé en étroite collaboration avec le propriétaire de l’incident peut créer les rapports RCA. Cette stratégie garantit une comptabilité 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 vos propres instructions, assurez-vous qu’elles sont examinées et approuvées par les parties prenantes.

Post-mortems d’incident

Un individu impartial doit mener des post-mortem sans reproche. Dans les sessions post-mortem, tout le monde partage ses résultats d’un incident. Chaque équipe qui a participé à la réponse à l’incident 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 été réussis et des domaines qui peuvent être améliorés. La session n’est pas un forum pour attribuer le blâme pour l’incident ou les problèmes qui ont pu se produire pendant la réponse. Le responsable post-mortem doit quitter la session avec une liste claire des éléments d’action qui se concentrent sur l’amélioration, tels que :

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

  • Améliorations apportées à la plateforme d’observabilité. Les seuils peuvent devoir être réévalués pour intercepter le type spécifique d’incident précédemment, ou une nouvelle surveillance peut devoir être implémentée pour intercepter un 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 en tant que correction permanente.

Considérations

Une stratégie de réponse trop agressive peut entraîner de 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-réparation pour répondre aux dépassements de seuil peut entraîner des dépenses inutiles et une charge 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 la collecte, l’analyse et la réponse aux données de supervision à partir d’environnements cloud et locaux. Il comprend 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 d’auto-réparation.

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

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

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

Liste de contrôle de l’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de l’excellence opérationnelle