Gestion des incidents - Partie 2 : Comment Zendesk gère les incidents de service

Ceci est la partie 2 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 (cet article)
• Partie 3 : Surveillance d’un incident de service Zendesk public
• Partie 4 : Analyse et rapports des incidents après résolution

Dans cet article, en partie 2, vous apprendrez à comprendrela façon dont les équipes Zendesk répondent aux incidents de service au sein de nos produits en fonction de niveaux de gravité. Zendesk adopte une approche complète pour comprendre un incident, de sa cause profonde à l’impact total sur les clients affectés, et communique le niveau de détails approprié.

Cet article contient les sections suivantes :

• Gravité de l’incident
• Structure de l’équipe de réponse aux incidents
• Calendriers de communication pour les incidents
• Processus d’incident faible

Gravité de l’incident

L’une des décisions clés que vous prenez quand un incident de service est créé est l’affectation de sa gravité. La gravité d’un incident détermine comment et quelles équipes Zendesk gèrent le problème et comment il est communiqué aux clients concernés.

Zendesk utilise un système qui regroupe les incidents de service en 5 niveaux de gravité en fonction des caractéristiques de l’incident :

 

Système de notes de gravité Zendesk

Plusieurs équipes et protocoles de transfert sont impliqués pour enquêter sur l’incident, le communiquer et y remédier en fonction de son niveau de gravité. Cela garantit que le bon niveau de gravité est attribué à chaque incident. Le graphique ci-dessous décrit les principales activités qui ont lieu pendant et après la résolution d’un incident en fonction de son niveau de gravité :

Processus par niveau de gravité

Les incidents graves font l’objet d’analyses et de mesures de correction rigoureuses, mais tous les incidents, quel que soit leur niveau de gravité, font l’objet d’un processus de réponse et d’enquête en temps réel. Cela produit :

• Mises à jour de la page de statut Zendesk quand l’incident est public
• Analyse des causes profondes et résolution des incidents
• Rapport d’incident Zendesk (interne)

Exemple d’incident de disponibilité d’un service Zendesk

Voici un exemple de la façon dont la gravité des incidents est définie par Zendesk et de la façon dont les équipes Zendesk répondent en interne :

Découverte d’un incident et exemple de réponse

Dans l’exemple, vous voyez le workflow suivant :

1. Le Centre d’opérations réseau Zendesk (ZNOC) a identifié un problème quand les alertes système indiquaient que les nœuds de service du Pod 17 ne pouvaient pas être atteints par les demandes. L’équipe d’ingénierie réseau de Zendesk a vérifié que les problèmes d’accès affectaient directement les services client et s’est vite rendu compte que les services Support, Guide et Talk pour plusieurs clients ne fonctionnaient pas comme prévu. Un nouvel incident de service Zendesk a été créé.
2. Au départ, cet incident avait affecté deux clients, mais du fait de la nature de la panne, plus de clients ont rencontré le problème et ont commencé à signaler les problèmes à Support client Zendesk. L’équipe d’ingénierie a attribué à l’incident la note de gravité 1, un incident avec une priorité élevée nécessitant une attention immédiate. 
3. L’équipe de service client chargée des incidents de service a été contactée immédiatement. En quelques minutes après la création de l’incident, un responsable d’incident a recueilli des informations et réuni des ressources d’ingénierie supplémentaires pour dépanner et résoudre l’incident de service.

Structure de l’équipe de réponse aux incidents

Zendesk dispose d’une équipe dédiée de réponse aux incidents mondiaux, chargée de s’assurer que chaque incident est géré via le processus de gestion des incidents de service et transféré aux niveaux appropriés de direction de Zendesk, le cas échéant. 

Rôles et responsabilités de la gestion des incidents

Cette structure d’équipe permet à Zendesk d’effectuer une analyse approfondie de l’incident avec des ressources techniques et de communiquer en temps réel avec les clients par le biais de Support client Zendesk. 

Calendriers de communication pour les incidents

