Der Blog

Eine (Hummer-)Geschichte von zwei Systemen, auch bekannt als die ServiceNow-Chroniken

von Lisa Yang 16. Juni 2020 | 7 min Lesezeit

Hallo Yangsters, ich hoffe, dass alle in diesen unvorhersehbaren Zeiten sicher sind. Als Kollege aus der Technikbranche gehe ich davon aus, dass Ihre Arbeitsbelastung entweder gleich geblieben ist oder Sie jetzt besonders beschäftigt sind, da immer mehr Menschen alles online erledigen. Ich war so beschäftigt, dass ich kein richtiges Update zu den Geschehnissen von geben konnte. Bikini-Unterteil -bis jetzt.

Aber keine Sorge! Gemeinsam schaffen wir das!

SIND SIE BEREIT, KINDER? ICH KANN SIE NICHT HÖREN! OHHHH!

Das Update: Der örtliche Burgerladen, Krusty Krab, ist noch geöffnet. Sie halten sich an die Abstandsregeln, halten 2 Meter Abstand und bieten nur Essen zum Mitnehmen und Lieferservice an. Anscheinend kann man selbst unter dem Meer nicht vorsichtig genug sein. Vor allem, wenn man von Sardinen umgeben ist.

Plankton, der Erzfeind von Mr. Krab, versucht, die technischen Abläufe in seinem Restaurant (dem Chum Bucket) zu verbessern, um mit der Krossen Krabbe konkurrieren zu können. Er bietet Online-Bestellungen an, damit die Kunden den Kontakt zwischen den Krustentieren minimieren können.

Plankton muss mit Hilfe seiner Robo-Frau Karen seinen Incident-Management-Tool-Stack erweitern, um die eingehenden Anfragen nach Chum zu organisieren und zu verwalten. Karen versteht definitiv die Auswirkungen von Missverständnissen, insbesondere als Roboter unter Wasser. Plankton hat sich für ServiceNow als sein zentrales Tool für das Anforderungsmanagement entschieden. Die gute Nachricht ist, dass es eine robuste Integration zwischen ServiceNow und PagerDuty verfügbar um die richtigen Leute zu benachrichtigen, wenn die Anfragen zu Vorfällen werden.

Durch die Einrichtung der ServiceNow + PagerDuty Integration wird der gesamte Vorfalllebenszyklus zwischen den beiden Systemen protokolliert. Benutzer können dann auf PagerDuty Produkte und -Funktionen zugreifen, wie z. B. Event Intelligence, Modern Incident Response, Postmortems, Vorfallerstellung, Stakeholder-Benachrichtigung und Vorfalllösung, um nur einige zu nennen. Unsere Integrationsleitfaden erklärt wunderbar, „wie“ man die Integration einrichtet, aber Plankton würde gern wissen, „warum“ eine bestimmte Konfiguration mehr Köder fängt als andere. Schließlich hat er sein hart verdientes Geld bereits in ServiceNow und PagerDuty investiert.

Mit der ServiceNow PagerDuty Integration können Sie Vorfälle auf zwei verschiedene Arten synchronisieren: Nur Zuweisungsgruppe oder Konfigurationselemente + Zuweisungsgruppe (CI + AG).

Nur Zuordnung von Zuweisungsgruppen

Die Zuordnung nur der Zuweisungsgruppe ist der einfachste Weg, um die beiden Systeme miteinander kommunizieren zu lassen, und ermöglicht es Ihren Teams, bei kritischen ServiceNow-Vorfällen in Echtzeit Maßnahmen zu ergreifen. Sobald eine Zuweisungsgruppe für PagerDuty bereitgestellt wurde, erstellt die Integration eine technische Service und ein Eskalationsrichtlinie in PagerDuty. Jeder ServiceNow-Vorfall, der dieser zugeordneten Zuweisungsgruppe zugewiesen ist, wird synchronisiert und erstellt einen PagerDuty Vorfall für diesen Service, der die Eskalationsrichtlinie dieser Zuweisungsgruppe benachrichtigt. Sie können sofort mit der Verfolgung von Kennzahlen wie der mittleren Zeit bis zur Bestätigung (MTTA) und der mittleren Zeit bis zur Lösung (MTTR) beginnen.

Dies ist eine gute Option für Unternehmen, die keine Konfigurationselemente in ServiceNow verwenden.

Im obigen Beispiel wird das Auftragsannahmeteam (bestehend aus Karen und Plankton) als Zuweisungsgruppe eingerichtet. Nach der Bereitstellung wird ein technischer Service für die Auftragsannahme erstellt und mit der Eskalationsrichtlinie für die Auftragsannahme verknüpft, die die Auftragsannahme enthält. Zeitplan , mit Karen und Plankton im Programm.

Alle ServiceNow-Vorfälle, die der Zuweisungsgruppe „Auftragseingang“ zugewiesen sind, erstellen einen entsprechenden Vorfall im technischen PagerDuty -Dienst „Auftragseingang“ und benachrichtigen die verknüpfte Eskalationsrichtlinie. Alle im technischen Dienst „Auftragseingang“ erstellten PagerDuty Vorfälle werden mit ServiceNow synchronisiert und erstellen einen ServiceNow-Vorfall, der der Zuweisungsgruppe „Auftragseingang“ zugewiesen ist.

Da jede Zuweisungsgruppe zu einem technischen Dienst in PagerDuty wird, wird es sehr schwierig, die technischen Dienste wieder einem Geschäftsdienst in PagerDuty zuzuordnen. Die Dienste der Zuweisungsgruppe werden zu einer Art Überwachungssenke. Wenn Plankton in seiner ServiceNow-Implementierung keine Konfigurationselemente verwendet hat, sind mit dieser Option die beiden Systeme im Handumdrehen einsatzbereit.

