برنامه ریزی برای شکست

یکی از دغدغه های معماران نرم افزار، مدیریت اشتباهات، خطاها و درنهایت شکستهای سیستم است. این مساله به قدری اهمیت دارد که یک بخش کامل در کتاب Software architecture in practice نوشته ی Paul Clements را به خود اختصاص داده است.

مدیریت خطاها همچنین بخشی زمانبر، پرهزینه اما به همان اندازه پرفایده از فرآیند توسعه و نگهداری نرم افزار است که باید در لایه ی معماری به آن پرداخته شود.

اما قبل از اینکه وارد مبحث اصلی شوم، مایلم با مفاهیمی که شاید برای شما و من که بخصوص در ایران فعالیت میکنیم تازگی داشته باشد شروع کنم. این مفاهیم به تفاوت های اساسی بین واژه های اشتباه و خطا می پردازد که میتواند دید ما را به معماری سیستم در لایه تحلیل بهبود بخشد.

یک تعریف ساده اما بسیار کلیدی:

مجموعه ای از اشتباهات باعث ایجاد خطا میشوند. تکرار و تداوم خطاها باعث شکست سیستم میشود.

بنابراین از نظر من یک اشتباه به خودی خود و به تنهایی شاید مهم نباشد. احتمالا اصلا دیده هم نمیشود و از زیر چشم تحلیلگران، توسعه دهندگان، تک لیدها و حتی QA عبور کرده باشد. اما توالی اشتباهات در یک سیستم قطعا منجر به بروز خطا خواهد شد. سیستم های پیچیده معمولا از جانب اشتباهات تکراری، ساده و کوچک شکست میخورند.

در دنیای امروز که اعتقاد دارم مرز بین تکنولوژی های فرانت اند و بک اند دیگر مثل دهه های قبل خیلی قابل تفکیک نیست، اشتباهات فرانت هم در بروز خطا و شکست در بک اند و در نهایت کل سیستم موثر است. برای شما مثالی میزنم:

تصور کنید در یک سیستم توسعه داده شده با React شما کلیدی دارید که با کلیک بر روی آن سرویسی فراخوانی میشود. تا آنجا که به کاربرنهایی و آنچه بر روی مانیتور خود میبیند مربوط است، اگر با یکبار کلیک بر روی این کلید، تا زمان دریافت Response (درست یا غلط) کلید Disable نشود، کاربر میتواند به طور مداوم روی آن کلیک کند و میتوانید حدس بزنید که اتفاقی خواهد افتاد: بالا رفتن بی دلیل بار ریکوئستها به سمت سرور و در نهایت بروز خطا در بهترین حالت و یا کرش کردن سیستم در بدترین حالت و از دسترس خارج شدن سیستم.

هرچند که برای این موضوع روشهای متداولی در بک اند مانند Rate limiting و روشهای متنوع دیگری وجود دارد که از بروز این اتفاق جلوگیری کند، اما در اینجا یک اشتباه در فرانت صورت گرفته. چون طبق آنچه ما از فرآیندهای کاری یک تیم نرم افزاری میدانیم، فارغ از اینکه آیا تیم بک اند کار خود را بلد است و میداند کجا باید از Rate limit استفاده کند، توسعه دهنده فرانت  هم باید کار خود را در نهایت ظرافت و وسواس پیش ببرد. پیش فرض هردو تیم باید این باشد که تیم مقابل ممکن است اشتباه کند پس ما باید تسک جاری را با رعایت حداکثر احتمالات ممکن تمام کنیم.

در سناریوی بالا غیرفعال نکردن کلید فراخوانی سرویس در لایه فرانت زمانی که ریکوئست ارسال میشود، لزوما یک خطا نیست، اما حتما یک اشتباه است.

روشن کردن یک نخ سیگار در انبار کاه و روشن کردن همان نخ سیگار در یک بیابان پیامدهای خیلی متفاوتی خواهد داشت. هنر معمار نرم افزار در برنامه ریزی برای شکستهای سیستم، هدایت تیم ها و تحلیلگران به سمتی است که کمترین خسارت ممکن حتی در صورت بروز برخی اشتباهات رخ دهد.

چنین اشتباهاتی معمولا از دید تحلیلگران و حتی تیم QA پنهان هستند اما من معتقدم مسئولیت مستقیم آن برعهده ی Code Reviewer و تک لید تیم فنی ست.

از مهمترین موضوعات در ساخت سیستمهایی با قابلیت دسترس پذیری بالا، درک ماهیت شکست هایی است که ممکن است در حین کار رخ دهد. وقتی به ماهیت شکست ها پی بردیم، میتوانیم استراتژیهای کاهش خسارت را در نرم افزار فراهم کنیم.

علت شکست را خطا میگوییم. به طور مشخص لغت fault به خطا اشاره میکند. حالا این خطا میتواند دلایل داخلی یا خارجی داشته باشد. حالت های میانی بین وقوع خطا و وقوع یک شکست را اشتباهات مینامیم که به طور مشخص با لغت errors ساخته میشوند.

ما همیشه به اشتباه خطاها را errors توصیف میکنیم، در حالی که خطا یک fault در سیستم است که میتواند حاصل چندین error یا اشتباه باشد. 

محاسبه دسترس پذیری

تمام این مباحث برای بالابردن امکان در دسترس بودن سیستم است. ممکن است شما برای فروش یک سرویس یا سیستم مجبور به امضای یک SLA (توافق سطح سرویس) باشید. اگر در هر صورتی نتوانید یک SLA خود ارائه کنید، احتمالا بیزینس شما که بر مبنای آن سیستم بناشده است به ورشکستگی میرسد.

درک تمایز بین اشتباهات و خطاها در زمان معماری سیستم میتواند ما را به طراحی نرم افزار برساند که در برابر شکستهای سیستمی مقاوم باشد.اما برای اینکه بسنجیم یک سیستم نرم افزاری چقدر برابر شکست ها مقاوم است فرمولی وجود دارد:

MTBF = میانگین زمان بین شکست ها
MTTR = میانگین زمان ترمیم

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

پایان- 1404/08/28

محمد مهدوی کیا

بازگشت