Produktive Skalierung

Produktive Skalierung

0:00 Im letzten Modul haben wir gelernt, Manifeste zu schreiben und einzureichen. Das funktioniert — für einen Dienst, in einer Umgebung, mit einem Menschen an der Kommandozeile. Produktiv sieht es anders aus: drei Umgebungen, ein Dutzend Dienste, ein Team, das nicht jeden Handgriff nachvollziehen kann. In diesem Modul geht es um alles, was aus Handgriffen einen Betrieb macht.

0:21 Wir paketieren, wir verlegen den Soll-Zustand ins Repository, wir lassen die Skalierung von selbst reagieren, wir messen — und am Ende reden wir über Versprechen, die man Nutzern gegenüber wirklich halten kann. Acht Kapitel, und sie bauen aufeinander auf.

Paketierung mit Helm und Kustomize

0:37 Beginnen wir mit einem Problem, das jeder kennt, der Kubernetes zum zweiten Mal benutzt: Dieselbe Anwendung soll in Test, Abnahme und Produktion laufen. Die naive Lösung ist Kopieren — und die rächt sich zuverlässig. Dieselben Manifeste, drei Umgebungen, keine Kopien. Die Aufgabe ist klar umrissen: dieselben Manifeste mit anderen Werten. Und es gibt zwei grundverschiedene Antworten darauf, die beide gut sind.

1:03 Ein Chart legt Platzhalter in die Manifeste und füllt sie aus einer Wertedatei — das kennt jeder aus der Textverarbeitung mit Serienbrief. Kustomize geht den anderen Weg: keine Platzhalter, sondern Änderungsschichten über einer unveränderten Basis, wie Folien auf einem Overheadprojektor. Beide Wege lösen dasselbe Problem, und die Wahl hängt davon ab, ob Sie Ihre Manifeste lieber lesbar oder lieber flexibel haben wollen. Zur Abwägung kommen wir in wenigen Folien.

1:30 Vier Teile mit festen Namen — mehr ist ein Chart nicht. Die Vorgabedatei enthält die Werte, die von außen überschrieben werden dürfen; im Vorlagenverzeichnis liegen die Manifeste mit Platzhaltern; das letzte Verzeichnis nimmt eingebundene Untercharts auf, etwa eine Datenbank. Interessant ist der Hinweis unten, weil er eine häufige Verwechslung auflöst: Es gibt zwei Fassungsnummern.

1:52 Die eine zählt das Paket, die andere nur die enthaltene Anwendung — und die zweite wirkt nirgends mit, sie ist reine Dokumentation. Wer sie für die maßgebliche hält, wundert sich, warum sich beim Einspielen nichts ändert. Drei Befehle, und der zweite ist der, den ich Ihnen wirklich mitgeben will: Er rendert das Chart, ohne den Cluster anzufassen.

2:12 Sie sehen also die fertigen Manifeste auf dem Bildschirm, bevor irgendetwas passiert — der Hinweis unten nennt es die billigste Fehlersuche im ganzen Modul, und das ist keine Übertreibung. Der dritte Befehl spielt ein und hat zwei Schalter, die zusammen wirken: Er wartet auf Bereitschaft und nimmt bei einem Fehlschlag alles vollständig zurück.

2:31 Halbe Zustände nach einem gescheiterten Einspielen sind nämlich das Unangenehmste, was in diesem Bereich passieren kann. Vier Vergleichszeilen, und die zweite ist die, an der sich die Gemüter scheiden: Ein Chart-Manifest ist erst nach dem Rendern lesbar — vorher steht dort eine Mischung aus YAML und Vorlagensprache, die keine Werkzeuge verstehen.

2:52 Bei Kustomize ist jedes Manifest immer gültiges YAML. Dafür ist ein Chart das etablierte Weitergabeformat: Wer Software an Dritte ausliefert, liefert ein Chart. Und Kustomize hat den unschlagbaren Vorteil, bereits eingebaut zu sein. Der Hinweis unten löst die Frage übrigens elegant auf: Beides ist kombinierbar. Ein gerendertes Chart lässt sich als Basis weiter überlagern — genau so machen es viele Teams.

3:17 Das Lernziel ist hier präziser formuliert, als es zunächst klingt: Trennen Sie umgebungsabhängige Werte von der Struktur der Manifeste — ohne die Manifeste zu vervielfachen. Geschafft ist es, wenn aus einem Chart zwei Umgebungen entstehen, die sich nur in Replikatzahl, Rechnername und Ressourcen unterscheiden, und wenn beide fehlerfrei rendern.

