Hallo Yangsters, ich hoffe, es geht euch allen gut und ihr bleibt gesund in diesen unvorhersehbaren Zeiten. Da ich selbst in der Technologiebranche arbeite, vermute ich, dass euer Arbeitspensum entweder gleich geblieben ist oder ihr jetzt sogar noch mehr zu tun habt, da immer mehr Menschen alles online erledigen. Ich war so beschäftigt, dass ich euch leider nicht über die aktuellen Entwicklungen informieren konnte. Bikini Bottom -bisher.

Aber keine Sorge! Wir schaffen das gemeinsam!

SEID IHR BEREIT, KINDER? ICH KANN EUCH NICHT HÖREN! OHHHH!

Update: Der örtliche Burgerladen Krusty Krab hat weiterhin geöffnet. Dort werden die Abstandsregeln eingehalten (mindestens 1,80 Meter Abstand) und es gibt nur Abhol- und Lieferservice. Offenbar kann man selbst unter Wasser nicht vorsichtig genug sein. Vor allem nicht, wenn man von Sardinen umgeben ist.

Plankton, Mr. Krabs Erzfeind, versucht, die technischen Abläufe seines Restaurants (des Chum Bucket) zu verbessern, um mit der Krossen Krabbe konkurrieren zu können. Er bietet Online-Bestellungen an, damit Kunden den direkten Kontakt zwischen Krustentieren minimieren können.

Plankton muss mithilfe seiner Roboterfrau Karen sein System für das Störungsmanagement erweitern, um die eingehenden Anfragen nach Ködern zu organisieren und zu verwalten. Karen ist sich der Folgen von Fehlfunktionen durchaus bewusst, insbesondere als Unterwasserroboter. Plankton hat sich für ServiceNow als zentrale Plattform für das Anfragemanagement entschieden. Die gute Nachricht: Es gibt eine robuste Lösung. Integration zwischen ServiceNow und PagerDuty möglich um die zuständigen Personen zu benachrichtigen, wenn die Anfragen zu Zwischenfällen werden.

Durch die Einrichtung der ServiceNow- und PagerDuty -Integration wird der gesamte Incident-Lebenszyklus zwischen beiden Systemen protokolliert. Benutzer können anschließend auf PagerDuty -Produkte und -Funktionen zugreifen, wie beispielsweise Event Intelligence, Modern Incident Response, Postmortems, Incident-Erstellung, Stakeholder-Benachrichtigung und Incident-Lösung, um nur einige zu nennen. Integrationsleitfaden Die Anleitung zur Einrichtung der Integration ist hervorragend, aber Plankton möchte wissen, warum eine bestimmte Konfiguration mehr Köderfische fängt als andere. Schließlich hat er bereits sein hart verdientes Geld in ServiceNow und PagerDuty investiert.

Die ServiceNow PagerDuty Integration ermöglicht es Ihnen, Incidents auf zwei verschiedene Arten zu synchronisieren: Nur Zuordnungsgruppe oder Konfigurationselemente + Zuordnungsgruppe (CI + AG).

Zuordnungsgruppe

Die Zuordnung von Aufgabengruppen ist der einfachste Weg, die beiden Systeme miteinander zu verbinden und Ihren Teams die Möglichkeit zu geben, kritische ServiceNow-Vorfälle in Echtzeit zu bearbeiten. Sobald eine Aufgabengruppe in PagerDuty bereitgestellt ist, erstellt die Integration eine technische Zuordnung. Service und ein Eskalationsrichtlinie In PagerDuty wird jeder ServiceNow-Vorfall, der dieser zugeordneten Aufgabengruppe zugewiesen ist, synchronisiert und ein PagerDuty Vorfall für diesen Service erstellt. Dabei wird die Eskalationsrichtlinie der Aufgabengruppe benachrichtigt. Sie können sofort Kennzahlen wie die durchschnittliche Zeit bis zur Bestätigung (MTTA) und die durchschnittliche Zeit bis zur Lösung (MTTR) erfassen.

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

Im obigen Beispiel ist das Auftragsannahme-Team (bestehend aus Karen und Plankton) als Aufgabengruppe eingerichtet. Nach der Bereitstellung wird ein technischer Dienst „Auftragsannahme“ erstellt und mit der Eskalationsrichtlinie „Auftragsannahme“ verknüpft, die die „Auftragsannahme“-Richtlinie enthält. Zeitplan , mit Karen und Plankton im Programm.

Alle ServiceNow-Vorfälle, die der Aufgabengruppe „Auftragsannahme“ zugewiesen sind, erzeugen einen entsprechenden Vorfall im technischen PagerDuty -Service „Auftragsannahme“ und benachrichtigen die verknüpfte Eskalationsrichtlinie. Jeder im technischen Service „Auftragsannahme“ erstellte PagerDuty Vorfall wird mit ServiceNow synchronisiert und erzeugt dort einen ServiceNow-Vorfall, der der Aufgabengruppe „Auftragsannahme“ zugewiesen wird.

Da jede Aufgabengruppe in PagerDuty zu einem technischen Dienst wird, gestaltet sich die Zuordnung dieser technischen Dienste zu den entsprechenden Geschäftsdiensten in PagerDuty sehr schwierig. Die Dienste der Aufgabengruppen führen zu einem erheblichen Überwachungsaufwand. Hätte Plankton in seiner ServiceNow-Implementierung keine Konfigurationselemente verwendet, wären die beiden Systeme mit dieser Option im Handumdrehen einsatzbereit.

