تصور کنید ساعت ۲ صبح است و یک نقص فنی بحرانی، کل سرویس شما را زمین زده است؛ در حالت عادی، مهندسان باید ساعتها لاگها را بررسی کنند تا بفهمند چه اتفاقی افتاده است. AegisSRE این وضعیت را تغییر میدهد و طبق یک راهنمای فنی که در ۲۵ ژوئیه ۲۰۲۶ در dev.to منتشر شد، تشخیص و رفع این حوادث را بهصورت خودمختار انجام میدهد.
ابزارهای سنتی مشاهدهپذیری (Observability) فقط به شما میگویند که چیزی خراب شده است. این ابزارها شبیه به یک زنگ هشدار در بیمارستان هستند که فقط خبر میدهد بیمار وضعیت بدی دارد، اما تشخیص بیماری و تجویز دارو همچنان بر عهده پزشک (انسان) است. AegisSRE در واقع یک مهندس قابلیت اطمینان سایت (SRE) خودکار است که شکاف بین «دیدن مشکل» و «حل آن» را پر میکند.
همانطور که در تحلیلهای پیشین ما دربارهی سامانههای عاملمحور اشاره کردیم، کلید موفقیت در این مسیر، تخصصی کردن نقشهاست. این سامانه بر پایه یک معماری ارکستراسیون عامل-به-عامل (Agent-to-Agent Orchestration) فعالیت میکند که در آن هر عامل (Agent) — شبیه به یک کارمند متخصص در یک شرکت که فقط مسئول یک بخش خاص از پروژه است — وظیفهای دارد. این رویکرد دقیقاً با سازوکارهای ارکستراتورها برای توزیع هوشمند وظایف همسو است تا از شکست مدلهای یکپارچه جلوگیری شود:
- هماهنگکننده (Coordinator): مدیریت کلی جریان کار را بر عهده دارد.
- طبقهبندیکننده (Classifier): حادثه را دستهبندی کرده و سرویس آسیبدیده را شناسایی میکند.
- عامل تشخیص (Diagnosis Agent): با تحلیل دادههای تلهمتری، لاگها و ردپاها، علت ریشهای را مییابد.
- عامل برنامهریز (Planning Agent): دفترچه دستورالعمل (Runbook) مناسب برای رفع مشکل را انتخاب میکند.
- عامل تأیید (Approval Agent): عملیاتهای پرریسک را برای تأیید نهایی نزد انسان میبرد.
- عامل اجرا (Execution Agent): اصلاحیه را در محیطی کنترلشده مستقر میکند.
- عامل تأیید نهایی (Verification Agent): پیش از بستن تیکت، بازیابی سیستم را تأیید میکند.
برای اینکه این فرآیندهای خودکار سیاهچاله نباشند، SigNoz بهعنوان ستون فقرات مشاهدهپذیری عمل میکند. بر اساس مستندات این سامانه، با استفاده از OpenTelemetry در هر مرحله، تمامی ردپاهای توزیعشده و لاگهای هر عامل ثبت میشود. این شفافیت در ثبت وقایع، به ویژه در زمان بروز خطا، مشابه روشهای شناسایی نقاط شکست در عاملهای هوش مصنوعی عمل کرده و امکان عیبیابی دقیق را فراهم میکند. این یعنی انسانها میتوانند دقیقاً بررسی کنند که چرا یک عامل تشخیص، مسیر خاصی را انتخاب کرد یا استقرار یک اصلاحیه چقدر زمان برد.
این تغییر، نقش مهندس SRE را از یک «اپراتور» به یک «ناظر» تغییر میدهد. اکنون مهندسان بهجای اجرای دستورات دستی، بر تعریف دستورالعملها و تأیید اقدامات حساس تمرکز میکنند. چنین نظارتی برای جلوگیری از رفتارهای پیشبینینشده ضروری است؛ چرا که مدیریت مستندمحور در برابر رویکرد امیدوارانه میتواند تفاوت میان یک بازیابی موفق و یک بحران جدید باشد. نتیجه این رویکرد، کاهش چشمگیر میانگین زمان بازیابی (MTTR) از طریق حذف مرحله دستیِ بررسیهاست.
گام بعدی شما
- بررسی کنید که آیا پشته (Stack) مشاهدهپذیری فعلی شما از OpenTelemetry برای ثبت فعالیتهای مدلهای AI پشتیبانی میکند یا خیر.
- دستورالعملهای رفع خطای (Runbooks) دستی خود را به فرمتهای قابلفهم برای عاملهای AI تبدیل کنید.
- تعریف کنید کدام عملیات در زیرساخت شما «پرریسک» هستند تا برای عامل تأیید (Approval Agent) تعریف شوند.
اما تأمین زیرساختی برای این حجم از استنتاجهای متوالی، چالشهای جدیدی در هزینه ایجاد میکند — به تحلیل ما درباره هزینه استنتاج در مقیاس بالا مراجعه کنید.
گفتگو