تاب‌آوری (Resiliency): طراحی سیستم‌هایی که خم می‌شوند اما نمی‌شکنند!
تو کتاب فارسی نمیدونم چندم دبستان بود که داستان یه درخت بلوط تنومند بود و چند شاخه نی، داستان اینطوری پیش می‌رفت که درخت به ریشه‌ها و تنه تنومندش می‌نازید و برای زندگی نحیف نی‌ها دلسوزی می‌کرد و میگفت شماها با هر باد خم میشید و هر چقدر اون باد ضعیف هم باشه شما رو خم میکنه، اما چیزی که درخت خبر نداشت انعطاف‌پذیری نی‌ها در برابر بادهای خیلی تند بود که می‌تونستند از پسش بربیان. که یک روز یکی از اون بادها درخت رو انداخت اما همچنان نی‌ها برقرار بودند. 🌳
دنیای واقعی ذاتاً پر از آشوب است. شبکه‌ها ناپایدارند، سرویس‌ها از کار می‌افتند، وابستگی‌ها خطا می‌دهند و این اتفاق‌ها معمولاً در بدترین زمان ممکن رخ می‌دهند (یا ساعت پایانی کار روز چهارشنبه یا نصفه شب).
حتی مقاوم‌ترین سیستم‌های دنیا نیز از شکست مصون نیستند. به همین دلیل، تمرکز صرف بر جلوگیری از خرابی کافی نیست؛ آنچه سیستم‌های مدرن را متمایز می‌کند، تاب‌آوری (Resiliency) آن‌هاست.
در حالی که Robustness (استحکام) تلاش می‌کند احتمال بروز خطا را کاهش دهد، Resiliency (تاب‌آوری) بر این اصل بنا شده است که:
«خرابی اجتناب‌ناپذیر است؛ مهم این است که سیستم چقدر سریع و هوشمند به حالت پایدار بازمی‌گردد.»
🪢 تاب‌آوری چیست؟
تاب‌آوری در معماری نرم‌افزار یعنی توانایی سیستم برای ادامهٔ ارائهٔ سرویس، حتی در شرایط شکست، و بازیابی سریع با حداقل اختلال برای کاربر.
🗯 یک سیستم تاب‌آور:
- شکست را تشخیص می‌دهد
- آن را مهار می‌کند
- اجازه نمی‌دهد خرابی یک جزء، کل سیستم را از کار بیندازد
و در نهایت، خود را بازیابی می‌کند
سیستم تاب‌آور مانند نیزار در برابر باد است: خم می‌شود، اما نمی‌شکند؛ و پس از طوفان دوباره سرپا می‌ایستد.
💥 دو شاخص کلیدی برای اندازه گیری تاب‌آوری:
1️⃣ RTO – Recovery Time Objective
حداکثر زمانی که یک سرویس باید در آن بازیابی شود تا اختلال ایجادشده غیرقابل‌قبول تلقی نشود.
ءRTO بسته به اهمیت سرویس متفاوت است و مرز بین «اختلال قابل قبول» و «Incident» را مشخص می‌کند.
2️⃣ MTTR – Mean Time To Repair/Recover
میانگین زمانی که طول می‌کشد تا یک سرویس پس از شکست به حالت عملیاتی بازگردد.
🌪 چرا تاب‌آوری حیاتی است؟
تاب‌آوری مستقیماً بر تجربهٔ کاربر و درآمد کسب‌وکار اثر می‌گذارد.
در بازارهای رقابتی، کاربر تحمل:
• لودینگ‌های طولانی
• درخواست‌های معلق
• صفحات خطای مداوم
را ندارد؛ به‌خصوص در روزهای اوج ترافیک مثل جمعه سیاه یا حراجی‌های بهمن ماه.
از سوی دیگر، تاب‌آوری مزایای مهمی برای تیم‌های فنی دارد:
- کاهش Incidentهای ناگهانی
- فشار کمتر on-call
- تست‌پذیری و پایداری بالاتر
تاب‌آوری اگر از ابتدا در طراحی لحاظ شود، بسیار کم‌هزینه‌تر و مؤثرتر از وصله‌کاری بعد از بحران است.
الگوهای کلیدی تاب‌آوری
🔹️ Circuit Breaker: قطع ارتباط موقت یک سرویس
🔸️ Fallback: نسخه از کش یا حذف از UI
🔹️ Bulkhead: جداسازی منابع مثلا گزارش‌گیری‌ها
🔸️ Redundancy: استفاده از نسخه‌های جایگزین مخصوصا در معماری Loosely Coupled
🔹️ Fault Tolerance در کد
🔸️ Message Queue
🔹️ Rate Limiter
📌جمع‌بندی نهایی
تاب‌آوری یعنی:
شکست یک جزء ≠ شکست کل سیستم
عملکرد اصلی باید همیشه زنده بماند
قابلیت‌های جانبی باید قابل حذف، جایگزینی یا تضعیف باشند
هدف نهایی: ارائهٔ حداقل تجربهٔ قابل قبول در بدترین شرایط
یا به زبان ساده‌تر:
هیچ‌وقت به کاربر خطای ۵۰۰ نشان نده؛
حتی وسط طوفان، بگذار سیستم خم شود، نه بشکند.
🔗Link