Gestion des incidents - Partie 4 : Analyse et rapports des incidents après résolution

Ceci est la partie 4 de l’ aperçu de la gestion des incidents chez Zendesk. Ce guide contient les sections suivantes :

• Partie 1 : Comment les problèmes de service Zendesk deviennent des incidents de service
• Partie 2 : Comment Zendesk gère les incidents de service
• Partie 3 : Surveillance d’un incident de service Zendesk public
• Partie 4 : Analyse et rapports sur les incidents après résolution (cet article)

Dans cet article, partie 4, vous allez apprendrecomment l’équipe de réponse aux incidents effectue une rétrospective qui inclut l’analyse des causes profondes et la correction des incidents de service, puis affecte les éléments de correction à la ou aux équipes d’ingénierie qui sont propriétaires.

En organisant ces activités, Support client Zendesk peut partager les détails des incidents et les étapes suivantes avec les clients concernés.

Cet article contient les sections suivantes :

• Rétrospective des incidents de service
• Affectation d’éléments de correction
• Clôture d’un incident de service

Rétrospective des incidents de service

Zendesk mène un exercice réfléchi avec tous les membres de l’équipe impliqué dans l’incident afin d’examiner et de documenter les causes de l’incident, l’impact de l’incident sur les clients et les mesures prises pour l’atténuer ou le résoudre.  L’équipe passe en revue la ou les causes profondes identifiées et les mesures de suivi qui permettront d’éviter que l’incident ne se reproduise. On parle de rétrospective interne d’un incident de service. Les incidents rétrospectifs sont partagés publiquement uniquement pour les incidents graves. 

Pour garantir la transparence et l’intégration de toutes les équipes Zendesk, un calendrier rétrospectif interne Zendesk est disponible pour leur permettre d’assister à la réunion de rétrospective interne et d’obtenir des informations au sujet des incidents de service et de leurs causes profondes.  Les résultats des incidents sont partagés avec toutes les équipes d’ingénierie et les résultats les plus importants sont mis en évidence et passés en revue lors de la réunion hebdomadaire d’ingénierie de Zendesk.

Quatre activités principales ont lieu dans le cadre d’une rétrospective d’incident de service :

1. Examiner les détails de l’incident contenu dans le document d’incident pour ancrer et orienter les participants vers l’incident
2. Vérifiez et validez les résultats de l’analyse des causes profondes contenus dans le document d’incident.
3. Identifiez et catégorisez toute tâche de correction nécessaire pour les équipes d’ingénierie Zendesk afin de traiter les causes profondes de l’incident de service. Tous les points de correction sont acceptés par tous les participants rétrospectifs
4. Affectez les travaux de correction aux équipes d’ingénierie appropriées en définissant des SLA clairs et pertinents.

Analyse des incidents de gravité grave

Une fois un incident grave résolu, le responsable des incidents planifie une réunion rétrospective qui inclut :

• Tous les membres de l’équipe qui ont participé à la réponse aux incidents
• Ingénieurs des équipes dont les produits ou services ont été affectés par l’incident
• Les équipes qui sont propriétaires ou ont un intérêt investi comme :
  • Assistance client Zendesk
  • Équipes de produits
  • Responsables des produits, services et domaines d’ assistance concernés 

Tous les efforts sont faits pour tenir la réunion rétrospective d’un incident dans les 72 heures suivant sa résolution, en sachant que le calendrier de la réunion dépendra de la complexité de la cause profonde et de la disponibilité des membres de l’équipe dans les régions géographiques. 

Après avoir planifié la rétrospective d’incident, le propriétaire de l’ingénierie documente l’analyse des causes profondes et crée un document d’incident basé sur les catégories suivantes :

• Aperçu des incidents
• Conséquence pour les clients
• Description technique
• Cause profonde et informations sur le service
• Détails et calendriers des incidents
• Corrections

Le document Incident guide le rétrospect des incidents et capture tout travail de correction identifié pour résoudre complètement les problèmes sous-jacents qui ont provoqué l’incident. 

