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 بالکل وہیں موجود تھا۔ پہلے بحال کریں، ہوشیار بعد میں بنیں۔