رول بک چیست؟ چه زمانی باید به نسخه قبلی برگردیم؟

فرض کنید یک نسخه جدید از محصول را منتشر کرده‌ایم.

چند دقیقه بعد، نمودار خطا بالا می‌رود. بخشی از کاربران نمی‌توانند وارد حسابشان شوند. نرخ تکمیل خرید پایین آمده و تیم فنی هنوز دقیقاً نمی‌داند مشکل از کجاست.

یکی می‌گوید:

«مشکل را پیدا می‌کنیم و همین نسخه را درست می‌کنیم.»

نفر دیگری می‌گوید:

«اول Rollback کنیم، بعد با خیال راحت دنبال علت بگردیم.»

در چنین شرایطی مسئله فقط فنی نیست. ما با یک تصمیم مدیریت ریسک روبه‌رو هستیم.

به نظرم سؤال اصلی این نیست که «آیا تیم فنی می‌تواند مشکل را حل کند؟»

تقریباً هر مشکلی بالاخره قابل حل است.

سؤال مهم‌تر این است:

تا زمانی که مشکل را پیدا و برطرف می‌کنیم، حاضر هستیم کاربران و کسب‌وکار چه میزان هزینه‌ای پرداخت کنند؟

Rollback دقیقاً در پاسخ به همین سؤال معنا پیدا می‌کند.

Rollback چیست؟

Rollback یا «بازگشت به نسخه قبلی» یعنی تغییراتی را که به‌تازگی در یک سیستم منتشر کرده‌ایم کنار بگذاریم و سیستم را به آخرین وضعیت سالم و شناخته‌شده برگردانیم.

این تغییر می‌تواند مربوط به موارد مختلفی باشد:

• نسخه جدید نرم‌افزار
• یک Feature
• تنظیمات سرور
• Infrastructure
• Configuration
• تغییرات دیتابیس
• قالب سایت
• سیستم پرداخت
• API
• تغییرات فنی سئو

بنابراین Rollback صرفاً به معنی برگرداندن چند خط کد در Git نیست.

هدف واقعی این است که سیستم دوباره به یک Known Good State یا وضعیت سالمی که قبلاً از عملکرد آن مطمئن بوده‌ایم برگردد.

AWS هم در توصیه‌های عملیاتی خود بر همین مفهوم تأکید دارد: تیم باید قبل از انتشار تغییر، برنامه‌ای برای بازگشت به وضعیت سالم قبلی یا اصلاح سریع وضعیت فعلی داشته باشد.

Rollback را با Undo اشتباه نگیریم

در ظاهر ممکن است Rollback شبیه زدن دکمه Undo به نظر برسد.

نسخه ۲ مشکل دارد؛ پس نسخه ۱ را دوباره Deploy می‌کنیم.

اما در سیستم‌های واقعی ماجرا معمولاً به این سادگی نیست.

فرض کنید نسخه جدید برای دو ساعت روی Production بوده است. در این دو ساعت:

• کاربران اطلاعات جدیدی ثبت کرده‌اند؛
• سفارش‌هایی ایجاد شده؛
• پرداخت‌هایی انجام شده؛
• ایمیل یا پیامک ارسال شده؛
• ساختار بعضی داده‌ها تغییر کرده؛
• سرویس‌های دیگری اطلاعات نسخه جدید را دریافت کرده‌اند.

برگرداندن کد لزوماً این اتفاق‌ها را برنمی‌گرداند.

این همان جایی است که تفاوت میان Rollback کردن کد و Rollback کردن سیستم مشخص می‌شود.

ممکن است بتوانیم نسخه قبلی Application را در چند دقیقه Deploy کنیم، اما دیتابیسی که نسخه جدید تغییر داده دیگر با نسخه قبلی سازگار نباشد.

Amazon در مستندات مربوط به Rollback Safety دقیقاً روی همین موضوع تأکید می‌کند: نسخه‌ها باید تا حد امکان Backward Compatible طراحی شوند تا نسخه قدیمی و جدید بتوانند هنگام Deploy و حتی Rollback بدون ایجاد اختلال با داده‌ها و سرویس‌های یکدیگر کار کنند.

پس جمله دقیق‌تر این است:

