Posztmortemek, Amelyek Tényleg Változtatnak

Egy posztmortemet könnyű összehívni, és nehéz hasznossá tenni. Megvan az értekezlet, elkészül a dokumentum, rögzítenek négy feladatot, majd hat hónappal később ugyanaz a hiba újra bekövetkezik, miközben valaki éppen mást keresve akad rá a régi dokumentumra.

A hibáztatásmentesség kapja a legtöbb figyelmet, amikor erről esik szó, és tényleg fontos is, de nem ott van a hiba. Rengeteg szervezet vezet szigorúan hibáztatásmentes elemzéseket, amelyek semmit nem változtatnak, mert magát az elemzést tekintették eredménynek, nem pedig annak, ami eredményt termel.

A teszt, ami megmutatja, hogy a tiétek működik-e, kínosan egyszerű: az elmúlt hat hónap feladatainak hány százaléka készült el? Ha a válasz az, hogy a legtöbb, akkor a folyamat működik, bárhogy is néz ki. Ha a fele alatt van, akkor értekezleteket tartotok, nem folyamatot működtettek, és ezen a jobb sablonok nem segítenek. Kevesebb feladat, felelőssel és határidővel, többet ér egy alapos listánál, amire senkinek nincs ideje.

Mire való valójában a posztmortem

Nem arra, hogy elmagyarázza, mi történt. A résztvevők az incidens végére ezt jellemzően már úgyis tudják.

Azért van, hogy megtaláljuk azokat a körülményeket, amelyek engedték, hogy egy kis baj naggyá váljon, és hogy néhányat közülük megváltoztassunk. Ez más kérdés, mint az, hogy mi romlott el, és a különbség azonnal látszik a leíráson. “Az adatbázisnak elfogytak a kapcsolatai” azt mondja meg, mi romlott el. “Semmi nem riasztott a kapcsolatkészlet telítődésére, és az a műszerfal, amelyik megmutatta volna, nincs benne a készenléti runbookban” egy körülményt ír le, és ezzel már lehet kezdeni valamit.

A második dolog, amit létrehoz, és amit rendszeresen alulértékelnek, az esemény közös elbeszélése. Enélkül mindenki megtartja a saját változatát, és ezek a változatok abba az irányba sodródnak, amit az illető eleve hitt a rendszerről. Egy évvel később két csapat vitatkozik egy olyan incidensen, amit együtt éltek meg.

A hibáztatásmentesség konkrét dolgot jelent

Nem azt jelenti, hogy senki nem hibázott. Azt jelenti, hogy az elemzés abból indul ki, hogy valaki az elérhető információk alapján ésszerűen járt el, és olyan lépést tett, ami utólag rossznak bizonyult, majd megkérdezi, miért tűnt az a lépés akkor helyesnek. A Google SRE-könyve részletesen leírja ezt a gyakorlatot és a vele járó hibamintázatokat.

Ez azért nem puszta kedvesség, mert a hibáztatás információt semmisít meg. Egy olyan szervezetben, ahol az incidensek személyekhez tapadnak, az emberek óvatosan írják le az eseményeket, kihagyják azt a részletet, ami rosszul fest, és addig halasztják a bejelentést, amíg biztonságosan elő nem tudják adni. Az elemzés ezután egy önvédelemből átszerkesztett beszámolóból dolgozik, ami a lehető legrosszabb kiindulópont.

A gyakorlatban a hibáztatásmentesség a nyelv tulajdonsága. A “Miért indítottad újra a szolgáltatást?” védekezésre hív. A “Mit mutatott a műszerfal, amikor az újraindítás mellett döntöttél?” információra hív. A második kérdés egyben hasznosabb is, mert a válasz a monitorozásotokról szóló tény, nem pedig egy kollégáról.

Ha valódi teljesítményprobléma áll fenn, kezeljétek külön és közvetlenül. Az incidenselemzésen belül elintézve elrontja az elemzést, és amúgy is rossz módja annak a beszélgetésnek.

Olyan idővonal, amiből tanulni lehet

Az idővonal a dokumentum legértékesebb része, és egyben az, amit a leggyakrabban rosszul írnak meg: technikai események sorozataként, amiből az embereket kivették.

Rögzítsétek, ki mit tudott és mikor. Ne csak azt, hogy “a szolgáltatást 14:32-kor újraindították”, hanem azt is, mit láthatott az illető 14:32-kor, és mit gondolt arról, mi történik. Itt van a valóban felhasználható anyag, mert egy tizenöt perces késés, amit egy félreérthető műszerfal okozott, javítható probléma, egy hézagként rögzített tizenöt perces késés viszont nem az.

Jelöljétek meg a számító pillanatokat: mikor kezdődött, mikor vette észre bárki először, mikor került képbe a megfelelő ember, mikor értették meg az okot, mikor enyhítették, mikor oldódott meg. A köztük lévő résekben lakik a fejlődés, és az észlelésig eltelt idő nagyon gyakran a legnagyobb közülük.

