అదే రకమైన incident రెండవసారి జరగకుండా నిరోధించడానికి మీరు ఏమి చేస్తారు?

Question

Accepted Answer

systemic కారణాన్ని కనుగొనే ఒక **blameless postmortem** ను నడపండి, ఆపై దాన్ని **concrete, owned, మరియు tracked** action items గా మార్చండి — మరియు అవి నిజంగా ship అవుతాయని verify చేయండి. ఎవరిని నిందించాలో కనుగొనడం లక్ష్యం కాదు; అదే class యొక్క వైఫల్యం అసాధ్యం లేదా స్వీయ-గుర్తించదగినదిగా మారేలా system ను మార్చడం.

## the core loop

1. **Blameless postmortem.** ఒక నిజాయితీగల timeline ను నిర్మించండి: ఏమి జరిగింది, మేము దాన్ని ఎప్పుడు గుర్తించాము, మేము ఎలా స్పందించాము, impact ఏమిటి. Blame మీకు అవసరమైన నిజాన్ని చంపేస్తుంది.
2. **trigger కాదు, systemic కారణాన్ని తవ్వండి.** "ఒక engineer ఒక చెడ్డ config ను push చేసాడు" అనేది ఒక trigger; "configs కోసం validation లేదా staged rollout లేదు" అనేది కారణం. **Five Whys** ను ఉపయోగించండి కానీ system వద్ద ఆగండి, ఎన్నడూ ఒక వ్యక్తి వద్ద కాదు.
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. **Verify మరియు loop ను close చేయండి.** fix ship అయిందా? ఇది original ను పట్టుకునేదా? MTTR మరియు detection నిజంగా మెరుగుపడ్డాయా?

## Trade-offs మరియు లోపాలు

- **మార్పులు కాదు, documents ఉత్పత్తి చేసే postmortems** — అత్యంత సాధారణ వైఫల్యం. follow-through లేకపోవడం అంటే మీరు అదే incident ను మళ్లీ కలుస్తారు.
- bug యొక్క class తెరిచి ఉండగా **నిర్దిష్ట symptom ను over-fix చేయడం**. ఈ ఉదాహరణ మాత్రమే కాదు, category ను సరిచేయండి.
- tuning లేకుండా detection పై పేర్చడం నుండి **Alert fatigue**; noisy alerts విస్మరించబడతాయి మరియు తదుపరి incident జారిపోతుంది.
- **Blame culture** reporting ను భూగర్భంలోకి నడిపిస్తుంది; మీ చౌకైన పాఠాలైన near-misses ను మీరు కోల్పోతారు.
- **repeat incidents ను చెడ్డ అదృష్టం కాదు, process వైఫల్యం యొక్క signal గా** పరిగణించండి — recurrence ను ఒక metric గా track చేయండి.

## ఇది ఎందుకు ముఖ్యం

Incidents అనేది మీరు ఇప్పటికే చెల్లించిన ట్యూషన్; ఏకైక వ్యర్థం వాటి నుండి నేర్చుకోకపోవడం. recurrence ను systematic గా నిరోధించే team ప్రతి quarter మరింత నమ్మదగినదిగా అవుతుంది, అయితే కేవలం firefight చేసే team శాశ్వతంగా అదే outages ను తిరిగి అనుభవిస్తుంది. ఈ learning loop ను నిర్మించడం — మరియు దానిలో నిజాయితీగా ఉండే safety — ఒక Tech Lead వదిలిపెట్టగల అత్యంత మన్నికైన విషయాలలో ఒకటి.