ویرگول
ورودثبت نام
Mohsen Farokhi - محسن فرخی
Mohsen Farokhi - محسن فرخی
خواندن ۴ دقیقه·۱۰ ماه پیش

مبانی معماری نرم افزار - بخش سوم

در بخش دوم، availability و ابعاد مختلف آن را بررسی کردیم و در این بخش به جزئیات بیشتری از مساله Fault می پردازیم.

همانطور که اشاره شد، fault در اثر رخ دادن یک اختلال، بوجود می آید. برای مثال وجود یک باگ در design یا قطع شدن برق یک سرور عملیاتی را به عنوان fault در نظر می گیریم. faultهایی هستند که ممکن است در اثر نفوذ یک شخص به سیستم اتفاق بیافتند و یا در مواردی که developer موجب بوجود آمدن fault می شود. بنابراین fault را الزاما به معنای Accident در نظر نمی گیریم.

عمده Quality Attributeهایی که در حوزه Operational هستند، مشخصه های کیفی هستند که در run و عملیات، خود را نشان می دهند. برای مثال availability, reliability, resiliency, performance که مساله fault می تواند مستقیم یا غیرمستقیم آن ها را تحت تاثیر قرار دهد.

عوامل کلیدی تحت عنوان Key Concepts در design وجود دارند که بخش مشخصی از quality attributeها را به شکل جدی درگیر مساله می کنند. در Structural Quality Attributeها می توانیم به پارامتر Coupling / Cohesion یا اتصالات اجزا به همدیگر فکر کنیم که مساله Change را مطرح می کند. برای مثال در maintainability و composability این پارامتر تاثیر گذار است.


مساله fault را می توانیم در ابعاد مختلف طبقه بندی کنیم.

  • Nature

در این بخش، fault را در دو نوع Accident و Intentional در نظر می گیریم. در intentional یا عمدی، گاهی شخصی نفوذ می کند و fault ایجاد می کند و یا developer از روی ناآگاهی ایجاد fault می کند.

  • Cause

در این بخش، دو نوع Physical و Human داریم. در physical faultها برای مثال network، کابل شبکه، disk، قطعی برق و غیره را می توانیم در نظر بگیریم.

  • Boundary

این بخش، مرز failure را در دو نوع Internal و External مشخص می کند. تعریفی که از internal و external می شود، معمولا در حوزه کنترل می باشد. کنترل الزاما به معنای جلوگیری از آن نیست. برای مثال حمله ای که از بیرون اتفاق می افتد، external است و down شدن database که در boundary اتفاق می افتد را به عنوان internal در نظر می گیرم.

  • Phase of Creation

به معنای اینکه fault کجا اتفاق افتاده است و در دو فاز Design و Operational می باشد. design faultها permanent هستند. در مرحله طراحی اتفاق می افتند و منشا internal و human دارند.

  • Persistence

به ماندگاری یک fault اشاره می کند و در دو حوزه Permanent و Temporary می باشد. faultهایی که در لحظه اختلال ایجاد می کنند جزو temporary می باشند و faultهایی که ماندگاری بیشتری دارند و نیاز به مداخله دارند، جزو permanent هستند. حجم زیادی از faultها قابلیت permanent شدن را دارند. physical faultها جزو دسته permanent هستند و نیاز به مداخله دارند.


در ادامه به بررسی برخی از quality attributeهایی می پردازیم که با failure بیشتر در ارتباط هستند.

به طور کلی دو state تحت عنوان Valid و Invalid برای سیستم در نظر می گیریم. transition از valid state به invalid state را failure می گویند و برعکس آن را restoration می گویند.

مشخصه Availability، میزان در دسترس بودن سیستم را نشان می دهد و مشخصه Reliability، تداوم سرویس می باشد. availability و reliability به شدت به هم متصل هستند و قابل تفکیک کردن نیستند. استمرار سرویس دادن برای چیزی که هنوز برای استفاده آماده نیست، معنا ندارد و اگر آماده سرویس دادن باشیم و سرویس را بصورت مستمر نتوانیم ارائه دهیم باز هم بی معنی است.

مشخصه Safety موضوع Trust در سیستم است و عدم وجود آن باعث از دست رفتن اعتماد به آن نرم افزار می شود.

مشخصه Resiliency به طور مشخصی در چند سال اخیر پر رنگ تر شده است و به بیرون آمدن سیستم از failure یا کم کردن تاثیرات آن می پردازد. قبل از فراگیر شدن موضوعات cloud computing، عمدتا با معماری های monolithic درگیر بودیم. به این صورت که یک جزء بزرگ داشتیم و در نتیجه نوع تعریف مساله availability و reliability هم فرق می کرد. خیلی از اِلمان های موضوع failure نیز در گذشته فرق می کرد. ساختار monolithic معمولا در فضای عملیات تحت کنترل بالایی بود و نوع نگاه به failure با توجه به کنترلی که وجود داشت متفاوت بود. با فراگیر شدن cloud computing، از ساختارهای monolithic فاصله گرفتیم و مباحث سرویس گرایی نقش پر رنگ تری پیدا کردند.

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

رویکرد اصلی resiliency این است که هر بخشی از سیستم از طریق سازگار کردن رفتار خود در زمانی که fault اتفاق می افتد در راستای کمک به availability سیستم موظف خواهد بود.


مشخصه resiliency در حوزه responseها در پنج طبقه دسته بندی می شود که در بخش بعدی به جزئیات بیشتری در مورد آنها می پردازیم.

  • Recognize

به شناسایی failureها می پردازد.

  • Isolate

به کم کردن تاثیر failureها می پردازد. برای مثال Async Communication یکی از tacticهایی است که در راستای ایزوله کردن انجام می شود.

  • Protect

به جلوگیری از تاثیرات failureها می پردازد. برای مثال Circuit Breaker به عنوان یک tactic در این راستا می باشد.

  • Mitigate

به موضوعات مقابله کردن با failureها می پردازد.

  • Resolve

مجموعه کارهایی که برای اطمینان از درست انجام شدن مقابله با failureها انجام می شوند.

معماری نرم افزارsoftware architectureFaultfailureمحسن فرخی
شاید از این پست‌ها خوشتان بیاید