Rollback یعنی تلاش برای بازگرداندن سرویس به وضعیت پایدار قبلی؛ نه الزاماً پاک‌کردن تمام اتفاقاتی که از لحظه انتشار نسخه جدید رخ داده‌اند.

چرا Rollback نشانه شکست نیست؟

گاهی در تیم‌ها یک مقاومت روانی در برابر Rollback وجود دارد.

تیم چند هفته روی Feature کار کرده، تست انجام شده، Release منتشر شده و حالا کسی باید بگوید:

«برگردیم عقب.»

طبیعی است که چنین تصمیمی خوشایند نباشد.

اما من Rollback را شکست تیم نمی‌بینم.

شکست واقعی زمانی است که تغییری منتشر کنیم، بفهمیم کاربران آسیب می‌بینند و صرفاً چون نمی‌خواهیم انتشارمان را پس بگیریم، مدت بیشتری وضعیت نامطلوب را تحمل کنیم.

هیچ تستی نمی‌تواند تمام رفتار Production را شبیه‌سازی کند. حجم واقعی Traffic، رفتار کاربران، Dependencyها، داده‌های عجیب و ترکیب شرایط مختلف گاهی مشکلی را آشکار می‌کنند که در Staging دیده نشده است.

اتفاقاً تیم بالغ باید از قبل فرض کند:

بعضی Releaseها شکست خواهند خورد.

موضوع این نیست که هرگز شکست نخوریم؛ موضوع این است که چقدر سریع متوجه شکست می‌شویم و چقدر سریع می‌توانیم سرویس را به وضعیت پایدار برگردانیم.

این نگاه با معیارهای DORA هم هم‌راستاست. در مدل فعلی DORA، «Change Fail Rate» و «Failed Deployment Recovery Time» از معیارهای مهم سنجش پایداری فرایند تحویل نرم‌افزار هستند. Rollback و Hotfix نیز از نمونه‌های مداخله پس از یک Deployment ناموفق محسوب می‌شوند.

چه زمانی Rollback تصمیم درستی است؟

نمی‌شود قانونی نوشت که بگوید اگر Error Rate از عدد مشخصی بالاتر رفت همیشه Rollback کنید.

محصول‌ها، زیرساخت‌ها و حساسیت کسب‌وکارها متفاوت‌اند.

اما چند موقعیت وجود دارد که باید Rollback را بسیار جدی بررسی کنیم.

۱. یکی از مسیرهای حیاتی محصول از کار افتاده است

اگر کاربران نمی‌توانند:

• وارد حساب شوند؛
• ثبت‌نام کنند؛
• خرید انجام دهند؛
• پرداخت کنند؛
• اطلاعات ضروری را ببینند؛
• یا از قابلیت اصلی محصول استفاده کنند،

دیگر با یک Bug معمولی روبه‌رو نیستیم.

در این شرایط باید بین «زمان لازم برای Fix» و «زمان لازم برای Rollback» مقایسه کنیم.

اگر Rollback در ۵ دقیقه سرویس را پایدار می‌کند اما پیدا کردن و Deploy کردن Fix ممکن است یک ساعت طول بکشد، نگه‌داشتن نسخه جدید باید دلیل بسیار خوبی داشته باشد.

۲. سلامت داده‌ها در خطر است

یکی از جدی‌ترین دلایل Rollback، Data Integrity است.

مثلاً:

• اطلاعات اشتباه ذخیره می‌شوند؛
• سفارش‌ها به کاربر اشتباه متصل می‌شوند؛
• داده‌ای حذف می‌شود؛
• محاسبات مالی غلط هستند؛
• عملیات تکراری روی داده انجام می‌شود.

در اینجا هر دقیقه‌ای که نسخه معیوب فعال بماند ممکن است هزینه بازیابی داده را بیشتر کند.

البته باید توجه داشت که در چنین شرایطی خود Rollback هم باید بررسی شود. اگر نسخه جدید Schema دیتابیس را تغییر داده باشد، بازگرداندن Application بدون بررسی سازگاری Database ممکن است مشکل دیگری ایجاد کند.

۳. یک آسیب‌پذیری امنیتی جدی ایجاد شده است

اگر Release جدید مسیر دسترسی غیرمجاز، افشای اطلاعات یا یک مشکل امنیتی مهم ایجاد کرده، سرعت واکنش اهمیت بسیار زیادی پیدا می‌کند.

