Het diagnosepad dat elk team krijgt

Vorige week beschreef ik twee teams. Het ene gokt drie uur lang, het andere is in twintig minuten klaar. Het verschil is geen talent. Het is dit ene pad, en hier is het.

Stap 0: eerst lezen, niet handelen. Noteer de exacte foutmelding en de Envoy-flag voordat iemand een pod herstart. Een restart die “het weer aan de praat krijgt” wist het spoor. De volgende keer staan jullie weer aan het begin.

Stap 1: istioctl proxy-status. Kent de Control Plane de pod überhaupt, en is zijn config SYNCED? Duikt de pod niet op, dan ontbreekt de sidecar en zitten jullie bij de banale WRONG_VERSION_NUMBER van vorige week. Staat er STALE, dan heeft de proxy de nieuwe config niet opgehaald. Een distributieprobleem, geen config-fout.

Stap 2: istioctl analyze. De statische check vangt in seconden af wat je anders urenlang zoekt: een vergeten injection-label, een VirtualService die nergens naartoe wijst, twee regels die elkaar overschrijven.

Stap 3: istioctl proxy-config. Nu kijken jullie naar wat de sidecar echt ziet, niet naar wat er in de YAML staat. cluster en endpoints: zijn er achter het doel wel gezonde adressen. route: komt de route uit waar jullie denken dat hij uitkomt. secret: zijn de mTLS-certificaten uitgerold.

Stap 4: terug naar de flag. Nu wijst hij naar de hop. UF leidt jullie naar endpoints en mTLS. NR naar de route. UO naar de DestinationRule en zijn limits. De flag was vanaf het begin de halve diagnose. Nu is hij de hele.

Stap 5: fix, daarna verifieer je met hetzelfde pad. proxy-status weer SYNCED, flag weg.

Vijf stappen, altijd dezelfde, bij elk incident. Een team met dit pad is er niet meer van afhankelijk of toevallig de juiste persoon dienst heeft. Het pad toepassen kan iedereen leren. Weten welke vijf stappen het zijn en wat de flag in het concrete mesh betekent, dat is de ervaring erachter.

Een runbook is onspectaculair. Juist daarom houdt het je overeind om drie uur ‘s nachts, wanneer niemand zin heeft in heldendom.

Precies dit runbook bouw ik met teams in assessments, op basis van de incidents die ze al hebben gehad. De methode blijft in het team. De ervaring die bepaalt welke stappen het zijn, breng ik mee.

Welke foutmelding heeft jullie laatst het langst opgehouden? Zet hem in de comments, dan vertel ik welke flag erbij hoort.