১৬ আগ, ২০২৫·7 মিনিট
রোলব্যাক ড্রিল প্লেবুক: ৫ মিনিটে ত্রুটিপূর্ণ রিলিজ ফিরিয়ে আনা
এই রোলব্যাক ড্রিল ব্যবহার করে অনুশীলন করুন: কী স্ন্যাপশট নিতে হবে, কী যাচাই করতে হবে, এবং ড্রিল চলাকালীন কে কোন কিছুর জন্য ক্লিক করবে—সব মিলিয়ে ৫ মিনিটে ভাঙা রিলিজ ফিরিয়ে আনার রুটিন।
কেন রোলব্যাক ভীতিকর মনে হয় (এবং অনুশীলন কেন সাহায্য করে)
রিলিজ টেস্টিং-এ ঠিক দেখালেও বাস্তব ট্র্যাফিকের প্রথম পাঁচ মিনিটে এটি ভেঙে পড়তে পারে। ভয়ানক অংশটি সাধারণত বাগ নয়। সমস্যা হলো অনিশ্চয়তা: কী বদলেছে, কী নিরাপদে পূর্বাবস্থায় ফিরিয়ে আনা যায়, এবং রোলব্যাক করলে কি কাজ আরও খারাপ হয়ে যাবে।
রিলিজের ঠিক পরে ব্যর্থতাগুলো প্রায়ই সরল এবং স্পষ্টভাবে দৃশ্যমান। নতুন একটি বোতাম মোবাইলে পেজ ক্র্যাশ করতে পারে। ব্যাকএন্ড পরিবর্তন ভুল ডেটা স্ট্রাকচার পাঠাতে পারে, ফলে চেকআউট ব্যর্থ হয়। ছোট কনফিগ টুইক লগইন, ইমেল বা পেমেন্ট ভেঙে দিতে পারে। সমাধান সহজ হলেও, ব্যবহারকারীরা পর্যবেক্ষণ করছেন বলে চাপ তীব্র হয় এবং প্রতিটি মুহূর্ত মূল্যবান মনে হয়।
পैनिक তখন শুরু হয় যখন রোলব্যাক পথটি অনিশ্চিত থাকে। সবাই একই সময়ে একই প্রশ্ন করে: আমাদের কি স্ন্যাপশট আছে? কোন ভার্সন শেষবার ভাল ছিল? অ্যাপ ফিরিয়ে নিলে ডাটাবেস কী হবে? কার কাছে করতে পারে? যখন এসব উত্তর লেখা থাকে না, দল সময় নষ্ট করে বিতর্ক করতে থাকে পরিবর্তে সার্ভিস ফিরিয়ে আনার।
ঘটনার সময় অনুমান করার দাম বাস্তব: আপনি সময় হারান, ব্যবহারকারীরা আত্মবিশ্বাস হারায়, এবং তাড়াহুড়ো করে করা পরিবর্তন দ্বিতীয় আউটেজ সৃষ্টি করতে পারে। ইঞ্জিনিয়াররাও একসাথে অনেক দিক থেকে টানাহেঁচড়ায় খাপ খায়: ডিবাগিং, মেসেজিং এবং সিদ্ধান্ত নেওয়া।
একটি অনুশীলন রান মেজাজ বদলে দেয় কারণ এটি অনিশ্চয়তার জায়গায় মেসল মেমরি দেয়। একটি ভাল রোলব্যাক ড্রিল মাত্র "কোড রিভার্ট করা যায় কি না" বিষয়টি নয়। এটি একটি পুনরাবৃত্ত রুটিন: আপনি কী স্ন্যাপশট নিচ্ছেন, কী ফিরে আনছেন, কী যাচাই করছেন, এবং কারা কাজটি করতে পারবে। কয়েকটি ড্রিলের পর, রোলব্যাক ব্যর্থতা মনে হয় না—বরং এটি হয়ে ওঠে একটি সেফটি টুল।
যদি আপনার ডেপ্লয়মেন্ট সেটআপ ইতিমধ্যে স্ন্যাপশট ও রিস্টোর সমর্থন করে (কয়েকটি প্ল্যাটফর্ম, যার মধ্যে Koder.ai–ও আছে, এটি রিলিজ ফ্লো-এ বোঝায়), ড্রিলগুলো সহজ হয়ে যায় কারণ “জানা ভাল অবস্থায় ফিরে যাওয়া” একটি স্বাভাবিক অ্যাকশন হয়ে যায়, এক্সট্রা জরুরী প্রক্রিয়া নয়। যেকোনো পথে, লক্ষ্য একই: যখন সময় আসে, কাউকে ইমপ্রোভাইজ করতে হবে না।
“৫ মিনিটে পুনরুদ্ধার” আসলে কী বোঝায়
“৫ মিনিটে পুনরুদ্ধার” মানে সবকিছু আবার নিখুঁত হয়েছে এমন নয়। এর মানে আপনি দ্রুত ব্যবহারকারীদের একটি কাজ করা ভার্সনে ফিরিয়ে দিতে পারবেন, যদিও নতুন রিলিজটি এখনও ত্রুটিপূর্ণ থাকুক।
প্রথম সার্ভিস, পরে ফিক্স। যদি আপনি দ্রুত সার্ভিস ফিরিয়ে আনতে পারেন, আপনি শান্তভাবে খতিয়ে দেখবার সময় কিনে নেন।
৫ মিনিটটি বিতর্কের জন্য নয়, কাজ করার জন্য
টাইমার তখন শুরু হয় যখন আপনি সম্মত হন: “আমরা রোলব্যাক করছি।” এতে দীর্ঘ আলোচনা অন্তর্ভুক্ত নয় যে স্বয়ংক্রিয়ভাবে ঠিক হয়ে যেতে পারে কি না।
আগেই আপনার রোলব্যাক ট্রিগার ঠিক করে নিন। উদাহরণ: “ডেপ্লয়ের ৩ মিনিট পরে চেকআউটের ত্রুটি X%-এর উপর থাকলে আমরা রোলব্যাক করব।” ট্রিগার হিট করলে, স্ক্রিপ্ট অনুসরণ করুন।
কী গণ্য হবে ‘পুনরুদ্ধার’ হিসেবে
'পুনরুদ্ধার' হওয়া উচিত একটি ছোট সংকেত সেট যা বলে দেয় ব্যবহারকারীরা নিরাপদ এবং সিস্টেম স্থিতিশীল। এটিকে সীমিত এবং সহজে পরীক্ষা করা রাখুন:
- মূল ব্যবহারকারীর অ্যাকশন আবার কাজ করে (লগইন, চেকআউট, সার্চ, বা আপনার অ্যাপের প্রয়োজনীয় কাজ)
- ত্রুটি হার প্রায় স্বাভাবিকের কাছে ফিরে আসে
- ল্যাটেন্সি গ্রহণযোগ্য সীমায় আসে
- ক্র্যাশ লুপ বা রিস্টার্ট ঝড় না হয়
যখন ঐ সংকেতগুলো ভাল লাগে, ৫ মিনিটের টাইমার বন্ধ করুন। বাকিটা পরে করা যাবে।
ড্রিল সতর্ক রাখতে, স্পষ্টভাবে চিহ্নিত করুন আপনি ৫ মিনিটের পথে কী করছেন না: গভীর ডিবাগিং, কোড পরিবর্তন বা হটফিক্স রিলিজ, এবং যেকোনো কাজ যা ইঞ্জিনিয়ারিং কাজ হয়ে যায়।
একটি পুনরাবৃত্ত পদ্ধতি বেছে নিন যা দল বারবার করতে পারে
একটি রোলব্যাক তখনই দ্রুত অনুভূত হয় যখন সিদ্ধান্তটি বেশিরভাগ সময়ে পূর্ব-নির্ধারিত থাকে। এমন একটি পদ্ধতি বেছে নিন যা বেশিরভাগ ঘটনার জন্য কাজ করে, তারপর এটিকে এত অনুশীলন করুন যে এটি বিরক্তিকর হয়ে ওঠে।
আপনার ড্রিলকে চারটি প্রশ্নের উত্তর দিতে হবে:
- আমরা রোলব্যাক করব না হটফিক্স করব?
- আমরা কোনটাতে রোলব্যাক করব?
- রোলব্যাকের ট্রিগার কী?
- কার কাছে “করো” বলার ক্ষমতা আছে?
রোলব্যাক বনাম হটফিক্স: ডিফল্ট বেছে নিন
রোলব্যাক সবচেয়ে ভালো যখন নতুন রিলিজ ব্যবহারকারীদের বা ডেটাকে সক্রিয়ভাবে ক্ষতিগ্রস্ত করছে এবং আপনার কাছে ইতিমধ্যে একটি জানা-ভাল ভার্সন আছে। হটফিক্স তখনই ভাল যখন প্রভাব ছোট, পরিবর্তন বিচ্ছিন্ন এবং আপনি নিরাপদে প্যাচ করতে আত্মবিশ্বাসী।
একটি সহজ ডিফল্ট ভালো কাজ করে: যদি ব্যবহারকারীরা মূল অ্যাকশন সম্পন্ন করতে না পারে (চেকআউট, লগইন, সাইনআপ) বা ত্রুটি হার বাড়ে, প্রথমে রোলব্যাক করুন এবং পরে ফিক্স করুন। হটফিক্সগুলো রাখুন সেই সমস্যাগুলোর জন্য যা বিরক্তিকর কিন্তু বিপজ্জনক নয়।
রোলব্যাক টার্গেট বেছে নিন
আপনার “টার্গেট” এমন কিছু হওয়া উচিত যা দল কয়েক সেকেন্ডে বেছে নিতে পারে, বিতর্ক ছাড়া। বেশিরভাগ দল তিনটি সাধারণ টার্গেট পায়:
- আগের ভার্সন (শেষ রিলিজ যা চেক পাস করেছিল)
- একটি ডেপ্লয়মেন্ট স্ন্যাপশট যা আপনি রিস্টোর করতে পারেন
- কনফিগ-শুধু রোলব্যাক (ফিচার ফ্ল্যাগ বা এনভায়রনমেন্ট পরিবর্তন)
যদি আপনার কাছে নির্ভরযোগ্য ডেপ্লয়মেন্ট স্ন্যাপশট থাকে, সেটিকে ডিফল্ট করুন কারণ এটি চাপের নিচেও সবচেয়ে পুনরাবৃত্তি যোগ্য। কনফিগ-শুধু রুট রেখে দিন সেই ক্ষেত্রে যেখানে কোড ঠিক আছে কিন্তু সেটিং ভুল।
এছাড়াও “আগের ভালো” কী গণ্য সেইটা সংজ্ঞায়িত করুন। এটি হওয়া উচিত সর্বশেষ রিলিজ যা মনিটরিং চেক পাস করেছে এবং কোন সক্রিয় ইনসিডেন্ট ছিল না—না যে ভার্সনটি সবাই মনে রাখে।
ট্রিগার ও কর্তৃত্ব নির্ধারণ করুন
ঘটনার সময় মিটিংয়ের জন্য অপেক্ষা কেবল করবেন না। সেই ট্রিগারগুলো লিখে রাখুন যা রোলব্যাক শুরু করবে এবং সেগুলো মানুন। সাধারণ ট্রিগার: কয়েক মিনিট ধরে প্রধান ফ্লো ভাঙা, ত্রুটি হার বা ল্যাটেন্সি নির্ধারিত থ্রেশহোল্ড অতিক্রম করা, ডেটা ঝুঁকি (ভুল রাইট, ডুপ্লিকেট চার্জ), এবং রিলিজ দ্বারা প্রবর্তিত কোনও নিরাপত্তা/গোপনীয়তা উদ্বেগ।
এরপর ঠিক করুন কে রোলব্যাক অনুমোদন করতে পারে। একটি ভূমিকা বেছে নিন (ইনসিডেন্ট লিড বা অন-কল), সাথে একটি ব্যাকআপ। বাকিরা পরামর্শ দিতে পারে, কিন্তু তারা ব্লক করতে পারবে না। যখন ট্রিগার হিট করে এবং অনুমোদক বলে “রোলব্যাক”, দল প্রত্যেকবারই একই ধাপ চালাবে।
প্রতিটি রিলিজের আগে কী স্ন্যাপশট নিতে হবে
রোলব্যাক ড্রিল শুধু কাজ করে যদি আপনি দ্রুত একটি জানা-ভাল অবস্থায় ফিরিয়ে আনতে পারেন। স্ন্যাপশটগুলো কেবল “ভালো থাকলে” নয়—এগুলো সেই রসিদ যা প্রমাণ করে কী রান করছিল, কী বদলেছে, এবং কীভাবে ফিরে যাওয়া যায়।
ধরার জন্য পাঁচটি জিনিস
প্রতিটি রিলিজের আগে নিশ্চিত করুন আপনি এই আইটেমগুলো ছাড়া সারিবদ্ধ না হয়ে খুঁজতে হবে:
- আপনি যে ঠিক ওই অ্যাপ বিল্ড শিপ করেছেন: commit hash, ভার্সন নম্বর, এবং বিল্ড আর্টিফ্যাক্ট (কন্টেইনার ট্যাগ, বান্ডেল, বা প্যাকেজ)।
- ডাটাবেস অবস্থা এবং মাইগ্রেশন প্লান: কোন মাইগ্রেশনগুলো অ্যাপ্লাই করা হয়েছে, এবং সেগুলো উল্টানো যায় কি না। ঝুঁকিপূর্ণ পরিবর্তনের জন্য দ্রুত রেস্টোরযোগ্য ব্যাকআপ নিন।
- ডিপ্লয় টাইম কনফিগারেশন: ফিচার ফ্ল্যাগ, এনভায়রনমেন্ট ভেরিয়েবল, তৃতীয় পক্ষের এন্ডপয়েন্ট, এবং কী পরিবর্তিত হয়েছে। সিক্রেটগুলো নিরাপদ সিস্টেমে থাকবে, কিন্তু আপনি এখনও ভার্সনকৃত রেকর্ড রাখতে হবে।
- ইনফ্রা ও রাউটিং সেটিংস: ডোমেইন, সার্টিফিকেট, লোড ব্যালানসার নিয়ম, এবং ট্র্যাফিক কোথায় যায় সেই সুইচগুলো।
- একটি সংক্ষিপ্ত রিলিজ নোট: এক বাক্যে কী বদলেছে, এবং এক বাক্যে কীভাবে সফল রোলব্যাক যাচাই করবেন।
ডাটাবেস সেফটি হচ্ছে সর্বাধিক ফাঁদ। দ্রুত অ্যাপ রোলব্যাক কাজে আসবে না যদি ডাটাবেস এখন নতুন স্কিমা আশা করে। ঝুঁকিপূর্ণ মাইগ্রেশনের জন্য দুই-ধাপ রিলিজ প্ল্যান করুন (প্রথমে নতুন ফিল্ড যোগ করুন, পরে সেগুলো ব্যবহার শুরু করুন) যাতে রোলব্যাক সম্ভব থাকে।
স্ন্যাপশটগুলোর নাম রাখুন যেন সেকেন্ডের মধ্যে খুঁজে পাওয়া যায়
সবার জন্য একটি নামকরণ নিয়ম ব্যবহার করুন এবং সেটিকে sortable রাখুন:
prod-2026-01-09-1420-v1.8.3-commitA1B2C3
এখানে পরিবেশ, টাইমস্ট্যাম্প, ভার্সন, এবং কমিট অন্তর্ভুক্ত করুন। যদি আপনার টুল UI-তে স্ন্যাপশট সমর্থন করে, সেখানে একই নামকরণ ব্যবহার করুন যেন কেউ সঠিক রিস্টোর পয়েন্ট দ্রুত খুঁজে পায়।
ভূমিকা: কে কী ক্লিক করবে (আর কে শুধু দেখবে)
আপনার প্রথম রোলব্যাক ড্রিল চালান
একটি ছোট অ্যাপ তৈরি করে সম্পূর্ণ রিস্টোর ফ্লো কিছু মিনিটে অনুশীলন করুন।
রোলব্যাক ড্রিল দ্রুত এবং শান্ত হয় যখন সবাই তাদের লেন জানে। লক্ষ্য সবাই ঝাঁপ দেয়া নয়। এটি এক ব্যক্তি সিদ্ধান্ত নেয়া, এক ব্যক্তি কাজ করে, এক ব্যক্তি যাচাই করে, এবং এক ব্যক্তি অন্যদের জানায়—এইভাবে কাজ দ্রুত হয়।
স্মল বা মিড-সাইজ টিমের জন্য এসব ভূমিকা কাজে দেয় (একজন একাধিক ভূমিকা নিতে পারে, তবে ড্রিল চলাকালীন Deployer এবং Verifier একসাথে না হওয়া ভালো):
- ইনসিডেন্ট লিড (টাইমকিপার ও সিদ্ধান্ত গ্রহণকারী): সফলতার টার্গেট বলে এবং রোলব্যাক ঘোষণা করে।
- ডিপ্লয়র (হাত কীবোর্ডে): রোলব্যাক ধাপ সম্পাদন করে ঠিক যেমন লিখে আছে এবং যা করছে তা aloud বলে।
- ভেরিফায়ার (প্রমাণ যে কাজ করেছে): must-pass চেকগুলো চালায় এবং প্রধান সংকেতগুলো দেখে।
- কমিউনিকেটর (বাহ্যিকভাবে এক কণ্ঠ): স্টেকহোল্ডার ও সাপোর্টকে সংক্ষিপ্ত, নিয়মিত আপডেট দেয়।
পারমিশনই ঠিক করে দেয় এই প্ল্যান বাস্তব হবে কি না। ড্রিলের আগে সম্মত হন কাকে প্রোডuction রোলব্যাক করার অধিকার আছে, এবং জরুরি সময় কিভাবে কাজ করবে।
একটি সাদামাটা সেটআপ:
- ডিপ্লয়রকে অন-কল রোটেশন বা নির্ধারিত ড্রিল উইন্ডোতে রোলব্যাক রাইট দিন।
- ইনসিডেন্ট লিড অনুমোদন করতে পারে (যদি তাদের বোতাম না থাকে তবুও)।
- ভেরিফায়ারকে ড্যাশবোর্ড ও লগস-এ রিড-অনলি অ্যাক্সেস দিন।
- একটি ব্রেক-গ্লাস অপশন সেট করুন (অডিটেড, সময়-সীমিত অ্যাক্সেস)।
- ড্রিল সেটআপের সময় অ্যাক্সেস টেস্ট করুন, ৫ মিনিটের টাইমারের সময় নয়।
আপনি যদি এমন একটি প্ল্যাটফর্ম ব্যবহার করেন যা স্ন্যাপশট ও রিস্টোর সমর্থন করে (Koder.ai-সহ), ঠিক করুন কে স্ন্যাপশট তৈরি করবে, কে রিস্টোর করবে, এবং সেটি কোথায় রেকর্ড হবে।
ধাপে ধাপে: রোলব্যাক ড্রিল রানবুক
রোলব্যাক ড্রিল সবথেকে ভালো কাজ করে যখন এটি একটি ফায়ার ড্রিলের মতো অনুভব হয়: একই ধাপ, একই শব্দ, একই জায়গায় ক্লিক করার পয়েন্ট। লক্ষ্য পারফেকশন নয়—হয় যে অন-কল যে কেউ দ্রুত শেষ জানেন ভাল ভার্সন ফিরিয়ে দিতে পারবে, বিতর্ক না করে।
শুরু করার আগে
একটি স্পষ্ট ট্রিগার বেছে নিন এবং ড্রিল শুরু হলে তা জোর করে বলুন। উদাহরণ: “চেকআউট ১ মিনিটের বেশি 500 রিটার্ন করছে” বা “ডেপ্লয়ের পর ত্রুটি হার ৫x বেড়ে গেছে।” তা জোর করে বলা দলেরকে ট্রাবলশুটিং মোডে ভাসতে বাধা দেয়।
রানবুকের পাশে একটি ছোট প্রিপ চেকলিস্ট রাখুন:
- লাইভ হেলথ সংকেত দেখা যাচ্ছে কি (আপটাইম, ত্রুটি হার, কিয়া ইউজার ফ্লো)
- শেষ জানা ভাল ভার্সন শনাক্ত আছে কি (ট্যাগ, বিল্ড, স্ন্যাপশট নাম)
- রোলব্যাক কোথায় চালানো হবে (CI/CD, হোস্টিং কনসোল, প্ল্যাটফর্ম UI)
- নতুন ডিপ্লয় কিভাবে পজ করবেন
- টাইমস্ট্যাম্প কে রেকর্ড করবে
৫ মিনিটের রানবুক
-
টাইমার শুরু করুন। একজন ব্যক্তিই ট্রিগার ও সিদ্ধান্ত বলবে: “আমরা এখনই রোলব্যাক করছি।”
-
পরিবর্তন ফ্রিজ করুন। নতুন ডিপ্লয় পজ করুন এবং অপ্রয়োজনীয় এডিট বন্ধ করুন যা রোলব্যাকের মাঝখানে সিস্টেম বদলে দিতে পারে।
-
একটি শেষ-চান্স স্ন্যাপশট নিন (যদি নিরাপদ এবং দ্রুত হয়)। এটি ক্ষতিগ্রস্ত অবস্থা পরে পুনরায় তৈরি করার ক্ষেত্রে সুরক্ষা। স্পষ্টভাবে নাম দিন এবং এগিয়ে যান।
-
রোলব্যাক কাজটি সঠিকভাবে ডকুমেন্ট করা অনুযায়ী চালান। ইম্প্রোভাইজ করবেন না। নিশ্চিতকরণ প্রম্পটগুলো উচ্চস্বরে বলুন যাতে রেকর্ডার কি ঘটলো ক্যাপচার করতে পারে।
-
একটি বিশ্বাসযোগ্য স্থানে রোলব্যাক সম্পন্ন হয়েছে নিশ্চিত করুন। প্রতিবার এক স্ক্রীন ও এক সংকেত ব্যবহার করুন (ডেপ্লয়মেন্ট হিস্ট্রি ভিউ, “অফশত ভার্সন” লেবেল, বা স্পষ্ট স্ট্যাটাস ইনডিকেটর)।
কর্মপরবর্তী হিসেবে, জিনিসগুলো যখন তাজা, তখনই যা গুরুত্বপূর্ণ তা ক্যাপচার করুন:
- সিদ্ধান্তের সময় (ট্রিগার ঘোষিত)
- রোলব্যাক শুরুর সময় (প্রথম ক্লিক/কমান্ড)
- রোলব্যাক সম্পন্ন সময় (আগের ভার্সন সক্রিয়)
- প্রথম গ্রীন ভেরিফিকেশন সময় (কী চেক পাস)
- কোনো অপ্রত্যাশিত সমস্যা (অনুপস্থিত পারমিশন, অস্পষ্ট বোতাম, ধীর ধাপ)
যদি রোলব্যাক ৫ মিনিটের বেশি সময় নেয়, তা পাত্তা দিয়ে বিবৃতি দেবেন না। ধীর ধাপটি খুঁজে বের করুন, রানবুক ঠিক করুন, এবং ড্রিলটি পুনরায় চালান।
রোলব্যাকের পরে কী যাচাই করবেন
রোলব্যাককে রুটিনে পরিণত করুন
নিয়মিতভাবে পরিচিত-ভাল ভার্সন ডিপ্লয় করে রোলব্যাক অনুশীলন করুন—চাপে আলোচনা নয়।
রোলব্যাক তখনই “কর্ম করেছে” যখন ব্যবহারকারীরা অনুভব করে এটি কাজ করেছে। আপনি প্রমাণ করার চেষ্টা করছেন না যে পুরানো ভার্সন ডিপ্লয় হয়েছে—আপনি প্রমাণ করছেন সার্ভিস আবার ব্যবহারযোগ্য এবং স্থিতিশীল।
জাচাই ছোট এবং পুনরাবৃত্তিযোগ্য রাখুন। তালিকা পাঁচটার বেশি হলে লোকেরা চাপের মধ্যে তা এড়িয়ে যাবে।
৩–৫টি অবশ্যই পাস করা চেক
দ্রুত চালানোর যোগ্য এমন চেক ব্যবহার করুন, স্পষ্ট পাস/ফেইল সহ:
- ব্যবহারকারী লগইন (বা সাইনআপ) করে হোম স্ক্রীনে কোনো ত্রুটি ছাড়া পৌঁছাতে পারে
- কোর ট্রানজেকশন কাজ করে (চেকআউট, বুকিং, ফরম সাবমিট)
- একটি কেবল-কী API এন্ডপয়েন্ট 200 রিটার্ন করে এবং রেসপন্স সাধারণ লাগে
- адমিন/সাপোর্ট একটি গুরুত্বপূর্ণ কাজ করতে পারে (রিফান্ড, ক্যানসেল, স্ট্যাটাস আপডেট)
- একটি প্রায়শই ভাঙা এজ ফ্লো (পাসওয়ার্ড রিসেট, ফাইল আপলোড, সার্চ) কাজ করে
ফাংশনাল চেকগুলো পরে, আপনি বিশ্বাসযোগ্য সবচেয়ে সহজ সিস্টেম হেলথ সংকেতে এক নজর দেবেন। আপনি দেখতে চান ত্রুটি হার কয়েক মিনিটের মধ্যে স্বাভাবিক নিকট ফিরে আসে এবং ল্যাটেন্সি স্পাইক বন্ধ হয়।
এছাড়াও নিশ্চিত করুন যে অদৃশ্য অংশগুলো আবার চলে। ব্যাকগ্রাউন্ড জবগুলো প্রসেস করছে এবং কিউগুলো প্রবাহিত হচ্ছে, বাড়ছে না। ডাটাবেস চেক দ্রুত এবং বিরক্তিকর হওয়া উচিত: কানেকশন স্থিতিশীল, কোনো স্পষ্ট লক জমা নেই, এবং অ্যাপ লিখতে পারে।
অবশেষে, বাহ্যিক জয়েন্টগুলো যেখানে গুরুত্বপূর্ণ সেগুলো টেস্ট করুন—সেফলি করতে পারেন কিনা দেখে একটি পেমেন্ট টেস্ট চালান, ইমেল ডেলিভারি ঠিক আছে কিনা নিশ্চিত করুন, এবং নিশ্চিত করুন ওয়েবহুকস গ্রহণ করা হচ্ছে (অথবা অন্তত ব্যর্থ হচ্ছে না)।
“অল ক্লিয়ার” বার্তা কী হবে তা সিদ্ধান্ত নিন
আগে থেকে একটি বাক্য লিখে রাখুন যাতে কেউ ইমপ্রোভাইজ না করে:
“Rollback complete. Core flows verified (login + checkout). Error rate and latency back to normal. Monitoring for 30 minutes. Next update at 14:30.”
উদাহরণ: একটি ভাঙা রিলিজ এবং একটি পরিষ্কার ৫-মিনিটের রিস্টোর
মঙ্গলবার বিকাল ১০:০২. একটি নতুন রিলিজ যায় আউট, এবং এক মিনিটের মধ্যে কিছু ব্যবহারকারী লগইন করতে পারে না। কারো কাছে “invalid session” আসে, অন্যের কাছে একটি স্পিনার ধরে থাকে। সাইনআপ কাজ করে, তাই সমস্যা প্রথমে সহজে ছাপা পড়ে না।
প্রথম সিগন্যাল সাধারণত নাটকীয় নয়। এটি একটি নীরব স্পাইক: সাপোর্ট টিকেট, সফল লগইনের সংখ্যা কমা, এবং কিছু রাগান্বিত বার্তা। অন-কল দেখে “login success rate down 18% in 5 minutes” অ্যালার্ট এবং সাপোর্ট পোস্ট করে: “3 ব্যবহারকারী আপডেট করার পর লগইন করতে পারছেন না।”
৫-মিনিটের রিস্টোর (কেমন হতে পারে)
দলেও দলটি ড্রিল অনুশীলন করেছে, তাই তারা দীর্ঘ বিতর্কে ঝামেলা করে না। তারা নিশ্চিত করে, সিদ্ধান্ত নেয়, এবং কাজ করে।
- 10:03: অন-কল নিশ্চিত করে এবং একজন ইনসিডেন্ট লিড নিয়োগ করে।
- 10:04: রোলব্যাকের সিদ্ধান্ত। নিয়ম: লগইন ভাঙলে এবং ২ মিনিটে নিরাপদ ফিক্স না থাকলে রোলব্যাক।
- 10:05: ডিপ্লয়র পূর্বের জানা-ভাল স্ন্যাপশট-এ রোলব্যাক ট্রিগার করে।
- 10:06: ট্রাফিক পূর্বের ভার্সনে ফিরে যায়। দল ওয়েব ও মোবাইলে লগইন পুনরায় টেস্ট করে।
- 10:07: ইনসিডেন্ট লিড পোস্ট করে “Login restored, monitoring for 10 minutes” এবং সাপোর্টকে অনুরোধ করে প্রভাবিত ব্যবহারকারীদের উত্তর দিতে।
কি রোলব্যাক করা হয়েছিল: ওয়েব ও API সার্ভিসের অ্যাপ কোড ও কনফিগ। যা অপরিবর্তিত থাকে: ডাটাবেস ও ব্যবহারকারী ডেটা।
যদি রিলিজে ডাটাবেস মাইগ্রেশন থাকত, ড্রিল নিয়ম সহজ: ৫-মিনিটের পথে ডাটাবেস কখনই রোলব্যাক করবেন না। মাইগ্রেশন ব্যাকওয়ার্ড-কম্প্যাটিবল রাখুন, অথবা ডিপ্লয়ের আগে দ্বিতীয় চোখ নিন।
কি সংযুক্ত করা হয় (দৌরান এবং পরে)
রোলব্যাক চলাকালীন, ইনসিডেন্ট লিড সংক্ষিপ্ত আপডেট প্রতি কয়েক মিনিটে পোস্ট করে: ব্যবহারকারীরা কি দেখছে, কী অ্যাকশন হচ্ছে, এবং পরবর্তী আপডেট কখন। উদাহরণ: “We are rolling back the last release to restore login. Next update in 2 minutes.”
রোলব্যাকের পরে, তারা লুপ বন্ধ করে: “Login is back to normal. Root cause review is in progress. We will share what happened and what we changed to prevent repeats.”
সাধারণ রোলব্যাক ড্রিলের ভুলগুলো (এবং সহজ সমাধান)
যেভাবে বিল্ড করবেন, ঠিক তেমনই রনবুক লিখুন
প্রোডাকশনে নামানোর আগে রিলিজ ধাপ ও যাচাইকরণ চেকগুলো প্ল্যান করুন।
রোলব্যাক ড্রিলটি বিরক্তিকর হওয়া উচিত। যদি এটি উদ্বেগজনক লাগে, ড্রিল সম্ভবত প্রকৃত ফাঁকগুলো উন্মোচন করছে: অ্যাক্সেস, অনুপস্থিত স্ন্যাপশট, বা সেই ধাপগুলো যা কেবল কারো মস্তিষ্কে আছে।
মিনিট নষ্ট করা ভুলগুলো
-
আপনি অনুমানকৃত অ্যাক্সেস দিয়ে অনুশীলন করেন, বাস্তব পারমিশন নয়। মানুষ ঘটনাকালে আবিষ্কার করে তারা ডিপ্লয় করতে পারে না, কনফিগ বদলাতে পারে না, বা ড্যাশবোর্ডে পৌঁছাতে পারে না। সমাধান: একই অ্যাকাউন্ট ও রোল নিয়ে ড্রিল চালান যা আপনি বাস্তবে ব্যবহার করবেন।
-
স্ন্যাপশট আছে, কিন্তু অসম্পূর্ণ বা খুঁজতে কঠিন। দল অ্যাপ স্ন্যাপশট করে কিন্তু env পরিবর্তন, ফিচার ফ্ল্যাগ, বা রাউটিং ভুলে যায়। অথবা স্ন্যাপশটের নাম অর্থহীন। সমাধান: স্ন্যাপশট তৈরি করা একটি রিলিজ ধাপ করুন নামকরণ নিয়ম সহ এবং ড্রিলে যাচাই করুন স্ন্যাপশট দৃশ্যমান এবং দ্রুত রিস্টোরযোগ্য।
-
ডাটাবেস মাইগ্রেশন রোলব্যাককে অনিরাপদ করে দেয়। ব্যাকওয়ার্ড-কম্প্যাটিবল নয় এমন স্কিমা একটি দ্রুত রোলব্য্যাককে ডেটা সমস্যায় পরিণত করে। সমাধান: অ্যাডিটিভ মাইগ্রেশন প্রাধান্য দিন। যদি ব্ৰেকিং পরিবর্তন অপরিহার্য, রিলিজটিকে পরিষ্কারভাবে লেবেল করুন: “rollback allowed: yes/no।”
-
আপনি সফলতা ঘোষণা করেন ব্যবহারকারী কি অনুভব করে তা পরীক্ষা না করে। অ্যাপ ডিপ্লয় হয়েছে, কিন্তু লগইন এখনও ভাঙা বা জব আটকে আছে। সমাধান: যাচাইকরণ সংক্ষিপ্ত কিন্তু বাস্তব রাখুন এবং টাইমবক্স করুন।
-
ড্রিলটি বারবার করা কঠিন। অনেকগুলি টুল, অনেক চেক, অনেক কণ্ঠ। সমাধান: ড্রিলটি এক পৃষ্ঠায় সংকুচিত করুন এবং এক মালিক রাখুন। যদি এটি এক রানবুক ও এক কমিউনিকেশন চ্যানেল থেকে করা যায় না, চাপের মধ্যে এটি ঘটবে না।
একটি ভাল রোলব্যাক ড্রিল অভ্যাস; কোনো নায়কোচিত প্রদর্শনী নয়। যদি আপনি শান্তভাবে শেষ করতে না পারেন, ধাপগুলো কমান যতক্ষণ না করতে পারেন, তারপর কেবল সেইগুলো যোগ করুন যা বাস্তবে ঝুঁকি কমায়।
দ্রুত চেকলিস্ট এবং পরবর্তী ধাপ
রোলব্যাক ড্রিল সবচেয়ে ভালো কাজ করে যখন সবাই একই এক-পৃষ্ঠার চেকলিস্ট অনুসরণ করে। এটি যেখানে দল বাস্তবে দেখে সেখানে পিন করে রাখুন।
একটি সঙ্কুচিত সংস্করণ যা ১০ মিনিটের মধ্যে চালানো যায় (সেটআপ ও যাচাইকরণসহ):
- রিলিজের আগে: রোলব্যাক পয়েন্ট (স্ন্যাপশট/ভার্সন) নিশ্চিত করুন, প্রত্যাশিত “ভালো” আচরণ রেকর্ড করুন, ভূমিকা বরাদ্দ করুন (ডিপ্লয়র, ভেরিফায়ার, কমস)।
- ট্রিগার: “রোলব্যাক শুরু” ঘোষণা করুন, টাইমার চালু করুন, নতুন ডিপ্লয় ফ্রিজ করুন।
- রোলব্যাক অ্যাকশন: শেষ জানা-ভাল রিলিজ রিস্টোর করুন, কী ক্লিক করা হলো এবং কোন ক্রমে রেকর্ড করুন।
- যাচাই: 2-3 গুরুত্বপূর্ণ চেক চালান (লগইন, মূল ওয়ার্কফ্লো, একটি ইন্টিগ্রেশন/এপিআই চেক), ত্রুটি হার কমা নিশ্চিত করুন।
- ক্লোজ: “সার্ভিস স্থিতিশীল” ঘোষণা করুন, তিনটি নোট লিখুন (কি কাজ করেছে, কি ধীর করেছে, কি পরিবর্তন করবেন), এবং ডিপ্লয় আনফ্রিজ করুন।
ড্রিলগুলো এত ঘন ঘন চালান যাতে ধাপগুলো স্বাভাবিক লাগে। মাসিক একটি ভাল ডিফল্ট। যদি আপনার প্রোডাক্ট প্রতিদিন বদলে, প্রতি দুই সপ্তাহে চালান, কিন্তু যাচাইকরণকে প্রধান ব্যবহারকারীর পথে কেন্দ্রিত রাখুন।
প্রতি ড্রিলের পরে, একই দিন রানবুক আপডেট করুন যখন এটি তাজা থাক
ুন। এটিকে রিলিজ নোটের সাথে সংরক্ষণ করুন এবং "last tested" লাইন যোগ করুন যাতে কেউ পুরনো প্রক্রিয়া বিশ্বাস না করে।
পরিমাপ কেবল সেইগুলো করুন যা উন্নতিতে সাহায্য করে:
- Time-to-rollback (ঘোষণা থেকে পুনরুদ্ধার)
- Time-to-verify (পুনরুদ্ধার থেকে স্থিতিশীল)
- ভূমিকা স্পষ্টতা (কোথায় মানুষ ভোগান্তি পেয়েছে বা কাজ দুভাব করে করেছে?)
- অনুপস্থিত তথ্য (ক্রেডেনশিয়ালস, পারমিশন, স্ন্যাপশট লোকেশন)
যদি আপনার দল Koder.ai-এ নির্মাণ করে, স্ন্যাপশট ও রোলব্যাককে অভ্যাসের অংশ হিসেবে নিন: স্ন্যাপশটগুলো ধারাবাহিকভাবে নামান, একই ইন্টারফেসে রিস্টোর অনুশীলন করুন যা আপনি অন-কল সময়ে ব্যবহার করবেন, এবং ভেরিফায়ার ধাপগুলোতে কাস্টম-ডোমেইন ও ইন্টিগ্রেশন চেকগুলো অন্তর্ভুক্ত করুন। রনবুকে এভাবে উল্লেখ রাখলেই ড্রিল আপনার আসল শিপিং পদ্ধতির সাথে সঙ্গতে থাকবে।
সাধারণ প্রশ্ন
রোলব্যাক ড্রিল কি, এবং এটি কী সমস্যা সমাধান করে?
A rollback drill is a practice run where you simulate a bad release and follow a written routine to restore the last known-good version.
The goal isn’t to “debug fast”—it’s to make restoring service repeatable and calm under pressure.
কখন আমরা হটফিক্সের বদলে রোলব্যাক করব?
Use a pre-set trigger so you don’t debate in the moment. Common defaults:
- Core flow broken (login/checkout/signup) for more than a couple minutes
- Error rate or latency spikes past an agreed threshold
- Any risk of bad writes, duplicate charges, or privacy/security issues
If the trigger hits, roll back first, then investigate after users are safe.
“৫ মিনিটে পুনরুদ্ধার” আসলে কী বোঝায়?
It means you can get users back onto a working version quickly—even if the new release is still broken.
In practice, “restored” is when a small set of signals look healthy again (core user action works, error rate and latency return near normal, no crash loop).
আমাদের ডিফল্ট রোলব্যাক টার্গেট কী হওয়া উচিত?
Pick a target you can select in seconds, without discussion:
- The previous release that passed checks
- A named deployment snapshot you can restore
- A config-only rollback (feature flag/env change) when code is fine
Define “previous good” as the most recent release with normal monitoring and no active incident—not the one people remember.
প্রতিটি রিলিজের আগে কী কী স্ন্যাপশট রাখা উচিত?
At minimum, capture these before every release:
- Shipped build identifier (version + commit + artifact tag)
- Database migration status and whether it’s reversible
- Deploy-time configuration (flags, env vars, endpoints) with versioned changes
- Routing/infra switches (domains, certificates, load balancer rules)
- A short release note: what changed + how to verify rollback success
Database changes are the common trap—an app rollback may not work if the schema isn’t compatible.
কিভাবে স্ন্যাপশটের নাম রাখলে দ্রুত খুঁজে পাওয়া যায়?
Name them so they sort and can be found fast, for example:
prod-YYYY-MM-DD-HHMM-vX.Y.Z-commitABC123
Include environment + timestamp + version + commit. Consistency matters more than the exact format.
রোলব্যাক ড্রিলের সময় কে কী করবে?
A simple, repeatable split for small teams:
- Incident lead: decides and keeps time
- Deployer: executes the rollback steps
- Verifier: runs the must-pass checks and watches signals
- Communicator: posts short updates to stakeholders/support
Avoid having the Deployer also be the Verifier during drills; you want an independent “did it really work?” check.
রোলব্যাক সফল হয়েছে কি না যাচাই করার জন্য সর্বনিম্ন চেকগুলো কী?
Keep it tiny and pass/fail. Good must-pass checks include:
- Login works end-to-end
- Core transaction works (checkout/booking/form submit)
- One key API endpoint returns a normal 200 response
- One critical admin/support action works (refund/cancel/status update)
- One fragile edge flow still works (password reset/upload/search)
Then confirm error rate and latency settle back near normal, and queues/jobs aren’t backing up.
কিভাবে ডাটাবেস মাইগ্রেশনে আচরিত করলে রোলব্যাক নিরাপদ থাকবে?
Don’t make “rollback the database” part of the 5-minute path. Instead:
- Prefer backward-compatible (additive) migrations so old code still runs
- Use a two-step release: add fields first, start using them later
- If a breaking migration is unavoidable, label the release clearly as “rollback safe: yes/no” and plan a forward fix
This keeps the quick rollback path safe and predictable.
আমরা যদি Koder.ai ব্যবহার করি, স্ন্যাপশট এবং রোলব্যাক কিভাবে কাজ করে?
If your platform supports snapshots and restore as part of the release flow, drills get easier because “go back to known good” is a normal action.
On Koder.ai specifically, decide ahead of time:
- Who can create snapshots and who can restore them
- Where the restore action is recorded
- Which quick verifications you’ll always run (including custom domain and key integrations)
The drill still needs roles, triggers, and a short verification list—tools don’t replace the routine.