Il est 2 h 37 un mardi soir, vous dormez, mais c'est aussi votre tour d'être de garde. Vous recevez un appel téléphonique de PagerDuty. Votre partenaire vous frappe avec un oreiller pour tenter de vous réveiller. Ça a marché. Vous répondez à l'appel, groggy, et entendez votre robot préféré à l'autre bout du fil :

Robot-Guy :
' Alerte PagerDuty . Vous avez 1 alerte déclenchée sur le Service : Datadog. Appuyez sur 2 pour accuser réception. Appuyez sur 4 pour escalader.

' Alerte PagerDuty . Vous avez 1 alerte déclenchée sur le Service : Datadog. Appuyez sur 2 pour accuser réception. Appuyez sur 4 pour escalader.

' Alerte PagerDuty . Tu as-'

Vous appuyez sur 2, puis sortez du lit le plus silencieusement possible pour que l'oreiller ne se transforme pas en coup de pied.

Vous vous connectez à PagerDuty et cliquez sur l'incident qui vous est attribué. Puisque l’incident s’est déclenché sur un service appelé « Chien de données ”, vous supposez que le problème est lié à quelque chose que Datadog a détecté. Mais, tu te demandes, Je n'ai pas travaillé sur quoi que ce soit lié à Datadog depuis des mois, alors pourquoi suis-je même de garde pour ce service ? Cette charge utile Datadog ne vous donne pas beaucoup d'informations, vous vous connectez donc à Datadog pour y jeter un œil.

Quelle pile ce Datadog surveille-t-il ? Un centre de données de la côte ouest ? De la côte est ? Une base de données ? Une API ?

Profond soupir

Après quelques minutes de clic, vous trouvez ce qui est cassé. Il ne vous reste plus qu'à passer sur PagerDuty et à réaffecter l'incident à la bonne équipe et vous pourrez vous rendormir !

Vous revenez donc à PagerDuty, cliquez sur « Réaffecter » et sur la possibilité de réaffecter à un utilisateur ou Politique d'escalade apparaît. Désormais, les politiques d'escalade (EP) doivent être nommées d'après les services ou les équipes, c'est donc probablement un pari sûr. Vous parcourez la liste des EP et vous trouvez :

• Le test EP de Lisa
• En mer 24h/24 et 7j/7
• Des pépites et des licornes
• Équipe de direction
• Homme chauve-souris

Un autre soupir profond

Semble familier?

En tant que consultant Digital Insights, je travaille avec des entreprises de toutes tailles et de tous secteurs verticaux qui utilisent PagerDuty, et j'ai entendu parler de ce scénario à maintes reprises. Grâce à la flexibilité de la plateforme, je peux travailler avec 10 entreprises différentes et voir 12 configurations PagerDuty différentes. Une grande partie de mon rôle consiste à conseiller les utilisateurs actuels sur la façon de maximiser leur flux de travail de gestion des incidents à l'aide de PagerDuty, que je propose via Services d'experts forfaits ou notre Service de gestion opérationnelle de la santé .

Préparez-vous au succès

Lorsque je travaillais avec une société de divertissement multimilliardaire pour maximiser son expérience PagerDuty , l'un des problèmes que j'ai rencontré lors de cet engagement était que leurs équipes réelles n'étaient pas synchronisées avec leurs équipes. équipes dans PagerDuty . Il y a plusieurs raisons à ce phénomène ; par exemple, la migration des employés entre les équipes ou la création d'équipes temporaires basées sur des projets qui ne sont pas supprimées lorsqu'elles ne sont plus pertinentes. Si les équipes ne sont pas tenues au courant dans PagerDuty, les intervenants risquent d'être réveillés au milieu de la nuit pour quelque chose qu'ils n'ont pas touché depuis des semaines, des mois, voire des années.

Un autre problème de configuration que je rencontre concerne les services PagerDuty nommés d'après les équipes, et non les services d'applications métier surveillés. Cette approche est logique dans une petite entreprise où une petite équipe est responsable de l’ensemble d’un produit. Cela a également du sens si l’équipe n’a travaillé que sur un seul produit et qu’elle est statique. Bien que cette option puisse être viable au début, la structure d’une équipe pour un produit n’est tout simplement pas évolutive.

Bonnes pratiques

