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

Il s’agit de la deuxième partie de l’article Tout afficher sur 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 (cet article)
• Partie 3 : Surveillance d’un incident de service Zendesk public
• Partie 4 : Analyses et rapports des incidents post-résolution

Dans cet article, partie 2, vous découvrirez comment hes équipes Zendesk répondent aux incidents de service au sein de nos produits en fonction de leur niveau de gravité. Zendesk a adopté une approche globale pour comprendre un incident (de sa cause à l’impact global 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 de faible gravité

Gravité de l’incident

L’une des décisions clés prises lors de la création d’un incident de service est l’affectation de la gravité de l’incident. La gravité d’un incident détermine comment et quelles équipes Zendesk traitent le problème et comment il est communiqué aux clients concernés.

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

Système de notation Zendesk

Différentes procédures de transfert et équipes sont chargées d’enquêter, de communiquer et de remédier à l’incident en fonction de son niveau de gravité. Cela permet de garantir que chaque incident est traité avec le bon niveau de workflow. Le graphique ci-dessous décrit les activités clés qui ont lieu pendant et après la résolution d’un incident, en fonction de son niveau de gravité :

Traiter par niveau de priorité

Les incidents les plus graves sont soumis à des analyses et des mesures correctives 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 et résolutions des incidents
• Rapport d’incident Zendesk (interne)

Exemple d’incident de disponibilité du 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éagissent en interne :

Exemple de découverte d’incident et 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 demandes ne pouvaient pas atteindre les nœuds de service du Pod 17. 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 moment de sa création, nous savons que cet incident affecterait deux clients, mais du fait de la nature de l’indisponibilité, d’autres clients ont été confrontés à ce problème et ont commencé à le signaler à l’assistance client Zendesk. L’équipe d’ingénierie a affecté la note de gravité de l’incident à l’incident, ce qui représente un incident prioritaire nécessitant une attention immédiate. 
3. L’équipe de service client a été immédiatement contactée. Quelques minutes après la création de l’incident, un gestionnaire d’incidents recueillait des informations et 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 a une équipe mondiale de réponse aux incidents qui se consacre à s’assurer que chaque incident est géré dans le cadre du processus de gestion des incidents de service et remonté aux instances Zendesk appropriées, selon les besoins. 

Gestion des incidents - Rôles et responsabilités

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

Calendriers de communication pour les incidents

Zendesk fait tout son possible pour s’assurer que les incidents sont correctement communiqués et résolus dans des délais appropriés pour les clients. Nous avons établi des calendriers internes pour la distribution des détails des incidents. La chronologie est fondée sur le niveau de gravité de l’incident et les étapes de gestion des incidents de service.

Étape	Temps de réponse
Annonce publique	Dans les 15 minutes de l’incident appelé
Mises à jour sur les 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 de l’incident
Analyse de la cause	Dans les 72 heures suivant la résolution de l’incident
Rétrospective d’incidents publics	Plus de 96 heures après la résolution de l’incident

Les incidents qui ont une note de gravité de 0 - 2 sont considérés comme élevés de plusieurs incidents. Quand un incident de grande gravité survient, l’équipe de réaction en cas d’incident est disponible 24 h/24, 7 j/7 pour répondre à ces incidents. L’équipe se compose des rôles suivants :

Rôles de l’équipe de réaction en cas d’incident

Emplacements des équipes de réaction en cas d’incidents dans le monde

Lorsque l’équipe de service client est interrogée, le diagnostic de l’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 à l’équipe de réponse de communiquer en temps réel. Quand l’équipe de réaction en cas d’incident trie l’incident et l’évalue, les équipes d’ingénierie de garde sont informées des produits et services affectés.

Une publication publique sur la page de statut Zendesk La suppression est effectuée dans un délai de 15 minutes après la création de l’incident pour que les clients soient informés de l’incident connu. Des mises à jour sont publiées toutes les 30 minutes par la suite, jusqu’à ce que de nouvelles informations soient disponibles. En fonction du problème et du volume d’informations nouvelles identifiées, cette fréquence peut être réduite ou prolongée en fonction des besoins.  Les clients peuvent suivre les incidents de service actifs sur la page de statut Zendesk - la page est décrite dans la section dans la troisième partie de ce guide.

En plus de nos équipes mondiales de réponse aux incidents, Zendesk a mis en place des processus pour les notifications et les transferts aux responsables. Si un incident grave répond à certains critères, nous passons au niveau de réponse suivant, la gestion des crises.

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

Dans la suite de l'utilisation de l'incident de disponibilité du service comme exemple, voici comment la réponse à l'incident a progressé dans le processus de gestion des incidents de Zendesk :

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

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

• L’équipe de service client a été contactée pour répondre à l’incident.

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

• Un appel Zoom a été automatiquement initié et publié dans le canal Slack pour que tous les participants puissent se joindre

• Un document de résumé d’événement était automatiquement créé pour documenter l’incident et partager sa progression en interne dans Zendesk.

Lors de l’appel Zoom, le responsable de l’incident a validé la gravité initiale et confirmé l’étendue 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 les services dépendants, notamment les produits Support, Guide et Talk. Un type de nœud en particulier n’avait pas de répliques disponibles dans les autres pods. Dans ce cas, ces produits ne répondaient plus aux attentes de plusieurs clients.

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

L’assistance client Zendesk a créé un ticket de problème pour suivre les signalements des clients. Ce ticket a été ajouté au canal d’incident Slack pour permettre l’ajout rapide des nouveaux rapports dès leur réception.

Pendant 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 de l’incident. 

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

Pendant que les équipes enquêtaient l’incident, les rapports des clients étaient liés au ticket de problème principal associé à l’incident. Ainsi, l’équipe de réaction en cas d’incidents a pu envoyer des mises à jour à tous les clients concernés quand ils envoyaient des notifications publiques.

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

• Nœuds inaccessibles désactivés

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

• Vérification de l’accès des nouveaux nœuds de service pour les services et via les appels API

• Surveiller le trafic entrant pour vérifier que les demandes entrantes sont désormais traitées correctement

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

Comme l’illustre l’exemple, les incidents les plus graves sont soumis à un processus rigoureux, dans le cadre duquel les causes sont déterminées et des mesures correctives sont créées pour permettre aux équipes d’ingénierie produits de résoudre le problème sous-jacent à l’origine de l’incident. Cette analyse a lieu pendant notre rétrospective d’incident et est expliquée plus en détail dans le Section Analyse des incidents post-résolution.

Processus d’incident de faible gravité

Les incidents de service de faible gravité (niveau 3-4) sont moins critiques, car ils affectent un nombre plus limité de clients et n’empêchent pas ces clients d’utiliser les fonctions critiques pour l’entreprise des produits Zendesk. Ces incidents sont traités conformément aux directives ci-dessus, mais ne sont pas publiés dans les canaux de communication publics.

Les incidents de priorité 3 sont traités de la même manière que les incidents de vue 0-2. Les temps de réponse attendus sont prolongés du fait de la réduction de l’impact sur l’activité. Même si l’équipe d’assistance n’est pas contactée, ces équipes sont traitées par des canaux Slack d’incidents Zendesk spécifiques associés à la ou aux équipes d’ingénierie produits et les équipes ont tendance à répondre plus rapidement aux incidents les plus graves. La plupart des incidents de niveau 3 n’utilisent pas les canaux de communications publics. Au lieu de cela, les équipes d’assistance client Zendesk contactent les clients par le biais de notifications proactives si une action spécifique est requise 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 le faire s’ils ne sont pas traités. Ces incidents sont créés en tant que réponses proactives à des problèmes potentiels. Les équipes d’ingénierie produits adoptent la même approche que pour le processus de Gravité 3.

En savoir plus

C’est la fin de 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.