May nasira sa production. Nabawasan ang feature na nakaharap sa customer, na-corrupt ang data, o tumabi ang pag-deploy noong 2 AM. Ang adrenaline ay kumupas. Ang pag-aayos ay nasa. Ngayon ano?
Ito ang sandaling sinasayang ng karamihan sa mga koponan. Maaari nilang laktawan ang retrospective nang buo ("naayos na natin ito, magpatuloy tayo") o tumakbo sila ng isang tahimik na nagbibigay ng sisi habang nagpapanggap na hindi. Hindi rin pinipigilan ang susunod na pangyayari.
Ang isang tunay na walang kapintasang postmortem ay isa sa mga aktibidad na may pinakamataas na pakinabang na maaaring patakbuhin ng isang pangkat ng produkto. Mahusay na ginawa, ginagawa nitong sistematikong pagpapabuti ang isang masakit na kaganapan. Tapos nang hindi maganda, tinuturuan nito ang iyong koponan na itago ang mga problema.
Narito kung paano patakbuhin ang insidente retrospective na talagang gumagana.
Bakit Ang "Walang Kapintasan" ay Hindi Lang Isang Magandang Salita
Maging direkta tayo tungkol sa kung ano ang ibig sabihin ng walang kapintasan, dahil ang mga koponan ay palaging nagkakamali.
Ang walang kapintasan ay hindi nangangahulugang "walang kasangkot" o "walang nagkamali." Nangangahulugan ito na tinatanggap mo na ang mga taong kasangkot ay gumawa ng mga makatwirang desisyon dahil sa kung ano ang alam nila noong panahong iyon, ang panggigipit sa kanila, at ang mga tool na mayroon sila. Ang tanong shifts mula sa "sino screwed up?" sa "paano ang tungkol sa aming system na ginawang malamang ang kabiguan na ito?"
Ito ay mahalaga para sa isang praktikal na dahilan: kung ang mga tao ay natatakot sa parusa, itinatago nila ang mga problema. Pinagsama-sama ang mga nakatagong problema. Nauuwi ka sa mga insidente na maaaring maagang nahuli ngunit sa halip ay lumala hanggang sa maging mga emerhensiya.
Ang layunin ay gawing pinakaligtas na bagay na magagawa ng isang tao sa iyong koponan ang mga lumalabas na problema.
Kailan Magpapatakbo ng Insidente Retrospective
Hindi lahat ng bug ay nangangailangan ng isang pormal na postmortem. I-save ang buong proseso para sa mga insidente na nakakatugon sa kahit isa sa mga pamantayang ito:
- Epekto ng customer-- Nakaranas ang mga user ng masamang serbisyo, pagkawala ng data, o downtime
- Malapit na makaligtaan-- Walang nasira, ngunit dahil lamang sa isang tao na nahuli ito sa oras
- Ulitin ang mga pattern-- Ang parehong kategorya ng problema ay lumitaw dati
- Paglahok ng cross-team-- Ang insidente ay nangangailangan ng koordinasyon sa maraming koponan
- Mga kabiguan ng nobela-- May nangyari na hindi inaasahan ng iyong pagsubaybay o mga proseso
Patakbuhin ang retrospective sa loob ng 48 oras habang sariwa ang mga detalye. Ang paghihintay ng isang linggo ay ginagarantiyahan na ang memorya ng lahat ay nabago sa pamamagitan ng pagbabalik-tanaw.
Ang Timeline: Ang Iyong Pinakamahalagang Artifact
Bago mo pag-aralan ang anumang bagay, buuin muli kung ano ang aktwal na nangyari. Ito ay mas mahirap kaysa ito ay tunog dahil ang mga alaala ng mga tao ng mga insidente ay kilalang-kilalang hindi mapagkakatiwalaan -- ang stress compresses at distorts oras.
Bumuo ng isang nakabahaging timeline gamit ang mga mapagkukunang layunin:
- Pagsubaybay sa mga alerto at dashboard-- Kailan talaga nagbago ang mga sukatan?
- I-deploy ang mga log-- Ano ang lumabas, at kailan?
- Mga log ng chat-- Ano ang sinabi ng mga tao sa Slack o sa channel ng iyong insidente?
- Mga ulat ng customer-- Kailan dumating ang unang reklamo?
- Mga tala sa tawag• Sino ang na-page, at kailan sila tumugon?
Ilatag ang mga ito ayon sa pagkakasunod-sunod. Huwag mag-editoryal. Ang timeline ay dapat magbasa tulad ng isang makatotohanang account, hindi isang salaysay na may mga bayani at kontrabida.
Ang timeline na ito lamang ang madalas na nagpapakita ng tunay na problema. Maaari mong matuklasan na ang pag-deploy ay nangyari sa 14:03 ngunit ang alerto ay hindi gumana hanggang 14:47, na nangangahulugang ang iyong pagsubaybay ay may 44 na minutong blind spot. Ang puwang na iyon ay mas mahalaga kaysa sa anumang pagbabago sa code na nagdulot ng isyu.
Pagsusuri sa Root Cause: Going Beyond the Obvious
Ang pinakakaraniwang kabiguan sa insidente retrospective ay ang paghinto sa unang dahilan na nakita mo. Naubusan ng memory ang isang server. Nawawala ang isang null check. Mali ang isang config value. Ang lahat ng ito ay totoo, at lahat sila ay hindi sapat.
Ang paraan ng 5 Whysgumagana dahil pinipilit ka nitong lampasan ang halata.
Magsimula sa pangyayari at magtanong ng "bakit?" paulit-ulit:
- Nagbalik ang API ng 500 error sa loob ng 20 minuto.Bakit?
- Naubos na ang database connection pool.Bakit?
- Ang isang query ay tumatakbo nang walang timeout at may hawak na mga koneksyon.Bakit?
- Ang query ay idinagdag sa isang kamakailang PR nang walang pagsusuri sa pagganap.Bakit?
- Walang kinakailangang hakbang sa pagsusuri ng pagganap para sa mga pagbabago sa database-touching.Bakit?
Ngayon ay mayroon ka nang naaaksyunan sa antas ng system: magdagdag ng gate ng pagsusuri para sa mga query, hindi lang isang paalala sa indibidwal na developer na sumulat nito.
Isang babala tungkol sa 5 Bakit:Gumagana nang maayos ang pamamaraang ito kapag mayroong isang kadena ng sanhi. Maraming mga insidente ang may maraming nag-aambag na mga salik na nagtagpo. Sa mga pagkakataong iyon, ang isang fishbone diagram o isang simpleng listahan ng "nag-aambag na mga kadahilanan" ay mas tapat kaysa sa pagpilit ng lahat sa isang kadena.
Pagbubuo ng Retrospective Session
Narito ang isang format na mahusay na gumagana para sa isang 60 minutong insidente retrospective. Ayusin ang timing batay sa kalubhaan.
1. Walkthrough sa timeline (15 minuto)
Ipakita ang muling itinayong timeline. Hilingin sa mga kalahok na itama o idagdag ito. Huwag makipag-debate sa mga sanhi -- magtatag lamang ng mga katotohanan.
2. Pagsusuri ng epekto (10 minuto)
I-quantify kung ano ang nangyari. Ilang user ang naapektuhan? Ano ang halaga ng negosyo? May nawala bang data? Pinagbabatayan nito ang pag-uusap sa katotohanan at nakakatulong na bigyang-priyoridad ang tugon.
3. Mga salik na nag-aambag (20 minuto)
Ito ang pangunahing pagsusuri. Para sa bawat yugto ng insidente -- ang sanhi, ang pagtuklas, ang tugon, ang paglutas -- itanong: ano ang nagpalala nito kaysa sa kinakailangan? Ano ang nagpaganda nito?
Mga kapaki-pakinabang na senyas:
- Anong impormasyon ang kulang sa mga tao sa paggawa ng mga desisyon?
- Saan nagkulang ang ating kagamitan o pagsubaybay?
- Anong mga proseso ang gumana nang maayos sa panahon ng pagtugon?
- Ano kaya ang magpapabilis ng pagtuklas?
- Saan nasira ang mga handoffs?
4. Mga item ng aksyon (15 minuto)
Bumuo ng mga partikular, pagmamay-ari, napapanahong pagpapabuti. Ikategorya ang mga ito:
- Mga agarang pag-aayos-- i-patch ang partikular na bagay na nasira (dapat nagawa na ang mga ito)
- Mga pagpapabuti sa pagtuklas-- mas mahusay na mga alerto, dashboard, o mga pagsubok upang mahuli ang klase ng problemang ito
- Mga pagbabago sa proseso-- repasuhin ang mga gate, mga update sa runbook, o mga pagpapahusay ng escalation path
- Mga sistematikong pamumuhunan-- mas malaking gawaing arkitektura o tooling na nagpapababa sa kategoryang ito ng panganib
Limitahan ang iyong sarili sa 3-5 na item ng pagkilos. Ang isang postmortem na bumubuo ng 15 na item ng aksyon ay kukumpleto ng zero sa mga ito. Unahin ang walang awa.
Ang Wika ng Kawalang-Kapintasan
Higit na hinuhubog ng wika ang kultura kaysa sa mga patakaran. Narito ang mga kongkretong pagbabago:
| sa halip na | Subukan mo |
|---|---|
| "Si John ay nagtulak ng masamang pag-deploy" | "Ang pag-deploy noong 14:03 ay nagpakilala ng regression" |
| "Dapat nahuli ito ng team" | "Hindi na-flag ng aming proseso ng pagsusuri ang klase ng pagbabagong ito" |
| "May nakalimutang i-update ang config" | "Hindi na-update ang config bilang bahagi ng proseso ng pag-deploy" |
| "Bakit walang nakapansin?" | "Ano kaya ang mas maagang makita ito?" |
Ang pattern: ilarawan ang mga kaganapan at sistema, hindi ang mga tao at ang kanilang mga pagkabigo. Hindi ito tungkol sa pagiging malabo. Maaari kang maging lubos na tiyak tungkol sa kung ano ang naging mali nang hindi ito ginagawa tungkol sa indibidwal na kasalanan.
Mga Karaniwang Pitfalls na Nakakasira sa Insidente Retros
Huminto sa malapit na dahilan.Ang pag-aayos ay pumasok, ang bug ay na-patched, tapos na. Kung hihinto ka rito, patuloy kang magkakaroon ng mga katulad na insidente na may iba't ibang detalye.
Bumubuo ng mga item ng pagkilos na walang sinusubaybayan.Ang isang item ng aksyon na walang may-ari at isang deadline ay isang kahilingan. Suriin ang pagkumpleto ng item ng aksyon mula sa mga nakaraang insidente sa simula ng bawat bagong postmortem.
Paglilinis ng retrospective para sa pamumuno.Kung ang nakasulat na rekord ay na-edit upang magmukhang mas mahusay bago ito umabot sa mga direktor o VP, mayroon kang problema sa pagtitiwala. Ang buong punto ay transparency.
Pinapatakbo lamang ang mga ito para sa mga outage.Ang mga near miss ay kadalasang mas mahalagang suriin dahil mas mababa ang mga stake at mas malayang magsalita ang mga tao. Kung ang isang deploy ay halos naging sanhi ng isang outage ngunit may nakahuli nito sa panahon ng canary, iyon ay nagkakahalaga din ng pag-unawa.
Ginagawa itong status meeting.Ang retrospective ay para sa pagsusuri at pag-aaral. Huwag hayaang maging isang rundown kung sino ang gumawa ng kung ano sa panahon ng insidente. Saklaw na iyon ng timeline.
Pagbuo ng Incident Knowledge Base
Ang mga indibidwal na postmortem ay kapaki-pakinabang. Ang isang mahahanap na library ng mga postmortem ay transformational.
Kapag mayroon kang anim na buwan ng mga nakadokumentong insidente, maaari kang magsimulang magtanong tulad ng: Ilang porsyento ng aming mga insidente ang nauugnay sa pag-deploy? Ano ang aming ibig sabihin ng oras sa pagtuklas? Nakukumpleto ba talaga ang aming mga item sa pagkilos?
Panatilihin ang isang pare-parehong format upang maihambing ang mga insidente. I-tag ang mga ito ayon sa kategorya (deploy, imprastraktura, data, dependency ng third-party). Gawing naa-access ang mga ito sa lahat sa organisasyon, hindi naka-lock sa isang team wiki.
Sa paglipas ng panahon, ang library na ito ay nagiging isa sa iyong pinakamahalagang asset ng engineering. Maaaring basahin ng mga bagong miyembro ng team ang mga nakaraang insidente upang maunawaan ang iyong mga system nang mas mahusay kaysa sa anumang dokumento ng arkitektura na maaaring ituro sa kanila.
Ginagawa Ito Stick
Ang pagkakaiba sa pagitan ng mga team na natututo mula sa mga insidente at mga team na umuulit sa kanila ay bumaba sa follow-through.
Suriin ang mga nakaraang aksyon na item sa bawat insidente retrospective. Kung ang parehong salik na nag-aambag ay lilitaw nang dalawang beses, palakihin ito -- iyon ay isang senyales na ang iyong proseso ng pagpapabuti mismo ay nangangailangan ng pagpapabuti.
Kilalanin ang mga taong maagang lumalabas ng mga problema. Kung ang isang tao ay nagpapahayag ng isang alalahanin na pumipigil sa isang insidente, iyon ay nagkakahalaga ng pagdiriwang sa publiko. Pinapatibay mo ang pag-uugali na gusto mo.
At tanggapin na mangyayari ang mga pangyayari. Ang layunin ay hindi zero insidente. Ang layunin ay ang bawat insidente ay nobela -- nabigo ka sa bago at kawili-wiling mga paraan, hindi paulit-ulit ang parehong mga pagkabigo sa isang loop.
Subukan ang NextRetro nang libre-- Patakbuhin ang structured, walang kapintasang insidente retrospective kasama ng iyong team gamit ang mga built-in na template at anonymous na koleksyon ng card.
Huling Na-update:Pebrero 2026
Oras ng Pagbasa:7 minuto
