De engste foutmelding heeft meestal de banaalste oorzaak

De meeste mesh-incidents die ik zie zijn niet moeilijk. Ze zien er alleen zo uit.

Een voorbeeld dat bijna iedereen kent die Istio draait. Een service kan plotseling een andere niet meer bereiken. In de log van de sidecar staat dit:

“upstream connect error … WRONG_VERSION_NUMBER”

Wie dit voor het eerst ziet, denkt aan kapotte certificaten, aan een TLS-misconfiguratie, aan iets diep in de encryptie-stack. Teams verliezen er uren mee.

De oorzaak is bijna altijd banaal: de doel-pod heeft geen sidecar. Het namespace-label voor de injection is vergeten. De caller praat mTLS, het doel antwoordt plain HTTP, en de eerste byte ziet er voor de proxy uit als een ongeldige TLS-versie. Angstaanjagende melding, doodsimpele oorzaak.

Hetzelfde patroon bij 503’s. De status alleen zegt niets. Maar Envoy schrijft er een flag bij, en die flag is de halve diagnose. UF betekent upstream-verbinding mislukt, vaak een ontbrekende sidecar of mTLS-mismatch. NR betekent geen route, Gateway of VirtualService wijst nergens heen. UO betekent dat de circuit breaker is dichtgegaan. Drie letters, drie totaal verschillende problemen.

Het eigenlijke punt is niet de losse foutmelding. Het is het verschil tussen twee teams.

Het ene team gokt. Het herstart pods, sleutelt aan configs, opent tickets, en hoopt. Drie uur later draait alles weer, niemand weet precies waarom.

Het andere team heeft een vast pad. Symptoom, dan proxy-status: kent de mesh de pod überhaupt. Dan analyze en proxy-config: wat ziet de sidecar echt. Dan de Envoy-flag: op welke hop sterft de request. Twintig minuten, duidelijke oorzaak, gerichte fix.

Het verschil is geen talent. Het is methode. En methode is iets dat je als organisatie kunt invoeren, lang voordat het volgende incident komt.

Wie in de mesh regelmatig blind zit te debuggen, heeft geen personeelsprobleem. Die heeft een ontbrekend runbook.

Volgende week: het diagnosepad als concrete stap-voor-stap-sequentie die je het hele team in handen kunt geven.