3:36 Wer schneller fertig ist, ergänzt eine Wertprüfung, die eine fehlende Angabe früh abweist — das ist in der Praxis Gold wert. Und achten Sie auf den Hinweis: Der Punkt ist das Trennen, nicht die Menge der Platzhalter. Mehr Platzhalter sind nicht besser. Der erste Punkt ist die Übertreibung, in die man beim ersten Chart verfällt: alles zum Platzhalter machen.

3:57 Das Ergebnis ist ein Paket, das niemand mehr lesen kann, und der Wartungsaufwand übersteigt schnell den Nutzen. Machen Sie konfigurierbar, was sich zwischen Umgebungen unterscheidet — und sonst nichts. Der zweite ist ein Entwurfsfehler: Produktionswerte gehören von außen, nicht ins Chart. Der dritte ist die vergebene Chance aus der Code-Folie — ohne Rendern merken Sie Syntaxfehler erst im Cluster.

4:20 Und der vierte ist die Verwaltungsschlamperei, die im Ernstfall wehtut: Ohne erhöhte Chart-Fassung lassen sich Auslieferungen nicht unterscheiden.

GitOps mit Argo CD

4:29 Jetzt kommt die konsequente Fortsetzung eines Gedankens aus Modul 5. Dort haben wir gesehen: Regler stellen einen Soll-Zustand her. Aber wo liegt dieser Soll-Zustand? Bisher im Cluster. Und die Frage dieses Kapitels ist, ob das der richtige Ort ist. Das Repository ist der Soll-Zustand, nicht die Kommandozeile. GitOps zieht den Soll-Zustand aus dem Cluster heraus ins Repository.

4:54 Ein Regler vergleicht dann fortlaufend den Stand im Git mit dem Cluster und gleicht Abweichungen an — es ist also genau die Reglerschleife aus Modul 5, nur eine Ebene höher gehängt. Und daraus folgt der Satz, der die Arbeitsweise verändert: Eingespielt wird nicht mehr von einem Arbeitsplatz aus, es wird zusammengeführt. Ein Deployment ist ein Merge.

5:14 Das klingt nach einer Verwaltungsformalie und ist eine erhebliche Verbesserung — denn plötzlich hat jede Änderung an der Produktion einen Autor, ein Datum und ein Review. Dieses Manifest ist bemerkenswert kurz für seine Wirkung: Es sagt, wo das Repository liegt, welcher Pfad darin gilt — und dann kommt der eigentliche Schalter.

5:33 Der Hinweis unten ist die wichtigste Information dieser Folie: Ohne den Block für automatisches Angleichen bleibt es beim Anzeigen der Abweichung. Und das ist der Ausgangszustand, mit dem man vernünftigerweise beginnt. Sie sehen dann in einer Oberfläche, dass Git und Cluster auseinanderlaufen, und niemand tut etwas. Genau dieser vorsichtige Anfang ist der Grund, warum sich GitOps ohne Drama einführen lässt — mehr dazu im Vorgehen.

5:59 Drei Schalter, und der Hinweis darunter ist der beruhigende Teil: Die beiden letzten stehen voreingestellt auf falsch, als Sicherung gegen unbeabsichtigtes Löschen. Ich sage kurz, warum sie so heißen, wie sie heißen. Der eine löscht, was im Repository nicht mehr beschrieben ist — mächtig und gefährlich, denn er löscht auch, was Sie vergessen haben zu beschreiben.

6:19 Der andere nimmt Änderungen am Cluster zurück, die nicht im Git stehen. Das ist der Schalter, der GitOps wirklich durchsetzt: Ohne ihn ist das Repository eine Empfehlung, mit ihm ist es verbindlich. Vier Punkte, und der erste ist der, mit dem Sie eine Revisionsprüfung gewinnen: Jede Änderung an der Produktion hat einen Autor, ein Datum und eine Prüfung.

6:40 Das lässt sich kein Betriebsprozess so ordentlich zusammenschreiben, wie es hier von selbst entsteht. Der zweite ist die Selbstheilung von vorhin — der Cluster kann nicht heimlich abweichen, was den Zustand über Monate ehrlich hält. Der dritte ist im Ernstfall unbezahlbar: Zurückrollen heißt, den vorigen Stand zusammenzuführen, nicht Befehle rückwärts abzuspielen.

7:01 Und der vierte zeigt sich beim Wiederaufbau: Ein neuer Cluster entsteht aus demselben Repository, nicht aus Erinnerung. Diese fünf Schritte sind eine Vertrauensleiter, und die Reihenfolge ist die ganze Kunst. Erst den Bestand übernehmen und nur anzeigen lassen. Dann die gemeldeten Abweichungen abarbeiten — das ist die eigentliche Arbeit, und sie ist lehrreich, weil man dabei erfährt, was im Cluster steht und in keiner Datei.

