ضعیفترین حلقه: تأثیر وابستگیهای زنجیرهای بر ریسک سیستم
هنگام ارزیابی سناریوهای ریسک سیستم، بسیار آسان است که وابستگیهای «زنجیرهای» را نادیده گرفت. ما آموزش میبینیم که ریسک را در سطح «گره» ببینیم و بپرسیم «چقدر احتمال دارد این یک چیز خراب شود.» اما ریسک سیستم بسیار پیچیدهتر از آن است.
در اکثر سیستمها برخی اجزا وجود دارند که به اجزای دیگر متکی هستند. رایجترین جایی که به این موضوع نگاه میکنیم در طراحی ذخیرهسازی برای سرورها است، اما در هر طراحی سیستمی رخ میدهد. مثال خوب دیگر این است که چگونه اپلیکیشنهای وب برای عملکرد به هر دو هاست اپلیکیشن و هاست پایگاه داده نیاز دارند.
توضیح وابستگیهای زنجیرهای با یک مثال آسانتر است. به یک طراحی استانداردسازی مجازیسازی با ذخیرهسازی SAN نگاه میکنیم تا بفهمیم کجا مرزهای دامنه خرابی وجود دارند و وابستگیهای زنجیرهای کجا هستند و تکرارپذیری چه نقشی در کاهش ریسک در سطح سیستم دارد.
در یک طراحی استاندارد SAN (شبکه ناحیه ذخیرهسازی) برای مجازیسازی، هاستهای مجازیسازی (که برای سادگی «سرورها» مینامیم)، سوئیچهای SAN (سوئیچهای اختصاصی برای شبکه ذخیرهسازی) و آرایههای دیسک دارید. هر یک از این سه «لایه» به لایههای دیگر برای عملکرد کل سیستم متکی است. اگر سادهترین مجموعه ممکن را با یک سرور، یک سوئیچ و یک آرایه دیسک داشتیم، بهوضوح سه دستگاه داریم که سه نقطه خرابی مجزا را نمایندگی میکنند. هر یک از سه تا که خراب شود کل سیستم از کار میافتد. هیچ قطعهای بهتنهایی مفید نیست. این یک وابستگی زنجیرهای است و زنجیر تنها به اندازه ضعیفترین حلقهاش قوی است.
در مثال ساده ما، هر دستگاه یک دامنه خرابی را نشان میدهد. میتوانیم ریسک را با بهبود قابلیت اطمینان هر دامنه کاهش دهیم. میتوانیم یک سرور دوم اضافه کنیم و یک استراتژی در دسترسی بودن بالا یا تحمل خطا برای لایه مجازیسازی پیادهسازی کنیم تا ریسک خرابی سرور را کاهش دهیم. این قابلیت اطمینان یک دامنه خرابی را بهبود میدهد اما دو تا را دست نخورده و به همان اندازه پرریسک میگذارد. سپس میتوانیم لایه سوئیچزنی را با اضافه کردن یک سوئیچ اضافی و پیکربندی یک استراتژی مسیریابی چندگانه برای مدیریت از دست دادن یک مسیر سوئیچزنی، ریسک را در آن لایه کاهش دهیم. اکنون دو دامنه خرابی مورد توجه قرار گرفتهاند. در نهایت باید دامنه خرابی ذخیرهسازی را مورد توجه قرار دهیم که بهطور مشابه با اضافه کردن تکرارپذیری از طریق یک آرایه دیسک دوم که آینهوار از اولی است و میتواند در صورت خرابی بهشفافیت منتقل شود انجام میشود.
حالا که سیستممان را تقویت کردهایم، هنوز سه دامنه خرابی در یک زنجیر وابستگی داریم. آنچه انجام دادهایم این است که هر «حلقه» در زنجیر، هر دامنه خرابی، را بهتنهایی انعطافپذیرتر کردهایم. اما زنجیر هنوز وجود دارد. این به این معناست که سیستم بهعنوان یک کل، بسیار کمتر از هر دامنه خرابی منفرد درون زنجیر بهتنهایی قابل اعتماد است. چیزی بسیار بهتر از جایی که شروع کردیم ساختهایم، اما هنوز دامنههای خرابی بسیاری داریم. این ریسکها اضافه میشوند.
آنچه در تعیین ریسک کلی دشوار است این است که باید ریسک هر آیتم را ارزیابی کنیم، سپس ریسک جدید پس از کاهش (از طریق اضافه کردن تکرارپذیری) را تعیین کنیم و سپس ریسک تجمعی هر یک از دامنههای خرابی را در یک زنجیر بیابیم تا ریسک کل سیستم را تعیین کنیم. تعیین ریسک در هر دامنه خرابی بسیار دشوار است چون روش کاهش ریسک نقش قابل توجهی دارد. برای مثال، یک خوشه آرایه دیسک ذخیرهسازی که خیلی کند منتقل میشود ممکن است منجر به خرابی کل سیستم شود حتی وقتی خوشه ذخیرهسازی بهدرستی به نظر میرسد کار کرده. حتی تعریف واضح یک خرابی میتواند در نتیجه چالشبرانگیز باشد.
اغلب وسوسه میشود ارزیابی ریسک «از بالا» داشته باشیم که بسیار خطرناک است، اما برای افرادی که بهطور منظم ارزیاب ریسک نیستند بسیار رایج است. تمایل اینجا این است که فقط به دامنه خرابی «بالاترین» نگاه کنیم — معمولاً سرورها در چنین موردی، و هر ریسکی که در زیر آن نقطه قرار دارد را نادیده بگیریم و آنها را «زیر کاپوت» بدانیم نه بخشی از ارزیابی ریسک. نادیده گرفتن اجزای فنیتر، کمتر آشکار و کمتر درکشده مثل شبکهبندی و ذخیرهسازی و تمرکز بر جنبههای قابلیت اطمینان لایه بالایی که نسبتاً آسانتر درک میشود و زیاد بازاریابی میشود آسان است. این «دیدگاه از بالا» به این معناست که ریسکهای زیر سطح بالا پوشانده و عموماً نادیده گرفته میشوند که منجر به ریسک بالا بدون درک خوبی از علت میشود.
درک مفهوم وابستگیهای زنجیرهای توضیح میدهد که چرا سیستمهای پیچیده، حتی با استراتژیهای پیچیده کاهش ریسک، اغلب نتیجهاش این میشود که بسیار شکنندهتر از سیستمهای سادهتر هستند. در مثال فوق میتوانستیم چند کار برای «فشرده کردن» زنجیر انجام دهیم که منجر به سیستم کلی قابل اعتمادتری شود.
آشکارترین جزئی که میتوان فشرده کرد دامنه خرابی شبکهبندی است. اگر سوئیچها را کاملاً حذف کنیم و ذخیرهسازی را مستقیماً به سرورها متصل کنیم (البته نه همیشه ممکن)، بهطور مؤثری یک کل دامنه خرابی را حذف میکنیم و یک حلقه از زنجیر را برمیداریم. حالا بهجای سه زنجیر که هر کدام پتانسیل خرابی دارند، فقط دو تا داریم. سادهتر بهتر است، در صورت برابر بودن سایر عوامل.
میتوانیم بهطور نظری دامنه خرابی ذخیرهسازی را نیز از طریق رفتن از ذخیرهسازی خارجی به ذخیرهسازی محلی در سرورها فشرده کنیم که اساساً ما را از دو دامنه خرابی به یک دامنه خرابی تکی میرساند — البته دامنه باقیمانده پیچیدگی بیشتری نسبت به قبل از فشردهسازی دارد، اما پیچیدگی کلی سیستم بسیار کاهش مییابد. باز هم، این با برابر ماندن همه عوامل دیگر است.
رویکرد دیگری که باید در نظر بگیریم این است که گرههای منفرد را بهتنهایی قابل اعتمادتر کنیم. امروز مد است که به سیستمهای بزرگتر نگاه کنیم و کاهش ریسک را از آن طریق انجام دهیم، با اضافه کردن گرههای تکراری با هزینه کم برای افزودن قابلیت اطمینان به دامنههای خرابی. اما بهطور سنتی این مسیر پیشفرض بهسوی قابلیت اطمینان نبود. در گذشته بسیار رایجتر بود، همانطور که در شیوع سابق سیستمهای مینفریم و مشابه نشان داده میشود، که درجات بالایی از قابلیت اطمینان را در یک گره منفرد بسازیم. سیستمهای مینفریم و ذخیرهسازی سطح بالا، برای مثال، هنوز این کار را امروز انجام میدهند. این در واقع میتواند یک رویکرد بسیار مؤثر باشد اما از بسیاری از سناریوها شکست میخورد و معمولاً بسیار پرهزینه است، که اغلب با نیاز به نگهداری سیستمها بهصورت جزئی یا حتی کامل توسط فروشنده تشدید میشود. این تمایل دارد فقط در شرایط خاص تخصصی کار کند و در حوزه وسیعتر عملی نیست.
بنابراین در هر سیستمی از این ماهیت سه استراتژی اصلی کاهش ریسک داریم که باید در نظر بگیریم: بهبود قابلیت اطمینان یک گره منفرد، بهبود قابلیت اطمینان یک دامنه منفرد یا کاهش تعداد دامنههای خرابی (حلقهها) در زنجیر وابستگی. قرار دادن اینها در کنار هم، همانطور که عاقلانه است، میتواند به ما کمک کند تا سطح کاهش ریسک مناسب برای سناریوی کسبوکارمان را به دست آوریم.
جایی که دشواری واقعی وجود دارد و باقی خواهد ماند، در مقایسه استراتژیهای مختلف کاهش ریسک است. ریسک یک گره منفرد معمولاً میتواند با سطحی از اطمینان تخمین زده شود. یک استراتژی تکرارپذیری در یک دامنه منفرد توانایی بسیار کمتری برای تخمین دارد — برخی استراتژیهای تکرارپذیری بسیار مؤثر هستند و دامنههای خرابی بسیار قابل اعتمادی ایجاد میکنند در حالی که برخی دیگر در واقع میتوانند بازتاب منفی داشته باشند و قابلیت اطمینان یک دامنه را کاهش دهند! پیچیدگیای که اغلب با استراتژیهای تکرارپذیری همراه است هرگز بدون اما و اگر نیست و در حالی که معمولاً نتیجه میدهد، بهندرت درجهای از مزیت قابلیت اطمینان که ابتدا انتظار میرود را حمل میکند. تخمین ریسک یک زنجیر وابستگی بنابراین بسیار دشوارتر است زیرا نیاز به درک واضح ریسکهای مرتبط با هر یک از دامنههای خرابی بهصورت انفرادی و همچنین درک فرصت خرابی موجود در مرزهای دامنه (مثل تأخیر خرابی منتقلشدن ذخیرهسازی که قبلاً ذکر شد) دارد.
بگذارید مسائل پیرامون تعیین ریسک در دو رویکرد بسیار رایج برای همان سناریو را بر اساس آنچه در بالا بحث کردیم بررسی کنیم.
دو مثال افراطی از همان وضعیتی که در حال بحث درباره آن بودیم، یک سرور با ذخیرهسازی داخلی استفادهشده برای میزبانی ماشینهای مجازی در مقابل یک «زنجیر» ششدستگاهی با دو سرور و استفاده از یک راهحل در دسترسی بودن بالا در لایه سرور، دو سوئیچ با تکرارپذیری در لایه سوئیچزنی و دو آرایه دیسک فراهمکننده در دسترسی بودن بالا در لایه ذخیرهسازی است. اگر هر عامل بزرگی را اینجا تغییر دهیم، معمولاً میتوانیم یک تخمین نسبتاً واضح از ریسک نسبی ارائه دهیم — اگر هر یک از دامنههای خرابی فاقد تکرارپذیری قابل اعتماد باشد، برای مثال — میتوانیم بهوضوح تعیین کنیم که سرور منفرد سیستم کلی قابل اعتمادتری است، جز در مواردی که مقدار فوقالعادهای از قابلیت اطمینان گره منفرد به یک گره منفرد اختصاص یافته است، که معمولاً از نظر مالی یک استراتژی غیرعملی است. اما با هر دامنه خرابی که تکرارپذیری را حفظ میکند، مجبوریم ریسکهای نسبی قابلیت اطمینان دروندامنهای (زنجیر تکراری) در مقابل قابلیت اطمینان بیندامنهای (زنجیر فشردهشده، سرور منفرد) را مقایسه کنیم.
با دو رویکرد کاملاً متفاوت، هیچ راه معقولی برای ارزیابی ریسکهای مقایسهای دو روش کاهش ریسک وجود ندارد. بهطور کلی پذیرفته شده است که رویکرد شش (یا بیشتر) گرهای با کاهش ریسک گسترده دروندامنهای قابل اعتمادتر از دو رویکرد است و این تقریباً مطمئناً بهطور کلی درست است. اما نه همیشه درست و بهندرت این رویکرد از استراتژی گره منفرد با حاشیه واقعاً قابلتوجهی پیشی میگیرد در حالی که معمولاً چهار تا ده برابر استراتژی سرور منفرد هزینه دارد. این بهطور بالقوه هزینه بسیار بالایی است برای آنچه احتمالاً کمبود کوچکی در قابلیت اطمینان است و پتانسیل کوچکی برای از دست دادن قابلیت اطمینان. هر قطعه اضافی از تکرارپذیری، پیچیدگیای را اضافه میکند که یک انسان باید پیادهسازی، نظارت و نگهداری کند و با پیچیدگی و تعامل انسانی ریسک بیشتر و بیشتری میآید. اجتناب از خطای انسانی اغلب میتواند مهمتر از اجتناب از خرابی مکانیکی باشد.
همچنین باید هزینه بازیابی را در نظر بگیریم. اگر خرابی رخ دهد، بهطور کلی بازیابی از خرابی یک سیستم ساده سادهای است. یک سیستم بسیار پیچیده که خراب شده، ممکن است برای بازگرداندن به وضعیت کاری نیاز به تلاش زیادی داشته باشد. سیستمهای پیچیده همچنین به درجه بسیار وسیعتر و عمیقتری از تجربه و اعتماد برای نگهداری نیاز دارند.
هیچ پاسخ آسانی برای تعیین قابلیت اطمینان سیستمها وجود ندارد. سیستمهای مدرن تحویل اطلاعات بهسادگی خیلی بزرگ و خیلی پیچیده با عوامل غیرقابل تعیین خیلی زیادی هستند که در همه موارد قابل ارزیابی باشند. با درک خوب از وابستگیهای زنجیرهای، با این حال، و درک استراتژیهای کاهش ریسک، میتوانیم گامهای عملی برداریم تا سطوح ریسک تقریباً نسبی را تعیین کنیم، ببینیم سناریوهای مشابه ریسک از نظر هزینه کجا مقایسه میشوند، نقاط شکنندگی را شناسایی کنیم، دامنههای خرابی و زنجیرهای وابستگی را تشخیص دهیم، و قدردانی کنیم که چگونه تغییرات در طراحی سیستم ما را بهوضوح به سمت یا دور از قابلیت اطمینان هدایت میکند.
آگهی
