Salut les Yangsters, j'espère que vous vous portez tous bien en ces temps incertains. Étant moi-même professionnel du secteur technologique, j'imagine que votre charge de travail est restée la même, voire plus importante, vu le passage au tout en ligne. Pour ma part, j'ai été tellement occupé que je n'ai pas pu vous tenir au courant des dernières nouvelles. Bas de bikini -jusqu'à maintenant.

Mais ne vous inquiétez pas ! Nous allons surmonter cela ensemble !

VOUS ÊTES PRÊTS, LES ENFANTS ? JE NE VOUS ENTENDS PAS ! OHHHH !

Dernières nouvelles : Le restaurant de burgers du coin, le Krusty Krab, est toujours ouvert. Ils respectent la distanciation sociale, en maintenant une distance de deux mètres entre les clients, et proposent uniquement des plats à emporter et la livraison. Apparemment, même sous la mer, la prudence est de mise. Surtout quand on est entouré de sardines.

Plankton, l'ennemi juré de M. Krabs, cherche à moderniser les opérations techniques de son restaurant (le Chum Bucket) pour rester compétitif face au Krusty Krab. Il propose notamment la commande en ligne afin de limiter les contacts entre crustacés.

Plankton, avec l'aide de sa femme robot, Karen, doit renforcer son système de gestion des incidents pour organiser et gérer les demandes d'appâts qui affluent. Karen comprend parfaitement les conséquences d'une erreur de communication, surtout pour un robot sous l'eau. Plankton a choisi ServiceNow comme plateforme centrale de gestion des demandes. La bonne nouvelle, c'est qu'il existe une solution robuste. Intégration disponible entre ServiceNow et PagerDuty avertir les personnes concernées lorsque les demandes se transforment en incidents.

En configurant l'intégration ServiceNow + PagerDuty , l'intégralité du cycle de vie des incidents est enregistrée entre les deux systèmes. Les utilisateurs peuvent ensuite accéder aux produits et fonctionnalités de PagerDuty , tels que l'analyse des événements, la réponse moderne aux incidents, les analyses post-mortem, la création d'incidents, la notification des parties prenantes et la résolution des incidents, pour n'en citer que quelques-uns. guide d'intégration Le guide explique très bien comment configurer l'intégration, mais Plankton aimerait savoir pourquoi une configuration particulière est plus efficace que d'autres. Après tout, il a déjà investi ses économies dans ServiceNow et PagerDuty.

L'intégration de ServiceNow PagerDuty vous permet de synchroniser les incidents de deux manières différentes : Groupe d'affectation uniquement ou Éléments de configuration + Groupe d'affectation (CI + AG).

Mappage du groupe d'affectation uniquement

Le mappage par groupe d'affectation uniquement est la méthode la plus simple pour faire communiquer les deux systèmes et permet à vos équipes d'intervenir en temps réel sur les incidents ServiceNow critiques. Une fois un groupe d'affectation provisionné dans PagerDuty, l'intégration créera un groupe d'affectation technique. Service et un Politique d'escalade Dans PagerDuty, tout incident ServiceNow attribué à ce groupe d'affectation sera synchronisé et créera un incident PagerDuty sur ce service, notifiant ainsi la politique d'escalade du groupe. Vous pourrez immédiatement commencer à suivre des indicateurs tels que le délai moyen de prise en charge (MTTA) et le délai moyen de résolution (MTTR).

C'est une bonne option pour les entreprises qui n'utilisent pas d'éléments de configuration dans ServiceNow.

Dans l'exemple ci-dessus, l'équipe de prise en charge des commandes (composée de Karen et Plankton) est configurée en tant que groupe d'affectation. Une fois provisionnée, un service technique « Prise en charge des commandes » sera créé et lié à la politique d'escalade « Prise en charge des commandes », qui contient les informations relatives à la prise en charge des commandes. Calendrier , avec Karen et Plankton au programme.

Tout incident ServiceNow attribué au groupe d'affectation « Prise en charge des commandes » créera un incident correspondant sur le service technique PagerDuty « Prise en charge des commandes » et notifiera la politique d'escalade associée. Tout incident PagerDuty créé sur le service technique « Prise en charge des commandes » sera synchronisé avec ServiceNow, créant ainsi un incident ServiceNow attribué au groupe d'affectation « Prise en charge des commandes ».

Étant donné que chaque groupe d'affectation devient un service technique dans PagerDuty, il devient très difficile de relier ces services techniques à un service métier dans PagerDuty. Les services des groupes d'affectation servent en quelque sorte de réceptacle aux données de surveillance. Par ailleurs, si Plankton n'a pas utilisé d'éléments de configuration dans son implémentation ServiceNow, cette option permettra de faire fonctionner les deux systèmes très rapidement.

Éléments de configuration + Association aux groupes d'affectation

