چند وقت پیش در حال ارائه‌ی یک سند به جمعی از اعضای Tech Leadership اسنپ‌فود بودم؛ سندی که اسمش را گذاشته ام Service Maturity Model. این مدل را برای سرویس‌های اسنپ‌فود طراحی کرده‌ام تا مسیر رشد، استانداردسازی و بلوغ آن‌ها شفاف‌تر باشد.
همه‌چیز داشت طبق روال پیش می‌رفت تا این‌که یکی از همکاران به بخشی از مدل اشاره کرد و پرسید:
«این‌که گفتی باید MTTR را به زیر یک دقیقه برسانیم، واقعاً شدنی است یا زیادی سخت‌گیرانه است؟»
همین پرسش ساده جرقه‌ای شد برای یک گفت‌وگوی یک‌ساعته بین من و او. بعدش هم چند روز ذهنم را درگیر کرد، باعث شد مطالعه کنم و تجربه‌های گذشته‌ام را مرور کنم. در نهایت به یک لیست عملی رسیدم که می‌تواند به تیم‌ها کمک کند زمان بازیابی سرویس‌هایشان (MTTR) را به شکل جدی کاهش دهند.
در این مقاله می‌خواهم هم تجربه‌ی شخصی خودم را تعریف کنم، هم راهکارهایی را که در مسیر تحقیق و بحث به آن‌ها رسیدم با شما به اشتراک بگذارم.
MTTR دقیقاً چیست؟
MTTR یا Mean Time To Recovery یکی از شاخص‌های کلیدی در حوزه‌ی Site Reliability Engineering (SRE) و DevOps است. تعریف ساده‌اش این است:
میانگین زمانی که طول می‌کشد تا بعد از یک failure یا incident، سرویس دوباره به حالت پایدار و قابل‌استفاده برگردد.
فرض کنید سه بار سرویس شما دچار مشکل شود:
Incident اول: ۱۰ دقیقه طول می‌کشد تا درست شود.
Incident دوم: ۴ دقیقه.
Incident سوم: ۶ دقیقه.
MTTR برابر است با (۱۰ + ۴ + ۶) تقسیم بر ۳ = ۶.۶ دقیقه.
هرچه این عدد پایین‌تر باشد، کاربران شما تجربه‌ی بهتری خواهند داشت و اعتماد بیشتری به سیستم پیدا می‌کنند.
چطور می‌توانیم MTTR را دقیق اندازه‌گیری کنیم؟
اینجا یک نکته‌ی کلیدی وجود دارد، شما نمی‌توانید چیزی را که درست اندازه‌گیری نکرده‌اید، مدیریت کنید.
برای اندازه‌گیری MTTR باید دو لحظه‌ی دقیق را مشخص کنید:
شروع incident: زمانی که سرویس از حالت stable خارج میشود (مثلاً health check fail یا هشدار مانیتورینگ فعال میشود).
پایان incident: زمانی که سرویس دوباره برای کاربران قابل‌استفاده است.
به نظر ساده می‌آید، اما در عمل اگر این دو نقطه شفاف نباشند، آمار شما گمراه‌کننده خواهد بود. بهترین کار این است که:
- همه‌ی incidentها در یک incident management system ثبت شوند. (مثل PagerDuty یا Jira Incident)
- شروع و پایان incident به‌طور خودکار ثبت شوند (از طریق alertها و health checkها).
چرا باید روی کاهش MTTR وسواس داشته باشیم؟
خیلی وقت‌ها تیم‌ها تمرکزشان را روی MTTF (Mean Time To Failure) یا همان میانگین زمان بین خطاها می‌گذارند. یعنی سعی می‌کنند فاصله‌ی بین failureها را بیشتر کنند. این البته مهم است، اما کافی نیست.
واقعیت این است که هرچقدر هم مهندسی قوی داشته باشید، سرویس شما بالاخره جایی دچار مشکل میشود. در این لحظه، چیزی که اهمیت پیدا می‌کند، سرعت شما در بازگرداندن سرویس به حالت پایدار است.
- از دید کاربر: هر دقیقه downtime یعنی کاربر ناراضی، تجربه بد، و احتمال رفتن به سمت رقیب.
- از دید سازمان: incident طولانی مساوی است با هزینه‌های بیشتر (هم هزینه مستقیم از دست رفتن درآمد، هم هزینه نیروی انسانی).
- از دید تیم: وقتی بدانید می‌توانید سریع مشکلات را حل کنید، اعتمادبه‌نفس بیشتری پیدا می‌کنید و بدون ترس از شکست، تغییرات را جلو می‌برید.
به بیان ساده:
MTTR پایین‌تر = سازمانی که سریع‌تر از بحران عبور می‌کند.
راهکارهای کاهش MTTR
خب، حالا برسیم به اصل مطلب، چه کارهایی می‌توانیم بکنیم تا MTTR را به‌طور واقعی کاهش دهیم، حتی تا کمتر از یک دقیقه؟
من این راهکارها را به چند دسته تقسیم می‌کنم:
پیشگیری از خطاهای بزرگ در ریلیز
بخش زیادی از incidentها بعد از ریلیز اتفاق می‌افتند. پس اگر بتوانیم فرآیند ریلیز را هوشمندانه‌تر کنیم، MTTR هم کاهش پیدا می‌کند.
Feature Flags / Toggles
به جای این‌که فیچر جدید را با دیپلوی نهایی فعال کنید، آن را پشت یک فلگ بگذارید. این‌طوری اگر فیچر مشکل داشت، کافی است فلگ را خاموش کنید.
Canary Release
تغییرات را اول روی درصد کوچکی از کاربران منتشر کنید. اگر مشکلی دیدید، همان‌جا متوقف شوید.
Blue/Green Deployment
دو محیط پروداکشن داشته باشید: یکی active و یکی standby. وقتی محیط active مشکل‌دار شد، در یک لحظه می‌توانید به محیط standby سوئیچ کنید.
Small Batch Release
هر بار تغییرات کوچک ریلیز کنید. پیدا کردن مشکل راحت‌تر میشود و rollback هم سریع‌تر انجام خواهد شد.
بهبود مشاهده پذیری (Observability)
یک جمله‌ی معروف هست که می‌گوید:
نمی‌توانید چیزی را که نمی‌بینید، درست کنید.
اگر نمی‌دانید دقیقاً چه اتفاقی در سیستم می‌افتد، MTTR شما هیچ‌وقت پایین نخواهد آمد.
Monitoring & Alerting دقیق
ابزارهایی مثل Prometheus، Grafana یا Datadog باید نه تنها خطا را ببینند، بلکه سریع هشدار بدهند. البته باید مراقب باشید که false positive زیاد نداشته باشید.
Centralized Logging
وقتی همه‌ی لاگ‌ها در یک جا جمع باشند (مثل ELK یا Loki)، می‌توانید در لحظه بفهمید چه خبر است.
Distributed Tracing
ابزارهایی مثل Jaeger یا OpenTelemetry به شما نشان می‌دهند که درخواست کاربر در طول سفرش بین سرویس‌ها کجا گیر می‌کند.
Dashboards آماده
وقتی incident اتفاق می‌افتد، وقت طراحی داشبورد نیست. داشبوردهای آماده می‌توانند در بحران واقعاً نجات‌بخش باشند.
تسهیل عملیات Incident
وقتی سیستم خراب شد، تیم نباید وقتش را صرف این کند که "خب حالا چه کار کنیم؟". همه‌چیز باید از قبل آماده باشد.
Runbook / Playbook
یک سری دستورالعمل ساده و آماده برای مشکلات رایج. مثلاً: "اگر دیتابیس کند شد، این مراحل را برو".
On-Call Rotation
باید همیشه فردی مشخص برای پاسخ اولیه وجود داشته باشد.
Incident Commander Role
یک نفر مسئول تصمیم‌گیری باشد تا تیم وارد بحث‌های طولانی و بی‌حاصل نشود.
Automated Rollback
اگر دیپلوی fail شد، سیستم خودش باید در چند ثانیه به نسخه‌ی پایدار قبلی برگردد.
Rollback و Revert آماده
یکی از ایده‌هایی که توسط همان فردی که اول مقاله گفتم سوال را پرسید مطرح شد، این بود که:
برای هر ریلیز یک revert آماده داشته باشیم.
همه‌ی مراحل تست و پایپلاین (که ممکن است ۲۰ دقیقه طول بکشد) از قبل اجرا شوند.
اما revert نهایی دیپلوی نشود و فقط آماده بماند.
اگر مشکلی پیش آمد، کافی است revert را اجرا کنیم.
در نتیجه بازگشت به نسخه‌ی پایدار در کمتر از یک دقیقه انجام میشود.
گاهی اوقات ساده‌ترین راهکارها بیشترین تاثیر را دارند.
یادگیری از گذشته و آماده‌سازی برای آینده
حتی وقتی MTTR را به زیر یک دقیقه می‌رسانید، باز هم incidentها رخ خواهند داد. نکته اینجاست که از هر کدام یاد بگیرید.
Postmortem Culture
بعد از هر incident یک جلسه‌ی postmortem برگزار کنید. بدون سرزنش، فقط یاد بگیرید که ریشه‌ی مشکل چه بود و چطور میشود دفعه‌ی بعد جلویش را گرفت.
Chaos Engineering
قبل از این‌که مشکل واقعی رخ بدهد، خودتان شرایط failure را شبیه‌سازی کنید. مثلاً عمداً دیتابیس را قطع کنید یا شبکه را کند کنید. این کار باعث میشود تیم در شرایط واقعی غافلگیر نشود.
جمع‌بندی
رسیدن به MTTR زیر یک دقیقه شاید در نگاه اول غیرواقعی به نظر برسد. اما اگر فرآیندها، ابزارها و فرهنگ تیمی‌تان را درست طراحی کنید، شدنی است.
کلید ماجرا این است:
- تغییرات کوچک و برگشت‌پذیر داشته باشید.
- سیستم را همیشه قابل‌مشاهده نگه دارید.
- نقش‌ها و فرایندهای incident را شفاف کنید.
- rollback را از قبل آماده داشته باشید.
- از هر failure یاد بگیرید و آماده‌تر شوید.
برای من، آن پرسش ساده‌ی همکارم یک تلنگر بود:
آیا واقعاً داریم به اندازه کافی سریع از بحران‌ها عبور می‌کنیم؟
امیدوارم این مقاله هم برای شما تلنگری باشد تا به فرآیندهایتان نگاه کنید و ببینید چطور می‌توانید MTTR را در سازمان خودتان کاهش دهید.