Félicitations ! Vous venez d’acheter PagerDuty, ce qui signifie que vous avez décidé d’investir dans votre système de messagerie. processus de gestion des incidents Toutefois, afin de maximiser votre investissement, vous devrez comprendre tous les éléments qui composent PagerDuty.

Aujourd'hui, nous allons configurer PagerDuty pour une équipe : l'équipe Bikini Bottom. Je vous guiderai pas à pas dans la configuration des utilisateurs, des équipes, des planifications, des politiques d'escalade et des services, et je soulignerai leur importance pour la gestion des incidents.

Cette équipe Bikini Bottom, véritable référence, peut servir de modèle pour déployer PagerDuty au sein de votre organisation. (Veuillez lire l'article en entier avant de configurer les ressources dans votre compte PagerDuty ; croyez-moi, cela vous évitera bien des frustrations.)

Qui sont les utilisateurs ?

« Pas besoin de permis pour conduire un sandwich. »
– Patrick Star, Bikini Bottom

La première étape de la configuration de votre instance PagerDuty consiste à déterminer quels utilisateurs ont besoin d'accéder à PagerDuty . Il existe deux types de licences utilisateur : utilisateur et partie prenante .

Licences d'utilisateur Ces licences sont destinées aux personnes d'astreinte, alertées en cas d'incident et chargées de publier des mises à jour ou de résoudre ces incidents. Leurs responsables auront également besoin d'une licence utilisateur PagerDuty. Ainsi, pour l'équipe de Bikini Bottom, Bob l'Éponge, Patrick l'Étoile de Mer et Carlo Tentacule, qui interviendront en cas d'incident, tous auront besoin d'une licence utilisateur. Leur responsable, M. Krabs, aura également besoin d'une licence utilisateur pour configurer les applications que son équipe devra utiliser.

Licences des parties prenantes Il s'agit de licences en lecture seule permettant à l'utilisateur de recevoir des mises à jour concernant les incidents, sans pour autant l'impliquer dans leur résolution. Par exemple, Gary l'Escargot est un cadre auquel l'équipe de Bikini Bottom rend compte ; il n'aura donc besoin que d'une licence de partie prenante, car il ne participe pas au tri des incidents. Gary l'Escargot a simplement besoin de consulter l'état d'avancement de l'incident et les actions de l'équipe de Bikini Bottom.

Parfait, nous avons déterminé qui doit être dans PagerDuty! Il est maintenant temps de réfléchir au rôle de base que chaque utilisateur devrait avoir.

Que sont les rôles de base ?

Les rôles de base déterminent l'accès d'un utilisateur aux paramètres de son compte PagerDuty .

UN Meilleures pratiques de PagerDuty Il s'agit d'attribuer à tous les utilisateurs le rôle de base « Observateur », puis d'étendre leurs droits d'accès en fonction de leur rôle au sein d'une équipe (nous y reviendrons dans la section suivante). Les utilisateurs qui ne font partie d'aucune équipe ou qui n'ont pas demandé à y être intégrés n'ont pas forcément besoin d'accéder à PagerDuty .

De plus, l'équipe d'administration de PagerDuty devrait se voir accorder un accès « Administrateur global » afin de pouvoir apporter des modifications au compte en fonction de l'évolution des rôles, comme la suppression des responsables d'équipe qui n'ont plus besoin d'accéder à PagerDuty .

Exemple de répartition des droits d'accès attribués aux différents rôles au sein d'une organisation.
*Les rôles marqués d'un astérisque peuvent bénéficier d'un accès plus étendu grâce aux rôles d'équipe.

En quoi consiste un rôle au sein d'une équipe ?

Dans mon Article de blog sur la taxonomie des actifs J'ai évoqué l'importance de nommer les équipes dans PagerDuty de manière à refléter les équipes réelles. Si vos équipes PagerDuty correspondent aux équipes existantes, cela évitera d'appeler la mauvaise personne. Pour les intervenants d'astreinte, se lever en pleine nuit fait partie du métier. Mais se lever pour une alerte dont on n'a plus la charge, c'est une véritable catastrophe. Imaginez : chaque fois qu'une alerte est envoyée au mauvais intervenant, la température de l'océan augmente d'un degré. (Un peu tôt pour le dire ?)

via GIPHY

Concernant les rôles au sein de l'équipe, trois rôles différents sont disponibles pour chaque utilisateur : Observateur , Répondant , et Directeur . Observateurs Les membres des équipes privées auront une visibilité (mais pas de droits de modification) sur les ressources de l'équipe. intervenants Ils pourront accuser réception, résoudre et planifier des interventions d'urgence uniquement pour les incidents qui leur seront attribués. gestionnaires Ils pourront ajouter et supprimer des utilisateurs, des calendriers, des politiques d'escalade et des services uniquement pour les ressources de leur équipe.

Pour l'équipe de Bikini Bottom, M. Krabs se verra attribuer le rôle de manager d'équipe et Bob l'éponge, Patrick et Carlo se verront attribuer le rôle d'intervenants de l'équipe.

Horaires
La fonctionnalité de planification de PagerDuty vous permet de configurer vos astreintes une seule fois ; nous nous occupons du reste. Dans la console de planification, vous pouvez définir quels utilisateurs sont d'astreinte, quand ils le sont, dans quel ordre et pendant quelles heures, entre autres avantages. Nommez votre planning de manière aussi explicite que possible, en tenant compte des éléments suivants :

• Le sous-ensemble d'utilisateurs de l'équipe qui seront d'astreinte
• Que ce calendrier soit spécifique à un service
• Pourquoi l'horaire est spécifique à un service

Par exemple, Patrick et Carlo sont spécialisés dans l'entretien des salades, donc Bob l'Éponge n'a pas besoin d'être inclus dans le planning de service des salades. Ce planning s'appellerait « Équipe Bikini Bottom | Krabby Patty | Rotation des salades », un sous-ensemble du planning de l'équipe Bikini Bottom. Vous pouvez consulter ce planning pour savoir qu'il est spécifique à l'entretien des salades, et en cliquant dessus, vous verrez qui sont les experts pour les questions relatives aux salades.

De plus, les bonnes pratiques DevOps stipulent que seuls les intervenants capables de traiter l'alerte doivent être d'astreinte pour le service concerné. Dans ce cas précis, même s'il est possible d'inclure une personne comme Plankton (qui ne fait pas partie de l'équipe Krabby Patty) dans le planning, il est déconseillé de le faire, car il ne peut de toute façon pas traiter les alertes.

Voici un scénario de test concernant les horaires : choisissez la meilleure réponse !

Sandy Cheeks est de garde pour le service des pâtés de crabe. Une alerte arrive : le serveur est en feu ! Désemparée, elle réveille Carlo pour qu'il répare le problème. Quelle est votre réaction ?

A) C’est parfaitement acceptable – plus on est de fous, plus on rit en matière de réponse aux incidents.
B) Sandy ne devrait pas faire partie du roulement pour ce service.
C) Sandy devrait être formée au triage des incidents pour le service A avant d'être inscrite à l'horaire.
D) Sandy devrait aller tester la température de l'océan après chaque notification.