Zendesk fait tout son possible pour que les incidents soient correctement communiqués et résolus dans des délais appropriés pour le client. Nous avons établi des délais internes pour la distribution des détails sur les incidents. Ce calendrier est fondé sur la gravité de l’incident et les étapes de gestion des incidents de service.

Étape	Temps de réponse
Annonce publique	Dans les 15 minutes suivant l’incident appelé
Mises à jour des incidents	Toutes les 30 minutes jusqu’à ce que le service soit rétabli ou que de nouvelles informations soient disponibles
Analyse des événements  (pour les incidents de gravité 0 et 1)	Dans les 48 heures suivant la résolution d’un incident
Analyse des causes profondes	Dans les 72 heures suivant la résolution d’un incident
Rétrospective des incidents publics	Dans plus de 96 heures après la résolution d’un incident

Les incidents qui ont une note de gravité comprise entre 0 et 2 sont considérés comme élevés. les incidents graves. Quand un incident grave se produit, l’équipe d’intervention d’urgence mondiale est disponible 24/7 pour répondre à ces incidents. L’équipe comprend les rôles suivants :

Rôles de l’équipe de réponse aux incidents

Emplacements des équipes de réponse aux incidents mondiaux

Quand l’équipe de garde est appelée, le diagnostic d’incident commence dans les minutes qui suivent la déclaration de l’incident. Un canal Slack et un appel Zoom sont créés pour permettre aux équipes de réponses de communiquer en temps réel. Quand l’équipe chargée de la réponse aux incidents trie et évalue l’incident, les équipes d’ingénierie sur appel sont basées sur les produits et services affectés.

Publication publique sur la page de statut Zendesk a lieu dans un délai de 15 minutes après la création d’un incident pour tenir les clients informés de l’incident connu. Les mises à jour sont publiées toutes les 30 minutes ensuite jusqu’à résolution quand de nouvelles informations sont disponibles. En fonction du problème et du volume de nouvelles informations identifiés, cette fréquence peut être réduite ou prolongée en fonction des besoins.  Les clients peuvent surveiller les incidents de service actifs à la page de statut Zendesk. Ce processus est décrit à la section à la partie 3 de ce guide.

En plus de nos équipes mondiales d’intervention en cas d’incidents, Zendesk a établi des processus pour les notifications aux dirigeants et les transferts. Si un incident grave répond à certains critères, nous activons le niveau de réponse suivant, la gestion d’une crise.

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

Pour continuer en utilisant l’incident de disponibilité du service comme exemple, voici comment la réponse à l’incident a progressé dans le processus de gestion des incidents chez Zendesk :

Calendrier de réponse aux incidents de disponibilité du service

Comme vous pouvez le voir dans l’exemple, une fois l’incident créé dans le portail des incidents Zendesk, une série d’actions automatiques ont été effectuées :

• L’équipe de service client de réponse aux incidents était disponible pour répondre à l’incident.

• Un canal Slack d’incident a été créé automatiquement et l’équipe de service client de réponse aux incidents a été ajoutée au canal Slack dédié.

• Un appel Zoom a été automatiquement initié et publié dans le canal Slack pour que tous les répondeurs puissent le rejoindre

• Un document récapitulatif de l’événement a été créé automatiquement pour documenter l’incident et partager les progrès en interne avec Zendesk.

Lors de l’appel Zoom, le responsable des incidents a validé la gravité initiale et confirmé la portée et l’impact du problème. 

Il a été rapidement déterminé que plusieurs nœuds de conteneurs dans le PoD 17 n’étaient pas accessibles et ne pouvaient pas être utilisés par des services dépendants, notamment Support, Guide et Talk. Un type de nœud en particulier n’avait pas de répliques disponibles dans les autres pods. Cela finirait par rendre ces produits sans réponse pour plusieurs clients.

Le ZNOC a contacté l’équipe d’ingénierie réseau appropriée pour l’appel Zoom pour commencer à enquêter sur la façon de résoudre le problème immédiat lié au rétablissement de l’accès au service et à l’API pour les clients.  Des experts de l’ingénierie Edge ont également été contactés et ont répondu à l’appel. En 5 minutes seulement, un correctif était identifié et déployé pour que les nœuds affectés soient à nouveau accessibles aux appels et services API. 

