Wie man eine Observability-Strategie entwickelt

Von Purva Upasak, Axel Larsson, and Jon Steele übersetzt durch David Surey

Ihre Observability-Strategie beginnt mit Ihrem Unternehmen. „Observability“ beschreibt, wie gut Sie verstehen können, was in einem System vor sich geht. Die Entwicklung einer Observability-Strategie ist keine einmalige Anstrengung, sondern ein kontinuierlicher Verbesserungsprozess, der während des gesamten Lebenszyklus Ihrer Workloads stattfindet. Sie ermöglicht es Ihren Teams zu bestimmen, ob die von ihnen entworfenen und ausgeführten Workloads die gewünschten Geschäftsergebnisse erzielen oder nicht. Eine solide Observability-Grundlage beginnt damit, von diesen Ergebnissen rückwärts zu arbeiten.

Identifizieren, was Sie messen werden

Der erste Schritt bei der Definition Ihrer Observability-Strategie ist die Identifizierung dessen, was Sie messen müssen. Jedes Geschäftsergebnis hat eine Reihe damit verbundener Schlüsselkennzahlen (Key Performance Indicators, KPIs). Diese sind keine Messungen selbst, sondern definieren vielmehr, was gemessen werden kann, um die erfolgreiche Erreichung von Geschäftszielen zu bewerten. Die Anzahl der KPIs variiert je nach Unternehmen, wobei die genaue Anzahl dieser unwichtig ist. KPIs werden von Fach- und Technologieverantwortlichen definiert, und die Einigung zwischen diesen Stakeholdern ist der Schlüssel zum Erfolg. In unserem ersten Beitrag haben wir das Beispiel einer E-Commerce-Website behandelt.

Für eine E-Commerce-Website könnte das gewünschte Geschäftsergebnis ein bestimmtes Wachstum des Umsatzvolumens in jeder Region sein. Damit verbundene KPIs könnten die Rate abgeschlossener oder abgebrochener Bestellungen sein, da diese sich direkt auf die Umsatzsteigerung auswirken.

Bestimmen der zu messenden Workloads, Komponenten und Quellen der Telemetrie

Sobald die KPIs definiert sind, ist es wichtig zu identifizieren, welche Workloads und Komponenten überwacht werden müssen, um diese KPIs zu messen. Auch dies ist eine kollaborative Übung zwischen den Stakeholdern. Die wichtigsten Geschäftsergebnisse sowie die zugehörigen KPIs und Messungen sollten zwischen den verschiedenen Stakeholdern abgestimmt werden. Um in unserem Beispiel abgeschlossene Bestellungen messen zu können, müsste die E-Commerce-Website Informationen von Komponenten wie Warenkorb, Auftragsabwicklung, Zahlungsverkehr usw. erhalten.

Definieren der Quellen der Telemetrie (Metriken, Logs und Traces)

Observability gibt Ihnen die Möglichkeit, den Zustand Ihres Systems zu verstehen. Sie können erkennen, wie gut Ihr System funktioniert, wo die Probleme liegen und welche Fehler von Ihren Systemen ausgehen. Ihre Observability-Einrichtung sollte es Ihnen ermöglichen, Ihre Anfragen durch das System, die Microservices, mit denen es interagiert, den Zustand der zugrunde liegenden Infrastruktur, auf der diese Services ausgeführt werden, und die Auswirkungen jeder dieser Aspekte auf die Benutzererfahrung zu verfolgen.

Diese Informationen erhalten Sie durch Metriken, Logs und Traces. Metriken sind Laufzeitmessungen über einen Service, einschließlich Systemmetriken wie CPU-Auslastung oder Netzwerkbandbreite, sowie workloadspezifischer Metriken wie die Anzahl der Ausführungen einer bestimmten Funktion.

Logs sind Textaufzeichnungen mit Metadaten, die oft zur Bestimmung der Grundursache eines Problems verwendet werden. Traces verfolgen den Ablauf einer Anfrage über Anwendungen hinweg. Metriken, Logs und Traces zusammen können eine umfassende Sicht auf das System bieten.

