Ką darote, kad tos pačios rūšies incident neatsitiktų antrą kartą?

Question

Accepted Answer

Atlik **blameless postmortem**, kuris randa sisteminę priežastį, tada paversk ją **konkrečiais, savininkų turinčiais ir sekamais** veiksmų punktais — ir patikrink, kad jie iš tiesų pristatyti. Tikslas yra ne rasti, ką kaltinti; tai pakeisti sistemą taip, kad ta pati nesėkmių klasė taptų neįmanoma arba pati save aptinkanti.

## Pagrindinis ciklas

1. **Blameless postmortem.** Sukurk sąžiningą laiko juostą: kas atsitiko, kada aptikome, kaip reagavome, koks buvo poveikis. Kaltinimas žudo tiesą, kurios tau reikia.
2. **Kask iki sisteminės priežasties**, o ne iki paleidiklio. „Inžinierius įstūmė blogą config“ yra paleidiklis; „nebuvo config validacijos ar staged rollout“ yra priežastis. Naudok **Penkis Kodėl**, bet sustok ties sistema, niekada ties žmogumi.
3. **Generuok prevencijos sluoksnius**, o ne vieną pataisymą:
   - **Užkirsk kelią** — padaryk nesėkmę neįmanomą (validacija, tipai, apsauginiai barjerai).
   - **Aptik** — pagauk anksčiau (perspėjimai, SLO, sintetiniai patikrinimai).
   - **Sušvelnink** — apribok sprogimo spindulį (rollback, flags, circuit breakers).
4. **Priskirk savininkus ir terminus.** Veiksmų punktas be savininko yra noras. Sek juos kaip realų darbą backlog.
5. **Patikrink ir uždaryk ciklą.** Ar pataisymas pristatytas? Ar jis būtų pagavęs originalą? Ar MTTR ir aptikimas iš tiesų pagerėjo?

## Kompromisai ir spąstai

- **Postmortem, kurie sukuria dokumentus, o ne pokyčius** — dažniausia nesėkmė. Jokio įgyvendinimo reiškia, kad vėl susitiksi su tuo pačiu incident.
- **Konkretaus simptomo perlopymas**, kol klaidų klasė lieka atvira. Taisyk kategoriją, o ne tik šį atvejį.
- **Alert fatigue** nuo aptikimo kaupimo be derinimo; triukšmingi perspėjimai ignoruojami ir kitas incident praslysta.
- **Kaltinimo kultūra** nuvaro pranešimus po žeme; prarandi beveik įvykusius, kurie yra tavo pigiausios pamokos.
- Traktuok **pasikartojančius incident kaip proceso nesėkmės signalą**, o ne nesėkmę — sek pasikartojimą kaip rodiklį.

## Kodėl tai svarbu

Incident yra mokestis, kurį jau sumokėjai; vienintelė švaistymas yra nepasimokyti iš jų. Komanda, kuri sistemingai užkerta kelią pasikartojimui, kas ketvirtį tampa patikimesnė, o komanda, kuri tiesiog gesina gaisrus, iš naujo išgyvena tuos pačius gedimus amžinai. Šio mokymosi ciklo sukūrimas — ir saugumo būti jame sąžiningam — yra vienas iš ilgiausiai išliekančių dalykų, kuriuos Tech Lead gali palikti.