اگر گودزیلا به دیتاسنتر ما حمله کند چه کنیم؟ نگاهی به نظریه پسماند ها

مرور سخنرانی :  Residues: Time, Change & Uncertainty in Software Architecture سخنران  Barry O'Reilly :

لینک یوتیوب:  https://www.youtube.com/watch?v=D8qQUHrksrE

معماری شما در برابر حمله هیولای آتش افشان از دریای شمال چقدر مقاوم است؟ وقتی بری اوریلی این سوال را در سخنرانی اش مطرح کرد، به نظر میرسید در حال شوخی با حضار است. اما چند دقیقه بعد، متوجه میشویم با یکی از عمیق ترین مفاهیم معماری نرم افزار روبرو هستم: نظریه پسماند (Residuality Theory).

ما در دانشگاه یاد گرفته ایم که معماری را بر اساس نیازمندی های مشخص (Requirements) بسازیم. اما اوریلی با وام گرفتن از مفاهیم علوم پیچیدگی، نشان می دهد که دنیای واقعی کسب و کار به هیچ وجه قابل پیش بینی نیست. او می گوید به جای تمرکز روی مسیر های ایده آل، باید سیستم را با سناریو های کاملا تصادفی و غیر منطقی تست کنیم.

مثال او درباره سیستم شارژ خودرو های برقی بی نظیر بود. تصور کنید سیستم را برای شارژ عادی ساخته اید. ناگهان یک سناریوی عجیب مطرح می شود: اگر یک راننده ماشین بنزینی از روی لجبازی جلوی شارژر پارک کند چه؟ معمار سیستم برای حل این تنش، تصمیم می گیرد دوربین ثبت پلاک اضافه کند. این دوربین، به صورت تصادفی مشکل دیگری را هم حل می کند: جلوگیری از دزدی کابل های شارژر! این یعنی وقتی ما معماری را با تنش های پیش بینی نشده درگیر می کنیم، چیزی که از سیستم باقی می ماند (همان پسماند)، به شدت تاب آورتر از طرح اولیه است.

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

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