उही प्रकारको incident दोस्रो पटक हुनबाट रोक्न तपाईं के गर्नुहुन्छ?

Question

Accepted Answer

प्रणालीगत कारण फेला पार्ने **blameless postmortem** चलाऊ, त्यसपछि यसलाई **ठोस, owned, र tracked** action item मा बदल — र तिनी साँच्चै ship हुन्छन् भनी प्रमाणित गर। लक्ष्य भनेको कसलाई दोष दिने भनी पत्ता लगाउनु होइन; यो system यसरी बदल्नु हो कि उही वर्गको असफलता असम्भव वा स्वतः-पत्तालाग्ने बनोस्।

## मुख्य loop

1. **Blameless postmortem।** एक इमानदार timeline बनाऊ: के भयो, कहिले पत्ता लाग्यो, हामीले कसरी प्रतिक्रिया दियौं, प्रभाव के थियो। दोषले तपाईंलाई चाहिने सत्य मार्छ।
2. **Trigger होइन, प्रणालीगत कारणसम्म खन।** "इन्जिनियरले खराब config push गर्‍यो" एउटा trigger हो; "config का लागि कुनै validation वा staged rollout थिएन" कारण हो। **Five Whys** प्रयोग गर तर system मा रोक, कहिल्यै व्यक्तिमा होइन।
3. **एउटै fix होइन, रोकथामका तहहरू उत्पन्न गर:**
   - **रोक्ने** — असफलतालाई असम्भव बनाऊ (validation, type, guardrail)।
   - **पत्ता लगाउने** — यसलाई चाँडै समाऊ (alert, SLO, synthetic check)।
   - **न्यूनीकरण गर्ने** — blast radius सीमित गर (rollback, flag, circuit breaker)।
4. **Owner र due date तोक।** owner बिनाको action item एउटा इच्छा हो। तिनलाई backlog मा वास्तविक काम जस्तै track गर।
5. **प्रमाणित गर र loop बन्द गर।** के fix ship भयो? के यसले मूललाई समात्थ्यो? के MTTR र पत्ता लगाउने काम साँच्चै सुधार भयो?

## Trade-off र जोखिमहरू

- **परिवर्तन होइन, document उत्पादन गर्ने postmortem** — सबैभन्दा सामान्य असफलता। Follow-through नभए तपाईं उही incident फेरि भेट्नुहुन्छ।
- वर्गको bug खुला रहँदा **विशिष्ट लक्षणलाई अति-ठीक गर्नु**। यो उदाहरण मात्र होइन, श्रेणी ठीक गर।
- tuning बिना पत्ता लगाउने थप्दा **alert fatigue**; हल्ला गर्ने alert बेवास्ता हुन्छन् र अर्को incident छुट्छ।
- **दोष संस्कृति** ले reporting लाई भूमिगत बनाउँछ; तपाईंले आफ्ना सबैभन्दा सस्ता पाठ near-miss हरू गुमाउनुहुन्छ।
- **दोहोरिने incident लाई दुर्भाग्य होइन, प्रक्रिया असफलताको संकेत** का रूपमा लेऊ — recurrence लाई मापदण्डको रूपमा track गर।

## यो किन महत्त्वपूर्ण छ

Incident तपाईंले पहिले नै तिरिसकेको शुल्क हो; एक मात्र बर्बादी भनेको तीबाट नसिक्नु हो। प्रणालीगत रूपमा पुनरावृत्ति रोक्ने टीम हरेक quarter बढी भरपर्दो हुन्छ, जबकि केवल firefighting गर्ने टीमले उही outage सधैं भोग्छ। यो सिकाइ loop — र यसमा इमानदार हुने सुरक्षा — बनाउनु Tech Lead ले छोड्न सक्ने सबैभन्दा टिकाउ कुराहरूमध्ये एक हो।