- PagerDuty /
- Blog /
- Meilleures pratiques et informations /
- Configurer votre PagerDuty pour une douce victoire
Blog
Configurer votre PagerDuty pour une douce victoire
Félicitations ! Vous venez d'acheter PagerDuty, ce qui signifie que vous avez décidé de faire un investissement dans votre processus de gestion des incidents . Cependant, afin de maximiser votre investissement, vous devrez comprendre tous les éléments mobiles de PagerDuty.
Aujourd'hui, nous allons configurer PagerDuty pour une équipe : l'équipe Bikini Bottom. Je vous expliquerai comment configurer les utilisateurs, les équipes, les plannings, les politiques d'escalade et les services, et je soulignerai pourquoi ils sont importants pour le processus de réponse aux incidents.
Cette équipe Bikini Bottom Team de référence peut être utilisée comme modèle pour déployer PagerDuty dans le reste de votre organisation. (Assurez-vous de lire l'intégralité de l'article avant de configurer des ressources dans votre compte PagerDuty . Croyez-moi, cela vous évitera bien des moments de casse-tête).
Qui sont les utilisateurs ?
« Vous n’avez pas besoin d’un permis pour conduire un sandwich. »
– Patrick l'Étoile, bas de bikini
La première étape de la configuration de votre instance PagerDuty consiste à déterminer quels utilisateurs ont besoin d'un accès à PagerDuty . Il existe deux types différents de licences utilisateur : utilisateur et partie prenante .
Licences d'utilisation sont destinés aux personnes qui seront de garde, appelées en cas d'incidents et qui sont censées publier des mises à jour ou résoudre ces incidents. Leurs responsables auront également besoin d'une licence d'utilisateur dans PagerDuty. Ainsi, pour l'équipe Bikini Bottom, Bob l'éponge, Patrick Star et Pieuvre, qui répondront aux incidents, auront tous besoin de licences d'utilisateur. Leur responsable, M. Krabs, aura également besoin d'une licence d'utilisateur pour configurer les applications auxquelles il souhaite que son équipe réponde.
Licences des parties prenantes sont des licences en lecture seule qui permettent à l'individu de recevoir des mises à jour sur les incidents, mais il n'est pas censé participer au processus de correction. Par exemple, Gary the Snail est un cadre auquel l'équipe 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 the Snail a juste besoin d'une visibilité sur l'état de l'incident et les actions de l'équipe Bikini Bottom.
Super, 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 doit avoir.
Que sont les rôles de base ?
Les rôles de base déterminent l’accès d’un utilisateur aux paramètres au niveau du compte PagerDuty .
UN Bonnes pratiques de PagerDuty consiste à définir les rôles de base de tous les utilisateurs comme « Observateur », puis à leur accorder un accès plus large en fonction de leurs rôles dans l'équipe (plus d'informations à ce sujet dans la section suivante). Ceux qui ne sont pas ajoutés à une équipe, ou qui n'ont pas demandé à être ajoutés à une équipe, n'ont peut-être pas besoin d'accéder à PagerDuty .
De plus, l'équipe d'administration de PagerDuty doit bénéficier d'un accès « Administrateur global » afin qu'elle puisse apporter des modifications au compte à mesure que les rôles changent, comme la suppression des chefs d'équipe qui n'ont plus besoin de l'accès à PagerDuty .
Rôle | Toutes les équipes | Tous les horaires | Toutes les politiques d'escalade | Tous les services | Tous les incidents | Tous les utilisateurs |
Administrateur global | Accès en modification | Accès en modification | Accès en modification | Accès en modification | Accès en modification | Accès en modification |
Directeur | Accès en modification | Accès en modification | Accès en modification | Accès en modification | Accès en modification | Voir seulement |
Répondant* | Voir seulement | Voir seulement | Voir seulement | Voir seulement | Accès en modification | Voir seulement |
Observateur* | Voir seulement | Voir seulement | Voir seulement | Voir seulement | Voir seulement | Voir seulement |
Accès restreint* | Pas d'accès | Pas d'accès | Pas d'accès | Pas d'accès | Pas d'accès | Pas d'accès |
Exemple de répartition des droits d’accès accordés à différents rôles dans une organisation.
*Les rôles avec des astérisques peuvent bénéficier d'un accès plus large avec les rôles d'équipe.
Qu'est-ce qu'un rôle d'équipe ?
Dans mon article de blog sur la taxonomie des actifs , j’ai évoqué l’importance de nommer les équipes au sein de PagerDuty de manière à refléter les équipes réelles. Si vos équipes PagerDuty sont à jour avec les équipes du « monde réel », cela évitera que la mauvaise personne soit appelée. Pour les intervenants d’astreinte, se réveiller au milieu de la nuit fait partie du travail. Mais se réveiller pour une alerte que vous ne gérez plus, c’est ainsi que les âmes meurent. Pensez-y de cette façon : chaque fois qu’une alerte est envoyée au mauvais intervenant, la température de l’océan augmente d’un degré. (Trop tôt ?)
Donc, les rôles d'équipe. Il existe trois rôles d'équipe différents disponibles pour chaque utilisateur : Observateur , Répondant , et Directeur . Observateurs sur les équipes privées, vous aurez une visibilité (mais aucun droit de modification) sur les ressources de l'équipe. intervenants pourront reconnaître, résoudre et planifier des remplacements uniquement pour les incidents qui leur sont attribués. Équipe gestionnaires pourra ajouter et supprimer des utilisateurs, des horaires, des politiques d'escalade et des services uniquement pour les actifs de leur équipe.
Pour l'équipe de Bikini Bottom, M. Krabs se verra attribuer le rôle de chef d'équipe et Bob l'éponge, Patrick et Squidward se verront attribuer le rôle d'intervenant de l'équipe.
Des horaires
La fonctionnalité de planification de PagerDuty vous permet de configurer une fois pour toutes votre rotation et votre modèle d'astreinte ; 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 ils le sont et à quelles heures de la journée une personne est d'astreinte, pour ne citer que quelques avantages. Vous devez nommer le planning avec autant de contexte que possible, en tenant compte des éléments suivants :
- Le sous-ensemble d'utilisateurs de l'équipe qui seront de garde
- Si ce calendrier est spécifique à un service
- Pourquoi l'horaire est spécifique à un service
Par exemple, Patrick et Squidward sont spécialisés dans l'entretien des laitues. Bob l'éponge n'a donc pas besoin de faire partie du programme de service « Laitue ». Ce programme s'appellerait « Équipe Bikini Bottom|Pâté de crabe|Rotation de laitue », un sous-ensemble du « Programme de l'équipe Bikini Bottom ». Vous pouvez vous référer au programme pour savoir qu'il est spécifique à l'entretien des laitues. En cliquant dessus, vous saurez qui sont les experts en la matière pour les problèmes liés à la « laitue ».
De plus, les bonnes pratiques DevOps indiquent que seuls les intervenants qui peuvent réagir à l'alerte doivent être sur la rotation d'astreinte pour ce service particulier. Donc, dans ce cas, même si vous pouvez mettre quelqu'un comme Plankton (qui ne fait pas partie de l'équipe Krabby Patty sur le planning), vous ne devriez pas le faire car il ne peut de toute façon pas réagir aux alertes.
Voici un scénario de test sur les horaires : choisissez la meilleure réponse !
Sandy Cheeks est de garde pour le service de Krabby Patty. Une alerte arrive, le serveur est en feu, elle ne sait pas quoi faire, alors elle réveille Squidward pour le réparer. Quelle est votre réaction ?
A) C’est tout à fait normal : plus il y a de monde, mieux c’est dans la réponse aux incidents.
B) Sandy ne devrait pas être dans la rotation pour ce service.
C) Sandy devrait être formée au triage des incidents pour le service A avant d'être inscrite au planning.
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 appeler Squidward pour résoudre un problème dans votre environnement, Squidward est votre point de défaillance unique. N'oubliez pas : la résilience de votre pile d'applications dépend de la résilience de vos points de défaillance uniques.
https://giphy.com/gifs/spongebob-spongebob-squarepants-season-6-26FmjKdhkXyfUPnj2
Politiques d'escalade
Si vous avez des SLA ou des SLO à respecter, Politique d'escalade (EP) est votre meilleur ami. Un EP détermine qui avertir lorsqu'une alerte arrive dans un service.
Disons que M. Krabs définit le SLA pour le service Krabby Patty où 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 avoir les meilleures chances de respecter ses SLA, M. Krabs devrait configurer l'EP comme suit :
- M. Krabs place son expert en la matière, Bob l'éponge, en première ligne de défense. Si Bob l'éponge est en train d'attraper des méduses et qu'il ne reçoit pas l'alerte, le problème est automatiquement transmis à Squidward au bout de 15 minutes, ce qui est conforme au SLA.
- Désormais, si Squidward se casse tous les os du corps et ne peut pas reconnaître la page, M. Krabs sera averti après 15 minutes, ce qui reste dans le délai de SLA.
Voici à quoi ressemblera cet EP dans PagerDuty:
Cependant, tous les services ne sont pas égaux. Le service Krabby Patty a un SLA de deux heures, mais d'autres services moins urgents accordent aux intervenants plus de temps avant de passer à l'intervenant suivant. Dans l'exemple ci-dessous pour le service Muscle Beach, Patrick a deux heures pour répondre avant que l'incident ne soit transmis à M. Krabs.
Configuration des services dans PagerDuty
Accrochez-vous bien, nous avons presque bouclé la boucle ! La première chose Après avoir obtenu l'accès à votre instance PagerDuty , vous souhaitez déterminer sur quoi vous souhaitez que PagerDuty envoie des alertes ; en d'autres termes, pour quels services souhaitez-vous être alerté ?
Alors pourquoi est-ce que je parle des services en dernier ?
Bonne question. Mais il y a une méthode derrière ma folie : pour pouvoir configurer un service, vous devez d'abord configurer vos utilisateurs, vos équipes, vos plannings et vos politiques d'escalade.
En un mot, l'outil de surveillance Bun Burner envoie des événements à un service dans PagerDuty (Krabby Patty|Buns), qui dispose d'une politique d'escalade. Le calendrier de la politique d'escalade détermine qui notifier. Dans ce cas, Buns brûle rapidement, donc la politique d'escalade a un SLA de 5 minutes, et les utilisateurs de Team Bikini Bottom sont sur le calendrier, comme illustré ci-dessous :
Ce qui m’amène à la question suivante : comment déterminez-vous les services à configurer dans PagerDuty?
Tout d’abord, vous devez déterminer ce qui est important pour vous.
Voici quelques options pour affiner ce qui est le plus important :
- Décomposez les services commerciaux en leurs propres composants distincts.
- Prenez chaque équipe que vous avez définie précédemment et examinez leurs domaines de responsabilités.
- Consultez un catalogue de services (si vous en avez un).
- Regardez vos outils de surveillance et voyez ce que vous surveillez.
Idéalement, vous devez décomposer chaque service de la manière la plus granulaire possible. Par exemple, si vous avez une application Krabby Patty, vous souhaiterez créer un service pour :
- Galette de crabe | Petits pains
- Galette de crabe|Patty
- Galette de crabe | Laitue
- Galette de crabe | Tomate
- Galette de crabe | Oignon
- Galette de crabe | Sauce secrète
Ainsi, lorsqu'il est 2 heures du matin et que Bob l'éponge reçoit une alerte du service Buns, c'est beaucoup plus instructif que de recevoir une alerte du service Krabby Patty, ce qui lui permet de réagir et de résoudre l'incident plus rapidement pour respecter les SLA.
Maintenant que vous avez décidé quels services vous devez créer dans PagerDuty, vous pouvez travailler à rebours et décider de leurs EP et de qui mettre sur le planning pour chaque service. Cela permettra ensuite de déterminer qui a besoin d'une licence utilisateur dans PagerDuty.
https://giphy.com/gifs/reactionseditor-reaction-26u4lOMA8JKSnL9Uk
Gestion des incidents – simplifiée
Même si l'esprit de Patrick peut être une énigme, votre processus de gestion des incidents ne doit pas l'être. En configurant correctement PagerDuty , vous avez identifié :
- Applications/Services qui vous intéressent (au moins votre équipe).
- Le SLA pour chaque service.
- Le point de contact lorsqu'une application échoue (ainsi que les points de défaillance des connaissances dans l'équipe !).
- Qui est dans quelle équipe.
Il s'agit du strict minimum pour configurer PagerDuty. Nous disposons d'une multitude de fonctionnalités qui optimisent encore davantage la gestion de vos opérations numériques, telles que Réponse moderne aux incidents , Renseignements sur les événements , Analytique , et Visibilité . Revenez ultérieurement pour découvrir d’autres bonnes pratiques afin de savoir comment tirer le meilleur parti de votre investissement PagerDuty !