«از تحلیل لاگ تا گزارش نهایی»؛ مسیر خودکار پاسخ به حوادث

تصور کنید یک عامل ناظر، ارتشی از زیر-عامل‌های تخصصی را هدایت می‌کند تا قطعی‌های محیط عملیاتی را پیش از آنکه مهندس مربوطه از خواب بیدار شود، برطرف کند. طبق راهنمایی که در ۲۷ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این رویکرد نقش مهندس SRE را از عیب‌یابی دستی به نظارت بر جریان‌های اصلاحی خودکار تغییر می‌دهد.

خودکارسازی «پیجرهای ساعت ۳ صبح» مدت‌ها آرزوی دست‌نیافتنی در مهندسی قابلیت اطمینان سایت (SRE) بود. امروز این هدف به لطف مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — امکان‌پذیر شده است؛ چرا که این مدل‌ها می‌توانند وضعیت‌های پیچیده سیستم را تفسیر کرده و دستورات دقیقی را در زیرساخت‌های پراکنده اجرا کنند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت عامل‌های هوش مصنوعی اشاره کردیم، این معماری بر یک عامل ناظر (Supervisor Agent) تکیه دارد که وظایف را به زیر-عامل‌های مجهز به ابزارهای خاص می‌سپارد. این ساختار ارکستراسیون یادآور رویکردهایی است که در تحلیل ما درباره جایگزینی فرآیندهای دستی با ارکستراسیون AI بررسی شد. اجزای کلیدی این سیستم عبارتند از:

• تحلیل لاگ و متریک‌ها: عامل‌های تخصصی که از پرس‌وجوهای Prometheus و دستورات kubectl برای تشخیص لحظه‌ای استفاده می‌کنند.
• بازیابی دانش: یک خط‌لوله تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — که برای یافتن اصلاحات مرتبط، جست‌وجوی معنایی روی دفترچه‌های راهنمای (Runbooks) داخلی انجام می‌دهد.
• اجرای عملیات: یکپارچگی با وب‌هوک‌های PagerDuty برای فعال‌سازی دستورالعمل‌های اصلاحی و استفاده از Slack برای ارجاع به انسان.

به گزارش منابع فنی، پیاده‌سازی این سیستم نیازمند یک سلسله‌مراتب ایمنی سخت‌گیرانه است تا از خطاهای فاجعه‌بار خودکار جلوگیری شود. این لایه‌های حفاظتی با چارچوب مدل خودمختاری کنترل‌شده کریستوفر کُک هم‌سو است که بر کاهش ریسک در استقرار عامل‌های هوش مصنوعی تأکید دارد. مهندسان باید از چهار مرحله تدریجی عبور کنند: حالت سایه (Shadow)، حالت پیشنهادی، نیمه‌خودکار و در نهایت خودکاری کامل. هر اقدام باید یک ردپای بازرسی ایجاد کند و هر تغییری که محیط عملیاتی را تحت تأثیر قرار می‌دهد، باید تاییدیه انسانی داشته باشد.

برای متخصصان، این بدان معناست که گلوگاه اصلی دیگر «چگونه باگ را رفع کنیم» نیست، بلکه «چگونه نرده‌های ایمنی را تعریف کنیم» است. در نتیجه، تمرکز کار SRE به سمت مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — برای دفترچه‌های راهنما و جمع‌آوری داده‌های معنایی باکیفیت برای خط‌لوله RAG می‌رود. در این مسیر، تعریف هویت و دسترسی‌های دقیق برای هر عامل، مشابه آنچه در استراتژی NewCore برای شناسنامه‌دار کردن عامل‌ها دیدیم، برای مدیریت دسترسی‌ها در محیط‌های سازمانی حیاتی است.

شما می‌توانید این چارچوب را با استفاده از پایتون برای تعریف مجموعه‌ابزارها و یکپارچه‌سازی APIهای PagerDuty پیاده کنید.

گام بعدی شما

• بررسی مستندات PagerDuty برای تعریف وب‌هوک‌های خودکار.
• طراحی یک دفترچه راهنمای (Runbook) متنی ساده برای آزمایش قابلیت‌های بازیابی مدل.
• تست مدل در «حالت سایه» برای مقایسه تصمیمات هوش مصنوعی با تصمیمات انسانی بدون اعمال تغییر واقعی.

اما مدیریت «رانش» یا Drift عامل‌ها، جایی که اصلاحات خودکار منجر به بدهی فنی پیش‌بینی‌نشده در میکروسرویس‌ها می‌شود، چالش بعدی است که در گزارش‌های آتی بررسی خواهیم کرد.