در چنین شرایطی حفظ نسخه جدید صرفاً برای اینکه مشکل را در Production Debug کنیم معمولاً ریسک قابل دفاعی نیست.

ممکن است Rollback، غیرفعال کردن Feature یا محدود کردن Traffic بخشی از پاسخ Incident باشد.

۴. یک KPI حیاتی بلافاصله بعد از Release افت کرده است

همه مشکلات Production با Error Message ظاهر نمی‌شوند.

گاهی از نظر سرور همه‌چیز سالم است، اما محصول دیگر درست کار نمی‌کند.

مثلاً بعد از Release:

• Conversion Rate به‌شدت افت می‌کند؛
• Add to Cart کاهش پیدا می‌کند؛
• تعداد پرداخت موفق پایین می‌آید؛
• Activation کاربران جدید سقوط می‌کند؛
• نرخ تکمیل یک Funnel ناگهان تغییر می‌کند.

اینجا نقش تیم محصول جدی‌تر می‌شود.

یک Release ممکن است از نگاه Infrastructure کاملاً Healthy باشد، اما از نگاه Business شکست خورده باشد.

اگر ارتباط زمانی و شواهد کافی میان تغییر و افت KPI وجود دارد، Rollback می‌تواند یکی از گزینه‌های اصلی باشد.

۵. دامنه مشکل را هنوز نمی‌دانیم

گاهی خطر اصلی خود Bug نیست؛ ندانستن دامنه Bug است.

ممکن است ابتدا تصور کنیم فقط پنج درصد کاربران مشکل دارند، اما هنوز نمی‌دانیم:

• چه Segmentهایی تحت تأثیر هستند؛
• آیا داده خراب می‌شود؛
• آیا مشکل در حال گسترش است؛
• آیا سرویس‌های دیگر هم درگیر شده‌اند.

وقتی Blast Radius مشخص نیست، ادامه دادن Release ریسک بیشتری دارد.

در چنین شرایطی Rollback می‌تواند زمان بخرد؛ ابتدا سیستم را پایدار کنیم و بعد بدون فشار Incident سراغ Root Cause برویم.

چه زمانی نباید فوراً Rollback کنیم؟

این طرف بحث هم مهم است.

Rollback همیشه بهترین جواب نیست.

گاهی برگرداندن نسخه قبلی از نگه‌داشتن نسخه جدید خطرناک‌تر است.

وقتی یک Hotfix کوچک و کم‌ریسک داریم

فرض کنید مشکل کاملاً مشخص شده و اصلاح آن:

• بسیار کوچک است؛
• تست شده؛
• Side Effect ندارد؛
• و سریع‌تر از Rollback قابل انتشار است.

اینجا ممکن است Fix Forward انتخاب منطقی‌تری باشد.

Fix Forward یعنی به‌جای برگشتن به نسخه قبلی، نسخه فعلی را با یک تغییر جدید اصلاح کنیم.

وقتی دیتابیس دیگر با نسخه قبلی سازگار نیست

یکی از خطرناک‌ترین Rollbackها همین است.

فرض کنید نسخه جدید یک ستون دیتابیس را حذف کرده و کد نسخه قبلی هنوز به آن ستون وابسته است.

در چنین شرایطی Deploy کردن نسخه قبلی ممکن است به‌جای حل مشکل، کل سرویس را از کار بیندازد.

به همین دلیل در سیستم‌های حرفه‌ای، تغییرات حساس داده معمولاً به چند Release کوچک‌تر تقسیم می‌شوند تا امکان اجرای همزمان نسخه قدیمی و جدید حفظ شود.

Amazon برای چنین تغییراتی استفاده از روش‌های چندمرحله‌ای و Backward Compatibility را توصیه می‌کند؛ چون در سیستم‌های توزیع‌شده ممکن است هنگام Deployment بخشی از سرورها نسخه قدیمی و بخشی نسخه جدید را اجرا کنند.

وقتی Feature Flag کافی است

فرض کنید مشکل فقط مربوط به یک قابلیت جدید است و آن قابلیت پشت Feature Flag قرار دارد.

لازم نیست کل Release را برگردانیم.

