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

Robo-Guy :
« Alerte PagerDuty . Vous avez déclenché 1 alerte sur le service : Datadog. Appuyez sur 2 pour accuser réception. Appuyez sur 4 pour faire remonter l’alerte. »

« Alerte PagerDuty . Vous avez déclenché 1 alerte sur le service : Datadog. Appuyez sur 2 pour accuser réception. Appuyez sur 4 pour faire remonter l’alerte. »

« Alerte PagerDuty . Vous avez… »

Vous appuyez sur 2, puis vous sortez du lit aussi silencieusement que 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é. Cet incident a été déclenché sur un service appelé « Datadog « Vous supposez que le problème est lié à quelque chose que Datadog a détecté. » Mais, vous vous demandez, Je n'ai rien fait en rapport avec 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 devez donc vous connecter à Datadog pour y jeter un œil.

Quel système Datadog surveille-t-il ? Centre de données de la côte ouest ? Côte est ? Base de données ? API ?

Soupir profond

Après quelques clics, vous trouvez la panne. Il ne vous reste plus qu'à basculer vers PagerDuty , à réassigner l'incident à l'équipe concernée et vous pouvez enfin dormir sur vos deux oreilles !

Vous retournez donc dans PagerDuty, cliquez sur « Réaffecter » et choisissez l’option de réaffectation à un utilisateur ou Politique d'escalade L'option apparaît. Les stratégies d'escalade (EP) devraient porter le nom de services ou d'équipes ; c'est donc probablement une bonne piste. Vous parcourez la liste des stratégies d'escalade et vous trouvez :

• L'épisode test de Lisa
• Disponible en mer 24h/24 et 7j/7
• Paillettes et licornes
• Équipe de direction
• Batman

Un autre profond soupir.

Ça vous dit quelque chose ?

En tant que consultant en veille numérique, je travaille avec des entreprises de toutes tailles et de tous secteurs qui utilisent PagerDuty, et j'ai constaté ce problème à maintes reprises. Grâce à la flexibilité de la plateforme, je peux collaborer avec 10 entreprises différentes et observer 12 configurations PagerDuty distinctes. Une part importante de mon rôle consiste à conseiller les utilisateurs actuels sur l'optimisation de leur flux de travail de gestion des incidents avec PagerDuty, que je fournis via Services d'experts nos forfaits ou nos Service de gestion de la santé des opérations .

Se préparer au succès

Lorsque je travaillais avec une entreprise de divertissement pesant plusieurs milliards de dollars pour optimiser leur expérience PagerDuty , l'un des problèmes rencontrés était le manque de synchronisation entre leurs équipes physiques et leurs équipes virtuelles. équipes dans PagerDuty Ce phénomène s'explique par de nombreux facteurs : par exemple, les transferts d'employés entre équipes ou la création d'équipes temporaires pour des projets spécifiques qui ne sont pas supprimées lorsqu'elles deviennent obsolètes. Si les équipes ne sont pas mises à jour dans PagerDuty, les intervenants risquent d'être réveillés en pleine nuit pour une tâche qu'ils n'ont pas effectuée depuis des semaines, des mois, voire des années.

Un autre problème de configuration que je rencontre concerne les services PagerDuty : ils portent le nom des équipes et non celui des applications métier surveillées. Cette approche se justifie dans une petite entreprise où une seule équipe est responsable d'un produit entier. Elle est également pertinente si l'équipe n'a travaillé que sur un seul produit et qu'elle est stable. Bien que cette option puisse être viable au départ, la structure « une équipe par produit » n'est tout simplement pas évolutive.

Bonnes pratiques

Les bonnes pratiques exigent une taxonomie cohérente pour vos équipes, planifications, politiques d'escalade et services PagerDuty . Pourquoi est-ce important ? Des services correctement nommés peuvent permettre de gagner de précieuses minutes. temps de réponse aux incidents en fournissant au répondant le contexte de ce qui est cassé — facilitant ainsi l'escalade des incidents, l'intervention de davantage d'experts en la matière (SME) et, surtout, la réduction de l'impact des incidents sur l'activité.

