Die Kladde hat seit Modul 3.4 Alarme: „Fehlerquote über 5 % in 5 Minuten“, „zwei von drei Orten erreichen /health/live nicht“. Das sind gute
Alarme, aber sie beantworten eine Frage nicht: Wie zuverlässig soll die Kladde eigentlich sein? Ist eine Fehlerquote von 1 % den ganzen Tag
lang in Ordnung? Und ist es schlimm, wenn der Import der Ausschreibungen eine Nacht ausfällt?
Dieses Modul gibt darauf eine Antwort, die man messen kann, und baut darauf das Handwerk des Betriebs, das unter dem Namen Site Reliability Engineering (SRE) bekannt ist: Ziele, die aus dem kommen, was Nutzer brauchen, ein Budget für Fehler, ein geordneter Ablauf bei Störungen, Nachbetrachtungen, Runbooks und Experimente, die Ausfälle absichtlich herbeiführen. Das Abschlussprojekt (3.10) verlangt genau das: Alarme, eine Wiederherstellung, ein Betriebshandbuch und eine Störungsübung mit Nachbetrachtung.
| Lektion | Was entsteht | h |
|---|---|---|
| 3.15.1 SLIs und SLOs | docs/slo.md, vier Abfragen unter ops/queries/, eine Arbeitsmappe |
4 |
| 3.15.2 Fehlerbudgets | Burn-Rate-Alarme in Bicep, eine Regel für das verbrauchte Budget | 3 |
| 3.15.3 Bereitschaft und der Ablauf einer Störung | Störungsablauf in docs/betrieb.md, eine Tischübung |
3 |
| 3.15.4 Nachbetrachtungen ohne Schuldige | die Vorlage aus 3.4.6, erweitert, und ein Review | 3 |
| 3.15.5 Runbooks | runbooks/ im Repository, ein ausführbares Runbook mit Test |
3 |
| 3.15.6 Chaos-Engineering mit Azure Chaos Studio | ein Experiment mit Hypothese und Ergebnis | 3 |
In dieser ersten Lektion legen Sie fest, was „zuverlässig“ für die Kladde heißt: für zwei Abläufe je zwei Messgrößen, je ein Ziel, die Abfragen dazu im Repository und eine Arbeitsmappe, die den Stand zeigt.
Vom Bauteil zum Nutzerfluss
Die Alarme aus 3.4.5 schauen auf Bauteile: die Web-App, die Datenbank, den Verfügbarkeitstest. Nutzer sehen keine Bauteile. Eine Besucherin will einen Termin buchen; ob dafür eine Datenbank, ein Cache oder drei Container arbeiten, ist ihr gleich. Das Büro will morgens die neuen Ausschreibungen sehen; wann und wie der Import nachts lief, interessiert es nur, wenn sie fehlen.
Das Well-Architected Framework von Microsoft nennt so einen Ablauf einen Fluss (flow): eine Folge von Schritten, die für einen Nutzer oder für das Geschäft etwas erreicht. Es gibt Nutzerflüsse, die ein Mensch anstößt, und Systemflüsse, die ohne ihn laufen. Die Empfehlung RE:04 lautet: Zuverlässigkeitsziele gehören zu den wichtigen Flüssen, nicht zu einzelnen Ressourcen. Die Kladde hat diese Flüsse:
| Fluss | Art | Wer merkt einen Ausfall? | Wie wichtig |
|---|---|---|---|
Termin buchen (öffentliche Seite /termin) |
Nutzerfluss | Kundinnen des Büros, sofort | hoch: das Büro verliert Termine und Vertrauen |
| Ausschreibungen importieren (Job und Worker) | Systemfluss | das Büro, am nächsten Morgen | hoch: Fristen von Ausschreibungen sind kurz |
| Kontakte pflegen (nach Anmeldung) | Nutzerfluss | das Büro, sofort | mittel: es kann eine Stunde warten |
| Bestätigungsmail einer Buchung (Outbox) | Systemfluss | die Kundin, später | mittel: die Buchung steht ja schon |
Die ersten beiden bekommen in dieser Lektion Ziele. Für die anderen reicht vorerst, was die Alarme aus 3.4.5 schon sehen. Eine Faustregel der Kladde: höchstens drei Messgrößen je Fluss, besser zwei. Jede weitere verdünnt die Aufmerksamkeit, und in 3.15.2 hängt an jeder ein Alarm.