Il y a environ un an, certains difficultés techniques Citi a temporairement fermé plusieurs centaines de milliers de cartes et une multitude de distributeurs automatiques simultanément. Résultat : les nouvelles cartes Costco Anywhere de Citi ont reçu un «  flot de plaintes .”

L’expression Internet pour quelque chose d’une telle ampleur est « incendie de pneu ».

Les incidents qui dégénèrent en incendie impliquent généralement tous les membres de l'organisation, de la direction aux utilisateurs, en passant par le support technique. Les RP ou le marketing donnent l'alerte et gèrent les communications externes, tandis que l'équipe technique doit se débrouiller seule.

Cela signifie écrire un document interne autopsie et un SLA régi mea culpa vers le monde extérieur. Ces analyses sont souvent rédigées sous forme d'analyses des « causes profondes », visant à blâmer et à corriger les personnes, les processus et les technologies impliqués dans l'incident.

Dans ces situations, les responsables techniques peuvent et doivent faire mieux que de blâmer. Certes, les équipes doivent agir au plus vite pour trier et rétablir le service normal. Mais lors de l'évaluation des causes de l'incident, de l'efficacité de la réponse et de son impact, l'objectif ne doit pas être de se concentrer uniquement sur les « causes profondes ».

L'approche ciblée consiste à blâmer et à demander un budget. L'approche portefeuille montre comment les investissements actuels ont généré des résultats spécifiques et comment une réaffectation pourrait modifier ces résultats. Elle aide le reste de l'organisation à identifier les investissements à investir. DevOps , des équipes de support et de service.

Parlez-moi d'affaires !

Par exemple, des outils internes comme ServiceNow , PagerDuty , et Mou Investir dans la rapidité et l'étendue des opérations permet de résoudre les problèmes sur l'ensemble de votre infrastructure beaucoup plus rapidement. Leur développement pourrait nécessiter des intégrations plus étroites avec des outils spécifiques au développement, davantage de personnel d'astreinte ou un système d'alerte des utilisateurs sur mobile ou dans l'application. Ces investissements ne doivent pas être présentés ponctuellement après un incident. Les indicateurs de gestion et de résolution des incidents doivent plutôt servir à illustrer leur configuration actuelle et les points à améliorer en termes de ressources humaines, de processus et d'outils.

De plus, il doit être communiqué dans un langage clair et « adapté aux entreprises », car les incidents obligent nécessairement DevOps, TechOps, le support et l’organisation de services à parler au côté commercial.

Voici un exemple très basique de cadre de communication sur les incidents :

Priorité 2

Les notifications d'incidents internes (par exemple, un ticket de gestion des modifications) sont immédiatement envoyées au personnel d'astreinte (via PagerDuty et Slack). Le contrat de niveau de service (SLA) exige une communication de gestion avec le propriétaire du compte le jour même.

• (Pourcentage historique) % d'incidents de priorité 3 résolus dans le cadre de l'objectif convenu dans le SLA
• (Pourcentage)% d'incidents de priorité 3 dans la période concernée.

Priorité 1

Les notifications d'incidents internes (par exemple, panne de l'application de paiement) sont immédiatement envoyées au personnel d'astreinte, à l'équipe de direction et au support. Le contrat de niveau de service exige une communication de la direction avec le responsable de l'incident dans l'heure suivant cette notification.

• (Pourcentage historique) % d'incidents de priorité 1 résolus dans le cadre de l'objectif convenu dans le SLA
• (Pourcentage) % d’incidents de priorité 1 dans la période concernée.

Ce modèle peut être utilisé en interne pour intervenants en cas d'incident et les parties prenantes de l'entreprise, ainsi qu'en externe pour les clients et prospects. Sans connaissances techniques particulières, l'équipe métier peut comprendre l'historique des incidents et leur délai de résolution. Ces données constituent un atout que l'équipe technique peut gérer, en les reliant directement à résolution d'incidents et les processus DevOps jusqu'au résultat net.