Konfigurationselemente + Zuordnung von Zuweisungsgruppen

Das Zuordnungsmodell „Konfigurationselemente + Zuweisungsgruppe“ (CI + AG) ermöglicht eine robustere Benachrichtigung zwischen den beiden Systemen. Wenn ein CI bereitgestellt wird, wird ein PagerDuty Technical Service für das CI erstellt, basierend auf der Zuweisungsgruppe für dieses CI, und die Eskalationsrichtlinie dieser Gruppe wird für diesen Service verwendet.

Im obigen Beispiel sehen Sie, dass wir das CI „Chum Bucket Ordering Service“ bereitgestellt haben, das mit der Zuweisungsgruppe „Order Intake“ in PagerDuty verknüpft ist, die wiederum den technischen Dienst „Chum Bucket Ordering Service“ erstellt hat, der mit der Eskalationsrichtlinie „Order Intake“ verknüpft ist.

Wenn in ServiceNow ein Vorfall erstellt wird, prüft die Integration sowohl die Felder „CI“ als auch „Zuweisungsgruppe“, um zu bestimmen, bei welchem technischen Dienst der Vorfall erstellt werden soll und welche Eskalationsrichtlinie benachrichtigt werden soll. Wenn es ein Problem mit dem „Chum Bucket Ordering Service“ gibt und dies ein Problem für das „Netzwerk“-Team (anstatt für das „Auftragseingang“-Team) ist, respektiert die Integration diese Zuweisung und erstellt den Vorfall beim technischen Dienst „Chum Bucket Ordering Service“ und benachrichtigt die „Netzwerk“-Eskalationsrichtlinie. Leider werden bei unserem unbeliebtesten Duo in Bikini Bottom immer noch Plankton oder Karen angepiept, da sie keine Mitarbeiter (oder Freunde) haben.

Wenn Sie in den hinteren Teil Ihres Gehirns greifen und herausziehen Lisas Best Practices für die PagerDuty Dienstkonfiguration , werden Sie wissen, dass die Erstellung von Services auf der Grundlage eines Teams kein guter Ansatz ist. Event Intelligence kann Events nicht angemessen gruppieren, technische Services fallen nicht unter die Bezeichnungen für Business Services und Sie haben keinen Einblick, in welche Business Services Sie investieren sollten.

Wenn die Zuordnung der Zuweisungsgruppen zu umfassend ist, sollte Plankton jedes Konfigurationselement in PagerDuty bereitstellen, richtig? Aber dann hätte er ServiceNow in PagerDuty repliziert und müsste nun zwei CI-Sätze verwalten. In der flüchtigen Welt der Cloud würde Plankton CIs in PagerDuty bereitstellen wollen, die sich nicht sehr oft ändern.

Was ist also der Sweet Spot?

Technischer Service oder Microservice-CIs.

Wenn Planktons ServiceNow CMDB nicht mit der Sichtbarkeitsebene „Technische Dienste/Microservices“ eingerichtet ist, gibt es einige Möglichkeiten, dies zu umgehen. Zunächst würde ich Plankton raten, eine neue PagerDuty Klasse von CIs zu erstellen. Diese Tabelle ist von CMDB-Erkennungstools isoliert und kann daher problemlos mit anderen CI-Datensätzen koexistieren, füllt aber die Lücke zwischen Business Services und Infrastruktur-CIs.

Alternativ könnten wir Planktons Business Service CIs für PagerDuty bereitstellen. Wenn Sie keine technischen oder Microservices CIs erstellen oder keine PagerDuty Klasse erstellen können, nutzen wir die vorhandenen Business Service CIs. Dies ist etwas weniger ein Überwachungsproblem als die Konfiguration „Nur Zuweisungsgruppe“ und bringt die Teams dazu, über die zugrunde liegenden Dienste nachzudenken, für die sie verantwortlich sind (oder nicht).

Um die Synchronisierung zwischen ServiceNow und PagerDuty aufrechtzuerhalten, müssen die folgenden Elemente zugeordnet werden:

  • Der Benutzerdatensatz muss die korrekte PagerDuty Benutzer-ID haben
  • Zuweisungsgruppendatensätze müssen die richtige PagerDuty Team-ID für die Teamsynchronisierung haben.
  • Zuweisungsgruppendatensätze müssen die richtige PagerDuty Eskalationsrichtlinien-ID aufweisen, damit die richtige Gruppe angepiept werden kann

Nur Zuordnung der Zuweisungsgruppe:

  • Die Datensätze der Zuweisungsgruppe müssen über die richtige PagerDuty Dienst-ID verfügen, damit der Vorfall erfolgreich erstellt werden kann.
  • Zuweisungsgruppendatensätze müssen die richtige PagerDuty Webhook-ID haben, damit der ServiceNow-Vorfalllink in PagerDuty angezeigt wird.

Konfigurationselemente + Zuordnung von Zuweisungsgruppen:

  • CI-Datensätze müssen über die richtige PagerDuty Service-ID verfügen, damit der Vorfall erfolgreich erstellt werden kann.
  • CI-Datensätze müssen die richtige PagerDuty Webhook-ID haben, damit der ServiceNow-Vorfalllink in PagerDuty angezeigt wird.

Wie Sie sehen, ist die PagerDuty ServiceNow-Integration unglaublich leistungsstark. Plankton hat viele Optionen zur Auswahl, wenn es darum geht, wie er die Integration einrichten und konfigurieren möchte, um den Anforderungen des Chum Buckets gerecht zu werden. Er verfügt nun über alle Informationen, um die besten Konfigurationsentscheidungen für seinen Incident Management-Workflow zu treffen. Er muss nur freunde dich mit mehr Fischen an, die bereit sind, für ihn zu arbeiten .