مهندسی قابلیت اطمینان برای سیستمهای ایزوله از اینترنت
خلاصهٔ کاملتر
نویسنده تعریف میکنه که چند تیم از بخش دفاعی رو کمک کرده تا چیز درست رو اندازه بگیرن (SLI)، انتظار معقول تعیین کنن (SLO) و قابلیت اطمینان رو از طریق هشدار به پاسخگویی گره بزنن. نکتهٔ جالب اینجاست که همهٔ این سیستمها air-gapped بودن؛ یعنی تیمی که نرمافزار رو میسازه هیچ دسترسیای به متریک، لاگ یا runtime نداره. پس چطور میشه بدون دادهٔ بلادرنگ فهمید چیزی خرابه و عیبیابی کرد؟
الزامات غیرکارکردی (NFR) سفتوسخت بودن: استقرار on-prem داخل تأسیسات نظامی، بدون هیچ اینترنتی برای کم کردن سطح حمله، تحویل نرمافزار بهصورت یک فایل آرشیو که فیزیکی دست اپراتور داده میشد، و حل مشکلات فقط از طریق تماس تلفنی امن. گاهی هم مجبور میشدن فیزیکی یک مهندس به محل بفرستن. نویسنده میگه بعد از یک قطعی یکهفتهای که اعتبار شرکت رو به خطر انداخته بود وارد ماجرا شده.
ایدهٔ اصلی این بود که محدودیت رصدناپذیری رو با تبدیل اپراتورِ محل (معمولاً پرسنل IT همون تأسیسات) به یک SRE دور بزنن. براش یک صفحهٔ سلفسرویس ساختن که چند لایه داره: داشبوردهای ساده برای وضعیت بلادرنگ CPU و حافظه و دیسک و شبکه؛ هشدار فعالانه تا اپراتور قبل از کاربر از مشکل باخبر بشه (کاهش زمان تشخیص)؛ runbookهای از پیش تعریفشده برای خطاهای رایج؛ خودترمیمی برای شایعترین خطاها (مثل ریاستارت یا مقیاس افقی)؛ و حتی تشخیص ناهنجاری با یک مدل زبانی کوچک (SLM) که روی یک نود کناری لاگها رو تحلیل کنه و مثل یک SRE داخلی عمل کنه.
یک توصیهٔ کلیدی نویسنده اینه که صفحهٔ وضعیت باید جدا از اپلیکیشن اصلی باشه، با چرخهٔ انتشار و وابستگیهای مستقل و حتی روی یک دامنهٔ جداگانه (مثل اینکه صفحهٔ وضعیت github.com روی githubstatus.com هست). دلیلش هم اینه که صفحهٔ وضعیت دقیقاً وقتی بیشترین کاربرد رو داره که سرویس اصلی داره خراب میشه. از ایدههای جانبی هم کدهای خطای مرموز ولی مشخص بود — یک رشتهٔ کوتاه مثل 0xAF6600BB که بشه پای تلفن خوند و دقیقاً فهمید کدوم ماژول خراب شده — و لاگهای شبهناشناس (pseudonymized) که اطلاعات حساس رو میپوشونن ولی در صورت نیاز قابل ردیابیان.
به گفتهٔ نویسنده این مدل از یک جهت نمونهای از «مالکیت شکستهست»، چون کسی که سیستم رو میسازه همونی نیست که اجراش میکنه. ولی نتیجهاش کاهش هشدارهای کاذب، کم شدن تماسهای پشتیبانی، پایین اومدن زمان رفع خطا (TTR)، افزایش حس مالکیت اپراتور و بالا رفتن اعتماد به فروشنده بود — چون فروشنده نشون میده میدونه چی تحویل داده و در صورت خرابی چه باید کرد.
نکات کلیدی:
- در سیستم air-gapped تیم سازنده به متریک، لاگ و runtime دسترسی نداره
- راهحل: تبدیل اپراتور محل به SRE با ابزارهای رصد و ترمیم سفارشی
- لایهها: داشبورد وضعیت، هشدار، runbook، خودترمیمی و تشخیص ناهنجاری با SLM
- صفحهٔ وضعیت باید کاملاً جدا از اپ اصلی و با چرخهٔ انتشار مستقل باشه
- کدهای خطای مشخص و لاگ شبهناشناس، عیبیابی پای تلفن رو ممکن میکنن