7:27 Dann Selbstheilung, dann Löschen, und zwar erst, wenn niemand mehr von Hand Objekte anlegt. Der Hinweis unten benennt den wahren Umzugstag: Schritt fünf, die Rechte am Arbeitsplatz auf Lesen zurücknehmen. Vorher bleibt der alte Weg offen — und solange er offen ist, wird er benutzt. Das Lernziel ist eine Umkehrung von Ursache und Folge: Die Änderung im Repository ist die Ursache, der Cluster ist die Folge.

7:51 Geschafft ist es, wenn eine Änderung an der Wertedatei ohne Zutun im Cluster erscheint — und wenn eine Änderung von Hand am Cluster binnen Minuten zurückgenommen wird. Dieser zweite Teil ist der Moment, der GitOps erklärt, und er ist erst irritierend und dann überzeugend: Sie ändern etwas, es funktioniert, und wenige Minuten später ist es weg.

8:10 Wer schneller fertig ist, prüft, was beim Einschalten des Löschens verschwinden würde. Diese Liste ist oft überraschend lang. Der erste Punkt ist der Grund, warum Löschen im Vorgehen zuletzt kommt: Von Hand angelegte Hilfsobjekte verschwinden, und in jedem gewachsenen Cluster gibt es solche. Der zweite ist die Kehrseite der Selbstheilung, und darauf muss man das Team vorbereiten: Ein Nottreffer im Störungsfall wird zurückgesetzt — auch der gute, auch der um drei Uhr nachts.

8:38 Der dritte ist ein echter Sicherheitsfehler mit nachvollziehbarer Ursache: Geheimnisse im Klartext, weil das Repository doch der Soll-Zustand ist. Nein — dafür gibt es verschlüsselte Verfahren. Und der vierte ist Gewohnheit: Zurückrollen im Cluster versuchen, obwohl der Weg jetzt über das Repository führt.

Horizontale Skalierung mit HPA

8:56 Jetzt zur Skalierung, und wir fangen mit der naheliegenden an: mehr Pods, sobald die Auslastung es verlangt. Sie ist naheliegend, gut dokumentiert und gleichzeitig die mit den meisten Fehlbedienungen — weil sie eine stille Voraussetzung hat, die viele nicht erfüllen. Die Rechnung dahinter ist erfreulich einfach, und man sollte sie kennen: aktuelle Zahl mal Verhältnis von gemessenem zu gewünschtem Wert, aufgerundet.

9:20 Liegt das Verhältnis nahe eins, bleibt alles stehen. Bei siebzig Prozent Ziel und hundertvierzig Prozent Messwert verdoppelt sich also die Pod-Zahl. Und jetzt die stille Voraussetzung, die ich angekündigt habe: Grundlage sind die Anforderungen aus Modul 5. Auslastung in Prozent ist nämlich immer Prozent von etwas — und dieses Etwas ist die Anforderung.

9:40 Ohne gesetzte Anforderungen gibt es keinen Prozentwert, und der HPA hat nichts zu rechnen. Beachten Sie die Reihenfolge in diesem Manifest, denn sie ist didaktisch klug: Zuerst kommen die Grenzen, dann die Messgröße. Die Untergrenze von drei ist mehr als Vorsicht — sie hält den Dienst über Zonen verteilt, worauf wir in Kapitel 8 zurückkommen.

10:00 Die Obergrenze ist Ihre Kostenbremse und gleichzeitig Ihr Schutz davor, dass ein Fehler in der Anwendung sich in die Rechnung skaliert. Setzen Sie sie bewusst, nicht großzügig. Die Fortsetzung nennt dann Rechenzeit als Ressource und siebzig Prozent als Ziel — ein guter Startwert, der genug Luft für Lastspitzen lässt. Diese Tabelle beschreibt eine bewusste Asymmetrie, und die zu verstehen erspart Ihnen eine Fehlbedienung.

10:25 Nach oben reagiert der Skalierer unmittelbar — bei Last soll er sofort helfen. Nach unten wartet er fünf Minuten. Das sieht nach Trägheit aus und ist Absicht; der Hinweis unten sagt es klar: Abwärts pendeln kostet mehr als ein paar Pods zu viel. Denn jeder neue Pod muss anlaufen, Verbindungen aufbauen, Caches füllen. Wer die Beruhigung nach unten verkürzt, weil ihm der Dienst zu träge herunterfährt, bekommt ein System, das im Fünfminutentakt zwischen vier und acht Pods pendelt.