می‌توان Feature را خاموش کرد و بقیه تغییرات سالم نسخه را نگه داشت.

این یکی از دلایلی است که Feature Flag فقط یک ابزار Product Experiment نیست؛ می‌تواند یک ابزار مدیریت ریسک Deployment هم باشد.

AWS نیز Feature Flag، Canary Testing و Automated Rollback را در کنار هم به‌عنوان روش‌هایی برای کاهش ریسک Release مطرح می‌کند.

Rollback، Hotfix یا Fix Forward؟

در زمان Incident معمولاً سه گزینه اصلی داریم.

گزینه	چه کاری انجام می‌دهیم؟	مناسب چه زمانی است؟
Rollback	نسخه قبلی را برمی‌گردانیم	نسخه جدید آسیب جدی ایجاد کرده و برگشت امن و سریع است
Hotfix	یک اصلاح کوچک و فوری منتشر می‌کنیم	علت مشکل مشخص و Fix کم‌ریسک است
Fix Forward	نسخه جدیدتری برای اصلاح مشکل می‌سازیم	Rollback پرریسک یا غیرممکن است

به نظرم انتخاب میان این سه را نباید به بحث سلیقه‌ای بین Developer و Product Manager تبدیل کرد.

بهتر است پنج سؤال مشخص بپرسیم.

پنج سؤال قبل از تصمیم به Rollback

۱. شدت مشکل چقدر است؟

آیا درباره یک ایراد ظاهری صحبت می‌کنیم یا کاربران نمی‌توانند خرید کنند؟

Severity اولین متغیر تصمیم است.

۲. چند درصد کاربران تحت تأثیر هستند؟

یک Bug ممکن است فقط کاربران یک Browser خاص را درگیر کند.

Bug دیگری ممکن است کل کاربران را تحت تأثیر قرار دهد.

Blast Radius را باید تا حد ممکن تخمین بزنیم.

۳. Rollback چقدر زمان می‌برد؟

اگر تیم برای Rollback به دو ساعت عملیات دستی نیاز دارد، شرایط متفاوت است با سیستمی که در چند دقیقه می‌تواند نسخه سالم قبلی را Deploy کند.

۴. Fix چقدر زمان می‌برد؟

و اینجا باید مراقب یک دام ذهنی باشیم.

جمله‌ی:

«فکر کنم ده دقیقه‌ای حلش کنیم»

تخمین قابل اتکایی نیست.

تا زمانی که Root Cause را دقیق نمی‌دانیم، زمان Fix هم قطعیت چندانی ندارد.

گاهی ۱۰ دقیقه Debug تبدیل به ۹۰ دقیقه می‌شود، در حالی که کاربران تمام این مدت با نسخه معیوب درگیر بوده‌اند.

۵. خود Rollback چه ریسکی دارد؟

این شاید مهم‌ترین سؤالی باشد که فراموش می‌شود.

آیا نسخه قبلی:

• داده جدید را می‌فهمد؟
• با Schema فعلی Database سازگار است؟
• با APIهای فعلی کار می‌کند؟
• Configuration مناسب دارد؟
• می‌تواند Transactionهای ایجادشده توسط نسخه جدید را پردازش کند؟

اگر جواب این سؤال‌ها روشن نیست، Rollback هم یک Change پرریسک است.

یک مثال ساده از تصمیم Rollback

فرض کنید Checkout یک فروشگاه اینترنتی را تغییر داده‌ایم.

نسخه ساعت ۱۴:۰۰ منتشر شده است.

ساعت ۱۴:۱۰ Monitoring نشان می‌دهد نرخ Payment Success از ۸۲ درصد به ۵۳ درصد رسیده است.

تیم بررسی می‌کند و متوجه می‌شود:

• Error Rate بالا رفته؛
• مشکل بعد از Release شروع شده؛
• علت دقیق هنوز مشخص نیست؛
• Rollback حدود ۴ دقیقه زمان می‌برد؛
• نسخه قبلی با Database فعلی سازگار است.

در چنین شرایطی من ترجیح می‌دهم ابتدا Rollback کنیم.

چرا؟

چون هدف ما در ساعت ۱۴:۱۵ «اثبات توانایی تیم برای Fix سریع Bug» نیست.

