Om 02:10 uur wordt een melding geactiveerd. Een engineer voert een configuratiewijziging door, de checkout-service begint fouten te geven en de dienstdoende teamleider draait de wijziging 40 minuten later terug. Tijdens de evaluatievergadering is de eerste vraag: "Wie heeft de wijziging doorgevoerd?" Binnen enkele minuten gaat het gesprek over het oordeel van één persoon om 2 uur 's nachts, en niemand vraagt zich af waarom de wijziging zonder een canary-test de productieomgeving heeft kunnen bereiken, waarom het zo lang duurde voordat de melding werd verzonden, of waarom het runbook verouderd was.
Dit is een illustratief scenario, geen klantcase. Het is herkenbaar omdat het daadwerkelijk voorkomt: een incidentanalyse die zich concentreert op de laatste persoon die actie ondernam, levert een keurig verhaal op, maar leidt tot weinig leerpunten.
Deze handleiding is bedoeld voor engineeringmanagers en enablement leads die willen dat mensen beter worden in het analyseren van incidentbewijs en het overeenkomen van verbeteringen die getest kunnen worden. De handleiding behandelt hoe je vaardigheidstekorten kunt onderscheiden van de omstandigheden eromheen, hoe je werkwijzen kunt ontwerpen, hoe je evaluaties kunt nabespreken en hoe je kunt meten of de evaluaties effectief zijn.
Wat "onberispelijk" wel en niet betekent
Het boek Site Reliability Engineering van Google stelt het duidelijk: om een postmortemonderzoek werkelijk objectief te laten zijn, moet het zich richten op het identificeren van de oorzaken van het incident, zonder een individu of team te beschuldigen van slecht of ongepast gedrag. Het beschrijft ook de onderliggende aanname: iedereen die erbij betrokken was, handelde met goede bedoelingen en deed het juiste met de informatie waarover ze beschikten.Google SRE-boek, "Postmortemcultuur: leren van mislukkingen".)
Onschuldig betekent niet dat er geen consequenties zijn. In hetzelfde hoofdstuk wordt verwacht dat analyses achteraf resulteren in concrete actiepunten met een prioriteit en een verantwoordelijke. Een onschuldig onderzoek vereist nog steeds verantwoording, maar die verantwoording verschuift van "wie heeft dit veroorzaakt?" naar "wie gaat het systeem veiliger maken, en wanneer?". Als je bij evaluaties het tweede deel overslaat, heb je een prettig gesprek, maar geen leerproces.
1. Identificeer het gedrag en de context ervan.
Begin met het specifieke gedrag dat je wilt veranderen. "Onze incidentanalyses richten zich op de laatste persoon die actie ondernam" is observeerbaar. "Onze cultuur is erg gericht op het aanwijzen van schuldigen" is dat niet.
Vraag je dan af of het überhaupt een vaardigheidsprobleem is. Training kan slechts een deel van de oorzaken van slechte prestaties verhelpen. Voordat je iets bouwt, moet je drie mogelijke oorzaken uitsluiten:
- Een ontbrekende vaardigheid. Beoordelaars weten niet hoe ze een tijdlijn moeten opstellen, een aanleiding moeten onderscheiden van een bijdragende factor, of zich moeten afvragen: "Waarom leek deze actie destijds redelijk?"
- Stimulansen. Recensies spelen een rol in gesprekken over prestaties, dus mensen passen hun accounts aan om zichzelf te beschermen.
- Autoriteitsgraden en eerdere reacties. Een junior engineer die in het vorige kwartaal een probleem aankaartte en te horen kreeg dat hij moest stoppen met negatief te zijn, zal in deze vergadering geen probleem meer aankaarten, hoe goed hij ook is opgeleid.
Alleen het eerste is een trainingsprobleem. De andere twee zijn omstandigheden. Als je de vaardigheid traint en de omstandigheden ongemoeid laat, zullen mensen iets herhalen wat op de werkplek wordt afgestraft. Beschouw je huidige visie op de oorzaak als een hypothese en toets deze door met een paar gesprekken met ingenieurs te praten en recente evaluatiedocumenten te bekijken voordat je je vastlegt op een programma.
2. Stel de operationele voorwaarden voor de oefening vast
Oefening baart alleen kunst als de werkomgeving er positief op reageert. Voordat iemand gaat oefenen, moet je dit afstemmen met degenen die de evaluaties uitvoeren:
- Goedgekeurde verantwoordelijkheden. Wie begeleidt de sessie, wie stelt de planning op en wie is verantwoordelijk voor de vervolgacties? Maak de rollen expliciet, zodat een facilitator niet zomaar de leiding hoeft te nemen.
- Hoe leiders omgaan met zorgen. Als een engineer zegt: "Met de implementatietool kon ik de canary-test overslaan", wat doet de directeur dan? Bepaal het antwoord van tevoren, bijvoorbeeld: bedank de engineer, noteer het als een bijdragende factor en wijs een actie toe.
- Het antwoord van de leidinggevende. Bij het oefenen met het personeel is een passende reactie van de leidinggevende nodig. Als je ingenieurs traint om zich uit te spreken tijdens beoordelingen, maar hun managers vragen vervolgens nog steeds "wiens schuld was het?", dan heeft de training geen effect.
Een korte toelichting voor managers over het beoordelingsproces is net zo belangrijk als de training voor de deelnemers. Neem een duidelijke verklaring op over hoe beoordelingsdocumenten wel en niet worden gebruikt bij prestatiebeheer.
3. Ontwerp een op gedrag gebaseerd leertraject
De richtlijnen van het Carnegie Mellon Eberly Center met betrekking tot leerdoelen benadrukken terecht dat doelstellingen, beoordelingen en onderwijsstrategieën op elkaar moeten aansluiten.Eberly Center, LeerdoelenDat is ontwerprichtlijn, geen bewijs over een specifiek instrument of resultaat, maar het is een goede test voor dit programma: als het doel is om bewijs te analyseren en toetsbare verbeteringen vast te stellen, dan kunnen vragen over het geheugen alleen niet volstaan voor de beoordeling.
De taxonomie van Bloom is hier nuttig om de cognitieve eisen van de taak te beschrijven: analyseren, evalueren, creëren. Het beschrijft wat de taak van een persoon vraagt. Het verklaart niet waarom ze het wel of niet doen, dus gebruik het niet om motivatie te diagnosticeren.
Een haalbaar traject bestaat uit drie fasen.
| Stadium | Actie van de leerling | Verzending |
|---|---|---|
| Voorbereiding | Lees uw beleid voor incidentevaluatie en een korte verklarende woordenlijst (aanleiding, oorzakelijke factor, beperking, actiepunt). Een korte diagnostische controle controleert de vereisten. | Zelfstudie in eigen tempo. Een toets bevestigt alleen de voorkennis, niet de herhaling van vaardigheden. |
| Praktijk | Analyseer een voorbereide incidentcasus en bepaal toetsbare verbeteringen. Een onderbouwd antwoord is vereist, geen meerkeuzevraag. | Interactieve of begeleide casusbespreking, met feedback op de kwaliteit van de analyse van de bijdragende factoren en de opvolging. |
| Beoordeling en overdracht | Bespreek een ambigue keuze en voltooi vervolgens een nieuwe casus of een begeleide praktijkbeoordeling. | Live coaching of asynchroon nakijken. Controleer de overdracht van de vaardigheden nadat mensen de tijd hebben gehad om ze op hun werk toe te passen. |
Houd de casus realistisch en laat deze valideren door een ervaren ingenieur. Een technisch onjuiste casus zorgt ervoor dat beoordelaars de oefening niet vertrouwen.
4. Doorloop het scenario en bespreek het na.
Hieronder ziet u hoe een oefensessie met het scenario van 02:10 eruit zou kunnen zien. Het bewijsmateriaal bevat het implementatielogboek, de tijdlijn van de waarschuwingen, het pagingbeleid, de pull request en het runbook, allemaal fictief.
Vraag aan de deelnemer. "Leg uit waarom de ingenieur de wijziging op dat moment heeft doorgevoerd. Vermeld het bewijsmateriaal dat u hebt gebruikt. Vertel ons welke aanvullende informatie of ondersteuning u nodig hebt voordat u hierover zekerheid kunt hebben."
Een zwak antwoord klinkt als volgt: "De ingenieur had de opstelling moeten controleren." Het noemt een persoon, geeft geen bronvermelding en stelt geen verandering voor.
Een krachtiger antwoord zou er als volgt uitzien: "Het implementatielogboek laat zien dat de wijziging direct is doorgevoerd omdat de canary-stap optioneel is in de tool. De pull request had één reviewer die deze na een tijdsvenster van 20 minuten goedkeurde. De pagina werd 18 minuten nadat de fouten begonnen te verschijnen, geladen omdat de waarschuwingsdrempel was ingesteld op een gemiddelde van vijf minuten. Ik zou graag willen weten hoeveel andere wijzigingen deze maand de canary-stap hebben overgeslagen en of de dienstdoende engineers ooit te horen hebben gekregen dat de stap overgeslagen kan worden. Voorgestelde acties: maak de canary-stap verplicht voor deze servicelaag, verantwoordelijke: platformteam, controle: probeer een implementatie zonder canary-stap in de stagingomgeving en bevestig dat deze wordt geblokkeerd; verlaag de waarschuwingsperiode, verantwoordelijke: teamleider dienstdoende, controle: speel de fouten van vorige week opnieuw af tegen de nieuwe drempel."
Merk op wat het beter maakt. Het maakt gebruik van bewijsmateriaal, benoemt beperkingen en onzekerheden, en eindigt met acties die getest kunnen worden.
Nu de nabespreking. Geef niet alleen een score. Stel vragen:
- Wat ondersteunde het bewijsmateriaal, en welke aannames had u?
- Welke van uw acties zou het team daadwerkelijk mogen uitvoeren?
- Wat zou het makkelijker maken om dit gedrag te herhalen tijdens je volgende echte beoordeling? Wat zou het juist moeilijker maken?
De derde vraag is het belangrijkst. Deze brengt de voorwaarden uit paragraaf 2 aan het licht. Als drie deelnemers zeggen: "Mijn manager zal vragen wie het gedaan heeft", dan heb je een belemmering gevonden die niet door training kan worden weggenomen.
5. Meet het gedrag en de opvolging.
De kernvraag is welk bewijs aantoont dat leerlingen incidentgegevens kunnen analyseren en tot toetsbare verbeteringen kunnen komen. Hier is een voorbeeld van een beoordelingsschema. Het is een voorstel om aan te passen in overleg met een ervaren ingenieur, geen gevalideerde standaard voor paraatheid.
| Criterium | Observeerbaar bewijs | 0 | 1 | 2 |
|---|---|---|---|---|
| Taakuitvoering | Analyseert het bewijsmateriaal en stemt verbeteringen in; legt de actie en het achterliggende bewijsmateriaal vast. | Afwezig of niet ondersteund | Gedeeltelijk, met relevante weglatingen | Volledig en onderbouwd aan de hand van overeengekomen criteria. |
| Redenering | Het verklaart beperkingen, alternatieven en onzekerheid; de factoren die hieraan bijdragen gaan verder dan de laatste actie. | Afwezig of niet ondersteund | Gedeeltelijk, met relevante weglatingen | Volledig en onderbouwd |
| Grenzen | Volgt goedgekeurde procedures; vraagt om hulp wanneer informatie of bevoegdheid ontbreekt. | Afwezig of niet ondersteund | Gedeeltelijk, met relevante weglatingen | Volledig en onderbouwd |
Definieer kritieke fouten afzonderlijk, bijvoorbeeld door een persoon als oorzaak aan te wijzen of een actie voor te stellen zonder verantwoordelijke. Een hoge totaalscore mag nooit een kritieke fout verbergen.
Voor de meting zelf:
- Kwaliteit van de bijdragende factoranalyse. Vergelijk beoordelingen die vóór het programma zijn geschreven met beoordelingen die erna zijn geschreven, beoordeeld aan de hand van dezelfde criteria door iemand die niet weet welke beoordeling bij welk programma hoort. Gebruik zowel onbekende vervolgcases als echte cases.
- Doorzetten. Tel het aandeel van de actiepunten die een eigenaar hebben, een test hebben ondergaan en zijn voltooid, van alle ingediende actiepunten. Vermeld de noemer en het tijdsvenster.
- Koppel observaties aan proceswijzigingen. Woon een echte evaluatie bij. Controleer wat er daarna met de actiepunten is gebeurd.
Wees voorzichtig met het rapporteren van het aantal meldingen. Als er na het programma meer meldingen van incidenten en bijna-incidenten binnenkomen, kan dat betekenen dat de veiligheid is verbeterd, het vertrouwen is toegenomen of dat een nieuwe tool het registreren heeft vereenvoudigd. Een valpartij kan betekenen dat er minder problemen zijn of dat er minder bereidheid is om erover te praten. Kijk naar wat er in dezelfde periode is veranderd voordat u een verandering toeschrijft aan de training, en vermijd het claimen van een effectgrootte die u niet hebt gemeten.
De bovenstaande richtlijnen van Eberly richten zich op afstemming; ze bewijzen niet dat deze aanpak het aantal incidenten vermindert. Houd uw eigen basisgegevens en vervolggegevens bij en beschouw deze als lokaal bewijsmateriaal.
Welke beperkingen kunnen blijven bestaan, zelfs nadat de vaardigheden zijn verbeterd?
Wees hierover eerlijk tegenover sponsors:
- Beoordelingsdocumenten kunnen nog steeds meewegen bij prestatiebeslissingen.
- Teams die onder tijdsdruk staan, slaan soms acties over die weliswaar kostbaar, maar wel verstandig zijn.
- Samenwerking tussen teams kan vastlopen omdat niemand de grenslijn beheerst.
- Senior ingenieurs zullen de discussie wellicht nog steeds domineren.
Betere analyses lossen deze problemen niet op. Plan hiervoor aparte proceswijzigingen.
Het in de praktijk brengen met AhaSlides
AhaSlides Het ondersteunt adaptief leren, interactief leren en de afwisseling tussen live en zelfgestuurd leren. Dit proces kan bijvoorbeeld bestaan uit een zelfgestuurde voorbereidingsstap, een live of begeleide casussessie met open vragen zodat iedereen zich inzet voor een analyse voordat de groep de casus bespreekt, en een vervolgopdracht na de sessie. Specifieke functies voor het opstellen, scoren en rapporteren moeten worden getest aan de hand van een eigen casus voordat u ze gebruikt. Alles wat te maken heeft met AI, simulators of integraties met uw incidenttools moet als extern worden beschouwd totdat het is aangetoond.
Volgende stap: Neem de bovenstaande beoordelingscriteria en pas deze aan met een van uw senior engineers. Bouw vervolgens de casus op die u hiervoor zult gebruiken.
Zodra je de casus en de beoordelingscriteria hebt opgesteld, kun je onderzoeken hoe een live en zelfstandige versie van dit traject zou kunnen werken. AhaSlides.