10:54 Der erste Punkt ist die Voraussetzung von vorhin, und er ist der häufigste Fehlstart: ohne gesetzte Anforderungen skalieren wollen. Der Skalierer meldet dann „unbekannt" und tut nichts, und man sucht lange in der falschen Ecke. Der zweite ist das Pendeln aus der Tabelle. Der dritte ist ein hübscher Selbstwiderspruch, den man häufig sieht: Die Replikatzahl im Manifest festschreiben und gleichzeitig einen Skalierer betreiben — dann arbeiten beide gegeneinander, und jedes Einspielen setzt die Skalierung zurück.

11:22 Und der vierte ist eine Modellierungsfrage: Nach Speicherauslastung zu skalieren funktioniert nur, wenn der Speicher mit der Last wächst. Bei den meisten Diensten tut er das nicht.

Ereignisgetriebene Skalierung mit KEDA

11:33 Jetzt der interessantere Weg. Es geht um den Unterschied zwischen zwei Fragen, und der ist im Betrieb erheblich: „Ist heiß" gegen „hat viel zu tun". Nicht die Auslastung zählt, sondern die Warteschlange. Der Kernsatz steht am Anfang und lohnt eine Sekunde Nachdenken: Rechenlast ist ein Nachlaufindikator. Sie steigt, wenn die Arbeit schon liegt — Sie skalieren also, nachdem die Warteschlange voll ist.

11:58 Das Bild dazu ist ein Supermarkt: Sie öffnen die zweite Kasse nicht, wenn die Kassiererin schwitzt, sondern wenn die Schlange lang wird. KEDA skaliert nach dieser Ursache — Länge einer Warteschlange, Zahl offener Aufträge, beliebige Messgröße. Und technisch ist es elegant gelöst: Es tritt nicht an die Stelle des Autoskalierers, sondern legt selbst einen an und speist ihn mit Werten.

12:21 Die eine Zeile, die alles verändert, steht in der Mitte: null als Mindestzahl. Der reguläre Autoskalierer kann das nicht, KEDA kann es — und das ist der zweite große Unterschied neben der Messgröße. Ein Rechendienst ohne Aufträge kostet dann nichts. Beachten Sie auch die Abkühlzeit von fünf Minuten; sie verhindert, dass der Dienst zwischen null und eins pendelt, und dazu gleich mehr.

12:42 Die Fortsetzung nennt die Adresse des Messdienstes, den Namen der Messgröße und einen Schwellwert — womit dieses Kapitel bereits auf das nächste zeigt: Ohne Messung gibt es hier nichts zu skalieren. Drei Wege, und die Sortierung ist nach dem, was sie verändern. Die ersten beiden ändern die Zahl der Pods und unterscheiden sich nur in der Frage, worauf sie hören.

13:04 Der dritte, der VPA, ist grundverschieden: Er ändert die Anforderungen je Pod und ist die Antwort auf falsch geschätzte Ressourcen — für das Problem also, das wir in Modul 5 mit dem Aufrunden hatten. Und der Hinweis unten ist eine echte Warnung, keine Fußnote: Auf derselben Messgröße arbeiten horizontale und vertikale Skalierung gegeneinander.

13:24 Der eine erhöht die Anforderung, wodurch die Auslastung sinkt, wodurch der andere Pods abbaut. Diese Kombination bleibt außen vor. Der erste Punkt ist ein Kostenargument, und in Zeiten teurer Cloud-Rechnungen ist es ein starkes: Ein Rechendienst ohne Aufträge kostet nichts, wenn kein Pod läuft. Der zweite ist die ehrliche Kehrseite — die erste Anfrage weckt ihn, und die Wartezeit ist der Preis.

13:47 Bei einem Bildverarbeitungsauftrag sind fünfzehn Sekunden Anlauf völlig gleichgültig. Der dritte nennt die Abkühlzeit als Schutz gegen Pendeln. Und der vierte zieht die klare Grenze, die man beachten muss: Für Dienste an der Web-Schnittstelle taugt das nicht — dort wartet ein Mensch, und der wartet nicht fünfzehn Sekunden.

14:05 Für Rechenarbeit im Hintergrund dagegen sehr wohl. Ihre Aufgabe: eine Skalierung an der Ursache statt an der Wirkung festmachen und ihr Verhalten unter Last belegen. Der Erfolg hat drei Teile, und der dritte ist der schönste — im Leerlauf läuft kein Pod. Wer schneller fertig ist, macht das eigentlich Interessante: dieselbe Last einmal mit Skalierung nach Rechenlast und einmal nach Warteschlange fahren und die Reaktionszeiten vergleichen.