هدف اصلی برگرداندن تجربه کاربران و درآمد محصول به وضعیت طبیعی است.

بعد از پایداری سیستم می‌توان نسخه خراب را در محیط مناسب بررسی کرد.

حالا همان سناریو را کمی تغییر دهیم.

فرض کنید تیم در همان چند دقیقه متوجه می‌شود مشکل از یک Feature Flag است و خاموش کردن آن فوراً رفتار Checkout را به حالت قبلی برمی‌گرداند.

دیگر Rollback کل Release احتمالاً تصمیم خوبی نیست.

یعنی تصمیم درست به خود کلمه Rollback وابسته نیست؛ به کم‌ریسک‌ترین مسیر برای بازگشت سرویس به وضعیت سالم وابسته است.

Rollback خوب قبل از Release شروع می‌شود

اگر اولین بار هنگام Incident درباره روش Rollback صحبت می‌کنیم، کمی دیر شده است.

قابلیت برگشت باید بخشی از طراحی Release باشد.

AWS هم در Well-Architected Framework توصیه می‌کند تیم‌ها پیش از انتشار، برنامه بازیابی را مشخص و مستند کنند و حتی تا حد ممکن Testing و Rollback را وارد Pipeline خودکار کنند.

چند مورد را من برای Releaseهای حساس ضروری می‌دانم.

یک نسخه سالم مشخص داشته باشیم

باید بدانیم دقیقاً قرار است به کدام نسخه برگردیم.

«نسخه قبلی» همیشه تعریف کافی نیست.

بهتر است آخرین نسخه تأییدشده، Artifact، Configuration و وابستگی‌های آن مشخص باشند.

مسیر Rollback را قبلاً تست کرده باشیم

وجود یک دکمه Rollback به معنی امن بودن Rollback نیست.

خود مسیر برگشت باید تست شود.

آیا واقعاً نسخه قدیمی بالا می‌آید؟

آیا Migrationها اجازه این کار را می‌دهند؟

آیا Configuration قبلی وجود دارد؟

آیا Dependencyها همچنان سازگار هستند؟

AWS در راهنمای Rollback Safety حتی روی Upgrade-Downgrade Testing تأکید می‌کند؛ یعنی فقط بالا رفتن به نسخه جدید تست نشود، مسیر برگشت هم آزمایش شود.

Monitoring قبل از Release آماده باشد

بعد از انتشار نباید تازه تصمیم بگیریم چه چیزی را اندازه بگیریم.

برای هر Release مهم بهتر است از قبل بدانیم:

• Error Rate طبیعی چقدر است؟
• Latency معمول چیست؟
• کدام Business KPI را نگاه می‌کنیم؟
• چه عددی Alarm ایجاد می‌کند؟
• چه Thresholdی می‌تواند Rollback را فعال کند؟

Rollback خوب بدون Observability تقریباً غیرممکن است.

Release را تا جای ممکن کوچک نگه داریم

هرچه Release بزرگ‌تر باشد:

• پیدا کردن علت خطا سخت‌تر می‌شود؛
• تعداد متغیرها بالا می‌رود؛
• Blast Radius بزرگ‌تر می‌شود؛
• Rollback پیچیده‌تر می‌شود.

به همین دلیل Small Batch فقط برای افزایش سرعت تیم نیست؛ یک ابزار مدیریت ریسک هم هست.

از Canary Deployment استفاده کنیم

لازم نیست هر Release از همان ثانیه اول برای صد درصد کاربران فعال شود.

در Canary Deployment می‌توان نسخه جدید را ابتدا برای بخش کوچکی از Traffic منتشر کرد و رفتار آن را بررسی کرد.

Google Cloud نیز Canary Deployment را به‌عنوان روشی معرفی می‌کند که نسخه جدید ابتدا روی بخشی از زیرساخت یا Traffic عرضه و قبل از Rollout کامل ارزیابی می‌شود.

این یعنی به‌جای اینکه بعد از آسیب دیدن صد درصد کاربران Rollback کنیم، شاید مشکل را زمانی ببینیم که هنوز فقط بخش کوچکی از کاربران درگیر شده‌اند.

Rollback در سئو چه شکلی دارد؟

از آنجا که بخش زیادی از کار من با سئو گره خورده، Rollback را فقط در Backend یا Application نمی‌بینم.

