پروداکشن سوخته در توسعه — چیست، علل و الگوریتم اقدام

«پروداکشن سوخته» یعنی چه و چه انواع خرابی وجود دارد

عبارت «پروداکشن سوخته» (production is on fire, everything is down) وضعیتی را توصیف می‌کند که محیط پروداکشن به درستی کار نمی‌کند و این روی کاربران تأثیر گذاشته است. خرابی می‌تواند به صورت عدم دسترسی کامل به اپلیکیشن (blank screen، خطای 502)، عدم دسترسی جزئی (ماژول پرداخت کار نمی‌کند اما سایر عملکردها در دسترس هستند) یا تخریب عملکرد (بارگذاری فوق‌العاده کند) ظاهر شود. Severity رویداد با درصد کاربران آسیب‌دیده و مدت زمان خرابی تعیین می‌شود.

طبق Atlassian Statuspage (2025)، میانگین downtime برای اپلیکیشن‌های موبایل در سال 2024، 27 دقیقه به ازای هر رویداد بود. شایع‌ترین علل: رگرسیون کد پس از deploy (34%)، از کار افتادن ارائه‌دهنده ابر (22%)، مشکلات پایگاه داده (18%)، خطاهای پیکربندی (15%) و حملات DDoS (11%). نکته کلیدی: اکثر خرابی‌ها مربوط به تغییراتی است که خود تیم اعمال کرده، نه عوامل خارجی.

تشخیص بین crash (از کار افتادن اپلیکیشن در سمت کلاینت) و backend outage (عدم دسترسی سرور) مهم است. Crash معمولاً با hotfix کد کلاینت و backend outage با تغییرات زیرساختی یا redeploy سرویس برطرف می‌شود. معیارهای نظارت: برای کلاینت — crash-free rate، برای سرور — error rate 5xx و p95 latency. APM (Application Performance Monitoring) — Sentry، New Relic، Datadog — به تشخیص سریع نوع خرابی کمک می‌کند.

سطوح severity رویدادها: P0، P1، P2 و معیارهای طبقه‌بندی

طبقه‌بندی یکپارچه severity اساس واکنش سریع است. بدون آن، تیم زمان را صرف بحث «این چقدر فوری است» می‌کند به جای اقدام. مقیاس کلاسیک: P0 (critical) — اپلیکیشن کاملاً در دسترس نیست یا داده‌های کاربران نشت می‌کند، زمان واکنش — فوری؛ P1 (high) — عملکرد بحرانی برای 50%+ کاربران کار نمی‌کند، زمان واکنش — 15 دقیقه؛ P2 (medium) — عملکرد غیربحرانی برای بخشی از کاربران در دسترس نیست، زمان واکنش — 1 ساعت.

P0 نیاز به escalation فوری دارد: مهندس شیفت هر کار جاری را متوقف می‌کند و به رویداد می‌پردازد. اگر بعد از 10 دقیقه مشکل حل نشد — tech lead وارد می‌شود. اگر بعد از 30 دقیقه — escalation به engineering manager. برای رویدادهای P0 نقض هر فرآیندی مجاز است: hotfix بدون code review کامل، deploy مستقیم به پروداکشن، نادیده گرفتن قوانین branch protection. Emergency override باید از قبل در سطح تیم توافق شده باشد.

جدول severity

بسیار مهم است که در severity به سمت پایین اشتباه نکنیم. P0 + P1 که به عنوان P2 طبقه‌بندی شده‌اند منجر به واکنش دیررس و افزایش downtime می‌شوند. قانون: اگر شک دارید — P0 بگذارید. Over-classification بهتر از under-classification است: بهتر است جلسه اضافی تشکیل دهیم تا یک ساعت زمان بازیابی را از دست بدهیم.

10 دقیقه اول: الگوریتم اقدام هنگام خرابی

Timer starts: از لحظه‌ای که alert یا پیام کاربر می‌رسد. 10 دقیقه اول — مهم‌ترین هستند. الگوریتم: 1) confirm the issue — مطمئن شوید مشکل واقعی است (نه alarm کاذب)؛ 2) stop the bleeding — فوراً impact را کاهش دهید (rollback، feature toggle، مسدودسازی endpoint)؛ 3) communicate — در کانال عمومی #incident وضعیت را بنویسید: چه شد، severity، چه اقداماتی انجام می‌شود. 10 دقیقه اول صرف تحلیل علت ریشه‌ای نمی‌شود.

همزمان با توقف خونریزی، یک مهندس تشخیص را آغاز می‌کند، دومی — ارتباطات. کانال‌های ارتباطی: Slack #incident channel (برای تیم)، صفحه وضعیت (برای کاربران)، ایمیل/SMS escalation (برای مدیریت). هر 15 دقیقه — به‌روزرسانی وضعیت با اطلاعات: چه مشخص است، چه اقداماتی انجام می‌شود، ETA بازیابی. Status page (StatuPage، Statuspal) uptime و تاریخچه رویدادها را برای کاربران خارجی نمایش می‌دهد.

چگونه خونریزی را متوقف کنیم: rollback، feature toggle و hotfix

اولین و مهم‌ترین قانون: سعی نکنید مشکل را روی پروداکشن برطرف کنید. اگر نسخه جدید باعث خرابی شده — به نسخه پایدار قبلی rollback کنید. اگر خرابی ناشی از ویژگی خاصی است که با feature toggle خاموش شده — فقط toggle را خاموش کنید. اگر نه rollback و نه toggle در دسترس نیست — hotfix با minimal diff. Rollback — امن‌ترین گزینه، زیرا به وضعیتی برمی‌گردیم که قبلاً کار می‌کرده است.

