ఒక rollback మరియు ఒక hotfix మధ్య నిర్ణయించడానికి మీరు ఏ ప్రమాణాలను ఉపయోగిస్తారు?

Question

Accepted Answer

**Rollback** కు default అవ్వండి — ఇది ఒక known-good state ను పునరుద్ధరించడానికి అత్యంత వేగవంతమైన, అత్యంత నమ్మదగిన మార్గం. rollback అసాధ్యం లేదా fix చేయడం కంటే ప్రమాదకరమైనప్పుడు మాత్రమే ఒక **hotfix** కోసం చేరుకోండి. ఒక active incident లో, ప్రాధాన్యత **ముందుగా రక్తస్రావాన్ని ఆపడం**, తర్వాత diagnose చేయడం.

## the decision criteria

- **rollback సురక్షితమా మరియు సాధ్యమా?** మునుపటి version known-good అయితే మరియు irreversible ఏదీ జరగకపోతే, roll back చేయండి. ఇది సాధారణ సమాధానం.
- **చెడ్డ release irreversible state ను సృష్టించిందా?** ఒక **database migration** లేదా data corruption rollback ను bug కంటే అధ్వాన్నం చేయగలదు. మీరు సురక్షితంగా తిరిగి వెళ్లలేకపోతే, మీరు forward fix చేయాలి.
- **మేము fix ను అర్థం చేసుకున్నామా?** Rollback కు diagnosis అవసరం లేదు — అది దాని శక్తి. మీరు పూర్తిగా అర్థం చేసుకోని hotfix incident ను లోతుగా చేయగలదు; ఒత్తిడిలో ఒక guess ను prod కు ఎన్నడూ ship చేయవద్దు.
- **safe state కు సమయం.** తక్కువ risk తో అత్యంత వేగంగా stability కు చేరుకునే ఏ మార్గాన్నైనా ఎంచుకోండి. ఒక one-line, బాగా అర్థమైన hotfix ఒక complex rollback ను ఓడించగలదు; ఒక risky forward-fix ఎన్నడూ ఒక clean revert ను ఓడించదు.
- **Blast radius మరియు severity.** ఒక పూర్తి outage అత్యంత వేగవంతమైన restore (సాధారణంగా rollback) ను డిమాండ్ చేస్తుంది; ఒక చిన్న degradation ఒక జాగ్రత్తైన hotfix ను అనుమతించవచ్చు.

## ఒక quick decision table

| పరిస్థితి | ఎంచుకోండి |
| --- | --- |
| మునుపటి version known-good, migration లేదు | Rollback |
| Irreversible DB migration ship అయింది | Hotfix / fix-forward |
| కారణం తెలియదు, తీవ్ర impact | Rollback (సమయం కొనండి) |
| Trivial, బాగా అర్థమైన one-liner | Hotfix |
| Rollback స్వయంగా risky/untested | Hotfix |

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

- **Rollback** సురక్షితం కానీ symptom ను మాత్రమే treat చేస్తుంది — మీరు ఇంకా ఒక నిజమైన fix మరియు ఒక postmortem owe అవుతారు.
- **Hotfix** root cause ను పరిష్కరిస్తుంది కానీ సాధారణ safety net ను skip చేస్తుంది; hotfixes లో bugs సాధారణం ఎందుకంటే అవి rushed.
- **Untested rollback path** ఒక ట్రాప్ — మీరు దాన్ని ఎన్నడూ rehearse చేయకపోతే, మీకు అత్యంత అవసరమైనప్పుడు అది విఫలమవ్వవచ్చు. అవసరం రాకముందే rollbacks ను practice చేయండి.
- ఒత్తిడిలో **production లో debugging** పట్ల జాగ్రత్తగా ఉండండి; మీరు ఒక నమ్మకమైన fix నుండి కొన్ని నిమిషాల కంటే ఎక్కువ దూరంలో ఉంటే, roll back చేసి ప్రశాంతంగా దర్యాప్తు చేయండి.

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

ఈ నిర్ణయం అత్యంత చెత్త క్షణంలో జరుగుతుంది — system down, clock running, ప్రతి ఒక్కరూ చూస్తున్నారు. దాని కోసం ఒక స్పష్టమైన, rehearsed నియమం ఉన్న Tech Lead MTTR ను నాటకీయంగా తగ్గిస్తాడు మరియు boring revert అక్కడే ఉన్నప్పుడు incident మధ్యలో తెలివిగా ఉండటానికి ప్రయత్నించే classic తప్పును నిరోధిస్తాడు. ముందుగా పునరుద్ధరించండి, తర్వాత తెలివిగా ఉండండి.

పరిస్థితి	ఎంచుకోండి
మునుపటి version known-good, migration లేదు	Rollback
Irreversible DB migration ship అయింది	Hotfix / fix-forward
కారణం తెలియదు, తీవ్ర impact	Rollback (సమయం కొనండి)
Trivial, బాగా అర్థమైన one-liner	Hotfix
Rollback స్వయంగా risky/untested	Hotfix