Gestion des incidents - Modèles
En savoir plus sur l’excellence opérationnelle bien archivée → Gestion des incidents
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Surveillance | ✅ L’architecture d’alerte inclut la classification de la sévérité qui achemine immédiatement les incidents critiques (production non disponible, corruption des données, atteinte à la sécurité) vers les appels de garde. |
| Plate-forme | Surveillance | ✅ Les incidents de haute gravité (performances dégradées, panne partielle) génèrent des notifications immédiates pour une enquête rapide pendant les heures ouvrables |
| Plate-forme | Surveillance | ✅ Les avertissements (seuils proches, dérive de configuration) sont regroupés dans un résumé quotidien pour une correction proactive |
| Plate-forme | Surveillance | ✅ L’enrichissement des alertes inclut le contexte de diagnostic : nombre d’utilisateurs affectés, percentiles de taux d’erreur, déploiements récents, alertes associées et liens directs vers les tableaux de bord |
| Plate-forme | Surveillance | ✅ Le contexte d’alerte réduit le délai moyen d’acceptation en fournissant une évaluation de la situation immédiate sans recueillir d’informations de base via des requêtes séparées |
| Plate-forme | Surveillance | ✅ Le regroupement des alertes empêche les tempêtes d’alerte en regroupant des centaines d’alertes associées à partir d’un problème sous-jacent unique dans une notification avec des statistiques agrégées |
| Plate-forme | Surveillance | ✅ Les alertes groupées affichent le nombre, le taux et les transactions affectées qui révèlent un schéma de problème sans accabler les répondants |
| Plate-forme | Surveillance | ✅ La suppression des alertes empêche les conditions transitoires connues de générer des alertes pendant les périodes de maintenance ou de correction automatique attendues |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Surveillance | ⚠️ L’échec de l’intégration génère des alertes individuelles de 100s en 5 minutes de téléphone d’astreinte écrasant, chaque alerte étant identique à l’exception de l’horodatage |
| Plate-forme | Surveillance | ⚠️ Les alertes manquent de contexte sur la portée, les changements récents ou les schémas de problème ; l’ingénieur d’astreinte doit recueillir manuellement des informations de base |
| Plate-forme | Surveillance | ⚠️ Toutes les alertes transitent par le même canal quelle que soit la gravité ; les pannes critiques de production rivalisent d’avertissements mineurs |
| Plate-forme | Surveillance | ⚠️ Alerte le feu pendant les fenêtres de maintenance planifiées générant des faux positifs qui érodent Trust dans le système de surveillance |
| Plate-forme | Surveillance | ⚠️ Le regroupement d’alertes n’existe pas ; chaque échec de transaction déclenche une alerte séparée créant des tempêtes d’alerte lors d’incidents |
| Plate-forme | Surveillance | ⚠️ Les alertes ne fournissent aucun lien vers les tableaux de bord pertinents ; les intervenants passent du temps à trouver des outils de surveillance pendant les interventions en cas d’incident |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Opérations | ✅ La rotation d’astreinte est une répartition hebdomadaire ou bihebdomadaire de la charge d’équilibre avec la préservation du contexte |
| Plate-forme | Opérations | ✅ Les runbooks sont documentés pour chaque type d’alerte, ce qui permet aux ingénieurs d’astreinte de répondre efficacement sans expertise approfondie du domaine |
| Plate-forme | Opérations | ✅ Les runbooks comprennent une description du problème, des étapes de diagnostic, des procédures de réparation, des critères d’escalade et des liens vers la documentation associée |
| Plate-forme | Opérations | ✅ Runbooks sont des documents vivants dans le contrôle de version qui évoluent à travers les éléments d’action post-mortem |
| Plate-forme | Opérations | ✅ Les procédures de transfert comprennent de brèves réunions pendant les transitions de rotation, le contexte de transfert, y compris les problèmes actifs, les changements récents, les risques connus et la maintenance à venir |
| Plate-forme | Opérations | ✅ Les notes de transfert écrites complètent le transfert verbal empêchant la perte d’information pendant les transitions de rotation |
| Plate-forme | Opérations | ✅ La fréquence des pages, le nombre d’incidents après les heures de travail et le taux de faux positifs sont mesurés afin d’identifier les charges d’astreinte insoutenables nécessitant une réparation architecturale |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Opérations | ⚠️ Les runbooks n’existent pas ; les ingénieurs d’astreinte s’appuient sur les tribal Knowledge et les escalades fréquentes vers les experts en la matière |
| Plate-forme | Opérations | ⚠️ Les runbooks sont stockés dans des documents personnels plutôt que dans un contrôle de version partagé où les membres de l’équipe peuvent y accéder et les mettre à jour |
| Plate-forme | Opérations | ⚠️ Les transitions de rotation des astreintes se font sans réunion de transfert ; l’ingénieur entrant manque de contexte sur les problèmes actifs et les récents changements |
| Plate-forme | Opérations | ⚠️ La charge élevée des astreintes continue indéfiniment par l’héroïsme opérationnel plutôt que par la conduite d’améliorations architecturales |
| Plate-forme | Opérations | ⚠️ Les métriques d’astreinte (fréquence des pages, incidents après les heures de travail, faux positifs) ne sont pas suivies ; les modèles de charge restent invisibles |
| Plate-forme | Opérations | ⚠️ Les runbooks sont créés une fois lors du déploiement initial et ne sont jamais mis à jour à mesure que le système évolue ou que de nouveaux modes d’échec émergent |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Opérations | ✅ Les parcours d’escalade technique définissent les experts qui gèrent des domaines problématiques spécifiques |
| Plate-forme | Opérations | ✅ Les parcours d’escalade de gestion définissent les responsables qui reçoivent une notification en cas d’incident dépassant les seuils de gravité ou de durée |
| Plate-forme | Opérations | ✅ Les parcours d’escalade des fournisseurs documentent les procédures de création de requêtes de support Salesforce et les critères de sévérité |
| Plate-forme | Opérations | ✅ Les parcours d’escalade des dirigeants définissent les dirigeants qui reçoivent une notification en cas d’incidents critiques pour l’entreprise |
| Plate-forme | Opérations | ✅ Les critères d’escalade sont explicites et objectifs: niveaux de sévérité, seuils temporels, nombre d’utilisateurs affectés, évaluations d’impact métier |
| Plate-forme | Opérations | ✅ Les parcours d’escalade sont documentés dans des runbooks et accessibles en cas d’incident sans rechercher les coordonnées |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Opérations | ⚠️ Les parcours d’escalade ne sont pas documentés ; les ingénieurs d’astreinte perdent du temps à rechercher les contacts appropriés lors d’incidents |
| Plate-forme | Opérations | ⚠️ Les critères d’escalade sont vagues (« escalader si cela semble mauvais ») ; les intervenants n’ont pas d’orientation claire sur le moment où escalader |
| Plate-forme | Opérations | ⚠️ La notification de la direction arrive trop tard, car les seuils de sévérité ne sont pas définis ; les dirigeants sont informés des incidents par les utilisateurs |
| Plate-forme | Opérations | ⚠️ Les procédures d’escalade du support Salesforce ne sont pas documentées ; les équipes retardent l’ouverture des requêtes de support en perdant un temps de réponse précieux |
| Plate-forme | Opérations | ⚠️ Les contacts d’experts en la matière sont obsolètes ; les escalades atteignent des personnes incorrectes ou échouent pendant les changements de rotation |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Opérations | ✅ Des examens post-incident irréprochables sont effectués dans les 5 jours ouvrables suivant des événements opérationnels importants |
| Plate-forme | Opérations | ✅ La culture irréprochable se concentre sur les améliorations du système plutôt que sur le blâme individuel, créant une sécurité psychologique pour une évaluation honnête |
| Plate-forme | Opérations | ✅ La chronologie inclut une séquence détaillée depuis les conditions initiales jusqu’au premier signal, la détection, l’accusé de réception, l’enquête, la réponse, la récupération et la validation |
| Plate-forme | Opérations | ✅ Chronologie horodate chaque événement permettant l’analyse de la durée des phases de détection, de réponse et de récupération |
| Plate-forme | Opérations | ✅ La cause première identifie la défaillance technique ou l’état qui a directement causé l’incident, différent des facteurs contributifs |
| Plate-forme | Opérations | ✅ L’analyse des facteurs contributifs révèle des conditions organisationnelles, de processus ou architecturales qui ont activé ou amplifié l’impact des incidents |
| Plate-forme | Opérations | ✅ L’analyse de la détection évalue comment l’incident a été détecté et si la détection aurait pu être plus rapide |
| Plate-forme | Opérations | ✅ L’évaluation de la réponse identifie ce qui s’est bien passé pendant la réponse et ce qui a été plus lent ou plus difficile que nécessaire |
| Plate-forme | Opérations | ✅ Les éléments d’action sont spécifiques, attribués et limités dans le temps, empêchant la récurrence ou améliorant la réponse future |
| Plate-forme | Opérations | ✅ Les éléments d’action évitent de vagues améliorations (“améliorer la surveillance”) au profit de tâches concrètes (“ajouter une alerte pour un taux d’erreur d’API supérieur à 5% sur une fenêtre de 10min”) |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Opérations | ⚠️ La discussion après incident conclut que « la tâche par lot avait un bogue, nous l’avons corrigé » sans documentation ni améliorations systématiques |
| Plate-forme | Opérations | ⚠️ Les examens postérieurs à l’incident se concentrent sur la faute individuelle plutôt que sur les améliorations du système, détruisant la sécurité psychologique |
| Plate-forme | Opérations | ⚠️ La chronologie manque d’horodatage empêchant l’analyse de la durée ; l’équipe ne peut pas identifier si la détection ou la réponse a été lente |
| Plate-forme | Opérations | ⚠️ L’analyse des causes premières ne distingue pas la cause technique immédiate des facteurs contributifs organisationnels ou de processus |
| Plate-forme | Opérations | ⚠️ L’analyse de détection est ignorée ; les lacunes de surveillance qui ont permis aux utilisateurs de signaler d’abord les incidents ne sont pas identifiées |
| Plate-forme | Opérations | ⚠️ Les éléments d’action sont vagues sans propriétaire ni date d’échéance ; les améliorations sont discutées mais jamais mises en œuvre |
| Plate-forme | Opérations | ⚠️ Les examens postérieurs à l’incident ne sont pas effectués dans les 5 jours ouvrables; le contexte est perdu et l’urgence d’améliorations s’estompe |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Gestion des Knowledge | ✅ Les examens postérieurs à un incident sont documentés et partagés largement au-delà des intervenants immédiats pour l’apprentissage organisationnel |
| Plate-forme | Gestion des Knowledge | ✅ Les examens postérieurs à l’incident sont stockés dans un wiki partagé ou une base Knowledge avec le balisage qui active l’analyse des modèles à travers plusieurs incidents |
| Plate-forme | Gestion des Knowledge | ✅ L’exécution des points de mesure est suivie dans les examens suivants afin d’éviter que les rétrospectives ne deviennent des discussions répétitives sans suivi |
| Plate-forme | Gestion des Knowledge | ✅ Les taux de réalisation d’éléments d’action sont mesurés en tant qu’indicateur de santé opérationnelle indiquant si des améliorations sont mises en œuvre ou simplement discutées |
| Plate-forme | Opérations | ✅ Les modèles d’incidents sont analysés à travers plusieurs incidents révélant des problèmes systémiques nécessitant un investissement architectural |
| Plate-forme | Opérations | ✅ Les catalogues sont mis à jour en fonction des apprentissages post-incidents afin de s’assurer que les procédures reflètent l’expérience réelle de réponse aux incidents |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Gestion des Knowledge | ⚠️ Les examens postérieurs à l’incident ne sont pas documentés; les apprentissages restent aux intervenants en cas d’incident plutôt que de se propager à l’ensemble de l’organisation |
| Plate-forme | Gestion des Knowledge | ⚠️ Les examens postérieurs à l’incident sont stockés dans des documents personnels plutôt que dans une base Knowledge partagée où les membres de l’équipe peuvent apprendre à partir de l’historique |
| Plate-forme | Gestion des Knowledge | ⚠️ Les éléments d’action sont définis mais jamais suivis ; le taux de réalisation est inconnu et les améliorations ne sont pas mises en œuvre |
| Plate-forme | Gestion des Knowledge | ⚠️ Les faibles taux de réalisation des éléments d’action persistent sans reconnaître que les rétrospectives sont inefficaces sans suivi |
| Plate-forme | Opérations | ⚠️ Les schémas d’incidents ne sont pas analysés dans plusieurs incidents ; les problèmes systémiques restent cachés car chaque incident est traité isolément |
| Plate-forme | Opérations | ⚠️ Les runbooks ne sont pas mis à jour après des incidents ; les procédures deviennent obsolètes à mesure que le système évolue et que de nouveaux modes de défaillance apparaissent |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Plate-forme | Opérations | ✅ Le temps moyen de détection (MTTD) est suivi en mesurant la durée depuis l’occurrence de l’incident jusqu’à la détection |
| Plate-forme | Opérations | ✅ Le temps moyen d’acquittement (MTTA) est suivi en mesurant la durée depuis la détection jusqu’à l’acquittement de l’ingénieur de garde |
| Plate-forme | Opérations | ✅ Le temps moyen de restauration (MTTR) est suivi en mesurant la durée depuis la détection jusqu’à la restauration du service |
| Plate-forme | Opérations | ✅ La fréquence des incidents est suivie avec un examen mensuel des tendances révélant si la stabilité s’améliore ou se dégrade |
| Plate-forme | Opérations | ✅ Le taux d’échec de modification est suivi en mesurant le pourcentage de déploiements entraînant des incidents de production nécessitant une correction |
| Plate-forme | Opérations | ✅ Le taux d’échec de modification est maintenu constamment bas, une petite fraction de tous les déploiements |
| Plate-forme | Opérations | ✅ Les métriques d’incident sont partagées avec les équipes de développement lors de la planification du sprint, ce qui informe de la priorité du backlog et des améliorations architecturales |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plate-forme | Opérations | ⚠️ Les métriques d’incident ne sont pas suivies ; l’équipe n’a aucune visibilité sur l’amélioration ou la dégradation des temps de réponse |
| Plate-forme | Opérations | ⚠️ Les MTTD, MTTA et MTTR ne sont pas mesurés ; les équipes ne peuvent pas identifier si la détection ou la réponse est le goulot d’étranglement |
| Plate-forme | Opérations | ⚠️ Le taux d’échec des modifications n’est pas suivi ; l’équipe ne sait pas si les portes de qualité sont efficaces |
| Plate-forme | Opérations | ⚠️ Les tendances de fréquence des incidents ne sont pas examinées tous les mois; la dégradation de la stabilité n’est détectée qu’après la survenance d’un incident majeur |
| Plate-forme | Opérations | ⚠️ Les métriques d’incident restent dans l’équipe d’exploitation sans partage avec les équipes de développement ; les problèmes architecturaux ne sont pas traités |
| Plate-forme | Opérations | ⚠️ Les métriques sont suivies, mais jamais utilisées pour éclairer les décisions; la mesure sans action gaspille des efforts et ne fournit aucune valeur |