Mitautor: Chris Bonnell, PagerDuty Data Scientist VI

Hallo und willkommen zum vierten Beitrag unserer EI-Architektur-Reihe mit dem Schwerpunkt Intelligent Alert Grouping. Zuvor haben wir darüber gesprochen, wie man Intelligent Alert Grouping mithilfe von Incident Merges trainiert ( Hier ) und wie Sie Ihre Alarmtitel konfigurieren, um die Standardübereinstimmung zu verbessern. In diesem Beitrag werden wir erläutern, wie sich das Servicedesign auch auf Ihre Erfahrung mit Intelligent Alert Grouping sowie der PagerDuty -App im Allgemeinen auswirken kann.

Ein wenig über Dienstleistungen

Bevor Sie sich mit der Gestaltung oder Neugestaltung Ihrer Services befassen können, ist es wichtig, eine Servicedefinition zu haben, die in Ihrer Organisation funktioniert. Die Definition muss spezifisch genug sein, um verstanden zu werden, aber breit genug, damit mehrere Teams das gleiche Verständnis davon haben, was ein Service abstrakt ist. Ist. Bei PagerDuty verwenden wir die folgende Definition:

A Service ist eine eigenständige Funktionalität, die einen Mehrwert bietet und vollständig im Besitz eines Teams ist.

Es ist wichtig, das Eigentümerteam zu kennen, da es das Team ist, das den Service aufbaut und wartet, und dazu gehört auch die Reaktion auf alle Vorfälle. Eine Zusammenfassung zu Services und Eigentum finden Sie in unserem Full Service Ownership Ops Guide auf Definieren eines Dienstes .

Neben der Frage, wer die Dienste vertreibt und wer sie besitzt, müssen Sie auch die Dienste berücksichtigen, Namen. Sie sollten in der Lage sein, die Serviceverzeichnis und in der Lage sein, leicht zu verstehen, was jeder Dienst ist, ohne zusätzliche institutionelle Kenntnisse. Kurz gesagt ist es der Unterschied zwischen einem Dienst namens „Zahlungsdienst“ oder dem Wissen/Referenzieren interner Dokumentation, dass alle Transaktionsdienste nach griechischen Göttern benannt sind und dann zu schauen, welcher griechische Gott dem Dienst entspricht, der die Zahlung abwickelt. Wir gehen im Detail darauf ein in Benennungsdienste Abschnitt des Full Service Ownership Ops Guide.

Ein letztes Wissen über Dienste, bevor wir fortfahren: In der PagerDuty -App unterscheiden sich Dienste von Geschäftsdiensten. Bisher ist alles, was ich oben erwähnt habe, relevant für Dienstleistungen . In unserer Dokumentation werden sie möglicherweise auch als technische Dienste bezeichnet, um eine Verwechslung mit Geschäftsdiensten zu vermeiden. Geschäftsdienstleistungen sind Aggregate technischer Services oder anderer Business-Services, normalerweise entsprechend Ihrer Geschäftslogik und/oder Ihren Stakeholdern. Intelligent Alert Grouping nutzt nur technische Services, keine Business-Services. Wenn ich in diesem Beitrag also von Services spreche, meine ich nur technische Services.

Die Granularität

Die richtige Balance für die Trennung von Diensten zu finden, ist keine triviale Aufgabe und es gibt dafür keine Universallösung. Im Grunde genommen müssen Sie mehr und weniger Granularität ausbalancieren und austauschen. Eine sehr granulare Nutzung von Diensten wäre beispielsweise ein einzelnes Überwachungstool, dessen Komponentenfunktionen in der PagerDuty -Anwendung in separate Dienste aufgeteilt sind. Eine breitere/weniger granulare Nutzung von Diensten wäre dagegen, alle mobilen Anwendungen als einen einzigen Dienst zu haben, selbst wenn die Entwicklung von iOS und Android von separaten Teams mit separaten Verantwortlichkeiten durchgeführt wird. Dieses letzte Beispiel macht auch deutlich, warum es keine einheitliche Empfehlung für die Strukturierung Ihrer Dienste geben kann, da einige Organisationen ein einzelnes Mobilteam, kein Mobilteam oder separate Mobilteams haben, die nach unterschiedlichen Kriterien aufgeteilt sind.

