Entmystifizierung der Beobachtbarkeit im SRE-Prozess

Wir leben in einer komplizierten Welt vernetzter IT-Systeme und wachsender Datenmengen, in der Kunden einwandfreie Erfahrungen verlangen und Unternehmen bestrebt sind, Innovationen zu beschleunigen. Die IT kann sich nicht mehr auf herkömmliche Überwachungstechniken verlassen, um diese modernen Systeme mit der Geschwindigkeit und Agilität des von uns bedienten Marktes am Laufen zu halten. Hier kommt die Beobachtbarkeit ins Spiel.

Observability ist ein Mechanismus, der hilft Site Reliability Engineering (SRE)-Teams Verstehen und erklären Sie unerwartetes Systemverhalten mit Hilfe von Logs, Traces und Metriken. Es hilft der IT, die Leistung komplexer verteilter Systeme, die auf einer sich entwickelnden Infrastruktur ausgeführt werden, proaktiv zu verwalten.

Die richtige Beobachtbarkeitsstrategie und -lösung führt zu einer erhöhten Standortzuverlässigkeit, einem besseren Kundenerlebnis und einer höheren Teamproduktivität. Angesichts der Datenflut müssen wir Signal und Rauschen schnell identifizieren, um es aggregieren, analysieren und bei Bedarf darauf reagieren zu können. Eine wichtige Erfolgsmetrik für die Beobachtbarkeit ist die durchschnittliche Zeit, um Probleme zu finden und zu lösen. Geschwindigkeit definiert den Erfolg in der heutigen digitalen Wirtschaft.

Heute ist es mehr denn je unerlässlich, komplexe Systeme zu vereinfachen.

Die einzige Möglichkeit, einen unbekannten Fehlerzustand zu beheben und das Verhalten einer Anwendung zu optimieren, besteht darin, alle Daten über Ihre Umgebung mit voller Genauigkeit zu instrumentieren und zu sammeln. Die bloße Verfügbarkeit von Daten liefert jedoch keine Observability-Lösung.

Out-of-the-Box-Lösungen können Ihnen zwar einen Vorsprung bei der Beobachtbarkeit verschaffen, bieten jedoch in der Regel keine vollständige Lösung für Ihre individuellen Anforderungen.

Glücklicherweise können einige Beobachtbarkeitstechniken helfen, die Komplexität zu vereinfachen und zu mehr Klarheit und Erfolg führen.

Brainstorming mit Fachexperten

Moderne verteilte Architekturen haben zahlreiche Interdependenzen und damit auch viele Schwachstellen. Eine Schlüsselkomponente ausfallsicherer Systeme ist die schnelle Lokalisierung des genauen Standorts eines erkannten Problems. Aus diesem Grund besteht einer der ersten Schritte eines SRE-Enablement-Teams beim Aufbau einer SRE-Strategie darin, mit Fachexperten zusammenzuarbeiten, die einen umfassenden Überblick über ihr Ökosystem haben.

Beginnen Sie mit einer Brainstorming-Sitzung mit Architekten, Leitern von Engineering-Teams, SREs, DevOps, Bereitschafts-Supportteams, Incident-Management und einem User-Experience-Designer, um eine Vogelperspektive oder eine End-to-End-Ökosystemansicht des Ökosystems der Organisation zu erstellen.

Die Sitzung hilft dabei, das Durcheinander zu beseitigen und High-Level-Services zu identifizieren, die auf einem einzigen Bildschirm dargestellt werden können und die den End-to-End-Fluss miteinander verbundener Anwendungen darstellen. Dieser grobe End-to-End-Flow ist ein lebendiges und atmendes Artefakt, das sich weiterentwickeln wird, wenn das Anwendungsökosystem Transformationen durchläuft.

Richten Sie KPIs und Scoring ein

Sobald Sie eine Liste der zu beobachtenden Dienste haben, identifizieren Sie die wichtigsten Leistungsindikatoren für jeden Dienst. KPIs werden aus Protokollen und Metriken abgeleitet, und wir müssen sie aus verschiedenen Quellen beziehen.

Nachdem die Daten in das Tool Ihrer Wahl instrumentiert wurden, sehen Sie sich das Verhalten des Dienstes in der Historie (idealerweise vier Wochen) an, um optimale Schwellenwerte zu bestimmen. Skizzieren Sie das „Gute“, das „Schlechte“ und das „Hässliche“.

