دسترسپذیری بالا و طراحی برای خرابی
هیچ سامانهای صد درصد بالا نیست. سرور میخوابد، دیسک میسوزد، اینترنت قطع میشود، و کسی در ساعت دو بامداد دستور اشتباهی میزند.
سؤال درست این نیست که چطور جلوی خرابی را بگیریم. این است که وقتی جزئی خراب شد، چقدر از سامانه با آن پایین میآید.
اول: عدد را از کسبوکار بگیرید
قبل از هر تصمیم فنی، دو عدد لازم دارید و هیچکدام فنی نیستند:
چقدر ازکارافتادگی قابل تحمل است؟ یک ساعت در ماه؟ پنج دقیقه؟
چقدر داده میشود از دست داد؟ اگر آخرین پشتیبان مال شش ساعت پیش باشد، شش ساعت کار از بین رفته. قابل قبول است؟
جواب این دو، هزینه را تعیین میکند و اختلاف بین سطوح مختلف، چند برابری است. سامانهٔ داخلی گزارشگیری با درگاه پرداخت یک نیاز ندارند و رفتار کردن با هر دو بهشکل یکسان، یا پول هدر میدهد یا ریسک.
راه ساده برای گرفتن این عدد: یک ساعت ازکارافتادگی چقدر برای شما خرج دارد؟ اگر آن عدد از هزینهٔ افزونگی بیشتر است، تصمیم گرفته شده.
نقطههای شکست را پیدا کنید
روی معماریتان انگشت بگذارید و بپرسید: اگر این یکی بخوابد، چه چیزی از کار میافتد؟
نامزدهای همیشگی: پایگاه دادهٔ اصلی، سرور برنامه اگر یکی است، سرویس پرداخت، سرویس پیامک، و دروازهٔ API اگر همه از آن رد میشوند.
نکتهای که معمولاً دیر کشف میشود: وابستگیهای بیرونی هم نقطهٔ شکستاند. اگر صفحهٔ اصلی سایت شما منتظر جواب یک سرویس بیرونی میماند، کندی آن سرویس یعنی کندی شما. و آن سرویس تحت کنترل شما نیست.
سه چیز که بیشترین اثر را دارند
پشتیبان آزموده. پشتیبانگیری که بازیابیاش امتحان نشده، فقط یک فرض است. تا روز حادثه نمیدانید فایل سالم است یا فرایند بازیابی چقدر طول میکشد. این را دورهای تمرین کنید — واقعاً بازیابی کنید، نه اینکه فقط ببینید فایل موجود است.
اگر یک کار از این مقاله انجام میدهید، همین باشد. ارزانترین است و بیشترین ریسک را برمیدارد.
بیش از یک نسخه از برنامه. شرطش این است که برنامه بدون وضعیت باشد — همان کاری که برای مقیاسپذیری هم لازم است.
افزونگی پایگاه داده. نسخهٔ آمادهبهکار که اگر اصلی خوابید جایش را بگیرد. پرهزینهترین قلم این فهرست و معمولاً آخرین.
طراحی برای خرابی
فراتر از افزونگی، خود کد باید فرض کند چیزها خراب میشوند.
مهلت روی هر تماس بیرونی. تماسی بدون مهلت، در بدترین حالت تا ابد منتظر میماند و نخهای برنامه را میبلعد تا کل سامانه بخوابد — بهخاطر یک سرویس جانبی.
تلاش مجدد، ولی با فاصلهٔ فزاینده. تلاش مجدد فوری و بیوقفه، سرویسِ در حال احیا را دوباره میخواباند.
قطعکننده. اگر سرویسی مدام خطا میدهد، مدتی اصلاً صدایش نزنید. هم به آن مهلت احیا میدهید و هم منابع خودتان را حفظ میکنید.
تنزل تدریجی. بخشهای غیرحیاتی در شرایط خرابی خاموش شوند. اگر سرویس پیشنهاد محصول نمیآید، صفحه باید بدون آن بالا بیاید نه اینکه خطا بدهد.
این آخری بیشترین تفاوت را در تجربهٔ واقعی میسازد و کمترین توجه را میگیرد.
بدترین حالت: خطای انسانی
آمار صنعت میگوید بخش بزرگی از ازکارافتادگیها از سختافزار نیست، از تغییری است که کسی اعمال کرده.
چیزهایی که این را مهار میکنند:
انتشار تدریجی بهجای یکباره، و راه برگشت سریع.
جدا بودن محیط تست و تولید، طوری که اشتباهگرفتنشان سخت باشد.
و آنچه از همه سادهتر است: کسی که به تنهایی نتواند دستور مخرب را روی تولید اجرا کند.
بعد از خرابی
هر رخداد یک بار اتفاق میافتد و اگر ازش یاد نگیرید، دوباره اتفاق میافتد.
بعد از هر ازکارافتادگی: چه شد، چرا، چقدر طول کشید تا فهمیدیم (این عدد اغلب از خود خرابی بدتر است)، و چه چیزی جلوی تکرارش را میگیرد.
و این جلسه را بدون دنبال مقصر گشتن برگزار کنید. تیمی که بابت گزارش خرابی سرزنش میشود، دفعهٔ بعد گزارش نمیدهد.
بندهایی که در قرارداد پشتیبانی باید باشند
اگر نگهداری با پیمانکار است، این عددها باید مکتوب باشند: پنجرهٔ پوشش، زمان پاسخ به تفکیک شدت، دورهٔ پشتیبانگیری، و اینکه بازیابی هر چند وقت آزموده میشود.
آن بند آخر را تقریباً هیچکس نمیپرسد و مهمترین است. چکلیست کاملش در SLA و قرارداد پشتیبانی هست.
و یک واقعبینی
افزونگی کامل برای هر جزء، برای بیشتر سازمانها توجیه اقتصادی ندارد. هدف این نیست که به بالاترین سطح برسید؛ این است که بدانید کجا ایستادهاید و آن را آگاهانه انتخاب کرده باشید.
سامانهای که ماهی یک ساعت پایین میآید و همه میدانند چرا و چقدر طول میکشد، وضعیت سالمتری دارد از سامانهای که ادعای پایداری کامل دارد و هیچکس پشتیبانش را امتحان نکرده.