De plus, la taxonomie des actifs doit être axée sur les services ; cela vous permet de voir clairement quel composant de votre service essentiel à l'entreprise est à l'origine du plus grand nombre de problèmes.

Qu’est-ce qui caractérise un service bien nommé ? Voici quelques exemples de services mal nommés :

• Datadog
• DevOps
• AWS
• Intégration de la messagerie électronique

Voici quelques exemples axés sur les services pour nommer vos services :

• Outil de surveillance des services logiciels pour entreprises
• (Production/AQ/Développement/Standardisation) - Service métier - Service logiciel - Outil de surveillance

Meilleure pratique

Une fonctionnalité offerte par PagerDuty (et rarement utilisée) consiste à nommer le intégrations sur votre service. Par défaut, le nom de l'intégration correspond à l'outil de supervision. Mais si chaque équipe de votre organisation dispose d'une intégration Datadog, comment savoir ce que Datadog supervise pour chaque équipe ? Pour éviter toute confusion, je recommande de nommer l'intégration en fonction de ce qu'elle supervise. Par exemple, les intégrations Datadog peuvent être nommées de manière plus explicite :

• Composant Datadog
• Application Datadog

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

• Outil de surveillance - Composant d'application

De plus, comme PagerDuty peut envoyer des alertes depuis n'importe quel système envoyant des e-mails, il est crucial de nommer correctement votre intégration de messagerie. Je suggère quelque chose comme :

• Outil de surveillance des composants - Courriel

Meilleures pratiques

La plupart des entreprises disposent d'un accord de niveau de service (SLA) pour 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 recommandons de nommer vos politiques d'escalade en fonction du service auquel elles se rapportent et de l'équipe concernée. Par exemple :

• Service logiciel d'application d'équipe - SLA min
• Service logiciel d'application d'équipe - Production/Standard/Développement

Ces formats vous permettent d'identifier en un coup d'œil le service à l'origine de l'incident, l'équipe concernée et le délai de réponse. C'est très utile pour les équipes NOC/Support, qui gèrent parfois les incidents manuellement, afin de trouver rapidement l'équipe compétente pour le traitement.

Les plannings sont composés d'utilisateurs, généralement membres d'équipes. Selon l'organisation de votre entreprise, vous pouvez nommer les plannings d'après les experts du service concerné ou les équipes qui le prennent en charge. Par exemple :

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

Succès!

À la fin de ma collaboration avec cette société de divertissement pesant plusieurs milliards de dollars, nous avons réalisé les opérations suivantes :

1. Nous avons fusionné deux équipes PagerDuty en une seule afin de mieux refléter leur réalité. Cela a permis d'éliminer les éléments superflus et d'offrir une vue d'ensemble claire et unifiée de l'équipe et des notifications.
2. Nous avons démêlé l'ensemble des intégrations qui convergeaient vers un seul service (ce qui n'est PAS une bonne pratique). De plus, les nouveaux services ont été nommés 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 à PagerDuty. Grâce à Event Intelligence, Fonction de regroupement des alertes en fonction du temps Ce système regroupe avec précision toutes les alertes provenant d'un même outil et d'une même application dans un intervalle de deux minutes, ce qui permet de réduire le nombre d'alertes non exploitables générées par les pics d'alertes. Les intervenants peuvent ainsi identifier rapidement la source de l'erreur et intervenir efficacement.

À 2h37 du matin, la dernière chose que vous avez envie de faire, c'est de passer en revue la documentation de l'entreprise. Les équipes d'exploitation expérimentées disposent d'une taxonomie standard pour leurs hôtes et serveurs ; il devrait en être de même pour la plateforme qu'elles utilisent pour orchestrer leur réponse aux incidents majeurs.