Häiriön postmortem on lyhyt kirjallinen katsaus katkoon: mitä tapahtui, miten se vaikutti käyttäjiin, miksi se tapahtui ja mitä muutatte, jotta se ei toistu. Syyllistämätön (blameless) postmortem keskittyy järjestelmiin ja prosesseihin eikä siihen, kuka teki virheen. Peruspohjassa on kuusi osaa: yhteenveto, vaikutus, aikajana, juurisyy, mikä meni hyvin ja mikä huonosti sekä toimenpiteet vastuuhenkilöineen ja määräaikoineen.
Alta löydät, milloin postmortem kannattaa kirjoittaa, periaatteet, jotka pitävät sen hyödyllisenä, kokonaisen kopioitavan pohjan, täytetyn esimerkin ja ohjeet siihen, miten siitä tehdään asiakkaille suunnattu yhteenveto.
Milloin postmortem kirjoitetaan
Jokainen pieni häiriö ei tarvitse dokumenttia. Määritä selkeät kriteerit, jotta päätöstä ei tehdä paineen alla. Yleisiä kriteerejä:
Asiakkaat eivät voineet käyttää keskeistä toimintoa, kuten kassaa, kirjautumista tai API-rajapintaa, muutamaa minuuttia pidempään.
Tietoja katosi, vioittui tai paljastui.
Häiriö kulutti suuren osan kuukauden virhebudjetista.
Asiakkaat tai asiakasyritys ilmoittivat ongelmasta ennen valvontaa.
Samanlainen häiriö on sattunut ennenkin.
Kirjoita se muutaman arkipäivän kuluessa, kun muistikuvat ja lokit ovat vielä tuoreita. Kolme viikkoa myöhemmin kirjoitettu postmortem on lähinnä arvailua.
Syyllistämättömyyden periaatteet
Syyllistämätön postmortem olettaa, että jokainen toimi järkevästi niillä tiedoilla, jotka hänellä silloin oli. Jos yksi ihminen pystyi kaatamaan sivuston yhdellä komennolla, ongelma on se, että yksi komento pystyi kaatamaan sivuston. Syyttely saa ihmiset salaamaan yksityiskohtia, ja juuri yksityiskohtia tarvitset.
Kuvaa toimia, älä ihmisiä. ”Tuontiajo käynnistettiin ruuhka-aikaan” eikä ”Anna käynnisti tuonnin väärään aikaan”.
Kysy ”miten”, älä ”kuka”. Miten järjestelmä salli tämän? Miten saimme tietää? Miten olisimme voineet saada tietää aiemmin?
Etsi useita syitä. Häiriöillä on harvoin vain yksi juurisyy. Yleensä laukaiseva tekijä osuu heikkouteen, jota puuttuva suojamekanismi ei pysäyttänyt.
Käytä faktoja ja aikaleimoja. Valvontadata, lokit ja chat-historia voittavat muistin.
Pidä toimenpidelista lyhyenä. Kaksi tai kolme toteutettua muutosta on parempi kuin kymmenen toteuttamatonta.
Postmortem-pohja
Kopioi tämä wikiin, repositorioon tai dokumenttityökaluun. Jokaisen otsikon alla on vihje siitä, mitä kohtaan kuuluu.
# Postmortem: [lyhyt otsikko]
Häiriön päivämäärä: [VVVV-KK-PP]
Laatija(t): [nimet]
Tila: [luonnos / tarkastettavana / valmis]
Vakavuus: [esim. SEV1 / SEV2 / SEV3]
## Yhteenveto
[Kaksi tai kolme virkettä: mikä hajosi, kuinka pitkäksi aikaa ja miten se korjattiin.]
## Vaikutus
– Häiriön kohteena olleet palvelut ja komponentit:
– Kesto (alusta palautumiseen):
– Käyttäjät tai asiakkaat, joihin häiriö vaikutti:
– Liiketoimintavaikutus (tilaukset, rekisteröitymiset, SLA):
– Asiakasviestintä (tilasivu, sähköpostit, tukipyynnöt):
## Havaitseminen
– Miten häiriö havaittiin? (valvonta, asiakas, tiimin jäsen)
– Aika alusta hälytykseen:
– Aika hälytyksestä kuittaukseen:
## Aikajana
[Kaikki ajat samalla aikavyöhykkeellä. Yksi rivi tapahtumaa kohden.]
HH:MM tapahtuma
HH:MM tapahtuma
## Juurisyy ja myötävaikuttaneet tekijät
– Laukaiseva tekijä:
– Taustalla oleva syy:
– Miksi suojamekanismit eivät havainneet sitä:
## Ratkaisu
[Mitä tehtiin palvelun palauttamiseksi ja kuka sen teki (rooli, ei syyllinen).]
## Mikä meni hyvin
–
## Mikä meni huonosti
–
## Missä olimme onnekkaita
–
## Toimenpiteet
| Toimenpide | Tyyppi (estä / havaitse / reagoi) | Vastuuhenkilö | Määräaika | Tiketti |
|————|———————————–|—————|———–|———|
| | | | | |
## Yhteenveto asiakkaille
[Lyhyt versio tilasivulle tai asiakkaalle lähetettävään sähköpostiin.]
”Missä olimme onnekkaita” -osio on helppo ohittaa, mutta usein se on arvokkain. Siihen kirjataan läheltä piti -tilanteet: häiriö sattui yöllä, varmuuskopio oli ajettu tuntia aiemmin, ainoa järjestelmän tunteva henkilö sattui olemaan hereillä.
Täytetty esimerkki
Tässä pohja on sovellettu kuvitteelliseen häiriöön verkkokauppa northwind.shopissa. Yksityiskohdat on keksitty havainnollistamiseksi, mutta rakenne on juuri sellainen, jollainen oikean postmortemin pitäisi olla.
Yhteenveto
Klo 03.12–03.19 CET northwind.shopin kassa palautti virheen 503 Service Unavailable. Yöllinen tuotetuonti käytti kaikki PHP-FPM-workerit, joten kassan pyynnöt hylättiin. Päivystävä kehittäjä pysäytti tuonnin ja käynnisti PHP-FPM:n uudelleen. Katkon kokonaiskesto: 7 minuuttia.
Vaikutus
Kassa ja ostoskori olivat poissa käytöstä 7 minuuttia. Tuotesivut tarjoiltiin välimuistista, ja ne pysyivät toiminnassa.
Palvelinlokeissa näkyy tuona aikana 23 epäonnistunutta kassapyyntöä (esimerkkiluku).
Tilasivulla luki klo 03.13 alkaen ”Kassa: vakava katko”. Tukipyyntöjä ei tullut.
Aikajana
03.00 Yöllinen tuotetuonti alkaa.
03.12 Käytettävyystarkistus osoitteeseen northwind.shop/checkout palauttaa 503.
03.13 Toinen tarkistus vahvistaa virheen. Häiriö avautuu, päivystävä kehittäjä saa hälytyksen Telegramiin ja tiedot julkaistaan tiimin Slack-kanavalla. Tilasivu merkitsee kassan alhaalla olevaksi.
03.15 Päivystäjä kuittaa Slackissa ja avaa palvelimen hallintanäkymän. Muistin ja suorittimen käyttö on korkealla web-01:llä.
03.17 PHP-FPM:n tila näyttää kaikkien workerien olevan varattuina tuontipyynnöille. Tuontiajo pysäytetään.
03.18 PHP-FPM käynnistetään uudelleen.
03.19 Tarkistukset menevät taas läpi. Palautumisilmoitus lähtee, ja katkon kokonaiskestoksi kirjataan 7 minuuttia.
Juurisyy ja myötävaikuttaneet tekijät
Laukaiseva tekijä: toimittajan tuotesyöte oli kolme kertaa tavallista suurempi luettelopäivityksen jälkeen.
Taustalla oleva syy: tuonti ajetaan samassa PHP-FPM-poolissa kuin kauppa. Suuret tuonnit voivat viedä jokaisen workerin.
Puuttuva suojamekanismi: tuonnilla ei ole rajaa samanaikaisille pyynnöille, eikä workerien täyttymisestä ollut hälytystä.
Taustaa siihen, miksi loppuun käytetyt workerit näkyvät juuri tänä virheenä, löydät oppaastamme 503 Service Unavailable -virheestä.
Mikä meni hyvin, mikä huonosti ja missä oli onnea
Hyvin: havaitseminen kesti minuutin ja kuittaus kaksi. Tilasivu päivittyi ilman käsityötä.
Huonosti: syyn löytäminen kesti neljä minuuttia, koska mikään ei yhdistänyt tuontiajoa verkkopalvelimiin.
Onnea: häiriö sattui klo 03.12 eikä illan ruuhkahuipun aikana.
Toimenpiteet
ToimenpideTyyppiVastuuhenkilöMääräaikaAja tuonti erillisessä worker-poolissa, jossa on rinnakkaisuusrajaEstäBackend-vastaava2 viikon kuluessaHälytä, kun web-01:n muistinkäyttö pysyy yli 85 %:ssaHavaitseYlläpitoTällä viikollaLisää heartbeat, joka ilmoittaa tuonnin valmistumisestaHavaitseBackend-vastaavaTällä viikollaLisää valvontaan ”503 kassalla” -toimintaohjeReagoiPäivystysvuoroTällä viikolla
Asiakkaille suunnatun yhteenvedon julkaiseminen
Sisäinen postmortem on tiimiä varten. Asiakkaat tarvitsevat lyhyemmän version ilman palvelinten nimiä: mitä tapahtui, kuinka kauan se kesti, ovatko heidän tietonsa turvassa ja mitä muutatte. Julkaise se tilasivullasi ja linkitä siihen häiriösähköposteista ja asiakkaille lähetettävistä päivityksistä. Uptimecheckissä kirjoitat häiriön katsauksen suoraan häiriöön sen aikajanan viereen ja voit halutessasi näyttää sen häiriön alla tilasivullasi.
Kassa poissa käytöstä klo 03.12–03.19 CET
Klo 03.12–03.19 CET asiakkaat eivät voineet viedä ostoksia loppuun
northwind.shopissa. Tuotteiden selaaminen toimi normaalisti, eikä
tilauksia tai maksutietoja kadonnut.
Syynä oli ajastettu tuotepäivitys, joka käytti odotettua enemmän
palvelinkapasiteettia. Pysäytimme sen, ja kassa palautui klo 03.19.
Siirrämme nämä päivitykset erilliselle kapasiteetille, jotta ne eivät
voi enää vaikuttaa kassaan, ja olemme lisänneet aiemmat varoitukset
tämäntyyppisestä kuormasta.
Pidä sävy asiallisena ja lupaukset konkreettisina. ”Suhtaudumme luotettavuuteen vakavasti” ei kerro mitään; ”tuonnit ajetaan nyt erillisellä kapasiteetilla” kertoo jotain. Oppaamme tilasivun luomisesta käsittelee häiriötiedotteiden sanamuotoja tarkemmin.
On myös hyödyllistä tietää, kuinka moni huomasi häiriön. Uptimecheckin jokaiseen tilasivuun sisältyy tilasivun analytiikka, josta näet käynnit päivittäin sekä maittain, viittaavan sivun ja laitteen mukaan viimeisten 30 päivän ajalta, joten voit lisätä postmortemiin, kuinka moni tarkisti sivun häiriöpäivänä. Yhdessä häiriön aikajanan kanssa saat alun, hälytyksen, kuittauksen, palautumisen ja tavoittavuuden kaivamatta lokeja. Verkkosivuston häiriöihin tallentuu myös epäonnistunut vastaus kuvakaappauksen tai traceroutin kera, mikä on hyvä lähtökohta havaitsemista ja juurisyytä käsitteleville osioille.
Toimenpiteiden seuraaminen
Postmortem ilman toteutettuja toimenpiteitä on tarina, ei korjaus. Käsittele toimenpiteitä kuten mitä tahansa muuta työtä:
Luo jokaisesta toimenpiteestä tiketti siihen järjestelmään, jota tiimi jo käyttää, ja linkitä se postmortemista.
Anna jokaiselle yksi vastuuhenkilö ja määräaika.
Luokittele toimenpiteet tyypin mukaan: estä, havaitse tai reagoi. Jos jokainen toimenpide on ”ollaan tarkempia”, katsaus jäi kesken.
Käy avoimet postmortem-toimenpiteet läpi säännöllisessä palaverissa, esimerkiksi kahden viikon välein.
Merkitse postmortem valmiiksi vasta, kun kaikki toimenpiteet on tehty tai niistä on perustellusti luovuttu.
Ajan mittaan postmortemeista itsestään tulee dataa. Laske, kuinka moni häiriö löytyi valvonnan ja kuinka moni asiakkaiden kautta, ja seuraa havaitsemis- ja reagointiaikoja häiriöstä toiseen. Artikkelimme MTTR, MTTA ja MTBF kertoo, miten ne lasketaan.
Katsauspalaverin vetäminen
Suuremmissa häiriöissä 30–45 minuutin palaveri auttaa. Jaa luonnos etukäteen, anna häiriön hoitamista johtaneen henkilön käydä aikajana läpi ja käytä suurin osa ajasta myötävaikuttaneisiin tekijöihin ja toimenpiteisiin. Puolueeton fasilitaattori, joka ei osallistunut häiriön hoitamiseen, pitää keskustelun syyllistämättömänä ja aikataulussa. Lopuksi vahvistetaan jokaisen toimenpiteen vastuuhenkilö ja määräaika.
Saat seuraavan postmortemin aikaleimat automaattisesti. Kokeile Uptimecheckiä ilmaiseksi 14 päivää, luottokorttia ei tarvita.