De meeste observatiestapels zijn uitstekend in het beantwoorden van één vraag: wat is er gebeurd?
Ze zijn zwakker bij de volgende vraag: waar kunnen we het oplossen?
In die kloof vertraagt de reactie op incidenten. Het team ziet het foutenpercentage, opent de trace, leest de logs, controleert de implementatietijdlijn en moet vervolgens nog handmatig de codebase doorzoeken.
Een bekend voorval
Stel je voor dat een API na een implementatie intermitterende 500's begint terug te sturen. Het dashboard toont de piek. De traceerpunten bij de kassaservice. De logboeken bevatten een validatiefout, maar het bericht is algemeen.
Op dat moment heeft het team geen andere kaart nodig. Het heeft richting nodig:
- de opslagplaats die eigenaar is van het afrekenen
- de handler die is aangesloten op de falende route
- de recente commit die het validatiegedrag veranderde
- de persoon of het team dat de oplossing moet beoordelen
Dat is codecontext.
Waarom codecontext ertoe doet
Waarneembaarheid zonder codecontext creëert bewustzijn. Waarneembaarheid met codecontext creëert een pad voor reparatie.
Het verschil is klein maar operationeel belangrijk. Een tracering kan u vertellen dat een verzoek is mislukt POST/afrekenen. Codecontext kan verwijzen naar de validatietak, het bestand dat gisteren is gewijzigd en de eigenaar die dat gebied gewoonlijk beoordeelt.
Dat in kaart brengen scheelt het eerste uur van veel incidenten.
De minimaal bruikbare context
U hoeft niet het hele onderzoek aan een pull request te koppelen. Een recensent heeft meestal een compacte set feiten nodig:
- productie symptoom
- betrokken dienst
- waarschijnlijk bestand of functie
- recente implementatie of codewijziging
- eigenaar of recensent
- volgende actie voorgesteld
Al het andere zou deze feiten moeten ondersteunen en niet begraven.
Waar dashboards stoppen
Dashboards zijn bedoeld om systeemgedrag te zien. Pull-verzoeken zijn bedoeld om systeemgedrag te veranderen. Een gezonde herstelworkflow verbindt deze werelden, in plaats van dat ingenieurs ze elke keer opnieuw handmatig moeten overbruggen.
Als het signaal de code niet kan vinden, wordt de waarschuwing een ander wachtrij-item. Als het signaal de code kan vinden, kan het team beslissen of het gaat patchen, terugdraaien, een backlog-item openen of dieper onderzoek doen.
Waar naartoe te bouwen
Het praktische doel is niet een groter waarneembaar oppervlak. Het is een korter pad:
productiesignaal -> codecontext -> beoordeelbare actie
Deze actie kan een pull-verzoek zijn. Het kan een Jira-probleem zijn. Het kan een opmerking zijn dat het probleem bij een upstream-provider hoort. Het punt is dat het team niet elke keer dat de productie spreekt, met een blanco onderzoek hoeft te beginnen.
Waarneembaarheid toont het falen aan. Codecontext geeft de mislukking een plek om naartoe te gaan.