Releaseهای سئویی هم می‌توانند نیاز به Rollback داشته باشند.

مثلاً یک Deploy انجام می‌دهیم و ناگهان:

• noindex روی صفحات مهم قرار می‌گیرد؛
• Canonicalها اشتباه می‌شوند؛
• Robots.txt بخشی از سایت را Block می‌کند؛
• JavaScript Rendering محتوای اصلی را از دسترس Googlebot خارج می‌کند؛
• Redirect Map اشتباه Deploy می‌شود؛
• لینک‌های داخلی مهم حذف می‌شوند؛
• Template جدید Heading یا Meta Data صفحات را خراب می‌کند.

اینجا هم همان منطق وجود دارد.

قرار نیست صرفاً چون «تغییر جدید است» فوراً آن را برگردانیم.

ابتدا باید بفهمیم:

• مشکل چقدر جدی است؟
• چند URL را درگیر کرده؟
• آیا Googlebot هنوز تغییر را Crawl کرده؟
• Fix سریع‌تر و مطمئن‌تر است یا Rollback؟
• برگشت Template چه Side Effect دیگری دارد؟

تفاوت مهم این است که در SEO نتیجه Rollback همیشه فوری دیده نمی‌شود.

ممکن است مشکل Technical را همین امروز برطرف کنیم، اما Search Engine برای Crawl مجدد، پردازش تغییرات و اصلاح سیگنال‌ها به زمان نیاز داشته باشد.

بنابراین «سیستم برگشت» و «نتیجه در Search» دو زمان متفاوت دارند.

این هم یکی از دلایلی است که در پروژه‌های SEO تغییرات Technical بزرگ را ترجیح می‌دهم با Monitoring دقیق و Scope محدود منتشر کنم.

بعد از Rollback چه کار کنیم؟

Rollback پایان Incident است، اما پایان مسئله نیست.

وقتی سرویس دوباره پایدار شد، تازه بخش مهم یادگیری شروع می‌شود.

Root Cause را پیدا کنیم

نباید پاسخ Incident در حد این جمله باقی بماند:

«نسخه جدید Bug داشت.»

باید مشخص شود:

• دقیقاً چه چیزی خراب شد؟
• چرا Testها آن را نگرفتند؟
• چرا Monitoring دیر متوجه شد؟
• چرا Deployment اجازه داد مشکل به این تعداد کاربر برسد؟
• آیا Architecture برگشت را سخت کرده بود؟

تصمیم Rollback را مستند کنیم

ثبت کنیم:

• چه زمانی مشکل شروع شد؟
• چه زمانی تشخیص داده شد؟
• چه کسی تصمیم Rollback گرفت؟
• چرا Rollback انتخاب شد؟
• Rollback چقدر طول کشید؟
• چه زمانی سرویس پایدار شد؟

این اطلاعات بعداً بسیار ارزشمندتر از چیزی هستند که هنگام Incident تصور می‌کنیم.

به‌جای پیدا کردن مقصر، Guardrail بسازیم

اگر نتیجه Postmortem فقط این باشد که:

«فلانی باید بیشتر دقت می‌کرد»

احتمالاً چیز زیادی یاد نگرفته‌ایم.

سؤال بهتر این است:

چه تغییری در سیستم ایجاد کنیم که دفعه بعد این اشتباه یا رخ ندهد یا خیلی زودتر شناسایی شود؟

ممکن است جواب یکی از این‌ها باشد:

• Automated Test جدید
• Monitoring جدید
• Feature Flag
• Canary Release
• Validation قبل از Deploy
• محدود کردن Batch Size
• تغییر Migration Strategy
• Alert جدید
• Runbook بهتر

هدف Postmortem باید افزایش توان سیستم باشد، نه صرفاً افزایش احتیاط آدم‌ها.

آیا تعداد زیاد Rollback نگران‌کننده است؟

خود Rollback بد نیست.

اما اگر تیم دائماً مجبور به Rollback می‌شود، باید یک لایه عقب‌تر برویم.

شاید مشکل در یکی از این بخش‌ها باشد:

