rollback और hotfix के बीच निर्णय लेने के लिए आप किन मानदंडों का उपयोग करते हैं?

Question

Accepted Answer

डिफ़ॉल्ट रूप से **rollback** चुनें — यह किसी known-good स्थिति को बहाल करने का सबसे तेज़, सबसे विश्वसनीय तरीका है। **hotfix** की ओर तभी बढ़ें जब rollback असंभव हो या आगे बढ़कर ठीक करने से अधिक खतरनाक हो। एक सक्रिय incident में, प्राथमिकता है **पहले रक्तस्राव रोकें**, निदान बाद में।

## निर्णय मानदंड

- **क्या rollback सुरक्षित और संभव है?** अगर पिछला version known-good है और कुछ भी अपरिवर्तनीय नहीं हुआ है, तो rollback करें। यह सामान्य जवाब है।
- **क्या खराब release ने अपरिवर्तनीय state बनाया?** एक **database migration** या data corruption rollback को बग से बदतर बना सकता है। अगर आप सुरक्षित रूप से वापस नहीं जा सकते, तो आपको आगे बढ़कर ठीक करना होगा।
- **क्या हम फ़िक्स समझते हैं?** rollback को कोई निदान नहीं चाहिए — यही इसकी ताकत है। एक hotfix जिसे आप पूरी तरह नहीं समझते, incident को गहरा कर सकता है; दबाव में prod पर कभी अनुमान ship न करें।
- **सुरक्षित state तक समय।** जो भी रास्ता सबसे कम जोखिम के साथ सबसे तेज़ी से स्थिरता तक पहुँचे उसे चुनें। एक एक-पंक्ति, अच्छी तरह समझा गया hotfix एक जटिल rollback को मात दे सकता है; एक जोखिम भरा forward-fix कभी साफ़ revert को मात नहीं देता।
- **Blast radius और गंभीरता।** एक पूर्ण outage सबसे तेज़ संभव restore माँगता है (आमतौर पर rollback); एक मामूली गिरावट एक सावधान hotfix की अनुमति दे सकती है।

## एक त्वरित निर्णय तालिका

| स्थिति | चुनें |
| --- | --- |
| पिछला version known-good, कोई migration नहीं | Rollback |
| अपरिवर्तनीय DB migration ship हुआ | Hotfix / fix-forward |
| कारण अज्ञात, गंभीर प्रभाव | Rollback (समय खरीदें) |
| तुच्छ, अच्छी तरह समझी गई one-liner | Hotfix |
| Rollback खुद जोखिम भरा/अपरीक्षित | Hotfix |

## Trade-offs और गलतियाँ

- **Rollback** सुरक्षित है लेकिन केवल लक्षण का इलाज करता है — आप अभी भी एक असली फ़िक्स और postmortem के ऋणी हैं।
- **Hotfix** root cause को संबोधित करता है लेकिन सामान्य सुरक्षा जाल को छोड़ देता है; hotfixes में बग्स ठीक इसलिए आम हैं क्योंकि वे जल्दबाज़ी में होते हैं।
- **अपरीक्षित rollback path** एक जाल है — अगर आपने इसका कभी अभ्यास नहीं किया, तो यह तब विफल हो सकता है जब आपको इसकी सबसे ज़रूरत हो। ज़रूरत पड़ने से पहले rollbacks का अभ्यास करें।
- दबाव में **production में डिबगिंग** से सावधान रहें; अगर आप एक आत्मविश्वासी फ़िक्स से कुछ मिनट से अधिक दूर हैं, तो rollback करें और शांति से जाँच करें।

## यह क्यों महत्वपूर्ण है

यह निर्णय सबसे बुरे संभव क्षण में होता है — सिस्टम डाउन, घड़ी चल रही, सब देख रहे। इसके लिए एक स्पष्ट, अभ्यस्त नियम वाला Tech Lead MTTR को नाटकीय रूप से कम करता है और incident के बीच चतुर बनने की क्लासिक गलती को रोकता है जब उबाऊ revert ठीक वहीं था। पहले बहाल करें, बाद में चतुर बनें।

स्थिति	चुनें
पिछला version known-good, कोई migration नहीं	Rollback
अपरिवर्तनीय DB migration ship हुआ	Hotfix / fix-forward
कारण अज्ञात, गंभीर प्रभाव	Rollback (समय खरीदें)
तुच्छ, अच्छी तरह समझी गई one-liner	Hotfix
Rollback खुद जोखिम भरा/अपरीक्षित	Hotfix