14:30 Dieser Vergleich am gleichen Lastprofil ist der eigentliche Erkenntnisgewinn des Kapitels, denn er macht den Nachlaufindikator sichtbar. Sie sehen dann in zwei Kurven, was ich vorhin behauptet habe. Der erste Punkt ist die Grenze aus dem Warum, und sie wird gerne ignoriert, weil die Kostenersparnis so verlockend ist: Ein Web-Dienst auf null skaliert lässt die erste Anfrage in eine Zeitüberschreitung laufen.

14:53 Der zweite ist die Abkühlzeit — zu kurz gesetzt, kommen und gehen Pods im Sekundentakt, was mehr kostet als es spart. Der dritte ist ein Zuständigkeitskonflikt, der schwer zu diagnostizieren ist: ein eigener Autoskalierer neben KEDA, und beide streiten um dasselbe Ziel. Und der vierte betrifft die Taktung und führt zu einer trägen Skalierung, die niemand erklären kann: Die Messgröße wird nur alle Minuten erneuert.

Messen mit Prometheus und Grafana

15:17 Und damit zu dem Kapitel, ohne das die beiden vorigen blind bleiben. Wir haben gerade nach Messgrößen skaliert — aber woher kommen sie? Was nicht gemessen ist, lässt sich nicht skalieren. Und ehrlicherweise: Was nicht gemessen ist, lässt sich auch nicht betreiben. Der entscheidende Satz steht am Ende, und er ist die Umkehrung dessen, was viele erwarten: Der Dienst wird abgefragt, er meldet nichts von sich aus.

15:43 Prometheus holt sich die Werte — es fragt in festem Takt Endpunkte der Dienste ab und legt Zeitreihen an. Das hat einen praktischen Vorteil: Ein Dienst, der nicht antwortet, fällt sofort auf, denn die Abfrage schlägt fehl. Abgefragt wird über eine eigene Sprache, die auf Zeitfenstern rechnet, und dieser Punkt wird uns gleich beschäftigen.

16:02 Grafana stellt dieselben Reihen dar und speichert selbst nichts — es ist die Anzeige, nicht die Quelle. Vier Arten, und die erste ist die, die zu den meisten Missverständnissen führt. Ein Zähler wächst nur — er zählt Anfragen seit dem Start des Prozesses. Der Hinweis unten sagt, was daraus folgt: Wer einen Zähler direkt anzeigt, sieht eine Treppe, die immer nur steigt.

16:25 Gemeint ist aber fast immer seine Steigung, also Anfragen pro Sekunde. Dafür gibt es eine eigene Funktion, und die sehen wir gleich. Ein Messwert steigt und fällt, etwa belegter Speicher, den kann man direkt anzeigen. Und Histogramme sind die Grundlage für Perzentile — die brauchen wir für die Antwortzeiten. Diese drei Abfragen deckt neunzig Prozent des Alltags ab. Die erste macht aus dem Zähler eine Rate, also Anfragen pro Sekunde.

16:52 Die zweite ist eine Fehlerquote und zeigt das Muster, das Sie sich merken sollten: Teil geteilt durch Ganzes, beides als Rate. Und die dritte holt ein Perzentil aus dem Histogramm — hier das fünfundneunzigste, also den Wert, unter dem die überwiegende Mehrheit der Anfragen liegt. Wichtig ist der Hinweis unten: Das Zeitfenster gehört zur Abfrage, nicht zur Messgröße.

17:14 Sie entscheiden also beim Fragen, wie träge die Kurve reagiert — und diese Wahl hat Folgen, wie der letzte Stolperstein zeigt. Diese vier Signale sind eine Empfehlung aus der Betriebspraxis großer Systeme, und sie sind erstaunlich robust: Verkehr, Fehler, Dauer, Sättigung. Wer nichts messen kann, fängt hiermit an — und wer schon alles messen kann, kehrt oft hierhin zurück. Beachten Sie die Klammer beim dritten: als Perzentil statt Mittelwert.

17:40 Der Mittelwert der Antwortzeit ist eine der irreführendsten Zahlen im Betrieb, weil er die langsamen Fälle in der Masse versteckt. Wenn eine von zwanzig Anfragen zehn Sekunden braucht, sieht der Mittelwert gut aus — und genau diese eine Anfrage ist der Kunde, der anruft. Der erste Punkt ist die Mittelwertfalle von der letzten Folie.

