یک merge به main، pipeline سبز، deploy موفق — و ۱۰ دقیقه بعد error rate از ۰.۱٪ به ۱۵٪ رسید. کاربران logout می‌شدند، sessionها invalid بودند، و تیم support در گروه شلوغ شده بود.

ریشه مشکل یک تغییر در migration بود که روی staging تست نشده بود — چون staging دیتابیس قدیمی‌تر داشت و migration فقط روی schema تازه‌تر main اجرا شده بود. pipeline سبز بود، ولی داده واقعی شکسته بود.

rollback دستی بود: image قبلی را در registry پیدا کن، tag بزن، دوباره deploy. ۴۵ دقیقه استرس خالص. هیچ دکمه «برگرد به نسخه قبل» نداشتیم — فقط kubectl و امید.

بدترین بخش: در آن ۴۵ دقیقه نمی‌دانستیم migration برگشت‌پذیر است یا نه. تیم backend و DevOps همزمان لاگ می‌خواندند و با هم حدس می‌زدند. incident بدون runbook خیلی کند پیش می‌رود.

بعد از incident، چند تغییر ساختاری دادیم: immutable tags برای هر image (هرگز latest در پروداکشن)، دو slot deploy (blue-green ساده)، و smoke test اجباری روی staging با داده نزدیک به واقعیت.

feature flag برای تغییرات پرریسک اضافه کردیم — نه برای همه چیز، فقط جاهایی که rollback سخت است: auth، payment، migration. هزینه setup کم است، ارزشش در اولین incident مشخص می‌شود.

یک runbook یک‌صفحه‌ای نوشتیم: چه کسی incident commander است، چطور rollback می‌کنیم، کجا لاگ می‌خوانیم، چه زمانی به کاربر اطلاع می‌دهیم. ساده است ولی وقتی شب است و همه عصبی‌اند، مغز به checklist نیاز دارد.

سبز بودن pipeline کافی نیست — باید بعد از deploy هم سالم باشی. الان هر release شامل ۱۵ دقیقه monitoring window است که deployer مسئول watch کردن error rate و latency است. اگر anomaly دید، rollback بدون جلسه.