In unserem Beispiel könnten Sie für die E-Commerce-Website die Benutzerbestellung durch die verschiedenen Subsysteme wie Bestellung, Finanzen, Auftragsabwicklung verfolgen, Logs von jedem dieser Services sammeln und Metriken von der zugrunde liegenden Infrastruktur erfassen. Dies würde es Ihnen ermöglichen, Fragen wie „Wo verlangsamt sich die Benutzerbestellung?“, „Wird diese Latenz durch die Hardware verursacht?“ oder „Gibt es eine zugrunde liegende Abhängigkeit zwischen Microservices, die während der Entwicklung nicht identifiziert wurde?“ zu beantworten. Es kann Ihnen auch die Erkenntnisse liefern, die Sie benötigen, um Ihr System, Ihre Architektur oder Ihren Entwicklungsprozess zu verbessern.

Definieren, was „gut“ bedeutet

Es ist wichtig, eine Grundlage für Ihre KPIs zu definieren. Dieser Prozess beginnt mit der Festlegung der Basislinie, von der aus Sie messen werden. Basislinien repräsentieren oft den normalen Bereich des Geschäftsbetriebs. Sie können Ihre Basislinie entwickeln, indem Sie Ihr Unternehmen eine Zeit lang beobachten. Sie werden feststellen, dass Ihr Geschäft normalerweise innerhalb eines bestimmten Bereiches operiert. Sie können diese Perzentile als Schwellenwerte festlegen und Warnmeldungen ausgeben, wenn Sie Anfragen außerhalb dieses vordefinierten Schwellenwerts feststellen. Perzentile sind besser als Durchschnittswerte, da sie nicht durch Ausreißer verzerrt werden. Sie sollten auch eine Karenzzeit einplanen, bevor Sie Maßnahmen ergreifen, um einer Warnungsmüdigkeit bei oft natürlich auftretenden, vorübergehenden Spitzen vorzubeugen. Diese Schwellenwerte sollten sich auch im Laufe des Lebenszyklus Ihrer Workloads weiterentwickeln. Mit zunehmender Reife Ihrer Observability-Fähigkeiten werden sich die Schwellenwerte anpassen. Mit Machine Learning (ML) können Sie Folgendes automatisch erledigen: 1) Schwellenwerte anpassen, basierend auf Trends über die Zeit. 2) Anomalien in den Daten erkennen, die durch einfache Perzentile nicht sichtbar wären. Für die E-Commerce-Website könnten Sie beispielsweise festlegen, dass eine Bestellrate, die das 90. Perzentil überschreitet und für eine vordefinierte Zeit (sagen wir 10 Minuten) außerhalb dieses Bereichs bleibt, ein unerwartetes Verhalten darstellt und Sie ggf. eine bestimmte Aktion ergreifen möchten.

Definieren der zu ergreifenden Maßnahmen, wenn ein Schwellenwert überschritten wird

Der nächste Schritt in einer Observability-Strategie verwandelt Informationsquellen in Aktionen und Erkenntnisse. Zu wissen, wann Maßnahmen ergriffen werden müssen und welche Maßnahmen zu ergreifen sind, ist die Wurzel einer funktionalen Observability-Strategie. Zahlreiche Alarme können zu Warnmüdigkeit führen. Karenzzeiten bei Alarmen und die Sicherstellung, dass jeder Alarm eine definierte Aktion hat, ist eine weitere Möglichkeit, Warnmüdigkeit zu begrenzen. Wenn keine Aktion erforderlich ist, sollten Sie keine Warnmeldungen auslösen.

Ein anderer Ansatz ist die Automatisierung. Anstatt IT-Teams zu alarmieren, können einige Alarme automatische Aktionen auslösen. IT-Teams sollten nur dann alarmiert werden, wenn ein manuelles Eingreifen erforderlich ist. Sie sollten Aktionen für manuelle Eingriffe bei Alarmen in Form von Runbooks (kodifizierte, skriptgesteuerte Aktionen, die Sie als Reaktion auf gut verstandene Probleme ergreifen) oder Playbooks (definierte Schritte zur Untersuchung von Problemen, deren Ursache nicht gut verstanden ist) definieren. Hier überschneidet sich Monitoring mit Observability.