Je nach Domain kann ein Dienst sehr unterschiedlich sein, einschließlich Webdienst, App, Netzwerk, Datenbank, Nachrichtenwarteschlange, E-Mail und vielem mehr. Jeder Service hat unterschiedliche Stakeholder, KPIs und Kriterien zur Erfolgs- und Leistungsmessung.

Wie kann man also eine Observability-Lösung bauen, die trotz unterschiedlicher Fachgebiete für alle leicht verständlich ist? Da kommt die Wertung ins Spiel.

Das Scoring ist ein Mechanismus, der in die menschliche DNA eingebettet ist. Während wir alle unterschiedliche Fächer in der Schule hatten, wurden sie im Allgemeinen anhand einer numerischen Rubrik benotet. Jeder versteht, was 50 bedeutet und was 90 bedeutet, unabhängig vom Thema. Die Messung des Zustands oder der Leistung eines Dienstes sollte nicht anders behandelt werden.

Eine gängige Methode zur Berechnung eines Service Health Scores besteht darin, die drei wichtigsten KPIs innerhalb eines Service zu identifizieren und jedem eine Gewichtung von der wichtigsten bis zur unwichtigsten zuzuweisen. Faktorisieren Sie die KPI-Gewichte mit dem Prozentsatz, bei dem der KPI herabgesetzt wird, um die Integrität dieses Dienstes zu bewerten.

Sie können Ihren Service Health Score weiter vereinfachen, indem Sie Score-Levels mit einem anderen weit verbreiteten Maßstab gleichsetzen: den Ampelsignalen von Rot, Gelb und Grün.

Die Standardisierung des Entscheidungsprozesses mithilfe eines Scoring-Modells bedeutet schnellere und stärker automatisierte Entscheidungen.

Alles zusammenfügen

Sobald eine IT-Organisation ein architektonisches Design, KPIs und Service Health Scores erstellt hat, kann ein SRE-Team diese dann in einem Diagramm kombinieren, um über ein fertiges Observability-Tool oder eine kundenspezifische Lösung eine einzige Glasscheibe zu erstellen. Die einzelne Glasscheibe ist so konzipiert, dass sie vollständig interaktiv und intuitiv ist, um von jedem, der sie verwendet, in Problembereiche vorzudringen.

Die SRE-Teams oder die Engineering-Teams sollten die Drilldown-Ansichten erstellen und sie so pflegen, dass sie mit den Integritätsbewertungen übereinstimmen, die auf der einzelnen Glasscheibe angezeigt werden.

Während die SRE-Dashboards eine kontinuierliche Überwachung der Ökosysteme ermöglichen, hängt die Strategie nicht davon ab, sie rund um die Uhr zu beobachten. Überwachungsergebnisse werden zusammen mit anderen verfügbaren Daten verwendet, um Leistungsereignisse zu korrelieren und zu adressieren.

Beispielsweise können Sie eine Verschlechterung einer Webseite, eine schleichende Datenbanklatenz und eine Verschlechterung des Domain Name System-Dienstes feststellen. Traditionell könnte dies drei separate Warnungen auslösen. Aber bei Dell generiert unsere Benachrichtigungsstrategie mit Hilfe der benutzerdefinierten Orchestrierung eine Benachrichtigung, die die Ursache und die Auswirkungen umfasst.

Das System vermeidet doppelte Benachrichtigungen über denselben Vorfall, indem es Datensätze zentralisiert und nur ein Tool für die Erstellung von Vorfällen bestimmt.

Es ist wichtig, Beobachtbarkeitsbenachrichtigungen an die spezifischen Entwicklungsteams zu richten, die von dem Systemproblem betroffen sind, und die Kommunikationskanäle zu nutzen, die am besten mit diesen Teams in Verbindung stehen. Während E-Mail einst der traditionelle Kommunikationskanal für Benachrichtigungen war, kann die Zusammenarbeit heute MS Teams, Slack, SMS, mobile Apps und WhatsApp umfassen, um nur einige zu nennen.

Die Beobachtbarkeitsstrategie sollte die Zuordnung von Microservices zu Entwicklungsteams und die Einrichtung der Kommunikationskanäle für die Benachrichtigung über kritische Probleme umfassen.

Letztendlich besteht das Ziel der Beobachtbarkeit darin, mehreren Teams zu ermöglichen, mit gemeinsam genutzten Daten zu agieren, Menschen mit Prozessen zu verbinden und sich an größeren Geschäftszielen auszurichten.

Bleiben Sie über unsere Dell Digital-Strategien und mehr auf dem Laufenden unter Dell Technologies: Unsere digitale Transformation.

Author: admin

Leave a Reply

Your email address will not be published. Required fields are marked *