Konfigurationselemente + Zuordnung von Zuordnungsgruppen

Das Zuordnungsmodell „Konfigurationselemente + Zuweisungsgruppe“ (CI + AG) ermöglicht eine robustere Benachrichtigung zwischen den beiden Systemen. Bei der Bereitstellung eines CI wird basierend auf der zugehörigen Zuweisungsgruppe ein PagerDuty -Service erstellt, dessen Eskalationsrichtlinie für diesen Service verwendet wird.

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. Dadurch wurde der technische Dienst „Chum Bucket Ordering Service“ erstellt, der mit der Eskalationsrichtlinie „Order Intake“ verknüpft ist.

Wird in ServiceNow ein Incident erstellt, prüft die Integration die Felder „CI“ und „Zuweisungsgruppe“, um den zuständigen technischen Service für die Erstellung des Incidents und die zu benachrichtigende Eskalationsrichtlinie zu bestimmen. Tritt ein Problem mit dem „Chum Bucket Ordering Service“ auf und fällt dieses in den Zuständigkeitsbereich des „Netzwerk“-Teams (anstatt des „Auftragsannahme“-Teams), berücksichtigt die Integration diese Zuordnung, erstellt den Incident im technischen Service „Chum Bucket Ordering Service“ und benachrichtigt die Eskalationsrichtlinie „Netzwerk“. Leider werden für unser unbeliebtestes Duo in Bikini Bottom weiterhin Plankton oder Karen benachrichtigt, da sie weder Mitarbeiter noch Freunde haben.

Wenn Sie in den hinteren Teil Ihres Gehirns greifen und etwas herausziehen Lisas bewährte Vorgehensweisen für die PagerDuty -Dienstkonfiguration Sie wissen also, dass die Erstellung von Services basierend auf einem Team kein optimaler Ansatz ist. Event Intelligence kann Ereignisse nicht angemessen gruppieren, technische Services fallen nicht unter die Kategorien der Geschäftsservices, und Sie haben keinen Überblick darüber, in welche Geschäftsservices Sie investieren sollten.

Wenn die Zuordnung von Aufgabengruppen zu allgemein ist, sollte Plankton jedes Konfigurationselement in PagerDuty bereitstellen, richtig? Dann hätte er aber ServiceNow in PagerDuty repliziert und müsste nun zwei Sätze von Konfigurationselementen verwalten. In der schnelllebigen Welt der Cloud möchte Plankton in PagerDuty nur Konfigurationselemente bereitstellen, die sich nicht häufig ändern.

Was ist also der optimale Bereich?

Technische Service- oder Microservice-CIs.

Falls Planktons ServiceNow CMDB nicht auf der Ebene der technischen Dienste/Microservices eingerichtet ist, gibt es verschiedene Lösungsansätze. Zunächst empfehle ich Plankton, eine neue PagerDuty Klasse für CIs zu erstellen. Diese Tabelle ist von den CMDB-Erkennungstools isoliert und kann daher problemlos mit anderen CI-Datensätzen koexistieren. Sie schließt die Lücke zwischen Business-Services- und Infrastruktur-CIs.

Alternativ könnten wir die Business-Service-CIs von Plankton für PagerDuty bereitstellen. Falls Sie keine technischen oder Microservices-CIs erstellen oder keine PagerDuty -Klasse anlegen können, nutzen wir die vorhandenen Business-Service-CIs. Dies ist etwas weniger aufwändig als die Konfiguration „Nur Zuweisungsgruppen“ und regt die Teams dazu an, über die zugrunde liegenden Services 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 enthalten.
• Die Datensätze der Aufgabengruppen müssen die korrekte PagerDuty -Team-ID für die Teamsynchronisierung enthalten.
• Die Datensätze der Zuweisungsgruppen müssen die korrekte PagerDuty Eskalationsrichtlinien-ID aufweisen, damit die richtige Gruppe benachrichtigt werden kann.

Zuordnung nur zu Aufgabengruppen:

• Die Datensätze der Aufgabengruppe müssen die korrekte PagerDuty -Dienst-ID enthalten, damit der Vorfall erfolgreich erstellt werden kann.
• Die Datensätze der Aufgabengruppe müssen die korrekte PagerDuty Webhook-ID enthalten, damit der ServiceNow-Vorfalllink in PagerDuty angezeigt wird.

Konfigurationselemente + Zuordnung von Zuordnungsgruppen:

• Für die erfolgreiche Erstellung eines Incidents müssen die CI-Datensätze die korrekte PagerDuty -Dienst-ID enthalten.
• CI-Einträge müssen die korrekte PagerDuty Webhook-ID enthalten, damit der ServiceNow-Vorfallslink in PagerDuty angezeigt wird.

Wie Sie sehen, ist die PagerDuty ServiceNow-Integration unglaublich leistungsstark. Plankton hat zahlreiche Optionen zur Auswahl, um die Integration an die Bedürfnisse von Chum Bucket anzupassen. Er verfügt nun über alle Informationen, um die optimale Konfiguration für seinen Incident-Management-Workflow zu treffen. Er muss nur noch sich mit mehr Fischen anfreunden, die bereit sind, für ihn zu arbeiten Die