• کیفیت Testها پایین است؛
• Releaseها بیش از حد بزرگ‌اند؛
• محیط Staging شبیه Production نیست؛
• Requirements مبهم هستند؛
• Monitoring ناکافی است؛
• تیم با عجله Deploy می‌کند؛
• وابستگی‌ها به‌خوبی شناخته نشده‌اند.

در واقع بهتر است به‌جای شمردن صرف تعداد Rollbackها، چند عدد را کنار هم ببینیم.

DORA در مدل فعلی خود علاوه بر Deployment Frequency و Change Lead Time، معیارهایی مانند Change Fail Rate، Failed Deployment Recovery Time و Deployment Rework Rate را برای درک بهتر عملکرد فرایند تحویل نرم‌افزار بررسی می‌کند.

ممکن است تیمی زیاد Deploy کند و گاهی هم Rollback داشته باشد، اما مشکلات را در چند دقیقه شناسایی و رفع کند.

تیم دیگری ماهی یک بار Deploy می‌کند، اما هر Release تبدیل به چند ساعت بحران می‌شود.

فقط با دیدن «تعداد Rollback» نمی‌توان گفت کدام تیم بالغ‌تر است.

یک چک‌لیست ساده برای تصمیم Rollback

وقتی Release مشکل‌دار شده، من این سؤال‌ها را مفید می‌دانم:

• آیا مسیر اصلی کاربر مختل شده است؟
• آیا Data Integrity در خطر است؟
• آیا مشکل امنیتی وجود دارد؟
• دامنه کاربران درگیر را می‌دانیم؟
• علت اصلی مشکل مشخص است؟
• زمان تقریبی Fix را واقعاً می‌دانیم؟
• Rollback چقدر طول می‌کشد؟
• نسخه قبلی با Database و سرویس‌های فعلی سازگار است؟
• می‌توان فقط Feature مشکل‌دار را خاموش کرد؟
• آیا بعد از Rollback می‌توانیم سلامت سرویس را سریع تأیید کنیم؟
• چه کسی مسئول تصمیم نهایی است؟
• کاربران یا تیم پشتیبانی نیاز به اطلاع‌رسانی دارند؟

اگر وسط بحران تازه دنبال پاسخ همه این سؤال‌ها می‌گردیم، یکی از خروجی‌های Postmortem باید آماده‌کردن جواب آن‌ها برای Release بعدی باشد.

جمع‌بندی؛ ارزش Rollback در «برگشتن» نیست

Rollback در ظاهر یعنی برگشتن به عقب.

اما از نگاه محصول، هدف آن عقب رفتن نیست.

هدف این است که وقتی یک تغییر نتیجه‌ای متفاوت از انتظار ایجاد کرد، بتوانیم سریع، کنترل‌شده و با کمترین آسیب مسیر خود را اصلاح کنیم.

به همین دلیل من Rollback را بیشتر از اینکه یک دستور فنی بدانم، یک قابلیت سازمانی می‌بینم.

تیمی که Rollback خوبی دارد:

• وضعیت سالم قبلی را می‌شناسد؛
• Releaseهایش را قابل بازگشت طراحی می‌کند؛
• Monitoring مناسبی دارد؛
• از قبل Thresholdهای شکست را تعریف می‌کند؛
• بین Rollback و Fix Forward تفاوت می‌گذارد؛
• و بعد از Incident تلاش می‌کند سیستم را بهتر کند، نه اینکه فقط مقصر پیدا کند.

شاید بهترین نشانه بلوغ یک تیم این نباشد که هیچ‌وقت Release ناموفق ندارد.

نشانه مهم‌تر این است که وقتی Release ناموفق اتفاق افتاد، تیم مجبور نباشد میان «ادامه دادن یک وضعیت خراب» و «یک Rollback ناشناخته و ترسناک» یکی را انتخاب کند.

Rollback خوب باید آن‌قدر از قبل طراحی و تمرین شده باشد که در زمان بحران، خودش بحران دوم نباشد.

منابع و مطالعه بیشتر

برای تکمیل این یادداشت از مستندات AWS Well-Architected درباره برنامه‌ریزی برای تغییرات ناموفق و Automated Rollback، مقاله AWS Builders Library درباره Rollback Safety، مستندات Google Cloud درباره Canary Deployment و چارچوب DORA برای سنجش عملکرد Software Delivery استفاده شده است.