Alexander Kaserbacher
08.03.2023
Die Pillar "Operational Excellence" bietet eine Menge an Praktiken, die ein System aus operativer Sicht beleuchten. Dieser Blogpost ist der zweite der Reihe "Well Architected Cloud" und beschäftigt sich näher mit dieser Pillar.
Die Pillar “Operational Excellence” kommt in allen drei Architekturframeworks der großen Cloud-Vendoren vor. Sie beinhaltet eine fundamentale Grundlage an Methoden, ohne denen viele Best Practices der anderen Pillars nicht umsetzbar wären.
Dieser Blogbeitrag bietet Ihnen einen schnellen Einstieg und Überblick in das Thema. Ich habe direkt die relevanten Inhalte der Frameworks referenziert, falls Sie an bestimmten Stellen weiter in die Tiefe gehen möchten. Die Namenskürzel der Verweise haben eine Bedeutung: Kürzel, die mit A beginnen, beziehen sich auf AWS, M auf Microsoft Azure und G auf Google Cloud.
Wie jede Pillar in den Architekturframeworks bietet auch “Operational Excellence” einen Satz von grundlegenden Designprinzipien. Ich habe die Designprinzipien aus allen drei Frameworks in Abbildung 1 zusammengefasst.
Abbildung 1: Verdichtete Designprinzipien aus den drei Frameworks für die "Operational Excellence"-Pillar
Im restlichen Teil des Blogposts stelle ich Ihnen einzelne Best-Practice-Bereiche der “Operational Excellence”-Pillar vor. Aggregiert aus den drei Architekturframeworks lassen sich die Best Practices grob in verschiedene Themenbereiche einteilen: Observability, Continuous Integration und Automatisierung/Infrastructure as Code.
Das Ziel von Observability ist, Anwendungs- und Systemverhalten nachvollziehbar zu machen. Einerseits ist es wichtig, im Fehlerfall schnell an Informationen zu gelangen, um das Problem zu beseitigen. Andererseits wollen wir nachvollziehen können, ob sich unser System so verhält, wie wir es erwarten – vor allem, ob wir unsere Geschäftsziele erreichen oder nicht.
Observability stützt sich daher auf Telemetrie-Daten:
Alle diese Daten sind für Observability wichtig. Abbildung 2 zeigt einen Prozess, wie wir uns diese Daten zunutze machen können.
![Abbildung 2: Ein Prozess zur Verarbeitung von Telemetrie-Daten zugunsten von Observability. Angelehnt an eine Best Practice Bereich aus dem Azure Well-Architected Framework [MPI]](/img/blog/ak/well-architected-cloud/02-operational-excellence/embarc_wac_oe_observability_prozess02.png "Abbildung 2: Ein Prozess zur Verarbeitung von Telemetrie-Daten zugunsten von Observability. Angelehnt an eine Best Practice Bereich aus dem Azure Well-Architected Framework [MPI]")
Abbildung 2: Ein Prozess zur Verarbeitung von Telemetrie-Daten zugunsten von Observability. Angelehnt an eine Best Practice Bereich aus dem Azure Well-Architected Framework [MPI]
Key Performance Indicators (KPIs) definieren
Bevor wir uns technisch über die Auswertung von Telemetrie-Daten Gedanken machen, müssen wir festlegen, was wir überhaupt messen wollen. Das Framework von AWS gibt uns in [AAT] zwei Fragen an die Hand, die beim Ableiten von KPIs nützlich sind:
Sie sollten jederzeit in der Lage sein, diese Fragen zu beantworten. Definieren Sie Ihre KPIs zudem auf verschiedenen Ebenen. Bedenken Sie neben einer allgemeineren Geschäftsziel-Ebene auch detaillierte, technische Faktoren (z. B. Speicherverbrauch, Netzwerklatenz von technischen Komponenten) [AOH] [GMB].
Datenquellen
Identifizieren Sie ein breites Spektrum an Datenquellen für Telemetrie. Je mehr Datenquellen Sie integrieren, desto besser sind die Metriken, mit denen Sie die Erreichung Ihrer KPIs überprüfen können.
Mögliche Datenquellen sind:
Inspiration zu möglichen Datenquellen finden Sie in [MMS] oder [ADT], an denen sich die obige Auflistung orientiert.
Sammlung und Speicherung von Telemetrie-Daten
Achten Sie darauf, dass Sie die Telemetrie-Daten aus den oben genannten Quellen an einer zentralen und einheitlichen Stelle sammeln und speichern. Das Azure Well-Architected Framework hat eine gute Sektion, in der unterschiedliche Strategien aufgeführt sind [MCS]. Eine Sammlung unterschiedlicher Tools finden Sie in Abbildung 3.
Abbildung 3: Auswahl von Tools
Auswertung
Separieren Sie Telemetrie-Daten nach Wichtigkeit. Manche Daten müssen zeitnah analysiert werden, da sie für kritische Metriken notwendig sind. Andere Daten können später analysiert werden, da sie eher für Reports und zur weiteren Analyse verwendet werden.
Viele Telemetrie-Services bieten die Möglichkeit, aus aggregierten Log-Daten Metriken zu berechnen. Beispielsweise können Sie aus verschiedenen Log-Statements eine Fehlerrate berechnen und als Metrik verarbeiten.
Visualisierung und Alarme
Visualisieren Sie die in den vorherigen Schritten gesammelten und aufbereiteten Daten. Stellen Sie diese Visualisierungen auf einem zentralen Dashboard zur Verfügung.
Nutzen Sie diese Daten auch, um Alarme auszulösen. Alarme sind Mechanismen, die Sie in bestimmten Situationen über wichtige Ereignisse informieren. Diese sind gefährdend und haben direkte Auswirkungen auf Ihre Nutzer, z. B. wenn die Verfügbarkeit Ihrer Website nicht gegeben ist.
Stellen Sie sicher, dass Sie auf solche Alarme adäquat reagieren können [MMS]:
Um Operational Excellence zu erreichen, müssen wir uns Gedanken über unsere Systeme und Entwicklungsprozesse machen. Alle drei Frameworks legen den Fokus auf solche Themen [ADO] [MCI] [GAD].
Abbildung 4: Automatisch deployte Umgebungen anhand von Git-Branches
Am Ende einer solchen Pipeline findet ein automatisches Deployment statt. Canary-Deployments sind ein Mechanismus zur Minimierung des Risikos, unbeabsichtigt Fehler einzuführen. Dabei werden einzelne Features des Systems vorerst nur für eine kleine Nutzergruppe aktiviert. Dadurch betreffen mögliche Probleme nicht die gesamte Nutzerbasis und können leichter zurückgerollt werden. Eine Übersicht von weiteren Best Practices zur Senkung des Deployment-Risikos finden Sie in den Architekturframeworks [AMR] [MDE] [GAD].
Zusätzlich habe ich die oben genannten Konzepte in einer schemahaften Pipeline in Abbildung 5 verortet.
Abbildung 5: Ein Beispiel für eine CI/CD-Pipeline
Automatisierung ist ein zentraler Baustein der “Operational Excellence”-Pillar. Allgemein geht es um die Minimierung von “Toil” (englisch für Mühsal). Dieser Begriff wird in den Frameworks regelmäßig benutzt und bezeichnet operative Arbeit, die wenig Mehrwert bietet und eigentlich automatisierbar ist [MTO].
Infrastructure as Code ist eine populäre Methode zur Automatisierung. Meistens handelt es sich bei diesem Konzept um einen deklarativen Ansatz. Im Gegensatz zum imperativen Ansatz definieren Sie hier einen erwarteten Zielzustand (also die Ressourcen, die Sie in Ihrer Cloud-Umgebung benötigen und deren Konfiguration) und delegieren die Ableitung der notwendigen Schritte zur Erreichung dieses Zielzustandes an ein Automatisierungstool. Einige Werkzeuge für diesen Ansatz finden Sie in Abbildung 3.
Doch nicht alle operativen Aspekte müssen immer vollständig automatisiert sein. Runbooks und Playbooks sind zwei Konzepte, die hier ergänzend hilfreich sind. Runbooks sind eine dokumentierte Serie von operationellen Aktionen, die dazu dienen, ein bestimmtes Ziel zu erreichen. Häufige Beispiele für Runbooks sind eine Auflistung von manuellen Schritten, die bei großen Releases durchzuführen sind. Sobald Sie Runbooks dokumentiert und zentral abgelegt haben, sollten Sie diese je nach Priorität komplett automatisieren [ARB] [MOT].
Playbooks sind eine Hilfestellung, die Sie verwenden können, um Zwischenfälle (z. B. Systemausfälle oder langsame Systemteile) besser analysieren zu können. Sie beschreiben einzelne Schritte, die Sie durchführen sollen, um die Ursache zu identifizieren. Sie sind meistens offener als Runbooks und behandeln eher Punkte wie “Performance-Logs auf Ausreißer prüfen” anstatt konkreter, automatisierbarer Anweisungen [APB].
Das war der zweite Beitrag in der Blogreihe “Well Architected Cloud”. Unten finden Sie eine Auflistung aller bisherigen Artikel. Nächste Woche werden wir uns die Security-Pillar genauer anschauen.
Sie möchten sich zum Thema “Operational Excellence” oder den Architekturframeworks der Cloud-Anbieter austauschen? Melden Sie sich gerne, meine Kontaktdaten finden Sie hier.
“Well Architected Cloud: ein Überblick über drei Architektur-Ratgeber”
“Well Architected Cloud: die Security-Pillar”
“Well Architected Cloud: die Reliability-Pillar”
‘Well Architected Cloud: die “Performance Efficiency”-Pillar’
“Well Architected Cloud: die Pillars “Cost Optimization” und Sustainability”
“Well Architected Cloud: die Architektur-Frameworks effektiv und effizient einsetzen”
“Die Pillar im AWS Well-Architected Framework”
“Die Pillar im Azure Well-Architected Framework”
“Die Pillar im Google Cloud Architecture Framework”
[AAL] “Alert when workload outcomes are at risk”
[AAT] “Implement application telemetry”
[ADO] “Design for operations”
[ADT] “Design telemetry”
[AGD] “Build Your Own Game Day to Support Operational Resilience”, Blogpost von Lewis Taylor und Haresh Nandwani, September 2021
[AMR] “Mitigate deployment risks”
[AOH] “Understanding operational health”
[ARB] “Use runbooks to perform procedures”
[ARE] “Responding to events”
[GAD] “Automate your deployments”
[GAL] “Set up alerting”
[GMP] “Create a monitoring plan”
[OPG] “GitOps”
[MAL] “Alerting for operations”
[MCS] “Collect, aggregate, and store monitoring data for cloud applications”
[MCI] “Release Engineering: Continuous Integration”
[MDE] “Release Engineering: Deployment”
[MMS] “Data sources for diagnostic data”
[MOT] “Operational tasks”
[MPI] “Monitoring workloads”
[MRT] “Testing your application and Azure environment”
[MTO] “Automate toil to improve efficiency”
[TBD] “Trunk Based Development”