మీ production website ఇప్పుడే down అయింది. మీరు దీన్ని ఎలా నిర్వహిస్తారు?

Question

Accepted Answer

మొదటి ప్రాధాన్యత **service ను పునరుద్ధరించడం, తర్వాత కారణాన్ని కనుగొనడం** — diagnosis కంటే mitigation ముందు వస్తుంది. నేను ఒక incident ను ప్రకటిస్తాను, స్పష్టమైన పాత్రలను కేటాయిస్తాను, మరియు వేగవంతమైన సురక్షిత recovery వైపు నడిపిస్తాను, మొత్తం మార్గంలో communicate చేస్తాను.

## ముందుగా stabilize చేయండి

- **ఒక incident ను ప్రకటించండి** మరియు ఒకే channel (war room / Slack thread) తెరవండి, తద్వారా coordination చెల్లాచెదురుగా ఉండదు.
- **పాత్రలను కేటాయించండి**: నిర్ణయాలు తీసుకోవడానికి ఒక **Incident Commander**, stakeholders ను update చేయడానికి ఒక **comms owner**, మరియు దర్యాప్తు చేయడానికి **responders**. Tech Lead గా నేను తరచుగా IC ను తీసుకుంటాను, తద్వారా engineers సమస్యపై దృష్టి పెట్టగలరు.
- **వేగవంతమైన reversible fix కోసం చేరుకోండి.** ఒక deploy outage తో correlate అయితే, ముందుగా **roll back** చేసి తర్వాత ప్రశ్నలు అడగండి — users ను పునరుద్ధరించడం సరిగ్గా ఉండటం కంటే మంచిది.

## సమాంతరంగా diagnose చేయండి

- **స్పష్టమైన signals** ను తనిఖీ చేయండి: dashboards, error rates, ఇటీవలి deploys, infra మార్పులు, traffic spikes, expired certs.
- ఒక hypothesis ను రూపొందించండి, చౌకైన దాన్ని ముందుగా పరీక్షించండి, మరియు **ఒకేసారి ఐదు విషయాలను మార్చడం మానండి** — ఏది పనిచేసిందో మీకు తెలియదు.

## నిరంతరం communicate చేయండి

నిశ్శబ్దం భయాందోళనను పెంచుతుంది. వార్తలు లేకపోయినా నేను స్థిరమైన cadence లో updates పంపుతాను:

```
[14:05] Investigating — checkout is down, ~40% of users affected. Next update 14:20.
[14:20] Identified: bad deploy. Rolling back now. ETA 10 min.
[14:35] Service restored. Monitoring. Postmortem to follow.
```

## recovery తర్వాత

- కేవలం "ఇది మెరుగ్గా కనిపిస్తోంది" కాకుండా పూర్తి recovery ని నిర్ధారించండి.
- కొన్ని రోజులలో ఒక **blameless postmortem** ను నడపండి: timeline, root cause, దాన్ని గుర్తించడం/సరిచేయడం నెమ్మదిగా చేసినది ఏమిటి, మరియు **owners తో నిర్దిష్ట action items**.
- ఫలితం systemic improvement (మెరుగైన alerts, guardrails, rollback automation) — నిందించడానికి ఒక పేరు కాదు.

## లోపాలు

- users బాధపడుతుండగా **mitigate చేయడానికి ముందు debugging చేయడం**.
- **ఒకే నిర్ణయాధికారి లేకపోవడం**, తద్వారా ఐదుగురు సమాంతరంగా ఊహిస్తారు.
- stakeholders పై **dark అవ్వడం**.
- **వ్యక్తులను నిందించడం**, ఇది భవిష్యత్ incidents ఆధారపడే నిజాయితీని చంపేస్తుంది.

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

Outages అనివార్యం; మీరు వాటిని ఎలా నడుపుతారనేది team నమ్మకం మరియు customer విశ్వాసాన్ని నిర్వచిస్తుంది. ప్రశాంతమైన, role-based coordination ప్లస్ blameless follow-up ఒక చెడ్డ రోజును బలమైన system గా మారుస్తుంది — మరియు failure ఒక process గా నిర్వహించబడుతుంది, witch hunt గా కాదు కాబట్టి వేగంగా కదలడం సురక్షితమని మీ engineers కు సంకేతం ఇస్తుంది.