Bonjour Yangsters, j'espère que tout le monde reste en sécurité pendant ces temps imprévisibles. En tant que collègue professionnel de la technologie, je suppose que votre charge de travail est restée la même ou que vous êtes maintenant très occupé puisque de plus en plus de personnes se tournent vers le tout en ligne. J'ai été tellement occupé que je n'ai pas pu fournir une mise à jour appropriée sur l'évolution de Bas de bikini -jusqu'à maintenant.

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

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

Mise à jour : le restaurant de hamburgers local, Krusty Krab, est toujours ouvert. Ils respectent la distanciation sociale, maintiennent une distance de deux mètres et proposent uniquement des plats à emporter et des livraisons. Apparemment, même sous la mer, on n'est jamais trop prudent. Surtout quand on est entouré de sardines.

Plankton, l'ennemi juré de M. Krab, tente d'améliorer les opérations techniques de son restaurant (le Chum Bucket) pour rester compétitif avec le Krusty Krab. Il propose la commande en ligne afin que les clients puissent minimiser le contact entre les crustacés.

Plankton, avec l'aide de sa femme robotique, Karen, doit étendre sa pile d'outils de gestion des incidents pour organiser et gérer les demandes de chum qui arrivent. Karen comprend parfaitement l'impact des croisements de fils, en particulier en tant que robot sous l'eau. Plankton a choisi ServiceNow comme centre de vérité pour la gestion des demandes. La bonne nouvelle est qu'il existe une solution robuste intégration disponible entre ServiceNow et PagerDuty pour avertir les bonnes personnes 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 Event Intelligence, Modern Incident Response, Postmortems, création d'incidents, notification des parties prenantes et résolution des incidents, pour n'en citer que quelques-uns. guide d'intégration fait un excellent travail en expliquant « comment » configurer l'intégration, mais Plankton aimerait savoir « pourquoi » une certaine configuration attirera plus de clients que d'autres. Après tout, il a déjà investi son argent durement gagné dans ServiceNow et PagerDuty.

L'intégration 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 de groupe d'affectation uniquement est le moyen le plus simple de faire communiquer les deux systèmes et permet à vos équipes de commencer à agir sur les incidents ServiceNow critiques en temps réel. Une fois qu'un groupe d'affectation est provisionné sur PagerDuty, l'intégration créera un groupe technique Service Et un Politique d'escalade dans PagerDuty. Tout incident ServiceNow attribué à ce groupe d'affectation mappé sera synchronisé et créera un incident PagerDuty sur ce service, en notifiant la politique d'escalade de ce groupe d'affectation. Vous pourrez immédiatement commencer à suivre des mesures telles que le temps moyen de reconnaissance (MTTA) et le temps moyen de résolution (MTTR).

Il s’agit d’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 de commandes (composée de Karen et Plankton) est configurée en tant que groupe d'affectation. Une fois provisionné, un service technique « Prise de commandes » sera créé et lié à la politique d'escalade « Prise de commandes », qui contient la « Prise de commandes » Calendrier , avec Karen et Plankton au programme.

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

Étant donné que chaque groupe d'affectation devient un service technique dans PagerDuty, il devient très difficile de relier les services techniques à un service métier dans PagerDuty. Les services du groupe d'affectation deviennent en quelque sorte un puits de surveillance. Encore une fois, si Plankton n'a pas utilisé d'éléments de configuration dans son implémentation ServiceNow, cette option permettra aux deux systèmes d'être opérationnels en un rien de temps.

Éléments de configuration + mappage de 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é, il crée un service technique PagerDuty pour le CI, basé sur le groupe d'affectation de ce CI, et la politique d'escalade de ce groupe est utilisée pour ce service.