Írjátok meg, amíg friss, ideális esetben egy vagy két napon belül. Annak az emléke, hogy valaki egy adott pillanatban mit hitt, sokkal gyorsabban halványul, mint annak az emléke, hogy mi történt.

Ritkán van egyetlen gyökérok

A kifejezés arra ösztönöz, hogy megálljunk az első elfogadható magyarázatnál, holott a bármekkora incidens olyan lánc, amelyben több dolognak kellett egyszerre teljesülnie.

Egy hasznos elemzés ehelyett hozzájáruló tényezőket sorol fel: a változtatást, ami kiváltotta, a tesztet, ami elkapta volna, és ami nem létezett, a riasztást, ami olyan csatornára ment, amit senki nem néz, a runbookot, ami egy korábbi architektúrára volt pontos. Mindegyik külön lehetőség, és ki lehet javítani a két legolcsóbbat ahelyett, ami történetesen elsőként állt a láncban.

Ez egy elterjedt torzítást is csökkent. Amikor egy elemzés egyetlen gyökérokot nevez meg, az nagyon gyakran “emberi hiba”, ami leírás és nem magyarázat, és ami pontosan ott zárja le a vizsgálatot, ahol el kellett volna kezdődnie.

Hogyan valósul meg az utánkövetés

Itt dől el a posztmortemek sorsa, és a megoldások egyáltalán nem látványosak.

Kevesebb feladat. Két elkészült feladat többet ér nyolc elmaradtnál. Rangsoroljátok aszerint, hogy csökkentik-e az észlelési időt, a hatókört vagy a valószínűséget, a többit pedig húzzátok ki.

Nevesített felelős és határidő, a szokásos munkakövető rendszerben, nem a dokumentumban. Az a feladat, ami csak a posztmortemben él, láthatatlan a tervezéskor, márpedig a munkát akkor ütemezik.

Nézzétek át a nyitott feladatokat a következő posztmortemen. Ez az egyetlen szokás többet tesz bármelyik sablonnál. Láthatóvá teszi az elmaradást, és összefüggéstelen értekezletek sorából folyamatot csinál.

Vállaljátok fel őszintén némelyiket. Az a csapat, amelyik rendre a vállalásai felét teljesíti, feleannyit vállaljon. Olyan szándékot rögzíteni, amit senki nem fog finanszírozni, rosszabb, mint azt rögzíteni, hogy nem cselekszünk, mert az utóbbi legalább igaz.

Az ebből származó javulások ugyanabba a családba tartoznak, mint a katasztrófa utáni helyreállítás útmutatónkban és a szoftvertesztelési stratégiákban leírtak: gyorsabb észlelés, kisebb hatókör, más által is üzemeltethető rendszer.

A Mecanik az általunk karbantartott rendszereken a szerver biztonsági elemzés részeként tart incidenselemzéseket. A minta szinte mindig ugyanaz: a technikai okot gyorsan megértették, és az észlelésig tartó rés volt a drága rész.

Gyakran ismételt kérdések

Mi értelme van a posztmortemnek? Az, hogy megtalálja azokat a körülményeket, amelyek engedték, hogy egy kis baj naggyá váljon, és néhányat megváltoztasson közülük, ami más kérdés, mint az, hogy mi romlott el. Létrehozza az esemény közös elbeszélését is, ami nélkül mindenki megtartja a saját változatát, és az afelé sodródik, amit eleve hitt a rendszerről.

Mit jelent valójában a hibáztatásmentesség? Azt, hogy az elemzés abból indul ki, hogy valaki az elérhető információk alapján ésszerűen járt el, és rossznak bizonyuló lépést tett, majd megkérdezi, miért tűnt az akkor helyesnek. Azért számít, mert a hibáztatás információt semmisít meg: az emberek önvédelemből átszerkesztik a beszámolójukat, és az elemzés romlott bemenetből dolgozik.

Kell egyetlen gyökérokot megnevezni a posztmortemben? Nem. A bármekkora incidens olyan lánc, amelyben több körülménynek kellett egyszerre teljesülnie, ezért hasznosabb a hozzájáruló tényezőket felsorolni. Így a két legolcsóbbat lehet javítani a lánc elsője helyett, és nem az “emberi hiba” lesz a végszó, ami leírás és nem magyarázat.

Mit tartalmazzon egy incidens idővonala? Azt, hogy ki mit tudott és mikor, nem csak azt, hogy a rendszerek mit csináltak. Rögzítsétek, mikor kezdődött, mikor vette észre bárki először, mikor került képbe a megfelelő ember, mikor értették meg az okot, mikor enyhítették és mikor oldódott meg. A résekben lakik a fejlődés, és az észlelési idő rendszerint a legnagyobb.

Miért nem készülnek el soha a posztmortem feladatai? Mert a dokumentumban élnek, nem a munkakövetőben, így láthatatlanok a munka ütemezésekor. Kevesebb feladattal, nevesített felelőssel és a szokásos követőben megadott határidővel javítható, valamint azzal, hogy a következő posztmortem elején átnézitek a nyitott feladatokat, ami láthatóvá teszi az elmaradást.