Bien que ce qui précède vous aidera à avoir la bonne conversation au niveau de l’entreprise, une discussion interne autopsie L'approche est plus introspective pour les équipes DevOps et de service. Posez-vous les questions suivantes : ces processus sont-ils corrects ? Notre infrastructure est-elle suffisamment résiliente ? Si ce n'est pas le cas, comment le mesurer ? Le saurons-nous et que modifierons-nous ?

Voici quelques exemples de mesures à prendre en compte pour déterminer les performances de votre équipe :

• Nous priorisons les incidents de manière appropriée, en fonction de leur impact et de leur urgence :
  • Nombre de tickets dont la priorité a été modifiée après la connexion
  • Nombre de tickets supplémentaires créés en raison de plaintes ou d'escalades
  • Nombre et niveau du personnel affecté à chaque priorité de ticket
• Nous communiquons bien afin que les clients et les utilisateurs comprennent ce qui se passe et quand ils peuvent s'attendre à ce que leurs incidents soient résolus :
  • Pourcentage d'incidents où le client a contacté le service d'assistance pour demander une mise à jour
• Les clients et les utilisateurs sont satisfaits de la manière dont nous gérons les incidents :
  • Pourcentage d'utilisateurs donnant une note de 4 ou 5 à l'enquête de satisfaction post-incident
  • Augmentation de la satisfaction concernant la résolution des incidents lors de l'enquête annuelle de satisfaction client
• Nous reconnaissons les incidents répétés et expliquons les problèmes sur le forum public pour aider à réduire l’impact négatif futur :
  • Nombre de problèmes signalés par le service d'assistance et découverts dans le forum
  • Nombre de tickets redirigés vers le forum
  • Nombre de tickets générés par le forum
• Nous utilisons efficacement nos investissements et nos outils de résolution d’incidents :
  • Pourcentage d'incidents enregistrés via e-mail/forum/application
  • Pourcentage d'incidents détectés et résolus avec des outils en libre-service
  • Coût moyen de résolution d'un incident (par priorité)
  • Délai moyen de résolution des incidents depuis l'investissement dans les outils
  • % de réduction du nombre d'incidents depuis l'investissement dans les outils

Il existe bien d'autres indicateurs, basés sur les analyses les plus pertinentes pour votre équipe, mais ils peuvent vous donner une longueur d'avance pour répondre à ces questions inévitables, et ils ne nécessitent pas de réinvention de processus majeurs. Il suffit d'utiliser un système de tickets moderne. surveillance , résolution d'incidents, collaboration et des outils de satisfaction client, dont beaucoup intègrent des fonctions d'analyse.

PagerDuty et Slack, mentionnés ci-dessus, sont des outils standards pour la résolution des incidents et la collaboration. ServiceNow et Atlassian Les suites sont idéales pour connecter la gestion des incidents et des actifs. Il est important de garder à l'esprit que la résolution et la prévention efficaces des incidents ne reposent pas uniquement sur des outils, mais aussi sur une plateforme. processus bien défini qui aide les gens à utiliser les outils de manière efficace, intégrée et en libre-service.

Jamais Incluez « Autre », « Divers » ou toute autre catégorie fourre-tout pour évaluer l'efficacité de vos outils, processus et collaborateurs ; cela revient à créer une trappe pour tous vos indicateurs. Par ailleurs, même si un modèle peut être un bon point de départ, l'équipe tirera un bien meilleur parti de vos rapports si vous ne vous contentez pas de copier un modèle. Commencez plutôt par vous fier à l'intuition de votre équipe :

• Une erreur de module de facturation est-elle classée P1 ou P2 pour votre service ?
• Pour quels clients serait-ce P1 ?
• Y a-t-il des clients pour qui tout est P1 ?

Ne faites pas bouillir l'océan. Souvenez-vous, vous êtes dans la même équipe et ce n'est pas un déposition.

Concentrez ces questions sur la manière dont votre équipe gère ces incidents (chronologie, personnel, utilisation des outils, etc.) et établissez des priorités en fonction de cela. Si vous disposez des catégories de base des outils et processus de résolution des incidents couverts, ainsi que des mesures qui permettent de suivre la manière dont l’entreprise peut continuer à investir dans des améliorations, alors vous êtes en excellente position, même en cas d’incendie de pneus.

^{Photo dans Parc à pneus de Springfield sur le wiki des Simpson}