Gestion des incidents - Partie 4 : Analyses et rapports d'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 parties 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 d’incident après résolution (cet article)

Dans cet article, partie 4, vous apprendrezcomment l’équipe de réponse aux incidents effectue une rétrospective qui inclut l’analyse des causes premières et la correction des incidents de service, puis affecte les mesures à prendre aux équipes d’ingénierie propriétaires.

En effectuant ces activités, l’assistance client Zendesk peut partager les détails des incidents et les mesures à prendre avec les clients affectés.

Cet article contient les sections suivantes :

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

Rétrospective des incidents de service

Zendesk organise un exercice de réflexion avec tous les membres de l’équipe impliqués dans l’incident pour examiner et documenter les causes de l’incident, l’impact de l’incident sur les clients et les mesures prises pour le minimiser ou le résoudre.  L’équipe passe en revue la ou les causes identifiées de l’incident et les mesures de suivi qui éviteront que cet incident ne se reproduise. On parle de rétrospective interne d’incident de service. Les rétrospectives des incidents sont partagées publiquement uniquement pour les incidents de haute gravité. 

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

Quatre activités principales sont effectuées dans le cadre d’une rétrospective d’incident de service :

1. Lisez les détails de l’incident contenus dans le document sur l’incident pour ancrer et guider les participants dans l’incident.
2. passer en revue et valider les résultats de l’analyse des causes premières contenus dans le document sur l’incident ;
3. Identifiez et catégorisez tout travail de remise en état nécessaire pour que les équipes d'ingénierie Zendesk puissent s'occuper des causes premières à l'origine de l'incident de service. Tous les points de correction sont acceptés par tous les participants rétrospectifs
4. Affectez les travaux de remise en état aux équipes d'ingénierie appropriées, avec des SLA clairs et appropriés.

Analyse des incidents de grande gravité

Une fois un incident de haute gravité résolu, le responsable de l’incident planifie une réunion rétrospective qui inclut :

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

Nous faisons de notre mieux pour que la réunion rétrospective de l’incident soit effectuée dans un délai de 72 heures suivant la résolution de l’incident, comprenant que l’heure de cette réunion dépendra de la complexité de la cause et de la disponibilité des membres de l’équipe dans toutes les régions géographiques. 

Après avoir planifié la rétrospective de l’incident, le propriétaire de l’ingénierie documente l’analyse de la cause et crée le document sur l’incident à partir des catégories suivantes :

• Aperçu des incidents
• Impact sur les clients
• Description technique
• Cause initiale et informations de service
• Détails et horaires des incidents
• Résolutions

Le document Incident guide l’analyse rétrospective des incidents et capture tous les travails de remise en état identifiés pour complètement résoudre 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 de la cause initiale. Cette analyse permet à l’équipe d’ingénierie de comprendre et de documenter l’incident, et de définir les mesures nécessaires à la résolution complète des problèmes. Ces informations sont capturées dans le document sur l’incident.

Processus d’analyse de la cause initiale des incidents Zendesk

Analyse des incidents de faible gravité

Les incidents de faible gravité passent par une phase de cause à l’origine et de signalement plus simple que celle des incidents de résolution élevée. Bien qu’une réunion de rétrospective sur les incidents formel n’ait pas lieu (sauf si cela est demandé par le propriétaire de l’ingénierie produit) pour les incidents de faible gravité, un document d’incident est créé par le propriétaire de l’ingénierie produit.  

Les causes sont identifiées, classifiées et partagées avec les équipes d’ingénierie, et des mesures correctives sont ajoutées aux tickets non traités de l’équipe d’ingénierie produits avec les SLA.  Comme pour les incidents plus graves, Zendesk s’efforce d’améliorer ses processus d’ingénierie en envoyant des enquêtes approfondies sur les incidents les moins graves.

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

Par définition, les incidents de gravité 4 n’ont pas d’impact direct sur les clients. Les analyses post-incident ne sont pas communiquées aux clients, mais les causes sont identifiées et les mesures correctives sont traitées en interne en utilisant les processus et procédures décrits ci-dessus.

Affectation des éléments de correction

Pour s’assurer que les éléments de correction sont terminés, l’équipe d’ingénierie produit examine les éléments de correction validés dans la rétrospective et effectue les actions suivantes :

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

• Les mesures préventives permettent d’éviter que l’incident ne se reproduise
• Les éléments généraux n’ont pas seulement un but préventif, ils permettraient de résoudre une partie essentielle des circonstances de l’incident
• Hiérarchisez les résolutions pour définir les SLA de réponse. Cet exercice se compose des activités suivantes :

• Identifier les équipes d’ingénierie chargées de la résolution des problèmes
• Liez l’élément de résolution à la cause racine identifiée sur laquelle il porte
• Ajouter l’élément de correction aux tickets non traités de l’équipe d’ingénierie responsable
• Ajouter l'élément de correction au rapport SLA d'ingénierie pour suivre la conformité SLA

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 leurs efforts de travail.