Observability ist an Geschäftsergebnisse geknüpft. Im Fall der E-Commerce-Website können Sie Warnmeldungen für Latenzen setzen und bei Überschreitung des Latenzschwellenwerts ein Auto-Scaling-Ereignis auslösen, um die Kapazität zu erhöhen. Sie sollten auch ein definiertes Playbook haben, das beinhaltet, welche Systeme zu untersuchen sind, wie die Reihenfolge der Untersuchung festgelegt wird, welche Metriken, Logs und Traces zu verwenden sind und wie diese korreliert werden.

Weiterentwicklung Ihrer Observability-Strategie im Laufe der Zeit

Während Sie Ihre Observability-Strategie mit regelmäßigen Inspektions- und Analysemechanismen weiterentwickeln, gibt es mehrere Eingaben, die zu einer reifen Observability-Fähigkeit beitragen können. Beispielsweise können Trendanalysen, Anomalieerkennung mit automatisierten Reaktionen sowie Methoden zur Korrelation von Ereignissen zur Verkürzung der Fehlerbehebungszeit eingesetzt werden. Diese Methoden helfen Ihnen, Ereignisse zu erkennen, die sich auf das Geschäft auswirken könnten, und ermöglichen es Ihnen, schnell zu untersuchen und einzugreifen, um Auswirkungen zu verhindern oder abzumildern. Das Ziel der Weiterentwicklung und Verbesserung Ihrer Observability-Strategie sollte die Reduzierung der mittleren Erkennungszeit (engl. Mean Time To Detect, MTTD) und der mittleren Behebungszeit (engl. Mean Time To Resolve, MTTR) sein. Eine reduzierte MTTD und MTTR werden Ausfallzeiten weiter reduzieren. Oder sie werden Ausfallzeiten gar verhindern. Außerdem werden sie Ihre Fähigkeit verbessern, die gewünschten Geschäftsergebnisse zu erreichen. Dafür wurde Ihre Technologie konzipiert.

Jedes Unternehmen ist einzigartig und Ihre Observability-Lösung sollte den Bedürfnissen Ihres Unternehmens gerecht werden. Wenn Sie Ihre Observability-Reise starten oder weiterentwickeln, überlegen Sie, ob Sie mit den richtigen fachlichen und technischen Stakeholdern zusammenarbeiten, um die richtigen KPIs für Ihr Unternehmen zu definieren. Wie könnte Ihr Unternehmen von der Anwendung des oben beschriebenen Ansatzes zur Entwicklung Ihrer Observability-Strategie profitieren? Die Antworten auf diese Frage wird es Ihnen ermöglichen, Ihre optimale Observability-Strategie zu erstellen.

Im nächsten Beitrag werden wir behandeln, wie Sie AWS-Lösungen nutzen können, um Metriken, Logs und Traces zu sammeln und so Ihre Observability-Strategie umzusetzen. Bis dahin empfehlen wir Ihnen, mehr über Observability bei AWS zu erfahren.

Lesen Sie hier den ersten Teil dieser Reihe

Über die Autoren

	Purva Upasak ist leitende Customer Solutions Managerin für strategische Konten bei AWS. Sie arbeitet mit ihrem Team daran, dass Kunden die gewünschten Ergebnisse auf ihrer AWS-Reise erreichen. Als deren Fürsprecherin arbeitet sie partnerschaftlich mit den Kunden zusammen, um deren Anliegen zu verstehen, deren Herausforderungen anzugehen und deren Erfolg sicherzustellen.
	Axel Larsson ist Enterprise Solutions Architect bei AWS. Er hat mehreren Unternehmen dabei geholfen, zu AWS zu migrieren und ihre Architektur zu modernisieren. Axel brennt dafür, Organisationen dabei zu unterstützen, ein solides Fundament in der Cloud aufzubauen, ermöglicht durch operative Best Practices.
	Jon Steele ist leitender Solutions Architect im AWS Well-Architected Team. Er hat mehr als 7 Jahre lang in verschiedenen Rollen bei AWS mit AWS-Kunden zusammengearbeitet, um ihnen dabei zu helfen, Operational Excellence in ihren Organisationen voranzutreiben. Er ist Co-Autor der Operational Excellence Säule des Well-Architected Frameworks und arbeitet ständig daran, die Anleitungen von AWS zu verbessern, damit unsere Kunden lernen, messen und sich verbessern können, indem sie „mit Ops im Hinterkopf entwerfen“.