18:00 Der zweite ist eine Krankheit reifer Systeme: Tausende Kennzahlen erheben und keine einzige Schwelle festlegen, die etwas auslöst. Solche Systeme sind gut ausgestattet und nicht überwacht — es sieht nur so aus. Der dritte verbindet dieses Kapitel mit dem vorigen: Nach einer Messgröße zu skalieren, deren Abfragetakt langsamer ist als die Skalierung selbst, ergibt ein System, das immer der Vergangenheit nachjagt.

18:24 Und der vierte betrifft die Zeitfensterwahl: zu lang gewählt, geht ein Lastsprung in der Kurve unter — Sie sehen die Spitze schlicht nicht.

Protokolle und Traces

18:33 Metriken zeigen, dass etwas klemmt. Sie zeigen nicht, warum. Für das Warum braucht es zwei weitere Sichten, und zusammen ergeben sie drei Blickwinkel auf dasselbe Ereignis. Wer alle drei hat und verbinden kann, findet Ursachen in Minuten statt in Stunden. Drei Sichten, drei Fragen. Messwerte verdichten viele Ereignisse zu Zahlen — sie sind billig und verlieren das Einzelne.

18:56 Protokolle behalten den einzelnen Vorfall im Wortlaut — sie sind teuer und behalten alles. Und ein Trace verfolgt eine Anfrage über Dienstgrenzen hinweg und zeigt, welcher Abschnitt die Zeit verbraucht. Denken Sie an eine Paketverfolgung: Sie sehen jede Station und wie lange das Paket dort lag. In einem System aus zwölf Diensten ist das die einzige brauchbare Antwort auf „warum dauert das".

19:19 Und ein offener Standard beschreibt Erzeugung und Übertragung aller drei — Sie binden sich also nicht an einen Anbieter. Die Kostenspalte ist die, über die man vorher nachdenken sollte, weil sie im Betrieb überrascht. Protokolle wachsen mit der Last — verzehnfachen Sie den Verkehr, verzehnfachen Sie die Protokollrechnung, und die kann die Rechnung für die Anwendung selbst übersteigen.

19:42 Traces nimmt man deshalb meist stichprobenweise, also nur jede hundertste Anfrage; für die Frage „wo geht die Zeit hin" genügt das völlig. Der Hinweis unten ist aber der eigentliche Inhalt: Verknüpft werden die drei über gemeinsame Kennungen. Ohne sie haben Sie drei Werkzeuge und keine Diagnose — Sie sehen eine Fehlerspitze und können nicht sagen, welche Protokolle dazugehören.

20:04 Zwei Umgebungswerte, und das ist tatsächlich der ganze Anschluss — der Rest steckt in Bibliotheken, die vieles selbsttätig erfassen. Bemerkenswert ist die Architektur, die der Hinweis unten beschreibt: Der Dienst kennt nur den Sammler. Er weiß nicht, wo Protokolle landen, wo Traces gespeichert werden, welches Produkt dahinter steht. Der Sammler nimmt entgegen, verarbeitet und verteilt weiter.

20:26 Das ist mehr als eine Aufräumidee: Sie können das Werkzeug hinter dem Sammler austauschen, ohne einen einzigen Dienst anzufassen. Dieselbe Entkopplung, die wir in Modul 1 beim offenen Container-Format gesehen haben, nur für Messung. Der erste Punkt klingt übertrieben und ist wörtlich gemeint: Wer alles im höchsten Detailgrad protokolliert, füllt die Ablage schneller, als die Anwendung antwortet.

20:50 Ich habe Systeme gesehen, deren Protokollierung mehr Rechenzeit verbrauchte als die Anwendung. Der zweite ist der Sammler als Engpass, wenn die Stichprobenregel fehlt. Der dritte ist die fehlende Verknüpfung aus der Tabelle — und er ist der teuerste, weil er die Diagnose genau dann verhindert, wenn man sie braucht. Und der vierte ist ein Datenschutzthema mit ehrlicher Ursache: Personenbezogene Daten mitzuprotokollieren ist im Fehlerfall bequem. Es bleibt trotzdem eine Datenpanne.

Progressive Delivery

21:17 Jetzt nehmen wir das Ausrollen aus Modul 5 noch einmal in die Hand — aber mit Rückfahrkarte und Messung. Die Idee ist so einfach wie wirkungsvoll: Zeigen Sie die neue Fassung erst einem Zwanzigstel Ihrer Nutzer. Wenn etwas schiefgeht, merken es fünf Prozent statt hundert. Der Satz, um den es hier geht, ist kurz: Bereit heißt nicht richtig.

21:38 Ein normales Ausrollen tauscht alle Pods, sobald die neue Fassung Bereitschaft meldet — und eine Fassung kann tadellos bereit melden und trotzdem falsche Ergebnisse liefern. Beim schrittweisen Ausrollen bekommt sie zunächst einen kleinen Anteil des Verkehrs, und gemessene Werte entscheiden, ob der Anteil wächst oder alles zurückgenommen wird.