Na und dürfen wir tun das? Wir können einige Ratschläge abstrahieren, die Ihnen bei der Navigation durch Ihre Servicedefinitionen helfen können. Der erste Ansatzpunkt ist der Eigentumsaspekt. Einer der Hauptgründe, Services in der PagerDuty -Anwendung zu definieren, ist die Reaktion auf Vorfälle, d. h. zu wissen, wer auf Probleme mit einem Service reagieren kann, ist der Eigentümer des Services. Daher kann Ihnen das Wissen, wer in Ihrer Organisation die Services besitzt, dabei helfen, sie in PagerDuty zu definieren. Das ist wichtig, denn wenn Sie eine vorhandene Servicestruktur haben, die kein vollständiges Serviceeigentumsmodell ist, Sie aber Ihre gewünschten Eskalationspfade kennen, können Sie dieses Wissen nutzen. In diesem Fall, wenn Intelligent Alert Grouping die Vorfälle gruppiert, ist das Ergebnis, dass selbst wenn die Services nur in ihrem gewünschten Eskalationspfad verknüpft sind, dieser in diesem Kontext zählt und das Endergebnis sein wird, das Sie erzielen.

Sie sollten auch Ihre aktuellen Projekte überprüfen und feststellen, welche tatsächlich eine funktionale Einheit darstellen, und diese als einen einzigen Dienst in PagerDuty definieren. Dies sollte sicherstellen, dass Projekte mit denselben Eskalationspfaden immer noch richtig gruppiert werden, aber das Szenario verhindern, dass mehrere Projekte nur aufgrund ihres Eskalationspfads als ein einziger Dienst definiert werden und dadurch die Sichtbarkeit verloren geht. Gehen wir noch einen Schritt weiter: Wenn Sie zwei oder mehr Dienste sehen, bei denen ständig Vorfälle gleichzeitig auftreten, müssen diese möglicherweise zu einem einzigen Dienst zusammengefasst werden. Als konkretes Beispiel nehmen wir an, Sie haben einen Überwachungs-Mikrodienst, der über separate Komponenten für Metriken, Heartbeats, Protokolle usw. verfügt. Wenn jeder dieser Dienste über einen eigenen PagerDuty Dienst verfügt, tritt ein Vorfall höchstwahrscheinlich gleichzeitig in allen diesen Diensten auf und sie sollten stattdessen als Überwachungs-Mikrodienst selbst zu einem Dienst zusammengefasst werden. Wenn andererseits separate Projekte als ein Dienst definiert werden, weil dieselben Personen daran arbeiten, es sich aber um separate Einheiten handelt, sind die Dienste möglicherweise nicht granular genug. In diesem Szenario wäre es schwierig zu sagen, welche Entitäten im Dienst mehr Aufmerksamkeit benötigen als die anderen, da sie für die PagerDuty App alle ein „Ding“ sind.

Wie geht es weiter?

Werfen Sie einen Blick auf Ihre bestehenden und möglicherweise bald zu erstellenden Dienste und überprüfen Sie deren:

• Eskalationspfade
• Namen
• Funktionseinheiten

Und verwenden Sie diese dann als Leitfaden, wie Sie die Dienste in der PagerDuty Anwendung definieren. Intelligent Alert Grouping übernimmt von dort aus, indem es Warnungen unter korrelierten Diensten gruppiert. Wenn Sie Dienste von Grund auf neu entwerfen oder Dienstdefinitionen überarbeiten, werfen Sie einen Blick auf unsere Vollständiger Service Ownership Ops-Leitfaden für Best Practices zur Benennung und Eigentümerschaft für Antworten sowie unsere Dokumentation zu (technischen) Dienstleistungen Und Geschäftsdienstleistungen . In unserem nächsten und letzten Beitrag der Serie werden wir alles, was wir besprochen haben, noch einmal zusammenfassen. Verwenden Sie die ei-Architektur-Serie Tag, um sich alle Stücke dieser Serie anzusehen.