Une phase d’analyse supplémentaire est effectuée pour les incidents de gravité 0 à 3, appelée Analyse des causes profondes. Cette analyse permet à l’équipe d’ingénierie de comprendre et de documenter l’incident, ainsi que de définir les mesures nécessaires pour le résoudre complètement. Ces informations sont capturées dans le document d’incident.

Processus d’analyse des causes profondes des incidents Zendesk

Analyse des incidents de gravité faible

Les incidents de faible gravité passent par une phase de cause profonde et de rapport plus ancienne que les incidents de gravité élevée. Bien qu'aucune réunion rétrospective d'incidents formel n'ait lieu (sauf si elle est demandée par le propriétaire de l'ingénierie produits) pour les incidents de gravité faible, un document d'incident est créé par le propriétaire de l'ingénierie produits.  

Les causes profondes sont identifiées, classées et partagées avec les équipes d’ingénierie, et des éléments de correction sont ajoutés aux tickets non traités de l’équipe d’ingénierie produits avec SLA.  Tout comme pour les incidents de gravité grave, Zendesk essaie d’apprendre et d’améliorer ses processus d’ingénierie afin d’enquêter de façon approfondie sur les incidents de faible gravité.

Comme les incidents de gravité 3 ont un impact minimal sur les clients, le statut du problème et les mesures de correction identifiées sont partagés avec les clients affectés qui ont contacté l’incident via Support client Zendesk par le biais d’un ticket Zendesk. 

Les incidents de gravité 4, par définition, n’ont pas d’impact direct sur le client. L’analyse après incident n’est pas communiquée aux clients, mais les causes profondes sont identifiées et les corrections effectuées en interne, en utilisant les processus et procédures décrits ci-dessus.

Affectation d’éléments de correction

Pour s’assurer que les éléments de correction sont terminés, l’équipe d’ingénierie produits examine les éléments de correction validés dans le rétrospectif et prend les mesures suivantes :

1. Classez les corrections comme préventives ou générales :
    

• Les éléments préventifs sont ceux qui empêchent activement la récurrence de l’incident
• Les éléments généraux ne sont pas seulement préventifs, mais résoudraient une partie essentielle des circonstances de l’incident.
• Hiérarchisez les corrections pour définir les SLA de réponse. Cet exercice va de par les activités suivantes :

• Identifiez les équipes d’ingénierie chargées de remédier à la situation
• Liez l’élément de correction à la cause profonde identifiée pour laquelle il traite
• Ajoutez l’élément de correction aux tickets non traités de l’équipe d’ingénierie responsable.
• Ajoutez l’élément de correction au rapport SLA (Accord sur les niveaux de service) d’ingénierie pour suivre le respect des SLA (Accord sur les niveaux de service)

Vous trouverez ci-dessous un graphique que les équipes d’ingénierie produits utilisent pour déterminer quand une correction est prioritaire et planifiée pour leur travail.

 

SLA (Accord sur les niveaux de service) sur la priorité des articles de correction Zendesk

L’équipe Support client Zendesk assistant à la rétrospective crée les descriptions des incidents, des causes profondes et des corrections potentielles. Ceci est publié dans Notifications de service de notre centre d’aide.

Exemple d’incident de disponibilité du service (suite)

Voici comment une rétrospective d’incident a été effectuée pour cet incident.

4 jours ouvrables après l’incident, l’équipe de réponse aux incidents et les ingénieurs se sont réunis à eux pour examiner l’incident, collaborer sur les causes profondes et créer ou mettre à jour les éléments de correction. Tous les points de correction sont acceptés par consentement des participants à la réunion.

Chaque personne impliquée dans l’incident a joué un rôle dans la rétrospective de l’incident :

Les détails passés en revue et discutés lors de cette réunion ont inclus :

