چطور Databricks دیباگ حادثه رو به یه ایجنت سپرد
هوش مصنوعیخلاصهٔ کاملتر
تیم Databricks تعریف میکنه که قبل از AI SRE، تجربهٔ ساعت ۲ بامداد این شکلی بود: مهندس آنکال بیدار میشد و باید داشبوردهای متریک، لاگها، دیپلویهای اخیر، تغییر فیچرفلگها و سلامت شبکه و کلاد رو یکییکی چک میکرد. هرکدوم از این ابزارها جدا خوب کار میکردن، ولی وصل کردن سیگنالهاشون به هم فقط تو ذهن مهندس اتفاق میافتاد. نتیجهش این بود که آدم باتجربه چند دقیقهای جواب میگرفت و آدم تازهکار چند ساعت.
به گفتهٔ نویسندهها، اونا اول ایجنت نساختن؛ چند هفته با مهندسهای آنکال دهها تیم مصاحبه کردن و پستمورتمها رو خوندن. سه الگو درآمد: ۶۰ تا ۸۰ درصد وقت بررسی صرف جمع کردن context میشد نه پیدا کردن علت؛ دانش هر تیم دست یکی دو نفر متمرکز بود و رانبوکها معمولاً قدیمی بودن؛ و خیلی از حادثهها ریشهشون تو لایهٔ زیرساخت بود ولی مهندسی که تو لایهٔ اپلیکیشن دیباگ میکرد راه سادهای برای دیدن اون سیگنالها نداشت.
AI SRE تا آلارم میخوره و قبل از اینکه مهندس لپتاپش رو باز کنه، سه مسیر بررسی رو همزمان راه میندازه: چک سلامت پلتفرم (کلاد، شبکهٔ منطقه، دیتابیسها و سرویسهای بالادست)، تحلیل خود سرویس روی لاگ و متریک و تریس و دیپلویهای اخیر، و اجرای رانبوک تیم. رانبوکها با skillها به agentic runbook تبدیل میشن، یعنی مراحل ثابت تیم با کدبیس و دادهٔ observability و تاریخچهٔ حادثهها ترکیب میشه. خروجی بهجای «CPU بالاست» چیزی مثل «CPU سه برابر شد، همزمان با یه دیپلوی که batch size رو عوض کرده» هست.
معماری عمداً لایهلایهست: primitiveها همون دادهٔ خامان (متریک، آلارم، لاگ، اطلاعات ریلیز و کد)، روشون یه لایهٔ API با احراز هویت و ریتلیمیت و نرمالسازی نشسته، بعد یه core engine که اجرای موازی و همبسته کردن نتیجهها و سنتز با LLM رو انجام میده، و آخر لایهٔ اپلیکیشن که بات تریاژ و ابزارهای شخص ثالث اونجا وصل میشن. فایدهش اینه که عوض شدن یه سیستم زیرین، ابزارهای بالادستی رو نمیشکنه.
برای قابل اعتماد بودن سه اصل رو رعایت کردن. اول چکهای قطعی و مراحل رانبوک اجرا میشه و LLM فقط نتیجه رو سنتز و توضیح میده. بعد هر نتیجه به شواهد خامش لینک میشه، یعنی همون متریک، همون خط لاگ، همون دیف دیپلوی، چون مهندس آنکال روی توصیهای که نمیتونه بررسیش کنه دست به کار نمیشه. و اگه مطمئن نباشه صراحتاً میگه نمیدونه و فقط شواهد جمعشده رو مرتب نشون میده. درس آخرشون هم اینه که ایجنتها ناگهانی و موازی به API فشار میارن، پس گاردریل براشون از آدمها هم مهمتره.
نکات کلیدی:
- AI SRE صدها میکروسرویس روی بیش از ۱۵۰۰ کلاستر Kubernetes در بیش از ۷۰ منطقه و سه کلاد رو پوشش میده
- بیشتر از ۱۵۰ تیم و ۲۵۰ کاربر فعال هفتگی، روزی بیش از ۲۰۰۰ بررسی
- ۶۰ تا ۸۰ درصد وقت بررسی حادثه صرف جمع کردن context میشد، نه تشخیص علت
- رانبوکهای تیمی بهشکل agentic runbook قابل ترکیبان تا پلتفرم مرکزی گلوگاه نشه
- هر توصیه به شواهد خام لینک میشه و وقتی علت قطعی نیست، سیستم صراحتاً اینو میگه
- قدم بعدی: mitigation راهنماییشده و یادگیری از الگوهای حادثههای قبلی