Si vous avez choisi C, alors vous avez raison !

Lorsque Sandy doit faire appel à Carlo pour résoudre un problème dans votre environnement, Carlo devient votre unique point de défaillance. N'oubliez pas : la résilience de votre infrastructure applicative dépend de la robustesse de vos points de défaillance uniques.

https://giphy.com/gifs/spongebob-spongebob-squarepants-season-6-26FmjKdhkXyfUPnj2

Politiques d'escalade
Si vous devez respecter des SLA ou des SLO, Politique d'escalade (EP) est votre meilleur allié. Un EP détermine qui avertir lorsqu'une alerte est reçue par un service.

Supposons que M. Krabs définisse le SLA du service Krabby Patty selon lequel un ingénieur est : 1) tenu de répondre à un incident dans les 30 minutes et 2) tenu de résoudre ledit incident dans les deux heures.

Pour optimiser ses chances de respecter ses SLA, M. Krabs devrait configurer le EP comme suit :

1. M. Krabs désigne son expert en la matière, Bob l'Éponge, comme première ligne de défense. Si Bob l'Éponge est parti pêcher des méduses et rate l'alerte, le problème est automatiquement transmis à Carlo Tentacule après 15 minutes, ce qui est conforme au contrat de niveau de service.
2. Maintenant, si Carlo se casse tous les os et ne peut pas accuser réception de la page, M. Krabs sera averti après 15 minutes, ce qui reste dans les délais prévus par le SLA.

