Der Diagnose-Pfad, den jedes Team bekommt
Letzte Woche zwei Teams: eins rät drei Stunden, eins ist in zwanzig Minuten fertig. Der Unterschied ist kein Talent. Es ist dieser eine Pfad.
- Datum
- Thema
- Debugging
- Lesezeit
- 2 Min.
Letzte Woche habe ich zwei Teams beschrieben. Eins rät drei Stunden, eins ist in zwanzig Minuten fertig. Der Unterschied ist kein Talent. Es ist dieser eine Pfad, und hier ist er.
Abbildung als Text
Ablaufdiagramm eines Diagnose-Pfads für Mesh-Incidents in fünf Schritten: vom Festhalten des Symptoms über istioctl proxy-status, analyze und proxy-config bis zum Mapping des Envoy-Flags auf den betroffenen Hop und dem gezielten Fix. Detailkästen erklären, was der Sidecar wirklich sieht und worauf die Flags UF, NR und UO zeigen.
Schritt 0: Erst lesen, nicht handeln. Die exakte Fehlermeldung und den Envoy-Flag notieren, bevor irgendwer einen Pod neu startet. Ein Neustart, der „es wieder zum Laufen bringt“, löscht die Spur. Beim nächsten Mal steht ihr wieder am Anfang.
Schritt 1: istioctl proxy-status. Kennt die Control Plane den Pod überhaupt, und ist seine Config SYNCED? Taucht der Pod nicht auf, fehlt das Sidecar, und ihr seid beim banalen WRONG_VERSION_NUMBER von letzter Woche. Steht da STALE, hat der Proxy die neue Config nicht gezogen. Ein Verteilungsproblem, kein Config-Fehler.
Schritt 2: istioctl analyze. Die statische Prüfung fängt in Sekunden, was man sonst stundenlang sucht: vergessenes Injection-Label, ein VirtualService, der ins Leere zeigt, zwei Regeln, die sich gegenseitig überschreiben.
Schritt 3: istioctl proxy-config. Jetzt schaut ihr, was der Sidecar wirklich sieht, nicht was im YAML steht. cluster und endpoints: gibt es hinter dem Ziel überhaupt gesunde Adressen. route: trifft die Route dahin, wo ihr sie vermutet. secret: sind die mTLS-Zertifikate ausgerollt.
Schritt 4: Zurück zum Flag. Jetzt zeigt er auf den Hop. UF führt euch zu endpoints und mTLS. NR zur Route. UO zur DestinationRule und ihren Limits. Der Flag war von Anfang an die halbe Diagnose. Jetzt ist er die ganze.
Schritt 5: Fix, dann mit demselben Pfad gegenprüfen. proxy-status wieder SYNCED, Flag weg.
Fünf Schritte, immer dieselben, in jedem Incident. Ein Team mit diesem Pfad ist nicht mehr davon abhängig, dass zufällig die richtige Person Schicht hat. Den Pfad anzuwenden, kann jeder lernen. Zu wissen, welche fünf Schritte es sind und was der Flag im konkreten Mesh bedeutet, ist die Erfahrung dahinter.
Ein Runbook ist unspektakulär. Genau deshalb trägt es um drei Uhr nachts, wenn niemand Lust auf Heldentum hat.
Genau dieses Runbook baue ich mit Teams in Assessments, aus den Incidents, die sie schon hatten. Die Methode bleibt im Team. Die Erfahrung, die entscheidet, welche Schritte es sind, bringe ich mit.
Welche Fehlermeldung hat euch zuletzt am längsten aufgehalten? Schreibt sie in die Kommentare, ich ordne den Flag ein.