Domaine	Exemple
Chronologie	20:02 UTC - Nouvelles versions de conteneurs déployées dans les services d’hôte avec les certificats mis à jour 20:08 UTC - Les avertissements de connectivité des conteneurs commencent à s'afficher 20:37 UTC - Première preuve que les services ne peuvent pas se connecter aux nouveaux conteneurs, ce qui entraîne un retard ou une interruption du service 20:57 UTC - Le service interne Zendesk arrête de traiter les demandes, ce qui provoque des erreurs de délai d’inactivité dans Support, Guide et Talk hébergés dans le pod 17 21:02 UTC - L’échelle automatique de groupes commence à créer de nouveaux conteneurs pour les services qui ne sont pas accessibles 21:07 UTC - Mise à disposition complète des conteneurs de service qui fonctionneront avec les configurations de service existantes terminées 21:49 UTC - Nettoyage des conteneurs inaccessibles terminé 22:07 UTC - L’incident est complètement résolu
Causes profondes	Après la modification du service de certificat de sécurité, les conteneurs n’ont pas tous été recréés pour détecter les modifications chiffrées dans le script.  Les conteneurs qui n’ont pas été redéployés ne faisaient pas référence au bon fournisseur de certificats de sécurité et n’étaient pas dignes de confiance par les autres services et conteneurs Zendesk.
Facteurs d’influence	Nous n’avons pas mis à jour les scripts de déploiement pour référencer correctement le nouveau fournisseur de certificat de sécurité lors de la création de nouveaux conteneurs Déploiement des nouveaux conteneurs trop rapide et trop large pour pouvoir les adapter après le début des échecs Pas de capacité de restauration automatisée
Corrections	Modifier la façon dont la conformité du certificat de sécurité est évaluée lorsque de nouveaux conteneurs sont créés et déployés Ajouter une méthode différente et plus robuste pour la vérification des certificats avant le lancement de nouvelles instances Documentez la stratégie de déploiement pour l’infrastructure à échelle horizontale Activer le rétablissement automatique des déploiements en cas d’alerte Chercher comment l’ingénierie de plateforme peut recréer plus souvent ses composants d’infrastructure Découvrez comment une infrastructure critique peut être mieux distribuée et tolérante aux pannes

Pour qu’il y ait une analyse approfondie pour générer des actions concrètes pour l’équipe d’ingénierie, tous les membres de l’équipe ont fourni des informations pour recompter l’incident et développer des tâches de correction. Une fois toutes les questions ou tous les problèmes résolus par l’équipe de réponse aux incidents, la rétrospective des incidents a été considérée comme terminée.

À la fin de la réunion de rétrospective interne, le responsable de Support client Zendesk responsable de la rétrospective des incidents publics a été invité à indiquer si elle avait des questions ou avait besoin d’informations supplémentaires de la part de l’équipe pour créer la documentation publique. Elle n’avait pas d’autres questions et a ajouté les informations rétrospectives ci-dessous Section Notifications de service dans notre centre d’aide.

Informations rétrospectives publiques pour l’incident de disponibilité du service DM

Voici trois résultats importants de cette rétrospective d’incident qui ont amélioré les produits et services Zendesk :

• Les causes profondes de l’incident ont été identifiées et seront prises en compte par toutes les équipes de produits Zendesk lors du développement futur.

• Les corrections ont été identifiées et affectées à des équipes d’ingénierie avec des SLA

• La rétrospective publique a été publiée par Support client Zendesk dans le centre d’aide et a été envoyée aux clients concernés qui ont envoyé des tickets. 

Clôture d’un incident de service

Zendesk ferme tous les tickets ouverts aux clients pour s’assurer que tout est correctement documenté et communiqué pour l’incident.

Tous les incidents de service terminés sont résumés dans un rapport d’incident de service hebdomadaire, largement partagé par l’ensemble de Zendesk. Les descriptions des incidents, l’impact sur les clients et les mesures Elles sont incluses dans ce rapport, ainsi que dans un rapport d’analyse des opérations bihebdomadaire, partagé avec la direction de Zendesk.

Une fois que des informations rétrospectives ont été publiées dans le centre d’aide et que les tickets ouverts sont mis à jour avec les résultats de la rétrospective, la phase d’analyse et de rapport pour l’incident de service est considérée comme terminée. Support client Zendesk lie ces tickets à l’incident de service et ils sont marqués comme clos. 

Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.

Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.