Feature toggle (یا feature flag) — ابزار قدرتمندی برای stop-the-bleeding بدون deploy. اگر ماژول پرداخت از کار افتاده اما با toggle خاموش شده — کاربران به سادگی دکمه پرداخت را نمی‌بینند، نه صفحه خطا. Toggle نیاز به ساخت build ندارد، نیاز به review فروشگاه ندارد، در چند ثانیه اعمال می‌شود. هر ویژگی بحرانی باید تحت feature toggle با امکان خاموش‌سازی در سطح سرور (remote config) باشد. Feature flag — خط اول دفاع.

اگر rollback ممکن نیست (مثلاً به دلیل مهاجرت غیرقابل بازگشت BD) و toggle پیش‌بینی نشده — آخرین راه: hotfix با حداقل اصلاح. Hotfix از آخرین تگ release ایجاد می‌شود، فقط شامل خطوط لازم برای رفع خرابی است و deploy fast-track را طی می‌کند (به مقاله «Hotfix — اصلاحات فوری» مراجعه کنید). Golden rule: پس از پایدارسازی، همیشه root cause analysis انجام دهید، حتی اگر علت واضح به نظر برسد.

تشخیص علل: لاگ‌ها، متریک‌ها و آلارم‌ها

پس از توقف خونریزی (یا همزمان، اگر تعداد مهندسان اجازه دهد) تشخیص آغاز می‌شود. اولین منبع — لاگ‌ها. لاگینگ متمرکز (ELK، Grafana Loki، Datadog Logs) امکان یافتن خطا بر اساس timestamp، ID کاربر یا ID درخواست را فراهم می‌کند. مهم: لاگ‌ها باید ساختاریافته (JSON) باشند تا grep سریع کار کند. Structured logging — الزام اجباری برای همه سرویس‌ها.

دومین منبع — متریک‌ها. Grafana، Datadog، New Relic نشان می‌دهند که چه زمانی spike خطاها رخ داده، روی کدام endpointها، با چه کدهای وضعیتی. مقایسه متریک‌های قبل و بعد از deploy به مکان‌یابی مشکل تا سطح سرویس یا endpoint خاص کمک می‌کند. RED metrics (Rate، Errors، Duration) — استاندارد نظارت میکروسرویس‌ها.

سومین منبع — distributed tracing. Jaeger، Zipkin، Datadog APM مسیر درخواست را از طریق میکروسرویس‌ها نشان می‌دهد و مشخص می‌کند که دقیقاً تأخیر یا خطا در کجا رخ داده است. Tracing به ویژه در خرابی‌های آبشاری مفید است، وقتی خطا در یک سرویس باعث خطا در همه سرویس‌های وابسته می‌شود. Trace ID باید از کلاینت به همه سرویس‌های backend منتقل شود.

# نمونه تشخیص سریع با استفاده از kubectl و لاگ‌ها
# لیست podهای دارای خطا
kubectl get pods --field-selector=status.phase!=Running

# بررسی لاگ‌های pod crashed شده
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# جستجوی خطاها در سرویس در ۳۰ دقیقه گذشته
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

مهم: قبل از توقف خونریزی سعی در تشخیص علت نکنید. اگر 50% کاربران crash می‌بینند — اول rollback، بعد تحلیل. استثنا: اگر rollback بیشتر از hotfix مستقیم زمان ببرد (مثلاً در صورت ناسازگاری داده‌ها). در این صورت hotfix فوراً اعمال می‌شود و post-mortem پس از پایدارسازی انجام می‌شود. Diagnosis before fix — الگوی خطرناکی که downtime را افزایش می‌دهد.

Post-mortem: چگونه رویدادها را بدون یافتن مقصر تحلیل کنیم

Post-mortem (همچنین incident review نامیده می‌شود) — تحلیل ساختاریافته رویداد است که 24-72 ساعت پس از حل آن انجام می‌شود. هدف: فهمیدن چرایی وقوع خرابی، چرایی عدم شناسایی آن توسط نظارت و تست‌ها قبل از پروداکشن، و چه تغییری در فرآیندها برای جلوگیری از تکرار. Blameless culture — اصل اساسی: post-mortem فرآیندها، ابزارها و ارتباطات را بررسی می‌کند، نه اشتباهات افراد خاص.

ساختار سند post-mortem: timeline (گاه‌شماری رویدادها با timestamp)، impact (کاربران آسیب‌دیده، مدت زمان، زیان مالی)، root cause (علت فنی ریشه‌ای)، detection (چگونه کشف شد، چرا زودتر شناسایی نشد)، response (چه اقداماتی انجام شد، چه کاری را می‌شد سریع‌تر انجام داد)، action items (وظایف مشخص با افراد مسئول و مهلت‌ها). Action items باید S.M.A.R.T. باشند: specific، measurable، assignable، realistic، time-bound.

Action items معمول پس از خرابی پروداکشن: افزودن نظارت و alert بر متریکی که ساکت بود؛ گسترش پوشش تست برای مورد از قلم افتاده؛ افزودن صفحه به runbook با الگوریتم گام‌به‌گام برای وضعیت مشابه؛ برگزاری training تیم برای ابزاری که نادرست استفاده شده بود. هر action item تغییری ملموس است که احتمال تکرار رویداد را کاهش می‌دهد.