21:57 Und beachten Sie den letzten Satz, denn er hat praktische Folgen: Ein eigenes Objekt tritt an die Stelle des Deployments. Sie tauschen also den Objekttyp — und dürfen ihn nicht doppelt betreiben. Diese Schritte liest man wie ein Drehbuch: zehn Prozent, zehn Minuten warten, fünfzig Prozent, zehn Minuten warten. Die Pausen sind kein Leerlauf, sie sind die Messfenster — in dieser Zeit sammelt sich genug Verkehr, um eine Aussage zu treffen.

22:22 Wählen Sie sie also nicht kürzer, als Ihr Messdienst braucht, um Werte zu liefern; darauf kommt der letzte Stolperstein zurück. Und beachten Sie den Hinweis: Eine Pause ohne Dauer hält unbegrenzt. Das ist der manuelle Haltepunkt — ein Mensch entscheidet über das Weiterrücken. Für die erste kritische Auslieferung ist das eine sehr vernünftige Wahl.

22:43 Zwei Verfahren, und die Ressourcenzeile ist der praktische Unterschied: Beim anteiligen Verschieben brauchen Sie ein paar Pods zusätzlich, beim Umschalten einen kompletten zweiten Satz. Bei einem Dienst mit dreißig Pods ist das ein Budgetthema. Dafür ist das Umschalten einfacher zu verstehen und die Rücknahme ein einziger Handgriff.

23:01 Der Hinweis unten gilt aber für beide, und er ist der Kernsatz dieses Kapitels: Ohne automatische Auswertung der Messwerte ist das alles nur ein langsameres Ausrollen. Sie haben dann die Kosten des Verfahrens und nicht seinen Nutzen — denn niemand sieht um drei Uhr nachts auf die Fehlerquote. Das Lernziel bringt es auf den Punkt: ein Ausrollen an gemessene Werte binden, statt es an der Bereitschaftsmeldung zu entscheiden.

23:25 Geschafft ist es, wenn eine absichtlich fehlerhafte Fassung bei zehn Prozent Verkehrsanteil erkannt und automatisch zurückgenommen wird — ohne dass jemand eingreift. Und lesen Sie den Hinweis zur Vorbereitung genau, denn er entscheidet über das Gelingen: Die fehlerhafte Fassung muss echte Fehler liefern, keine Abstürze.

23:42 Ein abstürzender Prozess wird nämlich schon von der Bereitschaftsprüfung abgefangen, und dann haben Sie das falsche Sicherheitsnetz getestet. Wer schneller fertig ist, ergänzt einen zweiten Prüfwert neben der Fehlerquote. Der erste Punkt ist der Kernsatz aus der Tabelle in Negativform, und er ist verbreitet: Anteile verschieben ohne Auswertung, und die Rücknahme wird von Hand verpasst — weil niemand hinsieht.

24:05 Der zweite ist die Taktfalle von vorhin: Das Auswertungsfenster kürzer als der Abfragetakt des Messdienstes ergibt eine Entscheidung auf leeren Daten. Der dritte ist die Objektfrage aus der Definition, und sie führt zu einem sehr verwirrenden Fehlerbild: Deployment und schrittweises Ausrollen parallel auf dieselben Pods gerichtet, und beide verwalten sie.

24:24 Und der vierte ist ein Budgetthema, das man vorher klären sollte — doppelter Ressourcenbedarf, entdeckt in der Produktion.

Resilienz, SLIs und SLOs

24:31 Zum Abschluss dieses Moduls das Kapitel, in dem aus Technik ein Versprechen wird. Und die Reihenfolge ist wichtig — erst absichern, dann versprechen. Verfügbarkeit ist keine Naturkonstante, sondern eine Zahl, auf die man sich einigt. Zwei Objekte schützen den Betrieb bei planbaren Eingriffen. Ein Störungsbudget legt fest, wie viele Pods eines Dienstes gleichzeitig weichen dürfen — Systemverwalter, die einen Knoten räumen, müssen also fragen und bekommen unter Umständen ein Nein.

25:01 Verteilungsvorgaben sorgen dafür, dass die Pods nicht alle auf demselben Knoten oder in derselben Zone liegen; drei Pods auf einem Knoten sind nämlich keine Redundanz, sondern nur teuer. Und der letzte Satz ist eine wichtige Einschränkung, die man verinnerlichen muss: Beides wirkt gegen geplante Eingriffe, nicht gegen Ausfälle. Dazu gleich die Tabelle.