Voici à quoi ressemblera cet EP dans PagerDuty:

Cependant, tous les services ne se valent pas. Le service Krabby Patty a un délai de réponse de deux heures, tandis que d'autres services, moins urgents, accordent plus de temps aux intervenants avant de transférer l'intervention à un autre intervenant. Dans l'exemple ci-dessous concernant le service Muscle Beach, Patrick dispose de deux heures pour intervenir avant que l'incident ne soit transmis à M. Krabs.

Configuration des services dans PagerDuty
Accrochez-vous bien, la boucle est presque bouclée ! La première chose Une fois que vous aurez accès à votre instance PagerDuty, vous devrez déterminer pour quels services vous souhaitez recevoir des alertes de la part de PagerDuty ; autrement dit, pour quels services souhaitez-vous être alerté ?

Alors pourquoi est-ce que je parle des services en dernier ?

Question pertinente. Mais il y a une logique derrière tout ça : pour pouvoir configurer un service, il faut d’abord configurer les utilisateurs, les équipes, les planifications et les politiques d’escalade.

En résumé, l'outil de surveillance Bun Burner envoie des événements à un service de PagerDuty (Krabby Patty|Buns), qui dispose d'une politique d'escalade. La planification de cette politique détermine les personnes à notifier. Dans ce cas précis, les Buns brûlent rapidement ; la politique d'escalade a donc un SLA de 5 minutes et les utilisateurs de l'équipe Bikini Bottom sont concernés, comme illustré ci-dessous :

Ce qui m'amène à la question suivante : comment déterminer quels services configurer dans PagerDuty?

Tout d'abord, vous devez déterminer ce qui est important pour vous.

Voici quelques options pour déterminer ce qui est le plus important :

• Décomposez les services de l'entreprise en leurs composantes distinctes.
• Prenez chaque équipe que vous avez définie précédemment et examinez leurs domaines de responsabilité.
• Consultez le catalogue de services (si vous en avez un).
• Examinez vos outils de surveillance et voyez ce que vous surveillez.

Idéalement, chaque service devrait être décomposé aussi finement que possible. Par exemple, pour une application Krabby Patty, il faudrait créer un service pour :

• Krabby Patty | Petits pains
• Krabby Patty|Patty
• Krabby Patty | Laitue
• Krabby Patty | Tomate
• Krabby Patty|Oignon
• Krabby Patty | Sauce secrète

Ainsi, lorsqu'il est 2 heures du matin et que Bob l'éponge reçoit une alerte du service Buns, cette alerte est beaucoup plus informative que celle du service Krabby Patty, ce qui lui permet de réagir et de résoudre l'incident plus rapidement afin de respecter les SLA.

Maintenant que vous avez déterminé les services à créer dans PagerDuty, vous pouvez définir leurs points d'intervention et les personnes à affecter à chaque service. Cela permettra de déterminer qui a besoin d'une licence utilisateur dans PagerDuty.

https://giphy.com/gifs/reactionseditor-reaction-26u4lOMA8JKSnL9Uk

Gestion des incidents — simplifiée
L'esprit de Patrick est peut-être une énigme, mais votre processus de gestion des incidents n'a pas à l'être. En configurant correctement PagerDuty , vous avez déjà identifié :

• Applications/Services qui vous intéressent (au moins votre équipe).
• Le SLA pour chaque service.
• Le point de contact en cas de défaillance d'une application (ainsi que les points de défaillance en matière de connaissances au sein de l'équipe !).
• Qui est dans quelle équipe ?

Voici le strict minimum pour configurer PagerDuty. Nous proposons une multitude de fonctionnalités qui optimisent la gestion de vos opérations numériques, telles que : Réponse moderne aux incidents , Renseignements sur les événements , Analytique , et Visibilité Revenez consulter cette page ultérieurement pour découvrir d'autres bonnes pratiques et apprendre comment tirer le meilleur parti de votre investissement PagerDuty !