Ga naar inhoud

Post-mortems

Een post-mortem is een schriftelijke review van een incident. Het doel is uitzoeken wat er gebeurde, waarom het mogelijk was en wat er verandert zodat het niet opnieuw gebeurt. Het is geen zoektocht naar iemand die de schuld krijgt.

Schrijf er een voor elk incident met severity 1, elk major incident (Incidentmanagement) en voor elk ander incident waarvan het team iets heeft geleerd dat het waard is om te delen. Een redelijk doel is een concept binnen vijf werkdagen. Deel het met de getroffen klant of workload teams. In het managed model schrijft het platformteam (XMMS) het en beoordeelt de klant het. In het zelfbeheermodel schrijft je eigen platformteam het voor zijn stakeholders.

Principes

  • Blameless. Beschrijf wat mensen op dat moment wisten en besloten. Vraag wat in het proces of de tooling de fout mogelijk maakte.
  • Eerst de feiten. Een tijdlijn met tijdstempels vóór conclusies. Gebruik één tijdzone en zeg welke.
  • Oorzaak en bijdragende factoren. Er is zelden één oorzaak. Benoem de trigger en de omstandigheden die het mogelijk maakten of verergerden.
  • Acties hebben een eigenaar en een datum. Een actie zonder eigenaar gebeurt niet. Volg de acties in dezelfde backlog als ander platformwerk, en bespreek ze in het operationele overleg.
  • Houd klantidentificerende gegevens uit de gedeelde versie (namen van personen, ID's, interne links). Gebruik rollen en resourcetypen.

Impactschaal

Gebruik een vaste schaal zodat rapporten vergelijkbaar zijn. Een voorbeeld:

Impact Betekenis
Kritiek Geen werkende verbinding of service voor productie. Meerdere applicaties onbruikbaar
Ernstig / Hoog Een productieapplicatie of -service is onbruikbaar, of een resource is vernietigd of heeft data verloren
Gemiddeld Korte onderbrekingen die in logs zichtbaar waren, maar geen klachten van gebruikers
Laag Geen zichtbare impact. Bijna-ongeval

Template

Kopieer dit naar een nieuwe pagina, één pagina per incident. Noem hem <date> | <short description>.

# <date> | <short description>

## Summary
Two to five sentences: what happened, what was the impact, how it was fixed.

## Impact
Level (see the impact scale), who was affected, for how long.

## Timeline
All times in <time zone>.

| Time | What happened | Who |
|---|---|---|
| hh:mm | Incident reported / detected | reporter / monitoring |
| hh:mm | ... | ... |
| hh:mm | Service restored | ... |

## Root cause
The trigger, and why the platform or the process allowed it. If the cause is not
confirmed, say so and say what is assumed.

## What went well
What worked and should be kept.

## Learnings
What the team would do differently, and what it did not know.

## Actions
| Action | Owner | Due | Status |
|---|---|---|---|
| ... | ... | ... | Open / Done |

Voorbeeldlessen

De onderstaande lessen zijn gegeneraliseerd uit post-mortems van echte incidenten op managed platformen. Ze zijn voorbeelden van het formaat en van het soort les dat het waard is om op te schrijven. De details, inclusief namen en getallen, zijn verwijderd.

Een WAF-instelling veroorzaakte 403-fouten op productieapplicaties
Impact Ernstig: meerdere productieapplicaties waren onbereikbaar achter de Application Gateway
Trigger Twee dagen eerder was een WAF-instelling (inspectie van de request body) ingeschakeld, omdat een documentatiereview vroeg waarom die uit stond en inschakelen een voor de hand liggende hardening leek. Het is niet getest en er is geen wijzigingsrecord gemaakt
Detectie Een gebruiker meldde 403 Forbidden. De WAF-logs toonden matchende regels
Oplossing De matchende regels zijn tijdelijk uitgeschakeld. Daarna is de instelling uitgezet en zijn de regels weer ingeschakeld. Ongeveer drie uur van melding tot oplossing
Bijdragende factoren Geen testomgeving voor WAF-wijzigingen. De klant was niet op de hoogte gebracht van de wijziging. Het incident werd eerst behandeld als serviceaanvraag en niet als P1, hoewel applicaties down waren

Lessen:

  • Test WAF- en firewallwijzigingen eerst op de canary-platformomgeving, met realistische verkeerspatronen, vóór prod. Zie Application Gateway en Wijzigingsworkflow.
  • Elke wijziging aan het platform heeft een wijzigingsrecord, ook een "kleine" instelling. Onaangekondigde wijzigingen maken incidenten moeilijker te diagnosticeren.
  • Registreer een incident met productie-impact als P1, wat de eerste melding ook zegt.

Een grote firewallwijziging liep tegen de apply-time-out aan, en de oplossing maakte het erger
Impact Gemiddeld: korte verkeersonderbrekingen zichtbaar in firewall-logs, geen klachten van gebruikers. Tegelijk werd een tweede, niet-gerelateerde storing gemeld
Trigger Een productiewijziging die in één deployment 16 firewall rule collections toevoegde en 8 vernietigde
Wat er gebeurde De canary-run had al de Terraform-time-out geraakt. Het team ging toch door op prod. Azure accepteert geen gelijktijdige updates van meerdere regelsets, dus de updates kwamen in de wachtrij en de apply werd door de time-out afgebroken. Sommige collections waren in Azure aangemaakt maar ontbraken in de state. Opnieuw draaien faalde met "already exists". Om de resterende regels snel erin te krijgen, vernietigde en herschiep het team bestaande collections
Bijdragende factoren De 8 destroys liepen eerst, dus het verkeer zat al zonder regels terwijl de toevoegingen opnieuw werden geprobeerd. Een ontbrekend private DNS-record veroorzaakte tegelijk 502-fouten, waardoor het incident groter leek dan de firewallwijziging

Lessen:

  • Een time-out op canary is een stopsignaal. Maak ongedaan, splits de wijziging in kleinere pull requests en deploy die één voor één.
  • Wordt een regel vervangen door een nieuwe, deploy dan eerst de nieuwe regel en verwijder de oude in een latere wijziging.
  • Bij "already exists"-fouten: importeer de resource in de state (terraform import). Vernietig geen productieresources om de state te laten kloppen. Lees eerst het plan (Firewallregels).
  • Vertel de klant vóór de wijziging dat korte onderbrekingen mogelijk zijn, en geef updates tijdens de deployment.
  • Controleer of twee symptomen echt dezelfde oorzaak hebben (Incidentmanagement).

Een site-to-site VPN-verbinding toonde connected maar liet geen verkeer door
Impact Kritiek: geen werkende verbinding tussen productieworkloads on-premises en in Azure
Trigger Onbekend. Logs aan de Azure-kant toonden niets. De status van de verbinding was connected
Oplossing Een major incident-call met de on-premises netwerkpartner. De verbinding is aan beide kanten gereset (de link bewerken en opslaan zonder wijzigingen). De eerste reset hielp niet; een tweede aan de Azure-kant herstelde het verkeer een paar minuten later
Oorzaak Niet bevestigd. Verondersteld een korte verstoring aan één kant die het verkeer onderbrak en de tunnel niet goed herstartte

Lessen:

  • Draai waar mogelijk twee verbindingen, zodat één storing geen uitval is.
  • Alert op verkeer dat stroomt, niet alleen op een statuswijziging. Voeg dit toe aan je monitoringregels.
  • Bepaal vooraf wie welke kant mag resetten, en in welke volgorde.

Meer lessen, in het kort

  • Naamgeving die de omgeving twee keer bevat leidt tot verkeerde verwijderingen. Op een managed platform was een configuratieset genoemd naar een omgeving, waardoor de VM die ze aanmaakte die omgeving twee keer in de naam had. De verkeerde set werd verwijderd en een datadisk werd vernietigd. Houd omgevingsnamen uit namen van configuratiesets, vergelijk het plan met de werkelijke resources voordat je een destroy toepast, en vraag de eigenaar de exacte resource te bevestigen voordat je verwijdert. Vierogenreview werkt alleen als de tweede persoon de werkelijke resources controleert, niet alleen de code.
  • Een destroy die halverwege mislukte laat een half opgebouwde resource achter. Als een destroy mislukt, bijvoorbeeld omdat een VM was gestopt en de extensions niet konden worden verwijderd, controleer dan wat er nog is en wat de nieuwe run opnieuw aanmaakt. Een opnieuw aangemaakte datadisk is leeg en niet gekoppeld.
  • Problemen die weken later worden gevonden zijn duur. Controleer het resultaat van een fix tegen de echte service (mounts, data, verkeer), niet alleen tegen een groene pipeline.