Les meilleures pratiques nécessitent une taxonomie cohérente pour vos équipes, calendriers, politiques de remontée d'informations et services PagerDuty . Pourquoi est-ce important? Des services correctement nommés peuvent vous faire gagner des minutes cruciales Temps de réponse aux incidents en donnant à l'intervenant un contexte sur ce qui ne va pas, ce qui facilite l'escalade des incidents, fait appel à davantage d'experts en la matière (SME) et, surtout, réduit l'impact commercial des incidents.

De plus, la taxonomie des actifs doit être centrée sur les services, ce qui vous permet de voir clairement quel composant de votre service critique pour l'entreprise cause le plus de problèmes.

Alors, qu'est-ce qui fait exactement qu'un service porte un nom bien choisi ? Voici quelques exemples de services mal nommés :

• Chien de données
• DevOps
• AWS
• Intégration de la messagerie électronique

Et voici quelques exemples centrés sur les services pour nommer vos services :

• Logiciel de service aux entreprises - Outil de surveillance des services
• (Production/AQ/Dev/Stg)-Service métier-Service logiciel-Outil de surveillance

Meilleures pratiques

Une fonctionnalité fournie par PagerDuty (et rarement utilisée) consiste à nommer le intégrations sur votre service. Par défaut, le nom de l'intégration est l'outil de surveillance. Mais lorsque chaque équipe de votre organisation dispose d'une intégration Datadog, comment savez-vous ce que le Datadog de votre équipe surveille ? Pour éviter toute confusion, je recommande de nommer une intégration en fonction de ce qu'elle surveille. Par exemple, les intégrations Datadog peuvent être nommées de manière plus significative :

• Composant Datadog
• Application Datadog

Une autre nomenclature d’intégration pourrait être :

• Outil de surveillance - Composant d'application

De plus, étant donné que PagerDuty peut envoyer des alertes à partir de tout type de système envoyant des e-mails, il est crucial de nommer correctement votre intégration de messagerie. Je suggère quelque chose du genre :

• Outil de surveillance des composants - Courriel

Meilleur entrainement

La plupart des entreprises ont un accord de niveau de service (SLA) concernant leurs services, et les politiques d'escalade de PagerDuty les aident à respecter ces SLA en accélérant le temps de réponse. Dans ce cas, nous vous recommandons de nommer vos politiques d'escalade en fonction du contexte du service auquel elles appartiennent et de l'équipe. Par exemple :

• Service d'application et de logiciel d'équipe SLA min
• Équipe - Application - Service logiciel - Production/Développement

L'utilisation de ces formats vous permet de savoir quel service est à l'origine d'un incident, à quelle équipe appartient ce service et dans quel délai vous pouvez vous attendre à ce qu'une personne réponde, le tout en un coup d'œil ! Cela fournit un contexte aux équipes NOC/Support, qui classent/escaladent parfois les incidents manuellement, pour trouver rapidement la bonne équipe à trier.

Les plannings sont constitués d'utilisateurs, qui appartiennent généralement à des équipes. Selon la configuration de votre organisation, vous pouvez nommer les plannings d'après les experts en la matière pour ce service ou les équipes qui prennent en charge ce service. Par exemple :

• Nom de l'équipe - Nom du service - Principal/Secondaire
• Nom du service - Principal/Secondaire

Succès!

À la fin de mon engagement auprès de cette société de divertissement de plusieurs milliards de dollars, nous avons exécuté les opérations suivantes :

1. Unifié deux équipes PagerDuty en une seule pour mieux refléter leur réalité. Cela a supprimé les éléments inutiles et a fourni une vue unique de leur équipe et de leurs notifications.
2. Nous avons séparé la confluence des intégrations qui ont toutes été intégrées dans un seul service (ce qui n'est PAS une bonne pratique). Ils ont également nommé les nouveaux services d'après l'application métier et l'outil de surveillance. Comme il n'y a qu'une seule intégration par service, nous avons ensuite appliqué Renseignements sur les événements aux signaux envoyés dans PagerDuty. Avec Event Intelligence, le Fonctionnalité de regroupement d'alertes en fonction du temps regroupe en toute confiance toutes les alertes provenant du même outil pour la même application dans une fenêtre de deux minutes, ce qui permet de réduire le bruit non exploitable des tempêtes d'alertes. Les intervenants peuvent alors rapidement identifier la source de l'erreur et agir sur l'incident.

À 2 h 37 du matin, la dernière chose que vous souhaitez faire est de parcourir la documentation de l'organisation. Les équipes d'exploitation matures disposent d'une taxonomie standard pour leurs hôtes et leurs serveurs, et la plateforme qu'elles utilisent pour orchestrer leur réponse aux incidents majeurs devrait en faire de même.