এই রোলব্যাক ড্রিল ব্যবহার করে অনুশীলন করুন: কী স্ন্যাপশট নিতে হবে, কী যাচাই করতে হবে, এবং ড্রিল চলাকালীন কে কোন কিছুর জন্য ক্লিক করবে—সব মিলিয়ে ৫ মিনিটে ভাঙা রিলিজ ফিরিয়ে আনার রুটিন।
রিলিজ টেস্টিং-এ ঠিক দেখালেও বাস্তব ট্র্যাফিকের প্রথম পাঁচ মিনিটে এটি ভেঙে পড়তে পারে। ভয়ানক অংশটি সাধারণত বাগ নয়। সমস্যা হলো অনিশ্চয়তা: কী বদলেছে, কী নিরাপদে পূর্বাবস্থায় ফিরিয়ে আনা যায়, এবং রোলব্যাক করলে কি কাজ আরও খারাপ হয়ে যাবে।
রিলিজের ঠিক পরে ব্যর্থতাগুলো প্রায়ই সরল এবং স্পষ্টভাবে দৃশ্যমান। নতুন একটি বোতাম মোবাইলে পেজ ক্র্যাশ করতে পারে। ব্যাকএন্ড পরিবর্তন ভুল ডেটা স্ট্রাকচার পাঠাতে পারে, ফলে চেকআউট ব্যর্থ হয়। ছোট কনফিগ টুইক লগইন, ইমেল বা পেমেন্ট ভেঙে দিতে পারে। সমাধান সহজ হলেও, ব্যবহারকারীরা পর্যবেক্ষণ করছেন বলে চাপ তীব্র হয় এবং প্রতিটি মুহূর্ত মূল্যবান মনে হয়।
পैनिक তখন শুরু হয় যখন রোলব্যাক পথটি অনিশ্চিত থাকে। সবাই একই সময়ে একই প্রশ্ন করে: আমাদের কি স্ন্যাপশট আছে? কোন ভার্সন শেষবার ভাল ছিল? অ্যাপ ফিরিয়ে নিলে ডাটাবেস কী হবে? কার কাছে করতে পারে? যখন এসব উত্তর লেখা থাকে না, দল সময় নষ্ট করে বিতর্ক করতে থাকে পরিবর্তে সার্ভিস ফিরিয়ে আনার।
ঘটনার সময় অনুমান করার দাম বাস্তব: আপনি সময় হারান, ব্যবহারকারীরা আত্মবিশ্বাস হারায়, এবং তাড়াহুড়ো করে করা পরিবর্তন দ্বিতীয় আউটেজ সৃষ্টি করতে পারে। ইঞ্জিনিয়াররাও একসাথে অনেক দিক থেকে টানাহেঁচড়ায় খাপ খায়: ডিবাগিং, মেসেজিং এবং সিদ্ধান্ত নেওয়া।
একটি অনুশীলন রান মেজাজ বদলে দেয় কারণ এটি অনিশ্চয়তার জায়গায় মেসল মেমরি দেয়। একটি ভাল রোলব্যাক ড্রিল মাত্র "কোড রিভার্ট করা যায় কি না" বিষয়টি নয়। এটি একটি পুনরাবৃত্ত রুটিন: আপনি কী স্ন্যাপশট নিচ্ছেন, কী ফিরে আনছেন, কী যাচাই করছেন, এবং কারা কাজটি করতে পারবে। কয়েকটি ড্রিলের পর, রোলব্যাক ব্যর্থতা মনে হয় না—বরং এটি হয়ে ওঠে একটি সেফটি টুল।
যদি আপনার ডেপ্লয়মেন্ট সেটআপ ইতিমধ্যে স্ন্যাপশট ও রিস্টোর সমর্থন করে (কয়েকটি প্ল্যাটফর্ম, যার মধ্যে Koder.ai–ও আছে, এটি রিলিজ ফ্লো-এ বোঝায়), ড্রিলগুলো সহজ হয়ে যায় কারণ “জানা ভাল অবস্থায় ফিরে যাওয়া” একটি স্বাভাবিক অ্যাকশন হয়ে যায়, এক্সট্রা জরুরী প্রক্রিয়া নয়। যেকোনো পথে, লক্ষ্য একই: যখন সময় আসে, কাউকে ইমপ্রোভাইজ করতে হবে না।
“৫ মিনিটে পুনরুদ্ধার” মানে সবকিছু আবার নিখুঁত হয়েছে এমন নয়। এর মানে আপনি দ্রুত ব্যবহারকারীদের একটি কাজ করা ভার্সনে ফিরিয়ে দিতে পারবেন, যদিও নতুন রিলিজটি এখনও ত্রুটিপূর্ণ থাকুক।
প্রথম সার্ভিস, পরে ফিক্স। যদি আপনি দ্রুত সার্ভিস ফিরিয়ে আনতে পারেন, আপনি শান্তভাবে খতিয়ে দেখবার সময় কিনে নেন।
টাইমার তখন শুরু হয় যখন আপনি সম্মত হন: “আমরা রোলব্যাক করছি।” এতে দীর্ঘ আলোচনা অন্তর্ভুক্ত নয় যে স্বয়ংক্রিয়ভাবে ঠিক হয়ে যেতে পারে কি না।
আগেই আপনার রোলব্যাক ট্রিগার ঠিক করে নিন। উদাহরণ: “ডেপ্লয়ের ৩ মিনিট পরে চেকআউটের ত্রুটি X%-এর উপর থাকলে আমরা রোলব্যাক করব।” ট্রিগার হিট করলে, স্ক্রিপ্ট অনুসরণ করুন।
'পুনরুদ্ধার' হওয়া উচিত একটি ছোট সংকেত সেট যা বলে দেয় ব্যবহারকারীরা নিরাপদ এবং সিস্টেম স্থিতিশীল। এটিকে সীমিত এবং সহজে পরীক্ষা করা রাখুন:
যখন ঐ সংকেতগুলো ভাল লাগে, ৫ মিনিটের টাইমার বন্ধ করুন। বাকিটা পরে করা যাবে।
ড্রিল সতর্ক রাখতে, স্পষ্টভাবে চিহ্নিত করুন আপনি ৫ মিনিটের পথে কী করছেন না: গভীর ডিবাগিং, কোড পরিবর্তন বা হটফিক্স রিলিজ, এবং যেকোনো কাজ যা ইঞ্জিনিয়ারিং কাজ হয়ে যায়।
একটি রোলব্যাক তখনই দ্রুত অনুভূত হয় যখন সিদ্ধান্তটি বেশিরভাগ সময়ে পূর্ব-নির্ধারিত থাকে। এমন একটি পদ্ধতি বেছে নিন যা বেশিরভাগ ঘটনার জন্য কাজ করে, তারপর এটিকে এত অনুশীলন করুন যে এটি বিরক্তিকর হয়ে ওঠে।
আপনার ড্রিলকে চারটি প্রশ্নের উত্তর দিতে হবে:
রোলব্যাক সবচেয়ে ভালো যখন নতুন রিলিজ ব্যবহারকারীদের বা ডেটাকে সক্রিয়ভাবে ক্ষতিগ্রস্ত করছে এবং আপনার কাছে ইতিমধ্যে একটি জানা-ভাল ভার্সন আছে। হটফিক্স তখনই ভাল যখন প্রভাব ছোট, পরিবর্তন বিচ্ছিন্ন এবং আপনি নিরাপদে প্যাচ করতে আত্মবিশ্বাসী।
একটি সহজ ডিফল্ট ভালো কাজ করে: যদি ব্যবহারকারীরা মূল অ্যাকশন সম্পন্ন করতে না পারে (চেকআউট, লগইন, সাইনআপ) বা ত্রুটি হার বাড়ে, প্রথমে রোলব্যাক করুন এবং পরে ফিক্স করুন। হটফিক্সগুলো রাখুন সেই সমস্যাগুলোর জন্য যা বিরক্তিকর কিন্তু বিপজ্জনক নয়।
আপনার “টার্গেট” এমন কিছু হওয়া উচিত যা দল কয়েক সেকেন্ডে বেছে নিতে পারে, বিতর্ক ছাড়া। বেশিরভাগ দল তিনটি সাধারণ টার্গেট পায়:
যদি আপনার কাছে নির্ভরযোগ্য ডেপ্লয়মেন্ট স্ন্যাপশট থাকে, সেটিকে ডিফল্ট করুন কারণ এটি চাপের নিচেও সবচেয়ে পুনরাবৃত্তি যোগ্য। কনফিগ-শুধু রুট রেখে দিন সেই ক্ষেত্রে যেখানে কোড ঠিক আছে কিন্তু সেটিং ভুল।
এছাড়াও “আগের ভালো” কী গণ্য সেইটা সংজ্ঞায়িত করুন। এটি হওয়া উচিত সর্বশেষ রিলিজ যা মনিটরিং চেক পাস করেছে এবং কোন সক্রিয় ইনসিডেন্ট ছিল না—না যে ভার্সনটি সবাই মনে রাখে।
ঘটনার সময় মিটিংয়ের জন্য অপেক্ষা কেবল করবেন না। সেই ট্রিগারগুলো লিখে রাখুন যা রোলব্যাক শুরু করবে এবং সেগুলো মানুন। সাধারণ ট্রিগার: কয়েক মিনিট ধরে প্রধান ফ্লো ভাঙা, ত্রুটি হার বা ল্যাটেন্সি নির্ধারিত থ্রেশহোল্ড অতিক্রম করা, ডেটা ঝুঁকি (ভুল রাইট, ডুপ্লিকেট চার্জ), এবং রিলিজ দ্বারা প্রবর্তিত কোনও নিরাপত্তা/গোপনীয়তা উদ্বেগ।
এরপর ঠিক করুন কে রোলব্যাক অনুমোদন করতে পারে। একটি ভূমিকা বেছে নিন (ইনসিডেন্ট লিড বা অন-কল), সাথে একটি ব্যাকআপ। বাকিরা পরামর্শ দিতে পারে, কিন্তু তারা ব্লক করতে পারবে না। যখন ট্রিগার হিট করে এবং অনুমোদক বলে “রোলব্যাক”, দল প্রত্যেকবারই একই ধাপ চালাবে।
রোলব্যাক ড্রিল শুধু কাজ করে যদি আপনি দ্রুত একটি জানা-ভাল অবস্থায় ফিরিয়ে আনতে পারেন। স্ন্যাপশটগুলো কেবল “ভালো থাকলে” নয়—এগুলো সেই রসিদ যা প্রমাণ করে কী রান করছিল, কী বদলেছে, এবং কীভাবে ফিরে যাওয়া যায়।
প্রতিটি রিলিজের আগে নিশ্চিত করুন আপনি এই আইটেমগুলো ছাড়া সারিবদ্ধ না হয়ে খুঁজতে হবে:
ডাটাবেস সেফটি হচ্ছে সর্বাধিক ফাঁদ। দ্রুত অ্যাপ রোলব্যাক কাজে আসবে না যদি ডাটাবেস এখন নতুন স্কিমা আশা করে। ঝুঁকিপূর্ণ মাইগ্রেশনের জন্য দুই-ধাপ রিলিজ প্ল্যান করুন (প্রথমে নতুন ফিল্ড যোগ করুন, পরে সেগুলো ব্যবহার শুরু করুন) যাতে রোলব্যাক সম্ভব থাকে।
সবার জন্য একটি নামকরণ নিয়ম ব্যবহার করুন এবং সেটিকে sortable রাখুন:
prod-2026-01-09-1420-v1.8.3-commitA1B2C3
এখানে পরিবেশ, টাইমস্ট্যাম্প, ভার্সন, এবং কমিট অন্তর্ভুক্ত করুন। যদি আপনার টুল UI-তে স্ন্যাপশট সমর্থন করে, সেখানে একই নামকরণ ব্যবহার করুন যেন কেউ সঠিক রিস্টোর পয়েন্ট দ্রুত খুঁজে পায়।
রোলব্যাক ড্রিল দ্রুত এবং শান্ত হয় যখন সবাই তাদের লেন জানে। লক্ষ্য সবাই ঝাঁপ দেয়া নয়। এটি এক ব্যক্তি সিদ্ধান্ত নেয়া, এক ব্যক্তি কাজ করে, এক ব্যক্তি যাচাই করে, এবং এক ব্যক্তি অন্যদের জানায়—এইভাবে কাজ দ্রুত হয়।
স্মল বা মিড-সাইজ টিমের জন্য এসব ভূমিকা কাজে দেয় (একজন একাধিক ভূমিকা নিতে পারে, তবে ড্রিল চলাকালীন Deployer এবং Verifier একসাথে না হওয়া ভালো):
পারমিশনই ঠিক করে দেয় এই প্ল্যান বাস্তব হবে কি না। ড্রিলের আগে সম্মত হন কাকে প্রোডuction রোলব্যাক করার অধিকার আছে, এবং জরুরি সময় কিভাবে কাজ করবে।
একটি সাদামাটা সেটআপ:
আপনি যদি এমন একটি প্ল্যাটফর্ম ব্যবহার করেন যা স্ন্যাপশট ও রিস্টোর সমর্থন করে (Koder.ai-সহ), ঠিক করুন কে স্ন্যাপশট তৈরি করবে, কে রিস্টোর করবে, এবং সেটি কোথায় রেকর্ড হবে।
রোলব্যাক ড্রিল সবথেকে ভালো কাজ করে যখন এটি একটি ফায়ার ড্রিলের মতো অনুভব হয়: একই ধাপ, একই শব্দ, একই জায়গায় ক্লিক করার পয়েন্ট। লক্ষ্য পারফেকশন নয়—হয় যে অন-কল যে কেউ দ্রুত শেষ জানেন ভাল ভার্সন ফিরিয়ে দিতে পারবে, বিতর্ক না করে।
একটি স্পষ্ট ট্রিগার বেছে নিন এবং ড্রিল শুরু হলে তা জোর করে বলুন। উদাহরণ: “চেকআউট ১ মিনিটের বেশি 500 রিটার্ন করছে” বা “ডেপ্লয়ের পর ত্রুটি হার ৫x বেড়ে গেছে।” তা জোর করে বলা দলেরকে ট্রাবলশুটিং মোডে ভাসতে বাধা দেয়।
রানবুকের পাশে একটি ছোট প্রিপ চেকলিস্ট রাখুন:
টাইমার শুরু করুন। একজন ব্যক্তিই ট্রিগার ও সিদ্ধান্ত বলবে: “আমরা এখনই রোলব্যাক করছি।”
পরিবর্তন ফ্রিজ করুন। নতুন ডিপ্লয় পজ করুন এবং অপ্রয়োজনীয় এডিট বন্ধ করুন যা রোলব্যাকের মাঝখানে সিস্টেম বদলে দিতে পারে।
একটি শেষ-চান্স স্ন্যাপশট নিন (যদি নিরাপদ এবং দ্রুত হয়)। এটি ক্ষতিগ্রস্ত অবস্থা পরে পুনরায় তৈরি করার ক্ষেত্রে সুরক্ষা। স্পষ্টভাবে নাম দিন এবং এগিয়ে যান।
রোলব্যাক কাজটি সঠিকভাবে ডকুমেন্ট করা অনুযায়ী চালান। ইম্প্রোভাইজ করবেন না। নিশ্চিতকরণ প্রম্পটগুলো উচ্চস্বরে বলুন যাতে রেকর্ডার কি ঘটলো ক্যাপচার করতে পারে।
একটি বিশ্বাসযোগ্য স্থানে রোলব্যাক সম্পন্ন হয়েছে নিশ্চিত করুন। প্রতিবার এক স্ক্রীন ও এক সংকেত ব্যবহার করুন (ডেপ্লয়মেন্ট হিস্ট্রি ভিউ, “অফশত ভার্সন” লেবেল, বা স্পষ্ট স্ট্যাটাস ইনডিকেটর)।
কর্মপরবর্তী হিসেবে, জিনিসগুলো যখন তাজা, তখনই যা গুরুত্বপূর্ণ তা ক্যাপচার করুন:
যদি রোলব্যাক ৫ মিনিটের বেশি সময় নেয়, তা পাত্তা দিয়ে বিবৃতি দেবেন না। ধীর ধাপটি খুঁজে বের করুন, রানবুক ঠিক করুন, এবং ড্রিলটি পুনরায় চালান।
রোলব্যাক তখনই “কর্ম করেছে” যখন ব্যবহারকারীরা অনুভব করে এটি কাজ করেছে। আপনি প্রমাণ করার চেষ্টা করছেন না যে পুরানো ভার্সন ডিপ্লয় হয়েছে—আপনি প্রমাণ করছেন সার্ভিস আবার ব্যবহারযোগ্য এবং স্থিতিশীল।
জাচাই ছোট এবং পুনরাবৃত্তিযোগ্য রাখুন। তালিকা পাঁচটার বেশি হলে লোকেরা চাপের মধ্যে তা এড়িয়ে যাবে।
দ্রুত চালানোর যোগ্য এমন চেক ব্যবহার করুন, স্পষ্ট পাস/ফেইল সহ:
ফাংশনাল চেকগুলো পরে, আপনি বিশ্বাসযোগ্য সবচেয়ে সহজ সিস্টেম হেলথ সংকেতে এক নজর দেবেন। আপনি দেখতে চান ত্রুটি হার কয়েক মিনিটের মধ্যে স্বাভাবিক নিকট ফিরে আসে এবং ল্যাটেন্সি স্পাইক বন্ধ হয়।
এছাড়াও নিশ্চিত করুন যে অদৃশ্য অংশগুলো আবার চলে। ব্যাকগ্রাউন্ড জবগুলো প্রসেস করছে এবং কিউগুলো প্রবাহিত হচ্ছে, বাড়ছে না। ডাটাবেস চেক দ্রুত এবং বিরক্তিকর হওয়া উচিত: কানেকশন স্থিতিশীল, কোনো স্পষ্ট লক জমা নেই, এবং অ্যাপ লিখতে পারে।
অবশেষে, বাহ্যিক জয়েন্টগুলো যেখানে গুরুত্বপূর্ণ সেগুলো টেস্ট করুন—সেফলি করতে পারেন কিনা দেখে একটি পেমেন্ট টেস্ট চালান, ইমেল ডেলিভারি ঠিক আছে কিনা নিশ্চিত করুন, এবং নিশ্চিত করুন ওয়েবহুকস গ্রহণ করা হচ্ছে (অথবা অন্তত ব্যর্থ হচ্ছে না)।
আগে থেকে একটি বাক্য লিখে রাখুন যাতে কেউ ইমপ্রোভাইজ না করে:
“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 ব্যবহারকারী আপডেট করার পর লগইন করতে পারছেন না।”
দলেও দলটি ড্রিল অনুশীলন করেছে, তাই তারা দীর্ঘ বিতর্কে ঝামেলা করে না। তারা নিশ্চিত করে, সিদ্ধান্ত নেয়, এবং কাজ করে।
কি রোলব্যাক করা হয়েছিল: ওয়েব ও 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।”
আপনি সফলতা ঘোষণা করেন ব্যবহারকারী কি অনুভব করে তা পরীক্ষা না করে। অ্যাপ ডিপ্লয় হয়েছে, কিন্তু লগইন এখনও ভাঙা বা জব আটকে আছে। সমাধান: যাচাইকরণ সংক্ষিপ্ত কিন্তু বাস্তব রাখুন এবং টাইমবক্স করুন।
ড্রিলটি বারবার করা কঠিন। অনেকগুলি টুল, অনেক চেক, অনেক কণ্ঠ। সমাধান: ড্রিলটি এক পৃষ্ঠায় সংকুচিত করুন এবং এক মালিক রাখুন। যদি এটি এক রানবুক ও এক কমিউনিকেশন চ্যানেল থেকে করা যায় না, চাপের মধ্যে এটি ঘটবে না।
একটি ভাল রোলব্যাক ড্রিল অভ্যাস; কোনো নায়কোচিত প্রদর্শনী নয়। যদি আপনি শান্তভাবে শেষ করতে না পারেন, ধাপগুলো কমান যতক্ষণ না করতে পারেন, তারপর কেবল সেইগুলো যোগ করুন যা বাস্তবে ঝুঁকি কমায়।
রোলব্যাক ড্রিল সবচেয়ে ভালো কাজ করে যখন সবাই একই এক-পৃষ্ঠার চেকলিস্ট অনুসরণ করে। এটি যেখানে দল বাস্তবে দেখে সেখানে পিন করে রাখুন।
একটি সঙ্কুচিত সংস্করণ যা ১০ মিনিটের মধ্যে চালানো যায় (সেটআপ ও যাচাইকরণসহ):
ড্রিলগুলো এত ঘন ঘন চালান যাতে ধাপগুলো স্বাভাবিক লাগে। মাসিক একটি ভাল ডিফল্ট। যদি আপনার প্রোডাক্ট প্রতিদিন বদলে, প্রতি দুই সপ্তাহে চালান, কিন্তু যাচাইকরণকে প্রধান ব্যবহারকারীর পথে কেন্দ্রিত রাখুন।
প্রতি ড্রিলের পরে, একই দিন রানবুক আপডেট করুন যখন এটি তাজা থাক
ুন। এটিকে রিলিজ নোটের সাথে সংরক্ষণ করুন এবং "last tested" লাইন যোগ করুন যাতে কেউ পুরনো প্রক্রিয়া বিশ্বাস না করে।
পরিমাপ কেবল সেইগুলো করুন যা উন্নতিতে সাহায্য করে:
যদি আপনার দল 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:
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:
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:
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-commitABC123Include environment + timestamp + version + commit. Consistency matters more than the exact format.
A simple, repeatable split for small teams:
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:
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:
This keeps the quick rollback path safe and predictable.
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:
The drill still needs roles, triggers, and a short verification list—tools don’t replace the routine.