آپ rollback اور hotfix کے درمیان فیصلہ کرنے کے لیے کون سے معیار استعمال کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**rollback** کو ڈیفالٹ بنائیں — یہ ایک معلوم اچھی حالت کو بحال کرنے کا تیز ترین، سب سے قابل اعتماد طریقہ ہے۔ ایک **hotfix** تک صرف اس وقت پہنچیں جب rollback ناممکن ہو یا آگے ٹھیک کرنے سے زیادہ خطرناک ہو۔ ایک فعال incident میں، ترجیح ہے **پہلے خون بہنا روکیں**، تشخیص بعد میں۔

## فیصلے کے معیار

- **کیا rollback محفوظ اور ممکن ہے؟** اگر پچھلا ورژن معلوم اچھا ہے اور کوئی ناقابلِ واپسی چیز نہیں ہوئی، تو roll back کریں۔ یہ عام جواب ہے۔
- **کیا خراب release نے ناقابلِ واپسی state بنائی؟** ایک **database migration** یا data corruption rollback کو bug سے بدتر بنا سکتا ہے۔ اگر آپ محفوظ طریقے سے واپس نہیں جا سکتے، تو آپ کو آگے ٹھیک کرنا ہوگا۔
- **کیا ہم fix کو سمجھتے ہیں؟** Rollback کو کسی تشخیص کی ضرورت نہیں — یہی اس کی طاقت ہے۔ ایک hotfix جسے آپ پوری طرح نہیں سمجھتے incident کو گہرا کر سکتا ہے؛ دباؤ میں prod پر کبھی اندازہ ship نہ کریں۔
- **محفوظ state تک کا وقت۔** جو بھی راستہ کم سے کم خطرے کے ساتھ سب سے تیزی سے استحکام تک پہنچے اسے چنیں۔ ایک ایک لائن، اچھی طرح سمجھی گئی hotfix ایک پیچیدہ rollback کو شکست دے سکتی ہے؛ ایک خطرناک forward-fix کبھی صاف revert کو شکست نہیں دیتا۔
- **Blast radius اور شدت۔** ایک مکمل outage تیز ترین ممکنہ بحالی کا تقاضا کرتا ہے (عام طور پر rollback)؛ ایک معمولی degradation ایک محتاط hotfix کی اجازت دے سکتی ہے۔

## ایک فوری فیصلہ جدول

| صورتحال | چنیں |
| --- | --- |
| پچھلا ورژن معلوم اچھا، کوئی migration نہیں | Rollback |
| ناقابلِ واپسی DB migration ship ہوا | Hotfix / fix-forward |
| وجہ نامعلوم، شدید اثر | Rollback (وقت خریدیں) |
| معمولی، اچھی طرح سمجھی گئی one-liner | Hotfix |
| Rollback خود خطرناک/غیر آزمودہ ہے | Hotfix |

## Trade-offs اور نقصانات

- **Rollback** محفوظ ہے لیکن صرف علامت کا علاج کرتا ہے — آپ پر اب بھی ایک حقیقی fix اور ایک postmortem واجب ہے۔
- **Hotfix** root cause کو حل کرتا ہے لیکن عام safety net کو چھوڑ دیتا ہے؛ hotfixes میں bugs بالکل اسی لیے عام ہیں کیونکہ وہ جلدی میں ہوتی ہیں۔
- **غیر آزمودہ rollback راستہ** ایک جال ہے — اگر آپ نے اسے کبھی مشق نہیں کیا، تو یہ تب ناکام ہو سکتا ہے جب آپ کو اس کی سب سے زیادہ ضرورت ہو۔ ضرورت سے پہلے rollbacks کی مشق کریں۔
- دباؤ میں **production میں debugging** سے ہوشیار رہیں؛ اگر آپ ایک پراعتماد fix سے چند منٹ سے زیادہ دور ہیں، تو roll back کریں اور پُرسکون طریقے سے تفتیش کریں۔

## یہ کیوں اہم ہے

یہ فیصلہ سب سے برے ممکنہ لمحے میں ہوتا ہے — سسٹم بند، گھڑی چل رہی، ہر کوئی دیکھ رہا۔ ایک Tech Lead جس کے پاس اس کے لیے ایک واضح، مشق شدہ اصول ہے MTTR کو ڈرامائی طور پر کم کرتا ہے اور mid-incident میں ہوشیار بننے کی کلاسک غلطی کو روکتا ہے جب بورنگ revert بالکل وہیں موجود تھا۔ پہلے بحال کریں، ہوشیار بعد میں بنیں۔

صورتحال	چنیں
پچھلا ورژن معلوم اچھا، کوئی migration نہیں	Rollback
ناقابلِ واپسی DB migration ship ہوا	Hotfix / fix-forward
وجہ نامعلوم، شدید اثر	Rollback (وقت خریدیں)
معمولی، اچھی طرح سمجھی گئی one-liner	Hotfix
Rollback خود خطرناک/غیر آزمودہ ہے	Hotfix

فیصلے کے معیار

ایک فوری فیصلہ جدول

Trade-offs اور نقصانات

یہ کیوں اہم ہے

متعلقہ سوالات