SLA de priorité des éléments de correction Zendesk

L’équipe d’assistance client Zendesk participant à la rétrospective crée les descriptions destinées aux clients des incidents, les causes et les mesures correctives identifiées. Il est publié dans le Article du centre d’aide associé à l’incident.

Suite de l’exemple d’incident de disponibilité du service

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

4 jours ouvrés après l’incident, l’équipe de réaction aux incidents et les ingénieurs se sont réunis pour examiner l’incident, collaborer sur les causes et créer ou mettre à jour les mesures pour remédier à l’incident. Tous les points concernant la 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 abordés lors de cette réunion incluaient :

Domaine	Exemple
Chronologie	20:02 UTC - Nouvelles versions de conteneurs déployées pour héberger les services avec des certificats mis à jour 20:08 UTC - Les avertissements de connectivité des conteneurs commencent à s'afficher 20:37 UTC - Premier signe que les services ne peuvent pas se connecter aux nouveaux conteneurs, ce qui provoque des retards/interruptions de service 20:57 UTC - Le service interne de Zendesk cesse de traiter les demandes, ce qui provoque des erreurs de dépassement du temps dans les applications Support, Guide et Talk hébergées sur le pod 17 21:02 UTC - L'auto-échelle de groupes commence à créer de nouveaux conteneurs pour les services qui ne sont pas accessibles 21:07 UTC - Le déploiement complet des conteneurs de service qui fonctionneront avec les configurations de service existantes est terminé 21:49 UTC - Nettoyage des conteneurs inaccessibles terminé 22:07 UTC - Incident entièrement résolu
Causes initiales	Après la modification du service de certificat de sécurité, les conteneurs n’ont pas tous été reconstruit pour refléter les modifications codées dans le script.  Les conteneurs qui n’ont pas été redéployés n’ont pas référencé le bon fournisseur de certificats de sécurité et les autres services et conteneurs Zendesk n’ont pas fait confiance à d’autres services et conteneurs Zendesk.
Facteurs influençant	Nous n’avons pas mis à jour les scripts de déploiement pour faire référence correctement au nouveau fournisseur de certificat de sécurité lors de la création de nouveaux conteneurs. Déployer les nouveaux conteneurs trop rapidement et trop largement pour qu’il soit possible de les adapter après le début des échecs Pas de récupération automatisée
Résolutions	Changer la façon dont la conformité du certificat de sécurité est évaluée quand de nouveaux conteneurs sont créés et déployés Ajoutez une méthode différente, plus solide, pour vérifier les certificats avant le lancement de nouvelles instances. Documenter la stratégie de déploiement pour une infrastructure à l’échelle horizontale Activer l’annulation automatique des déploiements en cas d’alerte étudier la façon dont l’ingénierie de plateforme peut reconstruire les composants de son infrastructure plus souvent ; Découvrir comment l'infrastructure critique peut être rendue plus distribuée et plus tolérante les pannes

Afin qu’il y ait une analyse approfondie permettant de générer des actions concrètes pour l’équipe d’ingénierie, tous les membres de l’équipe ont fourni des informations pour rapporter l’incident et développer des tâches pour remédier à ce problème. Une fois tous les problèmes ou questions résolus par l’équipe de réaction aux incidents, l’évaluation rétrospective des incidents a été considérée comme terminée.

À la fin de la réunion sur les incidents, l’agente de l’assistance client Zendesk responsable de la rétrospective des incidents a été invitée à indiquer si elle avait des questions ou avait besoin d’informations supplémentaires de l’équipe pour créer la documentation publique. Elle n’avait plus de questions et a ajouté les informations rétrospectives ci-dessous à l’article sur les incidents de service public dans la section Notifications de service dans dans notre centre d’aide.

Informations rétrospectives publiques pour l’incident de disponibilité de la machine virtuelle

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

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

• Les travaux de remise en état ont été identifiés et affectés à des équipes d'ingénierie avec des SLA

• Cette rétrospective publique a été publiée dans le centre d’aide par l’assistance client Zendesk et envoyée aux clients concernés ayant envoyé un ticket. 

Clôture d’un incident de service

Zendesk recommande de clore tous les tickets ouverts auprès des clients pour vous assurer que tout est correctement documenté et communiqué au sujet de l’incident.

Tous les incidents de service terminés sont résumés dans un résumé hebdomadaire des incidents de service, largement partagé dans l’ensemble de Zendesk. Les descriptions des incidents, l’impact sur les clients et les mesures correctives importantes sont inclus dans ce rapport et dans un rapport d’exploitation bihebdomadaire partagé avec la direction de Zendesk.

Une fois les informations rétrospectives publiées dans le centre d’aide et les tickets ouverts 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. L’assistance client Zendesk associe ces tickets à l’incident de service pour les marquer 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.