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

در بخش قبلی درباره ی سطح اول تاب آوری، پایداری صحبت کردیم. جایی که سیستم ها به ثبات نسبی می رسند اما هنوز تا تاب آوری کامل فاصله دارند. در این بخش درباره ی موضوع مهم تر، تله 100% Availability صحبت می کنیم.

بخش سوم: https://vrgl.ir/6XMFj

این تله یک اشتباه رایج است که تصور می کند سیستم ها همیشه و تحت هر شرایطی در دسترس هستند. این طرز فکر معمولا از این پیش فرض نادرست ناشی می شود که مسئولیت Availability بر عهده ی تیم Ops است. در عمل این باور باعث نادیده گرفتن احتمال خرابی بخش هایی می شود که خارج از کنترل مستقیم یک تیم قرار دارند، مانند:
Operating systems
Routers
Message busses
Databases
...
در طراحی های اغلب فرض می شود این ها همیشه در دسترس خواهند بود. اما این فرض اشتباه است و خرابی ها اجتناب ناپذیرند.

برای مثال وقتی سرویس Kinesis در AWS دچار مشکل شد، بسیاری از شرکت‌ها به مشکل برخوردند، چون در طراحی سیستم هایشان احتمال خرابی این سرویس را پیش‌بینی نکرده بودند.

این تله به یک توهم امنیت منجر می شود. طراح ها فکر می کنند که با استفاده از redundancy و روش های معمول دیگر، سیستم به 100% Availability می رسد. اما همانطور که می دانیم این مورد با اصول مهندسی قابل اعتماد در تضاد است. آقای Pat Helland میگه:
Reliable systems have always been built out of unreliable components.
در مقابل در توسعه ی سیستم های سازمانی معمولا برعکس عمل می شود: سیستم های غیرقابل اعتماد ساخته می شوند و انتظار دارند که infra آن ها را قابل اعتماد کند!

سطح دوم: پذیرش خرابی ها
برای پیشرفت در مسیر تاب آوری، باید قبول کنیم که خرابی ها اجتناب ناپذیرند. این پذیرش باعث می شود که از تلاش بیهوده برای جلوگیری از خرابی ها به سمت برنامه ریزی برای مدیریت و بهبود آن ها حرکت کنیم. آقای Michael Nygard میگه که:
Continuous partial failure is the normal state of affairs.

برای افزایش قابلیت Availability، از فرمول زیر استفاده می کنیم:
Availability = MTTF / (MTTF + MTTR)
MTTF: Mean Time To Failure
MTTR: Mean Time To Recovery
در سطح پایداری معمولا تلاش برای جلوگیری از خرابی ها هستش. هدف این که MTTF آن قدر بزرگ شود که MTTR اهمیتی نداشته باشد. اگر MTTF به 1.000.000 ساعت برسد(بیش از ۱۰۰ سال!) انتظار خرابی برای نسل های آینده می باشد و MTTR اهمیت چندانی نخواهد داشت. اما این فرض که MTTF آن قدر بزرگ است، باعث می شود که همه انتظار داشته باشند سیستم هرگز خراب نشود و این همان تله است. در نتیجه هرچند افزایش MTTF مهم است، اما این متریک حد بالایی دارد. برای همین کاهش MTTR اولویت بیشتری دارد.

سطح سوم: شناخت انواع خرابی ها
در اینحا به خرابی هایی فکر می کنیم که ممکن است سیستم ما را تحت تاثیر قرار دهند و اینکه چگونه می توانیم به سرعت سیستم را بازیابی کنیم. به عبارت دیگر چگونه می توانیم MTTR را کاهش دهیم. در سطح پایداری اغلب تمرکز افراد بر روی خرابی های ناشی از crash و overload است. اما خرابی ها فراتر از این دو مورد هستند. مانند:
Omission failures
Timing failures
Response failures
Byzantine failures
Software bugs
Configuration bugs
...
اگر بپذیریم که خرابی ها اجتناب ناپذیرند، باید انواع خرابی ها را شناسایی کنیم و به طور خاص به این سوال پاسخ دهیم که چگونه می توانیم این خرابی ها را سریع تر شناسایی و رفع کنیم تا MTTR کاهش یابد.

منبع: Uwe Friedrichsen - ufried . com