Dans l'exemple ci-dessus, vous verrez que nous avons provisionné le CI « Chum Bucket Ordering Service », qui est lié au groupe d'affectation « Order Intake » dans PagerDuty, qui 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 CI et Groupe d'affectation pour déterminer sur quel service technique créer l'incident et quelle politique d'escalade notifier. S'il y a un problème avec le « service de commande Chum Bucket » et qu'il s'agit d'un problème pour l'équipe « Réseau » (au lieu de l'équipe « Prise de commandes »), l'intégration respectera cette affectation et créera l'incident sur le service technique « Service de commande Chum Bucket » et notifiera la politique d'escalade « Réseau ». Malheureusement, pour notre duo le moins préféré de Bikini Bottom, c'est toujours Plankton ou Karen qui seront appelés, car ils n'ont pas d'employés (ou d'amis).

Si vous atteignez l'arrière de votre cerveau et retirez-le Meilleures pratiques de Lisa pour la configuration du service PagerDuty , vous savez que créer des services basés sur une équipe n'est pas une bonne approche. Event Intelligence ne pourra pas regrouper les événements de manière appropriée, les services techniques ne relèveront pas des désignations de services commerciaux et vous n'aurez pas de visibilité sur les services commerciaux dans lesquels investir.

Si le mappage du groupe d'affectation est trop large, Plankton doit alors provisionner chaque élément de configuration dans PagerDuty, n'est-ce pas ? Mais il aurait alors répliqué ServiceNow dans PagerDuty et aurait maintenant deux ensembles de CI à gérer. Dans le monde éphémère du cloud, Plankton souhaiterait provisionner des CI sur PagerDuty qui ne changent pas très souvent.

Alors, quel est le point idéal ?

Service technique ou CI de microservices.

Si la CMDB ServiceNow de Plankton n'est pas configurée avec le niveau de visibilité Services techniques/Microservices, il existe plusieurs solutions. Tout d'abord, je conseillerais à Plankton de créer une nouvelle classe PagerDuty de CI. Cette table est isolée des outils de découverte CMDB, coexistant donc avec bonheur avec d'autres enregistrements de CI, mais comble le vide entre les CI de services métier et d'infrastructure.

Alternativement, nous pourrions provisionner les CI de services métier de Plankton sur PagerDuty. Si vous n'êtes pas en mesure de créer des CI techniques ou de microservices, ou de créer une classe PagerDuty , nous exploiterons les CI de services métier existants. Il s'agit d'un puits de surveillance un peu moins important que la configuration Assignment Group Only, et cela permet aux équipes de commencer à réfléchir aux services sous-jacents dont elles sont (ou non) responsables.

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

• L'enregistrement des utilisateurs doit avoir un identifiant d'utilisateur PagerDuty correct
• Les enregistrements du groupe d'affectation doivent avoir l'ID d'équipe PagerDuty correct pour la synchronisation de l'équipe
• Les enregistrements du groupe d'affectation doivent avoir l'ID de stratégie d'escalade PagerDuty correct pour que le bon groupe soit paginé

Mappage du groupe d'affectation uniquement :

• Les enregistrements du groupe d'affectation doivent avoir l'ID de service PagerDuty correct pour que l'incident soit créé avec succès.
• Les enregistrements du groupe d'affectation doivent avoir l'ID Webhook PagerDuty correct pour que le lien d'incident ServiceNow apparaisse dans PagerDuty

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

• Les enregistrements CI doivent avoir l'ID de service PagerDuty correct pour que l'incident soit créé avec succès.
• Les enregistrements CI doivent avoir l'ID Webhook PagerDuty correct pour que le lien d'incident ServiceNow apparaisse dans PagerDuty

Comme vous pouvez le constater, l'intégration PagerDuty ServiceNow est incroyablement puissante. Plankton dispose de nombreuses options pour configurer l'intégration en fonction des besoins du Chum Bucket. Il dispose désormais de toutes les informations nécessaires pour faire les meilleurs choix de configuration pour son flux de travail de gestion des incidents. Il n'a plus qu'à se lier d'amitié avec plus de poissons qui sont prêts à travailler pour lui .