Il y a environ un an, certains difficultés techniques Citi a temporairement fermé quelques centaines de milliers de cartes et une série de distributeurs automatiques en même temps. Résultat : les cartes Costco Anywhere récemment lancées par 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 incendies de pneus impliquent généralement tous les membres de l'organisation, de la direction aux utilisateurs en passant par le service d'assistance. Les services de relations publiques ou de marketing sonnent l'alarme et gèrent les communications externes, tandis que l'équipe technique doit se débrouiller seule.

Cela signifie écrire un 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 », qui se concentrent sur la responsabilité et la correction des personnes, des processus et de la technologie impliqués dans l’incident.

Les responsables techniques peuvent et doivent faire mieux que de blâmer les autres dans ces situations. Oui, les équipes doivent agir aussi vite que possible pour trier et rétablir le service normal. Mais dans le processus de mesure des causes de l’incident, de l’efficacité de la réponse et de l’impact, l’objectif ne doit pas être de se concentrer uniquement sur les « causes profondes ».

L'approche point-and-shoot blâme et demande un budget. Une approche de portefeuille montre comment les investissements actuels ont donné des résultats spécifiques et comment une réaffectation pourrait changer ces résultats. Elle aide le reste de l'organisation à voir comment investir dans DevOps , des équipes de support et de service.

Parlez-moi d'affaires !

Par exemple, des outils internes comme ServiceNow , PagerDuty , et Mou Les investissements en termes de rapidité et d’étendue permettent aux équipes de résoudre les problèmes de l’ensemble de votre infrastructure beaucoup plus rapidement. Leur développement peut 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 ad hoc après un incident. Les mesures de gestion et de résolution des incidents doivent plutôt servir à montrer comment elles sont actuellement configurées et où des personnes, des processus et des outils peuvent être ajoutés pour améliorer les résultats de la résolution des incidents.

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 ticket de gestion des modifications) sont envoyées immédiatement au personnel d'astreinte (via PagerDuty et Slack). Le SLA nécessite une communication de gestion le jour même avec le propriétaire du compte.

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

Priorité 1

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

• (Pourcentage historique) % d'incidents de priorité 1 résolus dans le délai convenu par 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 les prospects. Sans aucune connaissance technique, le côté commercial peut comprendre l'historique des incidents et le temps de résolution. Ces données sont un atout que l'équipe technique peut conserver, en liant directement résolution d'incident et les processus DevOps jusqu'au résultat final.

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

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

• Nous hiérarchisons 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é du 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 selon l'enquête annuelle de satisfaction client
• Nous reconnaissons les incidents récurrents et expliquons les problèmes sur le forum public pour aider à réduire les impacts négatifs futurs :
  • Nombre de problèmes enregistrés par le service d'assistance 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 grâce aux 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 plus de mesures basées sur ce qui est le plus logique à analyser pour votre équipe spécifique, mais ces mesures peuvent vous donner une longueur d'avance pour commencer à répondre à ces questions inévitables, et elles ne nécessitent pas beaucoup de réinvention de processus pour commencer. Utilisez simplement des tickets modernes, surveillance , résolution d'incident, 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 standard pour la résolution d'incidents et la collaboration. ServiceNow et le Atlassien Les suites sont idéales pour connecter la gestion des incidents et des actifs. Il est important de garder à l'esprit, avant tout, que la résolution et la prévention efficaces des incidents ne reposent pas uniquement sur des outils, mais également sur la mise en place d'un 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 dans l’évaluation de l’efficacité de vos outils, processus et personnes. C’est comme construire une trappe dans toutes vos mesures. De plus, même si un modèle peut être un bon point de départ, l’équipe tirera beaucoup plus de profit de vos rapports si vous allez au-delà de la simple copie d’un modèle. Commencez plutôt par 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. N'oubliez pas que vous êtes dans la même équipe et que ce n'est pas une 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 d’outils et de processus de résolution d’incidents couverts, ainsi que des mesures qui permettent de suivre la manière dont l’entreprise peut continuer à investir pour des améliorations, alors vous êtes en excellente position, même en cas d’incendie de pneus.

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