একটি rollback ও একটি hotfix-এর মধ্যে সিদ্ধান্ত নিতে আপনি কোন মানদণ্ড ব্যবহার করেন?

Question

Accepted Answer

ডিফল্ট হলো **rollback** — একটি পরিচিত-ভালো অবস্থা পুনরুদ্ধারের এটি দ্রুততম, সবচেয়ে নির্ভরযোগ্য উপায়। একটি **hotfix**-এর দিকে কেবল তখনই যান যখন rollback অসম্ভব বা সামনে এগিয়ে fix করার চেয়ে বেশি বিপজ্জনক। একটি সক্রিয় incident-এ অগ্রাধিকার হলো **আগে রক্তপাত বন্ধ করা**, পরে রোগনির্ণয়।

## সিদ্ধান্তের মানদণ্ড

- **rollback কি নিরাপদ ও সম্ভব?** আগের সংস্করণ পরিচিত-ভালো হলে এবং অপরিবর্তনীয় কিছু না ঘটে থাকলে, rollback করুন। এটিই সাধারণ উত্তর।
- **খারাপ release কি অপরিবর্তনীয় state তৈরি করেছে?** একটি **database migration** বা data corruption rollback-কে bug-এর চেয়ে খারাপ করে দিতে পারে। নিরাপদে ফিরতে না পারলে, আপনাকে সামনে এগিয়ে fix করতে হবে।
- **আমরা কি fix বুঝি?** rollback-এর কোনো রোগনির্ণয় লাগে না — সেটিই এর শক্তি। আপনি পুরোপুরি না বোঝা একটি hotfix incident গভীর করতে পারে; চাপের মধ্যে কখনো prod-এ একটি অনুমান ship করবেন না।
- **নিরাপদ অবস্থায় পৌঁছানোর সময়।** যেটি সবচেয়ে কম ঝুঁকিতে দ্রুততম স্থিতিশীলতায় পৌঁছায় তা বেছে নিন। একটি এক-লাইনের, ভালোভাবে-বোঝা hotfix একটি জটিল rollback-কে হারাতে পারে; একটি ঝুঁকিপূর্ণ forward-fix কখনো একটি পরিষ্কার revert-কে হারায় না।
- **Blast radius ও তীব্রতা।** একটি পূর্ণ outage দ্রুততম সম্ভব পুনরুদ্ধার দাবি করে (সাধারণত rollback); একটি গৌণ অবনতি একটি সতর্ক hotfix-এর সুযোগ দিতে পারে।

## একটি দ্রুত সিদ্ধান্ত টেবিল

| পরিস্থিতি | বেছে নিন |
| --- | --- |
| আগের সংস্করণ পরিচিত-ভালো, কোনো migration নেই | Rollback |
| অপরিবর্তনীয় DB migration ship হয়েছে | Hotfix / fix-forward |
| কারণ অজানা, তীব্র প্রভাব | Rollback (সময় কিনুন) |
| তুচ্ছ, ভালোভাবে-বোঝা এক-লাইনার | Hotfix |
| rollback নিজেই ঝুঁকিপূর্ণ/অপরীক্ষিত | Hotfix |

## Trade-off ও ভুলত্রুটি

- **Rollback** নিরাপদ কিন্তু কেবল উপসর্গের চিকিৎসা করে — আপনি এখনো একটি প্রকৃত fix ও একটি postmortem দেনা।
- **Hotfix** root cause-এর সমাধান করে কিন্তু স্বাভাবিক safety net এড়ায়; hotfix-এ bug সাধারণ ঠিক এ কারণেই যে সেগুলো তাড়াহুড়ো করে করা।
- **অপরীক্ষিত rollback path** একটি ফাঁদ — কখনো মহড়া না দিলে, এটি সবচেয়ে দরকারের সময় ব্যর্থ হতে পারে। দরকারের আগে rollback অনুশীলন করুন।
- চাপের মধ্যে **production-এ debugging** থেকে সাবধান; একটি আত্মবিশ্বাসী fix থেকে কয়েক মিনিটের বেশি দূরে থাকলে, rollback করুন এবং শান্তভাবে তদন্ত করুন।

## এটি কেন গুরুত্বপূর্ণ

এই সিদ্ধান্ত সবচেয়ে খারাপ সম্ভাব্য মুহূর্তে ঘটে — সিস্টেম বন্ধ, ঘড়ি চলছে, সবাই দেখছে। এর জন্য একটি স্পষ্ট, মহড়াপ্রাপ্ত নিয়মসহ একজন Tech Lead MTTR নাটকীয়ভাবে কমায় এবং সেই ক্লাসিক ভুল প্রতিরোধ করে যেখানে বিরক্তিকর revert ঠিক হাতের কাছে থাকা সত্ত্বেও incident-এর মাঝখানে চতুর হওয়ার চেষ্টা করা হয়। আগে পুনরুদ্ধার করুন, পরে বুদ্ধিমান হোন।

পরিস্থিতি	বেছে নিন
আগের সংস্করণ পরিচিত-ভালো, কোনো migration নেই	Rollback
অপরিবর্তনীয় DB migration ship হয়েছে	Hotfix / fix-forward
কারণ অজানা, তীব্র প্রভাব	Rollback (সময় কিনুন)
তুচ্ছ, ভালোভাবে-বোঝা এক-লাইনার	Hotfix
rollback নিজেই ঝুঁকিপূর্ণ/অপরীক্ষিত	Hotfix