Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Un incident est un événement non planifié qui interrompt, dégrade ou menace de perturber le fonctionnement normal d’un système. Les incidents affectent souvent négativement les clients ou une entreprise. Ils existent sur un spectre, de perturbations temporaires ou localisées à des événements ou des catastrophes généralisées. Parmi les exemples d’incidents de sécurité, citons les violations de données, les violations réglementaires, les programmes malveillants ou les compromissions d’identité. Les causes incluent des défaillances matérielles ou d’infrastructure, des limites de ressources, des erreurs humaines telles que des déploiements défaillants ou des configurations incorrectes, ou des facteurs externes tels que des attaques de sécurité.
La gestion des incidents (IcM) offre une approche systématique pour restaurer le service pendant les interruptions. Il coordonne la détection, l’enquête, l’atténuation et la résolution, tout en assurant une communication claire et en documentant des informations pour l’amélioration continue. La réponse aux incidents suit le même playbook quel que soit le type d’incident.
Lorsque vous créez votre plan IcM, ne vous concentrez pas uniquement sur les tableaux de bord et les runbooks. En tant qu’architecte, les opérations de conception où les personnes, les processus et les outils travaillent ensemble sous pression pour restaurer les systèmes efficacement et sans chaos. Votre stratégie IcM doit être mise à l’échelle en fonction de la gravité, de l’atténuation rapide des incidents mineurs aux efforts inter-équipes coordonnés pour les événements majeurs. La réponse peut également varier en fonction de la cause.
Cet article se concentre sur les phases d’IcM, qui incluent la préparation, la réponse active aux incidents, l’examen post-incident et l’amélioration continue. Ces conseils incluent également un exemple pour illustrer les pratiques de conception. Avant de commencer, passez en revue les stratégies clés et choisissez celles qui sont logiques pour votre entreprise. Pour plus d’informations, consultez OE :08 stratégies d’architecture pour la conception d’un processus IcM.
Cet article ne couvre pas les catastrophes nécessitant des efforts de récupération spécialisés. Pour plus d’informations sur la gestion de ces scénarios, consultez Développer un plan de récupération d’urgence pour les déploiements multirégions.
Terminologie
Avant de commencer à développer votre plan de gestion des incidents, familiarisez-vous avec ces termes clés.
| Terme | Definition |
|---|---|
| Rayon d’explosion | L’étendue de l’impact ou de la zone affectée lorsqu’un incident se produit, que les stratégies de confinement visent à limiter. |
| Comptes de rupture | Accès d'urgence ayant des privilèges élevés, utilisés lors des incidents critiques et strictement contrôlés avec des directives d'utilisation claires. |
| Équipe passerelle | L’équipe de triage qui se réunit pour enquêter sur un incident, également appelée passerelle d’ingénierie. Il se compose d’experts techniques et de décideurs pertinents. |
| Inclusion | La première étape de la correction des incidents qui isole les composants affectés pour empêcher le problème de se propager à d’autres parties de la charge de travail. |
| Gestion des incidents (IcM) | Processus structuré de détection, de triage, d’atténuation et de résolution des incidents tout en coordonnant la communication et en capturant les leçons apprises. |
| Last-known-good | Dernier état sain de la charge de travail avant le début d’un incident, utilisé comme point de référence pour les opérations de restauration vers l'état antérieur. |
| Atténuation | Actions pour réduire ou supprimer l’impact d’un incident, notamment la restauration, le repli, le contournement ou les correctifs d’urgence. |
| Rétrospective | Un processus d’examen post-incident sans blâme s’est concentré sur l’identification des leçons apprises et des améliorations actionnables plutôt que sur l’affectation de la responsabilité. |
| Analyse de la cause racine (RCA) | Processus d'investigation systématique d’un incident afin d’identifier les facteurs sous-jacents responsables du problème et d’éviter sa récurrence. |
| Niveau de gravité | Un système de classification, tel que critique, élevé, moyen et faible, qui détermine le niveau de réponse approprié en fonction de l’impact de l’entreprise et des utilisateurs affectés. |
| Triage | Processus d’analyse et de hiérarchisation des incidents pour déterminer la gravité, l’effet et les actions de réponse appropriées. |
Préparation
Avant qu’un incident ne se produise, configurez la base d’une réponse efficace en concevant l’observabilité, en définissant des rôles et des processus clairs et en préparant les outils et ressources dont vos équipes ont besoin. Documentez le plan de réponse aux incidents et mettez à jour et examinez-le régulièrement.
Conservez des diagrammes d'architecture précis et à jour montrant tous les composants et leurs interactions pour aider les équipes à identifier rapidement les goulots d'étranglement ou les points de défaillance uniques. Cette approche permet une résolution plus rapide des problèmes pendant les situations à haute pression.
Définissez les données d’incident que votre pile de surveillance doit fournir pour l’ensemble de la charge de travail :
Collecter des données de télémétrie de bout en bout, notamment l’infrastructure et les applications.
Activez la journalisation structurée pour tous les composants afin de prendre en charge le triage et l’investigation, et envoyez des journaux aux récepteurs de données à des fins d’analyse. Si nécessaire, transférez également les journaux vers des points de collecte gérés de manière centralisée. Assurez-vous que les membres de l’équipe disposent d’un accès temporaire avec un minimum de privilèges pendant les incidents.
Créez des tableaux de bord basés sur le modèle de santé de la charge de travail. Les tableaux de bord affichent des métriques et des signaux que votre équipe surveille.
Configurez des alertes actionnables qui déclenchent des notifications uniquement lorsque des seuils sont dépassés et qu’un incident potentiel est détecté. Paramétrez les alertes pour éviter un trop grand nombre d’alertes (bruit) ou trop peu d’alertes. Par exemple, pour les incidents de site en direct, les alertes doivent surveiller les métriques critiques telles que l’unité centrale de traitement (UC), la mémoire, les temps de réponse et les performances de la base de données pour détecter des problèmes actionnables qui s’alignent sur les cibles de performances.
Acheminer automatiquement les alertes vers les équipes appropriées. Par exemple, la prise en charge de niveau 1 obtient toutes les alertes, tandis que les ingénieurs de sécurité reçoivent uniquement des alertes liées à la sécurité.
Pour plus d’informations, consultez Recommandations pour la conception et la création d’une infrastructure d’observabilité.
Définissez les rôles clés pour assurer la responsabilité, la prise de décision et le suivi efficace pendant et après les incidents. Créez des processus d’approbation appropriés et codifiez-les dans un arbre de décision clair. Définissez les niveaux d’autorisation pour différents types de gravité, les décisions d’atténuation, les chemins d’escalade et d’autres domaines.
Utilisez les exemples suivants comme point de départ et adaptez-les pour adapter votre structure d’équipe.
Role Responsabilités Gestionnaire de réponse aux incidents Gère l'incident de la détection jusqu'à la résolution et l'analyse des causes racines. Garantit que les processus sont suivis, que les décisions sont prises et que les bonnes personnes sont informées. Leader rétrospectif Mène des examens post-incidents, capture les leçons apprises, produit des rapports actionnables et garantit que les résultats sont appliqués. Ingénieur à l’appel Atténue et résout activement les incidents. Suit les responsabilités pour différents types d’incidents et collabore avec des équipes spécialisées selon les besoins pour garantir la résolution en temps opportun de l’incident. Définissez les procédures d’investigation :
Définissez des catégories pour les types d’incidents, tels que les incidents opérationnels, de sécurité, de performances et de déploiement, ainsi que les niveaux de gravité, tels que critiques, élevés, moyens et faibles, qui s’appliquent à votre charge de travail.
Documentez comment évaluer la gravité, l’impact et l’urgence de l’incident. Tenez compte de l’impact de l’utilisateur, des systèmes affectés et des fonctions critiques pour l’entreprise. En fonction du niveau de gravité, l’équipe active le plan de récupération d’urgence pour les cas qui répondent aux seuils de niveau sinistre. Ou ils suivent le plan de réponse standard pour les incidents moins graves.
Définissez des stratégies qui isolent ou suppriment le composant affecté des chemins de flux de charge de travail, telles que l’arrêt d’une ressource ou la réacheminement du trafic. Identifiez les rôles qui ont l’autorité de prendre des mesures de confinement.
Définissez les systèmes de surveillance pour lancer automatiquement l’isolement pour les incidents définis. Cette approche maintient les humains dans le processus pour les décisions critiques. Les administrateurs système, les ingénieurs et les développeurs principaux doivent collaborer pour limiter le rayon d’explosion tout en conservant les fonctionnalités détériorées. Si un composant doit rester disponible pour le triage, isolez strictement son accès du reste de la charge de travail.
Créez des instructions pour sélectionner des stratégies d’atténuation en fonction de la gravité des incidents, telles que l’isolation, la restauration, les modifications de configuration et les solutions de contournement.
Spécifiez les équipes ou les personnes qui gèrent l’incident en fonction du type et de la gravité. Incluez des chemins d’escalade lorsque les répondeurs initiaux ne peuvent pas résoudre le problème.
Décrivez les données à collecter pendant le triage, telles que les journaux, les métriques, les rapports utilisateur et les alertes, pour prendre en charge l’examen et la prise de décision. Incluez également qui doit avoir accès à ces données.
Important
Protégez vos informations d’identification d’urgence ou vos comptes de secours en établissant des règles claires. Déterminez qui peut les utiliser, quand et exactement comment. Associez ces règles à des exercices d’urgence et suivez chaque exécution. Définissez la fréquence à laquelle l’équipe doit pratiquer des exercices. Au cours d’un incident, il n’y a pas de temps à le déterminer dans le moment. Les exercices offrent des possibilités adéquates de pratique et d’affinement.
Configurez votre infrastructure pour soutenir la résolution :
Paramétrez les pipelines. Permettre aux pipelines de déploiement et de récupération d’accepter des versions spécifiques pour une restauration rapide ou corriger le déploiement.
Vérifiez la cohérence du plan de données. Conservez les clés, les secrets, les configurations et les données d’état alignées pendant les opérations de récupération.
Automatisez la mise à l’échelle de l’infrastructure. Ajustez automatiquement les ressources pour gérer les décalages de trafic ou augmenter la charge.
Implémentez l’auto-guérison. Automatisez en toute sécurité les réponses aux modèles d’incident courants, mais incluez une surveillance et des options appropriées pour la substitution manuelle.
Définir des processus de communication. Documentez les plans de communication et d’escalade clairs afin que la prise en charge de niveau 1 puisse rapidement atteindre les bonnes équipes. Spécifiez les canaux de communication appropriés pour les parties prenantes internes et externes, et incluez des planifications d’appel et des coordonnées.
Définissez l’utilisation d’un outil IcM et les procédures d’exploitation standard qu’il doit capturer dans un flux de travail simple. Le flux de travail comprend quatre étapes : créer, reconnaître, atténuer et résoudre. L’outil offre une visibilité des équipes, suit la progression, maintient la responsabilité et garantit une gestion cohérente des incidents à tout moment. Il centralise toutes les activités pour prendre en charge la gestion des sites en direct et les rotations d’appel.
Définissez les critères qui marquent officiellement un incident comme fermé :
Incluez des facteurs de résolution clairs. En règle générale, la résolution signifie que le système et les services fonctionnent dans des contrats de niveau de service (SLA), que les performances et la fiabilité reviennent à des niveaux acceptables et que les actions d’atténuation immédiates se terminent correctement.
Effectuez des contrôles de validation pour confirmer la résolution complète. Utilisez les outils de surveillance pour vérifier que l’incident n’affecte plus le système et que les utilisateurs concernés ne subissent plus d’interruption.
Incluez les besoins en communication lorsque vous fermez un incident. Informez les parties prenantes pertinentes, y compris les équipes internes, le personnel de support et les utilisateurs concernés, et fournissez un résumé des actions prises avec le travail continu.
Incluez une documentation complète lorsque vous fermez un incident. Enregistrez tous les détails dans le système IcM. Incluez le déclencheur, les étapes de confinement, les décisions de triage et la résolution finale. Traitez cette documentation comme le transfert de la RCA et la rétrospective pour capturer les leçons apprises.
Important
Concevez vos opérations afin que seule l’autorité désignée, comme le Gestionnaire de réponse aux incidents, puisse fermer un incident. Appliquez des listes de contrôle strictes pour bloquer la fermeture prématurée. Ignorer les étapes peut laisser les problèmes masqués non résolus, ce qui peut transformer un incident fermé en sinistre répété.
Détecter, examiner et répondre
La phase 2 se concentre sur la détection et la réponse aux incidents rapidement et efficacement. Cette phase identifie les problèmes tôt, évalue leur impact et implémente les stratégies d’atténuation appropriées tout en limitant les perturbations. Cette phase garantit également que le triage, la résolution et la communication sont coordonnés, cohérents et responsables dans toutes les équipes.
Important
La communication claire et cohérente maintient le contrôle et la clarté dans les situations de stress élevé. Définissez exactement qui parle, ce qui est partagé et la fréquence à laquelle. Normaliser la cadence de mise à jour, les canaux et les formats de message afin que personne ne se brouillonise pour obtenir des informations pendant la crise. Assurez-vous que chaque partie prenantes, des ingénieurs aux cadres, sait quand attendre des mises à jour et quand l’escalade est nécessaire.
Agir immédiatement lorsque des alertes ou des rapports utilisateur indiquent un problème. Utilisez les outils d’observabilité et de performances pour mettre en corrélation les anomalies avec les modifications du système. Le destinataire de l’incident configure une équipe de triage (pont) avec les membres appropriés et accepte le mode de communication, le suivi de la progression et l’accès aux ressources d’incident.
Mobiliser le pont d’ingénierie pour évaluer l’impact et la gravité. Évaluez l’impact de l’incident à l’aide de vos classifications de gravité prédéfinies. Utilisez des données pour justifier les critères décrits dans le plan de réponse aux incidents, comme le nombre d’utilisateurs affectés, les fonctions métier interrompues, les implications en matière de sécurité et de conformité, ainsi que l’impact potentiel sur la confiance et la réputation des clients. Cette évaluation détermine le niveau de réponse approprié et guide les étapes d’atténuation suivantes.
L’étape d’investigation commence lorsque les équipes d’ingénierie appropriées sont engagées et démarrent une RCA. Ce processus implique une analyse technique approfondie pour identifier la cause et contenir l’impact. Les ingénieurs utilisent des données d’observabilité, des tableaux de bord de télémétrie, des journaux système et des historiques de modification pour tracer les anomalies et identifier les points d’échec. Ils se concentrent sur l’isolation rapide du problème, la validation des hypothèses à l’aide de données en temps réel et le développement d’un plan d’atténuation précis qui restaure la stabilité du service sans introduire de nouveaux risques.
Compromis: Une RCA peut prendre beaucoup de temps. Pour mettre en corrélation les problèmes de performances, vous devez collecter et stocker des données. Le temps nécessaire et l’infrastructure peuvent ajouter du travail supplémentaire aux équipes d’exploitation et au coût de la charge de travail.
Risque: Si vous effectuez une RCA sans garde-fous de sécurité appropriés, vous pouvez exposer des informations sensibles lorsque vous fournissez l’accès aux journaux de bord et aux données.Suivez les stratégies de confinement pour isoler les composants affectés et limiter le rayon d’explosion. Vous pouvez effectuer les actions suivantes :
Bloquer l’accès aux composants affectés à l’aide de chemins d’accès distincts pour le triage. Par exemple, vous pouvez arrêter une ressource, limiter le trafic ou désactiver un microservice défaillant.
Limitez l’accès de l’incident à des utilisateurs, régions ou composants spécifiques.
Maintenez la fonctionnalité de charge de travail dans un état détérioré si possible.
Sélectionnez une stratégie d’atténuation appropriée. Choisissez des approches d’atténuation en fonction de l’état actuel de la charge de travail, des ressources disponibles et des contraintes immédiates.
Votre choix dépend de facteurs tels que le type d’infrastructure, les mécanismes de contournement disponibles, la complexité du correctif, la sensibilité des données et les exigences de conformité, les dépendances système et les objectifs de temps de récupération (RTO).
Rollback: Rétablissez les systèmes mis à jour à leur dernier état stable connu. L’équipe de charge de travail doit définir ce que signifie le dernier bon moyen connu. Il fait généralement référence au dernier état sain de la charge de travail avant le début du déploiement, ce qui peut ne pas être la version immédiatement antérieure de l’application. La restauration peut être complexe, en particulier lorsque des modifications de schéma ou de données sont impliquées. Pour réduire les risques, faites des mises à jour de schémas additifs au lieu de remplacer les enregistrements. Les anciennes et nouvelles données peuvent coexister jusqu’à ce que vous puissiez supprimer en toute sécurité les enregistrements déconseillés. Les reprises peuvent nécessiter une planification et une coordination minutieuses entre plusieurs équipes.
Secours: Éliminez les systèmes mis à jour du réseau de production et redirigez tout le trafic vers l'environnement stable. Cette stratégie à faible risque résout les problèmes de déploiement sans provoquer d’interruptions supplémentaires. Le repli dans les déploiements canari peut être compliqué en fonction de la conception de l'application et de l'infrastructure. Assurez-vous d'une capacité adéquate sur l'infrastructure stable avant de rediriger le trafic. Fallback prend en charge l’opération continue et isole le déploiement problématique.
Contourner la fonction problématique : Utilisez des indicateurs de fonctionnalité ou des propriétés de configuration d’exécution pour contourner la fonctionnalité problématique. Cette approche permet au déploiement de continuer et d’isoler le problème. Évaluez les compromis et communiquez-les aux parties prenantes. Incluez la durée pendant laquelle vous pouvez tolérer un état détérioré et le temps estimé pour résoudre complètement le problème. Obtenez l’approbation des parties prenantes pour le plan.
Déploiement d’urgence (correctif rapide) : Déployez rapidement un correctif à chaud pendant le déploiement pour résoudre le problème. Suivez les pratiques de déploiement sécurisées, y compris la promotion du code par le biais d’environnements et de contrôles des seuils de qualité, mais accélérez les délais. Raccourcissez ou modifiez les temps de cuisson et les tests pour accélérer le déploiement. Utilisez des tests automatisés pour garantir la fiabilité. Les correctifs à chaud nécessitent une coordination et une planification minutieuse pour minimiser les risques et résoudre rapidement le problème.
Important
Assurez-vous que les décisions d’atténuation suivent les règles d’autorisation prédéfinies. Le Gestionnaire d’incidents doit gérer toutes les actions d’atténuation. Exiger que le personnel autorisé approuve les étapes à impact élevé et documente chaque action. Gardez les mesures contrôlées, sécurisées et responsables pendant la restauration du système.
Lorsqu’un problème affectant les utilisateurs survient à peu près au moment où votre équipe a déployé une modification, supposez que cette modification en est la cause probable et annulez-la immédiatement au lieu de passer beaucoup de temps à enquêter d’abord. Le temps nécessaire pour sélectionner la stratégie d’atténuation est pris en compte dans votre temps moyen de récupération (MTTR). Optimisez ce temps en prenant immédiatement des mesures d’atténuation.
Appliquez la résolution. Cette étape se concentre sur la restauration du système en pleine capacité opérationnelle tout en empêchant la récurrence. Les équipes d’ingénierie appliquent des correctifs vérifiés qui suivent des procédures de script spécifiques à l’équipe. Ils utilisent des outils d’analyse des journaux et de surveillance pour guider l’examen. Les étapes de restauration à un état antérieur annulent les modifications inefficaces pour s'assurer que chaque action dirige le système de manière cohérente vers une récupération complète.
Générez un rapport RCA. Après avoir résolu un incident, générez le rapport d'analyse post-incident dans le délai du SLA. Le propriétaire de l’incident, ou un membre d’équipe étroitement impliqué si le propriétaire n’est pas disponible, doit créer le rapport pour garantir la précision. Suivez un modèle RCA défini qui contient des instructions claires sur les informations à inclure et à partager, ou créez et approuvez un nouveau modèle par le biais de l’examen des parties prenantes.
Activités post-incident
Effectuez des rétrospectives après chaque incident. Ils offrent des opportunités d’apprentissage critiques, mettent en évidence les faiblesses en réponse, au déploiement ou à l’infrastructure, et informent les améliorations. Documenter les éléments d’action et les suivre dans un backlog pour l’implémentation itérative.
L’objectif n’est pas de blâmer, mais d’identifier les améliorations exploitables. Un animateur impartial devrait mener ce processus. Les personnes qui ont travaillé sur la réponse doivent représenter chaque équipe impliquée dans l’incident. Ils doivent être préparés avec des observations sur les réussites et les domaines d’amélioration :
Améliorations apportées au plan de réponse : Mettez à jour les processus ou procédures pour garantir des actions plus claires et plus efficaces.
Améliorations de l’observabilité : Ajustez les seuils, ajoutez une surveillance ou implémentez des alertes pour détecter des incidents similaires précédemment.
Correction de la charge de travail : Résolvez les vulnérabilités exposées pendant l’incident pour des correctifs permanents.
Exemple : Réponse aux échecs de déploiement
L’exemple suivant décrit un incident lié au déploiement. Même avec une planification et des tests prudents, les déploiements peuvent parfois introduire des problèmes qui affectent les performances du système ou l’expérience utilisateur.
Dans cet exemple, une équipe de charge de travail déploie une fonctionnalité d’amélioration de recherche qui inclut plusieurs composants :
- Nouveau point de terminaison d’API de recherche qui a amélioré la fonctionnalité de filtrage
- Schéma de base de données mis à jour
- Widget de recherche d’interface utilisateur repensé
- Nouvelle logique de mise en cache
L’équipe effectue les étapes suivantes pour détecter, atténuer et résoudre l’incident :
Détection: L’équipe remarque un problème lorsque les taux d’erreur augmentent dans l’un des groupes de déploiement canary. L’équipe utilise immédiatement ses outils d’observabilité, tels que la surveillance des performances des applications (APM), la journalisation et la télémétrie qui relient les utilisateurs aux phases de déploiement, pour identifier le groupe concerné.
L’équipe s’est préparée pour ce scénario en créant une observabilité forte dans son processus de déploiement. Ils ont exécuté des tests de fumée et des contrôles de qualité à chaque phase de déploiement et instrumenté leur application avec des métriques de journalisation, de suivi et de performances. La télémétrie lie les utilisateurs à des groupes de déploiement spécifiques, afin qu’ils puissent identifier rapidement la version affectée par les utilisateurs. Ils ont également planifié des déploiements pendant les heures de travail lorsque le support complet était disponible et s’est assuré que le personnel de soutien savait comment élever les problèmes en fonction du plan d’intervention d’urgence. Cette préparation leur permet de détecter rapidement le pic des taux d’erreurs et de répondre sans délai.
Atténuation: L’équipe décide rapidement d’une stratégie d’atténuation. Ils déterminent s’il faut restaurer la dernière version connue, revenir à l’environnement stable, contourner la fonction problématique à l’aide d’un indicateur de fonctionnalité ou déployer un correctif à chaud. L’arbre de décision et le processus d’approbation sont déjà définis.
Une fois que l’équipe passe en revue toutes les stratégies disponibles, ils restreignent leur choix au rollback ou au fallback, et décident finalement de fallback. Ils déterminent que la redirection du trafic vers la pile stable est plus rapide et moins risquée qu’une restauration complète, ce qui peut nécessiter des opérations complexes de données et de schémas. L’équipe confirme que l'infrastructure stable dispose d’une capacité suffisante pour gérer la charge de production complète et qu’elle peut isoler les systèmes actualisés de l'acheminement du trafic de production.
L’équipe a regroupé plusieurs modifications interdépendantes, notamment l’API, le schéma de base de données, les composants de l’interface utilisateur et la logique de mise en cache, afin d’identifier le composant spécifique qui a provoqué les erreurs est plus difficile et fastidieuse que si elles avaient déployé chaque modification séparément.
Résolution: L’équipe met en œuvre la procédure de secours. Ils déplacent le trafic hors de l’environnement mis à jour pour isoler le déploiement problématique. L’équipe peut résoudre le problème sous-jacent sans affecter la plupart des utilisateurs.
La solution de repli révèle des lacunes opérationnelles. Ils trouvent des informations de contact obsolètes pour deux membres clés de l’équipe, et un ingénieur de la chaîne d’escalade a quitté l’entreprise des mois plus tôt. L’équipe perd du temps pour déterminer l’individu responsable. Lorsqu’ils essaient de supprimer le déploiement mis à jour de l’équilibreur de charge, la documentation fait référence à une configuration obsolète de l’équilibreur de charge qui a changé dans une mise à jour Azure récente. Ils doivent trouver la procédure correcte sous pression temporelle.
La communication est un élément clé du plan d’atténuation. L’équipe informe les parties prenantes de la décision et de ses implications, y compris la chronologie attendue pour résoudre le problème dans l’environnement isolé. L’équipe a déjà normalisé la cadence pour fournir des mises à jour d’état pendant les incidents de déploiement, afin que les parties prenantes sachent quand attendre des rapports d’avancement et des mises à jour. L’équipe a également défini le type et le niveau de détail à partager avec les utilisateurs et assuré la conformité avec d’autres exigences pour les communications d’incident de déploiement. Cette approche structurée réduit la confusion et contribue à maintenir la confiance dans le processus de réponse.
Rétrospectif: Une fois que l’équipe a atténué l’incident de déploiement, elle effectue une rétrospective pour capturer les leçons apprises et améliorer les processus futurs. La session comprend tout le monde impliqué dans le déploiement, des développeurs et des opérateurs au soutien et aux représentants des parties prenantes. L’équipe passe en revue la séquence d’événements, de la détection à l’atténuation, pour comprendre ce qui s’est bien passé et où les lacunes existaient.
Un point important est que le regroupement des modifications apportées à l’API de recherche, les mises à jour de schéma de base de données, la refonte de l’interface utilisateur et la mise en cache des modifications de couche compliquent les efforts de résolution des problèmes et de récupération.
Améliorations post-incidents : À partir de la rétrospective, l’équipe implémente plusieurs améliorations opérationnelles pour rendre les déploiements futurs plus sûrs et les atténuations plus fiables :
Modifications plus petites et fréquentes : L’équipe se déplace vers des déploiements plus petits et incrémentiels afin de réduire le delta entre les versions successives et de simplifier et réduire les risques.
Pour l’amélioration de la recherche spécifiquement, l’équipe décide de déployer chaque composant indépendamment. Ils déploient désormais les modifications de schéma de base de données avec des modifications rétrocompatibles, puis les mises à jour du point de terminaison d’API, puis d’autres modifications. Cette approche permet à l’équipe de valider chaque couche indépendamment avant d’ajouter la couche suivante, et d’isoler plus facilement les problèmes à un composant spécifique.
Tests et exercices réguliers : L’équipe établit une pratique de test fréquent pour la stratégie d’atténuation des défaillances de déploiement complète. Ils introduisent des tests d’ingénierie de chaos et d’injection de pannes pour simuler des scénarios d’échec et valider les processus d’atténuation. Ces exercices réguliers auraient détecté les problèmes rencontrés pendant l’incident, y compris les informations de contact obsolètes et les procédures de runbook obsolètes.
Facilitation Azure
Microsoft fournit 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.
Azure Monitor est une solution pour collecter, analyser et répondre aux données de surveillance à partir d’environnements cloud et locaux. Il inclut une plateforme d’alerte 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 Azure Monitor pour intégrer le Machine Learning. Automatisez et optimisez le tri des incidents et les mesures proactives. Pour plus d’informations, consultez les opérations d’IA et le Machine Learning dans Azure Monitor.
Log Analytics est un outil d’analytique dans Azure Monitor. Vous pouvez utiliser Log Analytics pour exécuter des requêtes sur des journaux agrégés afin d'obtenir des aperçus sur votre charge de travail.
Application Insights est une extension d’Azure Monitor qui fournit des fonctionnalités APM.
Microsoft Sentinel est une solution SIEM (Security Information and Event Management) et d’orchestration de sécurité, d’automatisation et de réponse (SOAR). Il s’agit d’une solution unique pour la détection des alertes, la visibilité des menaces, la chasse proactive et la réponse aux menaces.
Azure Pipelines fournit des services de génération et de mise en production pour prendre en charge l’intégration continue et la livraison continue (CI/CD) de vos applications.
Azure Test Plans est une solution de gestion des tests basée sur un navigateur. Cette solution fournit des fonctionnalités requises pour les tests manuels planifiés, les tests d’acceptation des utilisateurs et les tests exploratoires. Les plans de test Azure vous permettent également de recueillir des commentaires des parties prenantes.
Azure Logic Apps est une plateforme cloud permettant d’exécuter des workflows automatisés qui intègrent des applications, des données, des services et des systèmes. Vous pouvez utiliser Logic Apps pour créer une nouvelle version de votre application lorsqu’elle obtient une mise à jour. Azure conserve un historique des versions et peut rétablir ou promouvoir n’importe quelle version précédente.
De nombreux services de base de données Azure fournissent des fonctionnalités de restauration dans le temps (PITR) qui peuvent vous aider quand vous devez restaurer :
Azure Chaos Studio est un service managé qui utilise l’ingénierie du chaos pour vous aider à mesurer, comprendre et améliorer votre application cloud et la résilience du service.