راه طولانی و پرپیچ‌ و خم به سوی تاب‌ آوری - بخش پنجم

در پست قبلی، درباره "تله 100% Availability" صحبت کردیم. در این پست به آنچه در مرحله Robustness خواهیم رسید، می پردازیم.

بخش چهارم: https://vrgl.ir/XZgdL

این مرحله، دومین توقفگاه موقت سازمان ها در مسیر تاب آوری است. به دلیل اینکه رسیدن به آن نیازمند تغییر نگرش است و تغییر نگرش معمولا سخت و زمان بر است، تعداد کمی از شرکت ها به این مرحله می رسند. این تغییر نیازمند پذیرش این واقعیت است که شکست ها اجتناب ناپذیر هستند:

ما نمی توانیم از شکست ها به شکل کامل جلوگیری کنیم، پس بیایید آن ها را بپذیریم.

البته این موضوع به معنای بی توجهی برای جلوگیری از شکست نیست. بهتر است به جای تجربه یک شکست در هرساعت، تنها یک بار در هفته آن را تجربه کنیم. اما موضوع اصلی این است که نباید تنها بر پیشگیری از شکست متکی باشیم، یعنی فرض کنیم که با افزایش MTTF تنها یک بار در قرن دچار مشکل شویم!

پذیرش شکست ها

بپذیریم امکان جلوگیری کامل از شکست ها محدود است. ما می توانیم آن ها را کاهش دهیم، اما نمی توانیم آن ها را به طور کامل حذف کنیم. برای همین بهتر است روی مدیریت شکست ها تمرکز کنیم، برای مثال کاهش اثرات آن ها یا بازیابی سریع.

تفکر اصلی در این مرحله

می خواهیم Availability را به حداکثر برسانیم. برای این کار باید بخشی از تمرکزمان را بر افزایش MTTF قرار دهیم، و از آن مهم تر باید راه هایی را برای کاهش MTTR پیدا کنیم، یعنی سریعا شکست ها را شناسایی و بازیابی کنیم یا حداقل اثرات آن ها را کاهش دهیم. سوالات مهم:
- چه چیزی ممکن است با مشکل مواجه شود و چگونه می توانم به آن پاسخ دهم؟
- اگر یک سرویس در دسترس نباشد، چه کاری می توانم انجام دهم؟
- چگونه می توانم درخواست ها و پاسخ های نامعتبر را شناسایی و مدیریت کنم؟
- چگونه می توانم سریعا باگ ها و مشکلات دیگر را برطرف کنم؟
سوال اول یک سوال کلی و جامع است. اما سوالات دیگر مثال هایی برای انواع خاصی از شکست ها هستند.

برای این سوالات، ما باید مجموعه از اقدامات را انجام دهیم:

1- پیاده سازی جایگزین ها (Fallbacks): انجام پاسخ های جایگزین منطقی در سطح بیزینس که در صورت وقوع خطا تکنیکال، به جای مسیر اصلی درخواست انجام می شوند.
2- بررسی کامل پارامترها: بررسی دقیق پارامترهای ورودی. درست است که این اقدام بدیهی به نظر می رسد، اما در بسیاری از موارد به درستی اجرا نمی شود.
3- اتومات کردن Deploy: استفاده از CI/CD و ابزارهایی مانند IaC/IfC. این کار بیشتر بر سرعت تمرکز دارد تا repeatability. هر چه استقرار نسخه های جدید سریع تر انجام شود، MTTR در مواجه با خطاها کاهش پیدا می کند.
4- کاهش زمان راه اندازی سیستم ها: کاهش زمان راه اندازی بخش ها می تواند MTTR را به طور قابل توجهی بهبود ببخشد، بدون اینکه فقط به Redundancy و Failover متکی باشد.
5- نظارت دقیق در سطح برنامه و بیزینس: برای شناسایی زودهنگام خطاها و مدیریت آن ها قبل از اینکه به شکست تبدیل شوند.

توضیح تفاوت بین Failure, Fault و Error از Robert S. Hanmer:

Fault: نقص که در سیستم وجود دارد و ممکن است باعث ایجاد خطا شود. مانند یک باگ نرم افزاری
Error: رفتار نادرست سیستم که از درون سیستم قابل مشاهده است و ممکن است منجر به شکست شود، اما از بیرون قابل مشاهده نیست. از بیرون سیستم همچنان عمل می کند.
Failure: رفتار نادرست سیستم که از بیرون قابل مشاهده است. یعنی رفتار سیستم با چیزی که باید باشد یکسان نیست.

مدیریت خطا معمولا به دو روش انجام می شود:

1- Error Recovery: رفع علت خطا و بازگرداندن سیستم به وضعیت عادی.
2- Error Mitigation: استفاده از Graceful Degradation تا زمانی که مشکل رفع شود یا شرایط برای رفع آن فراهم شود.
در بهترین حالت، خطا فورا رفع می شود و عملیات عادی ادامه می یابد بدون اینکه کسی متوجه مشکل شود. اما گاهی اوقات سیستم فاقد زمان، اطلاعات یا منابع لازم برای بازیابی فوری است.

Graceful Degradation

اگر سیستم نتواند فورا خطا را رفع کند، باید سرویس های خود را به صورت کنترل شده کاهش دهد:
- در شرایط Overload، شاید بعضی از درخواست ها را حذف کنیم.
- اگر دسترسی به دیتابیس با مشکل مواجه شود، می توانیم داده ها را از کش بخوانیم و درخواست های write را نپذیریم.

FallBack Pattern

این پترن می پرسد، اگر چیزی مطابق انتظار عمل نکرد، چه کاری باید انجام داد؟ برای مثال در صورت مشکل در برنامه A، برنامه B چیست؟
اجرای FallBack نیازمند درگیر کردن بیزینس است. تصمیم درباره نحوه پاسخگویی سیستم به شکست های مختلف بسته به اهمیت و حساسیت آن ها متفاوت خواهد بود.
- در صورت شکست در یک recommendation engine، ممکن است خطا به‌صورت بی صدا نادیده گرفته شود.
- اما شکست در فرآیند پرداخت یک فروشگاه آنلاین موضوعی بسیار جدی خواهد بود.

نقش بیزینس در این مرحله

یکی از تفاوت های اصلی بین پایداری و مقاومت:
- در مرحله پایداری فرض بر این بود که می توان با روش های فنی از شکست ها جلوگیری کرد و نیازی به همکاری بخش بیزینس نبود.
- در مرحله مقاومت مشخص است که شکست ها اجتناب ناپذیرند و باید پذیرفته شوند. این به معنای درگیر شدن بخش بیزینس برای تصمیم گیری درباره بهترین روش برای مدیریت شکست ها است.

منبع: Uwe Friedrichsen - ufried . com