એ જ પ્રકારનો incident બીજી વાર ન બને તે માટે તમે શું કરો છો?

Question

Accepted Answer

એક **blameless postmortem** ચલાવો જે systemic કારણ શોધે, પછી તેને **નક્કર, માલિકીવાળા, અને tracked** action items માં ફેરવો — અને ચકાસો કે તેઓ ખરેખર ship થાય છે. ધ્યેય દોષ આપવા માટે કોને શોધવો તે નથી; તે સિસ્ટમ બદલવાનો છે જેથી એ જ વર્ગની નિષ્ફળતા અશક્ય અથવા સ્વ-શોધક બને.

## મુખ્ય loop

1. **Blameless postmortem.** એક પ્રામાણિક timeline બાંધો: શું થયું, અમે ક્યારે તેને શોધ્યું, અમે કેવી પ્રતિક્રિયા આપી, અસર શું હતી. દોષ એ સત્યને મારી નાખે છે જે તમને જોઈએ છે.
2. **trigger નહીં, systemic કારણ સુધી ખોદો.** "એક engineer એ ખરાબ config push કર્યો" એ trigger છે; "configs માટે કોઈ validation અથવા staged rollout નહોતું" એ કારણ છે. **Five Whys** વાપરો પણ સિસ્ટમ પર અટકો, ક્યારેય વ્યક્તિ પર નહીં.
3. **એક જ fix નહીં, prevention layers ઉત્પન્ન કરો**:
   - **Prevent** — નિષ્ફળતાને અશક્ય બનાવો (validation, types, guardrails).
   - **Detect** — તેને વહેલા પકડો (alerts, SLOs, synthetic checks).
   - **Mitigate** — blast radius મર્યાદિત કરો (rollback, flags, circuit breakers).
4. **owners અને due dates સોંપો.** owner વગરનું action item એ એક ઈચ્છા છે. તેમને backlog માં વાસ્તવિક કામ જેવા track કરો.
5. **ચકાસો અને loop બંધ કરો.** શું fix ship થયું? શું તે મૂળને પકડ્યું હોત? શું MTTR અને detection ખરેખર સુધર્યા?

## Trade-offs અને ભૂલો

- **Postmortems જે documents ઉત્પન્ન કરે, ફેરફારો નહીં** — સૌથી સામાન્ય નિષ્ફળતા. કોઈ follow-through નહીં એટલે તમે એ જ incident ને ફરી મળશો.
- ચોક્કસ **લક્ષણને over-fix કરવું** જ્યારે bug નો વર્ગ ખુલ્લો રહે છે. માત્ર આ instance નહીં, વર્ગ ઠીક કરો.
- tuning વગર detection ઢગલો કરવાથી **alert fatigue**; ઘોંઘાટિયા alerts ની અવગણના થાય છે અને આગામી incident સરકી જાય છે.
- **Blame culture** reporting ને ભૂગર્ભમાં ધકેલે છે; તમે near-misses ગુમાવો છો જે તમારા સૌથી સસ્તા પાઠ છે.
- **repeat incidents ને નસીબ નહીં, પ્રક્રિયા નિષ્ફળતાના સંકેત** તરીકે ગણો — recurrence ને એક metric તરીકે track કરો.

## આ શા માટે મહત્વનું છે

Incidents એ tuition છે જે તમે પહેલેથી ચૂકવી છે; એકમાત્ર બગાડ એ છે કે તેમાંથી ન શીખવું. એક ટીમ જે વ્યવસ્થિત રીતે recurrence અટકાવે છે તે દર quarter વધુ વિશ્વસનીય બને છે, જ્યારે એક ટીમ જે માત્ર firefight કરે છે તે કાયમ એ જ outages ફરી જીવે છે. આ learning loop બાંધવું — અને તેમાં પ્રામાણિક રહેવાની safety — એ Tech Lead પાછળ છોડી શકે તેવી સૌથી ટકાઉ વસ્તુઓમાંની એક છે.