25:21 Zwei Objekte in einer Datei, mit einem gemeinsamen Ziel. Das erste sagt: Mindestens zwei Pods müssen immer verfügbar bleiben. Das zweite verteilt über Zonen, und die Schieflage von eins bedeutet: höchstens ein Pod Unterschied zwischen den Zonen. Beachten Sie die letzte Zeile und den Hinweis darunter, denn hier liegt eine Falle: Bei strenger Vorgabe bleibt ein Pod ausstehend, wenn keine Zone ihn ohne Schieflage aufnehmen kann.

25:46 Das ist genau richtig in einem Cluster über drei Zonen — und ein selbst gebauter Stillstand in einem Cluster mit einer. Prüfen Sie also, was Ihr Cluster überhaupt hat. Diese Tabelle ist wichtiger als sie aussieht, weil sie eine verbreitete Fehlerwartung korrigiert. Zwei Zeilen mit ja, drei mit nein. Und die drei Neins sind es, die man kennen muss: Ein ausgefallener Knoten fragt nicht — das Budget hilft nicht. Ein von Hand gelöschter Pod umgeht es.

26:13 Und ein Ausrollen regelt das Deployment mit seinen eigenen Einstellungen. Der Hinweis unten fasst es in einem Satz, den ich Ihnen mitgeben möchte: Ein Budget schützt gegen Eingriffe, die fragen. Gegen Unglücke und gegen Löschen schützt es nicht. Wer mehr Sicherheit will, braucht Redundanz über Zonen — nicht ein strengeres Budget.

26:34 Jetzt die Begriffe, mit denen man über Verfügbarkeit reden kann, ohne sich zu verheddern. Ein Indikator, der SLI, ist die gemessene Größe — etwa der Anteil erfolgreicher Anfragen unter einer Sekunde. Ein Ziel, das SLO, ist der Wert, auf den man sich einigt, über einen benannten Zeitraum. Und dann kommt der Begriff, der die Betriebskultur verändert: Die Differenz zum Hundertprozentigen ist das Fehlerbudget — erlaubte Störung, die man ausgeben darf.

27:00 Beachten Sie den letzten Satz, er ist die Pointe: Alarmiert wird nicht bei Fehlern, sondern bei zu schnellem Verbrauch dieses Budgets. Fünf Schritte, und der erste ist eine Haltungsfrage: Wählen Sie den Indikator aus Sicht der Nutzung, nicht aus Sicht der Technik. Ob ein Pod läuft, interessiert niemanden — ob eine Kartenabfrage in einer Sekunde beantwortet wird, interessiert.

27:23 Schritt drei ist der pragmatische Rat, den man selten hört: Setzen Sie das Ziel unter Ihren heutigen Messwert. Ein Ziel, das Sie heute schon verletzen, ist am ersten Tag verbrannt. Schritt vier macht es greifbar — drücken Sie das Budget in Minuten aus, dann versteht es jeder. Und der Hinweis unten ist mein Lieblingssatz: Ein Ziel von hundert Prozent ist eine Absage an jede Wartung.

27:46 Der erste Punkt ist der selbst gebaute Stillstand: ein Störungsbudget ohne Spielraum blockiert jede Knotenwartung — und irgendwann räumt jemand mit Gewalt. Der zweite ist die häufigste Ursache für Ausgebranntheit in Rufbereitschaften: auf jeden einzelnen Fehler alarmieren. Nach zwei Wochen schaltet jemand die Benachrichtigungen stumm, und dann ist die Überwachung nicht nur wertlos, sondern schädlich.

28:08 Der dritte ist der Blickwinkel aus dem Vorgehen — Verfügbarkeit an der Technik statt am Erfolg der Nutzung gemessen. Und der vierte ist die Zonenfalle aus der Code-Folie: strenge Verteilungsvorgaben, wo es nur eine Zone gibt.

Was ab hier trägt

28:21 Vier Sätze aus diesem Modul. Umgebungen unterscheiden sich in Werten, nicht in kopierten Manifesten — das ist die Grundregel gegen den schleichenden Auseinanderlauf. Der Soll-Zustand liegt im Repository, und der Cluster ist die Folge, nicht die Quelle. Skaliert wird an der Ursache, und die muss vorher gemessen werden. Und ein Ziel ohne Fehlerbudget ist ein Wunsch, kein Betriebsversprechen.

28:43 Im nächsten Modul kommen wir auf die Sicherheit zurück — diesmal nicht am Image, sondern an der Plattform: Wer darf im Cluster was, wer darf mit wem sprechen, und wie hält man Mandanten auseinander?