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

در مطلب قبلی، درباره «دره تکمیل فیچرها» به عنوان نقطه شروع سفر ما به سوی تاب‌ آوری صحبت کردیم و متوجه شدیم که چنین ساختاری دیگه معمولا توصیه نمیشه. برای همین در ادامه بررسی خواهیم کرد که چرا با وجود نامناسب بودن این رویکرد همچنان شاهد چنین ساختارهایی در شرکت ها هستیم. سپس خواهیم دید که در اولین سطح تاب آوری به چه چیزی خواهیم رسید.

پارت دوم:‌ https://vrgl.ir/G8BKz

گذشته‌ای که هنوز زنده است!
چرا هنوز این طرز فکر در شرکت‌ها وجود دارد که تیم Ops مسئول Availability است؟ در شرایطی که باقی تیم ها فقط بر روی فیچرها تمرکز دارند. اگر به سیستم ها توجه کنیم مشخص است که این طرز فکر دیگر کارساز نیست. برای درک بهتر این موضوع به گذشته برمیگردیم. در دهه ۲۰۰۰ بیشتر زیرساخت ها از برنامه های بزرگ و یک پارچه به نام مونولیتیک تشکیل شده بودن. این برنامه ها مستقل کار می کردند و اگر لازم می شد باهم ارتباط برقرار کنند، معمولا از batch updates استفاده می کردند. برای مثال سیستم A هرچند وقت یک بار یک فایل تولید می کرد و سیستم B آن دریافت و پردازش می کرد. خب در این سیستم ها اگر یک سیستم با مشکل مواجه می شد سیستم دیگری همچنان می توانست کار خودش را ادامه دهد.

اما سیستم ها بسیار تغییر کرده اند. دیگر کسی نمی خواهد که یک یا چندبار در ساعت های مختلف به روزرسانی شوند. انتظار این است که همه چیز در همه جا و در لحظه در دسترس باشد. درحال حاضر سیستم ها به دو روش عمل می کنند:
Pull-based: مصرف کننده اطلاعات هروقت که لازم باشد داده ها را از تولید کننده درخواست می کند.
Push-based: تولید کننده هر تغییری را در لحظه برای مصرف کننده ها ارسال می کند.
برای همین زیرساخت ها از سیستم های جداگانه به شبکه ای پیچیده و به Tightly Coupled تبدیل شده اند. سیستم ها دیگر فقط یک برنامه ساده نیستند، بلکه یک سیستم به یک سیستم توزیع شده بزرگ و پیچیده تبدیل شده اند که با معماری های مدرن مثل میکروسرویس ها و... کار می کنند.


تیم Ops دیگر به تنهایی کافی نیست
باتوجه به تغییرات دیگر نمی شود انتظار داشت تیم Ops به تنهایی مسئول Availability باشد. تاثیرات توزیع شدگی به لایه برنامه ها نفوذ کرده است و مشکلات در سطح برنامه باید توسط تیم Dev مدیریت شوند. به همین خاطر اولین سطح تاب آوری یعنی سطح پایداری مطرح می شود.

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

پایداری در عمل - این سطح معمولا شامل اقدامات زیر است:
- استفاده از ابزارهایی مثل Kubernetes برای ایجاد Redundancy.
- پیاده سازی پترن هایی مانند Retry, Circuit breaker و ... برای مدیریت خطاها.
- تنظیم محدودیت ها برای جلوگیری از overload یا استفاده از مقیاس پذیری خودکار.

نقاط قوت

- پیاده سازی آسان است و نیازی به تغییرات بزرگ در ساختارهای تیمی وجود ندارد.
- هزینه ها نسبتا پایین است.

ضعف ها
- اگر سیستم توزیع شده است یا Availability بالایی نیاز داریم این سطح کافی نمی باشد.
- مشکلات جدید سیستم های توزیع شده مثل پیچیدگی در تعاملات را پوشش نمی دهد.
- برای سیستم های حیاتی مثل خدمات مالی مناسب نیست.

در پایان, باید توجه داشته باشیم که سطح پایداری یک شروع خوب برای سفر تاب آوری است. چرا که این سطح می پذیرد تیم Ops به تنهایی نمی تواند مسئول Availability باشد و تیم Dev را هم درگیر می کند. اما اگر نیاز به Availability بسیار بالا یا مدیریت پیچیدگی سیستم های توزیع شده داریم, باید به سطح بعدی برویم. در بخش بعدی درباره "تله 100% Availability" صحب می کنیم و بررسی می کنیم که چگونه می توانیم از آن عبور کنیم.

منبع: Uwe Friedrichsen - ufried . com