Support client Zendesk a créé un ticket de problème pour suivre les rapports des clients. Ce ticket a été ajouté au canal Slack d’incidents pour permettre l’ajout rapide des nouveaux rapports au fur et à mesure qu’ils arrivent.

Alors que l’enquête se poursuivait, le responsable du transfert des incidents a créé et publié la première mise à jour publique de la page de statut Zendesk 12 minutes après la création d’un incident. 

Publication du premier incident de disponibilité du service sur la page de statut du système Zendesk

Pendant que les équipes enquêtaient sur l’incident, les rapports de clients reçus étaient liés au ticket de problème principal associé à l’incident. Cela a permis à l’équipe de réponse aux incidents d’envoyer des mises à jour à tous les clients concernés quand ils ont envoyé des notifications publiques.

L’équipe d’ingénierie réseau a déterminé qu’une modification de la façon dont les certificats étaient générés et utilisés était responsable de l’incident et a pris les mesures suivantes pour rétablir le service pour les clients concernés :

• Nœuds inaccessibles désactivés

• Créer de nouveaux nœuds de service avec des certificats correctement référencés

• Vérification de l’accessibilité des nouveaux nœuds de service pour les services et par le biais des appels API

• Surveiller le trafic entrant pour vérifier que les demandes entrantes sont désormais traitées de façon appropriée ;

Au fil de la progression de l’incident, deux autres mises à jour publiques ont été effectuées : une conversation de 14 minutes après la création d’un incident et une autre de 63 minutes après sa création. Vous trouverez l’historique des communications publiques ainsi que les informations rétrospectives sur les incidents publiés sur le à la page Notifications de service pour l’incident.

Comme l’illustre l’exemple, les incidents de haute gravité sont soumis à un processus rigoureux dans lequel les causes sont déterminées et des mesures de correction sont créées pour permettre aux équipes d’ingénierie produits de résoudre le problème sous-jacent qui a provoqué l’incident. Cette analyse a lieu pendant notre rétrospective d’incidents et est expliquée plus en détail à la Section Analyse des incidents après résolution.

Processus d’incident faible

Les incidents de service les moins graves (niveaux 3 ou 4) sont moins critiques, car ils affectent un plus petit nombre de clients et n’empêchent pas ces clients d’utiliser les fonctions commerciales essentielles des produits Zendesk. Ces incidents sont traités conformément aux directives ci-dessus, mais ne sont pas publiés dans les canaux publics.

Les incidents de gravité 3 sont traités plus ou moins de la même façon que les incidents de gravité 0-2. Les temps de réponse attendus sont prolongés du fait de l’impact réduit sur l’activité. Bien que l’équipe d’assistance ne soit pas appelée, ces incidents sont traités par le biais de canaux Slack spécifiques aux incidents Zendesk associés à la ou aux équipes d’assistance produits et les équipes répondent généralement aussi rapidement que les incidents plus graves. La plupart des incidents de gravité 3 n’utilisent pas de canaux de communication publics. Au lieu de cela, les équipes Support client Zendesk contactent les clients par le biais de notifications proactives si une action spécifique est requise de la part d’un sous-ensemble de clients.

Les incidents de gravité 4 n’affectent pas directement l’utilisation des services Zendesk par les clients, mais peuvent avoir le potentiel de le faire si nous ne les traitons pas. Ces incidents sont créés en tant que réponses proactives à des problèmes potentiels. Les équipes d’ingénierie produits collaborent de la même façon que le processus de gravité 3.

En savoir plus

Vous avez terminé la partie 2, Comment Zendesk gère les incidents de service, de l’ aperçu de la gestion des incidents chez Zendesk.

Si vous voulez en savoir plus, passez à la partie suivante de ce guide : Partie 3 : Surveillance d’un incident de service Zendesk public. 

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.