Le modèle de mappage Éléments de configuration + Groupe d'affectation (CI + AG) permet une notification plus robuste entre les deux systèmes. Lorsqu'un CI est provisionné, un service technique PagerDuty est créé pour ce CI, en fonction du groupe d'affectation qui lui est associé. La politique d'escalade de ce groupe est ensuite appliquée à ce service.

Dans l'exemple ci-dessus, vous verrez que nous avons provisionné l'élément de configuration « Chum Bucket Ordering Service », qui est lié au groupe d'affectation « Order Intake » dans PagerDuty, lequel a créé le service technique « Chum Bucket Ordering Service », lié à la politique d'escalade « Order Intake ».

Lorsqu'un incident est créé dans ServiceNow, l'intégration examine les champs « Élément de configuration » et « Groupe d'affectation » pour déterminer le service technique concerné et la procédure d'escalade à notifier. En cas de problème avec le service « Chum Bucket Ordering Service » relevant de l'équipe « Réseau » (et non de l'équipe « Prise des commandes »), l'intégration respectera cette affectation, créera l'incident sur le service technique « Chum Bucket Ordering Service » et notifiera la procédure d'escalade « Réseau ». Malheureusement pour nos deux compères les moins appréciés de Bikini Bottom, ce sont toujours Plankton ou Karen qui seront contactés, puisqu'ils n'ont ni employés ni amis.

Si vous allez au fond de votre cerveau et que vous en retirez Meilleures pratiques de Lisa pour la configuration du service PagerDuty Vous constaterez que créer des services basés sur une équipe n'est pas une approche optimale. L'analyse des événements ne permettra pas de les regrouper correctement, les services techniques ne seront pas considérés comme des services métiers et vous n'aurez aucune visibilité sur les services métiers dans lesquels investir.

Si le mappage des groupes d'affectation est trop large, Plankton devrait provisionner chaque élément de configuration dans PagerDuty, n'est-ce pas ? Mais il aurait alors répliqué ServiceNow dans PagerDuty et se retrouverait avec deux ensembles d'éléments de configuration à gérer. Dans l'environnement éphémère du cloud, Plankton souhaiterait provisionner dans PagerDuty les éléments de configuration qui évoluent peu fréquemment.

Alors, quel est le juste milieu ?

Service technique ou éléments de configuration de microservices.

Si la CMDB ServiceNow de Plankton n'est pas configurée avec le niveau de visibilité Services techniques/Microservices, plusieurs solutions existent. Je recommande tout d'abord à Plankton de créer une nouvelle classe d'éléments de configuration (CI) PagerDuty . Cette table, isolée des outils de découverte de la CMDB, peut coexister sans problème avec les autres enregistrements de CI, tout en comblant le fossé entre les CI des services métiers et ceux de l'infrastructure.

Autrement, nous pouvons provisionner les éléments de configuration (CI) des services métier de Plankton dans PagerDuty. Si vous ne pouvez pas créer de CI techniques ou de microservices, ni de classe PagerDuty , nous utiliserons les CI des services métier existants. Cette approche, moins axée sur la supervision que la configuration « Groupe d'affectation uniquement », incite les équipes à réfléchir aux services sous-jacents dont elles sont (ou non) responsables.

Pour assurer la synchronisation entre ServiceNow et PagerDuty, les éléments suivants doivent être mappés :

• L'enregistrement de l'utilisateur doit comporter un identifiant utilisateur PagerDuty correct.
• Les enregistrements des groupes d'affectation doivent comporter l'ID d'équipe PagerDuty correct pour la synchronisation d'équipe.
• Les enregistrements des groupes d'affectation doivent comporter l'identifiant de politique d'escalade PagerDuty correct pour que le bon groupe soit contacté.

Mappage des groupes d'affectation uniquement :

• Pour que l'incident soit créé avec succès, les enregistrements du groupe d'affectation doivent comporter l'identifiant de service PagerDuty correct.
• Les enregistrements du groupe d'affectation doivent comporter l'ID de webhook PagerDuty correct pour que le lien vers l'incident ServiceNow apparaisse dans PagerDuty.

Éléments de configuration + mappage des groupes d'affectation :

• Les enregistrements CI doivent comporter l'identifiant de service PagerDuty correct pour que l'incident puisse être créé avec succès.
• Les enregistrements CI doivent comporter l'ID de webhook PagerDuty correct pour que le lien vers l'incident ServiceNow apparaisse dans PagerDuty.

Comme vous pouvez le constater, l'intégration PagerDuty ServiceNow est extrêmement performante. Plankton dispose de nombreuses options pour configurer l'intégration et l'adapter aux besoins de Chum Bucket. Il possède désormais toutes les informations nécessaires pour optimiser la configuration de son flux de travail de gestion des incidents. Il ne lui reste plus qu'à… se lier d'amitié avec plus de poissons disposés à travailler pour lui .