به گزارش از وبسایت cncf 📣

در ماه مارس در رویداد KubeCon + CloudNativeCon Europe 2026 در آمستردام سخنرانی کردم. پس از جلسه، چندین پرسش تکرارشونده در CNCF Slack و به‌صورت حضوری مطرح شد: اساساً چرا باید یک عامل مبتنی بر هوش مصنوعی را روی زیرساخت‌های Cloud Native ساخت؟ کدام پروژه‌های CNCF واقعاً کار سنگین را انجام می‌دهند؟ نقش انسان کجاست و چگونه تیم‌ها را حول این کار سازماندهی کنیم؟ در ادامه پاسخ کوتاهی می‌آورم که برگرفته از سیستمی است که در Orange Innovation در حال توسعه و عرضه است. 🔐

زمینه: یک پلتفرم عملیات امنیتی بی‌درنگ داخلی که از یک محیط تولید تنظیم‌شده محافظت می‌کند و اکنون در فاز توسعه فعال و عرضه قرار دارد. پروتکل A2A برای هماهنگی بین عامل‌ها (منبع باز در سال 2025، اکنون تحت Linux Foundation). MCP برای ادغام محیطی (میزبانی شده تحت بنیاد Agentic AI، یک پروژه LF). Falco با eBPF همه سیستم‌ها را در بارهای کاری که نظارت می‌کنیم، رهگیری می‌کند. رویدادها از طریق Kafka به یک مدل ناهنجاری کلاسیک Isolation Forest فرستاده می‌شوند که پیش از ارسال به عوامل مبتنی بر LLM فیلتر می‌شود. هدف کاهش محسوس میانگین زمان شناسایی و پاسخ و نقل‌مکان نوشتن قوانین از تحلیلگران انسانی به لایه عامل است. ⚙️

درس‌های زیر برای همین زمینه نوشته شده‌اند، اما به‌طور برابر در هر محیط Cloud Native که یک تیم SOC و یک تیم پلتفرم مسئول تولید باشند، صادق است.

شکل 1: نمای کلی سیستم. یک عامل هماهنگ‌کننده (LangGraph + A2A) چهار عامل تخصصی را هماهنگ می‌کند: Detect (Falco + ML)، تحلیل (Threat Analyst)، Remediate و Notify (Mattermost)، به همراه یک شاخه Human-in-the-Loop و حلقه بازخورد که مدل ناهنجاری را بازآموزی می‌کند. این تصویر برگرفته از سخنرانی من در KubeCon + CloudNativeCon Europe 2026 است. 🧭

در ادامه پنج درس فنی که تاکنون یاد گرفته‌ایم آمده است، سپس نحوه سازماندهی کار میان تیم‌ها و جامعه و در نهایت دلیل اینکه چرا پشته CNCF و LF بستر مناسبی برای این نوع سیستم است.

1. هر عامل باید یک بار کاری Kubernetes باشد، نه یک ماژول درون‌فرآیند. اکثر عامل‌ها LangGraph را برای استفاده از ابزارها و حلقه استدلال خود به‌صورت محلی اجرا می‌کنند، و برخی از آن‌ها هم در مواردی که نیاز به کنترل دقیق‌تری داریم با دست پیاده‌سازی می‌شوند. لایه عامل مانند یک شبکه میکروسرویس رفتار می‌کند: رول‌اوت قناری، HPA، جداسازی namespace بدون اختراع مجدد اعمال می‌شود. الگوی مخالف (همه عوامل در یک فرآیند) برای توسعه محلی سریع‌تر است اما در تولید اشتباه است. اگر یک عامل در انتظار API مدل گیر کند، سایر عامل‌ها را هم پایین می‌کشد—پس جداسازی ضروری است. 🧩

2. ترافیک بین عامل‌ها نیازمند mTLS است، نه لزوماً یک Service Mesh. پیام‌های A2A قوانین تشخیص پیشنهادی و اقدامات پاسخ را حمل می‌کنند؛ مدل تهدید نشان می‌دهد که این پیام‌ها حداقل به‌اندازه یک صفحه داده حساس هستند. ما Service Mesh اجرا نکردیم؛ به‌جای آن عامل‌ها خودشان mTLS را مستقیماً در حمل‌ونقل gRPC/HTTP پیاده‌سازی می‌کنند و Cilium به‌عنوان زیرلایه شبکه عمل می‌کند و CiliumNetworkPolicy تعیین می‌کند کدام شناسه عامل می‌تواند به کدام سرور MCP دسترسی داشته باشد. ترکیب مدیر گواهی + mTLS در سطح عامل + CiliumNetworkPolicy برای ما از نظر عملیاتی ساده‌تر و کفایت‌کننده‌تر از یک مش بود. A2A انتخابی است که بدون تردید دوباره انجام می‌دهم؛ منبع باز بودن آن تحت Linux Foundation اجازه برنامه‌ریزی استقرار چندساله را می‌دهد و جفت‌شدن A2A با پشته CNCF زیر یک چتر حاکمیتی باز می‌آورد—که در صنایع تنظیم‌شده اهمیت تدارکاتی دارد. 🔒

3. محدودیت‌های ایمنی عامل باید به‌صورت Policy as Code باشند، نه استدلال آزاد LLM. در معماری ما، یک بازبین تصمیم می‌گیرد که آیا اجرای یک اقدام پیشنهادی ایمن است یا خیر؛ این می‌تواند استقرار یک قانون تشخیص، اعمال مهار، یا تغییر فایروال باشد. به‌جای فرستادن نثر آزاد LLM به بازبین، عامل تحلیلگر تهدید هر تشدید را بر اساس چارچوب MITRE ATT&CK طبقه‌بندی می‌کند تا بازبین ورودی ساختاریافته دریافت کند. محدودیت‌های بازبین را به‌عنوان سیاست‌های OPA و قوانین Kyverno تعریف کرده‌ایم؛ بازبین از طریق MCP با OPA تماس می‌گیرد، حکم می‌گیرد و عمل می‌کند. این سیاست‌ها در کنترل نسخه، واحد تست و بازبینی کد هستند—اگر باید از هر چیزی شروع کنید، با این‌ها شروع کنید. 📜

4. قابلیت مشاهده: A2A یک trace_id را حمل می‌کند و GitOps مالک پیکربندی است. هر بسته A2A یک trace_id دارد که نقطه اتکای قابلیت مشاهده ماست. عامل‌ها گزارش‌های JSON ساختار‌یافته با trace_id، هویت عامل، تماس‌های MCP و استفاده از توکن LLM منتشر می‌کنند. Prometheus متریک‌های هر نماینده (نرخ درخواست، تأخیر تماس MCP، نسبت‌های اجرای خودکار/رد/افزایش خودکار) را جمع‌آوری می‌کند. Cilium Hubble نمای جریان را وقتی می‌پرسیم «آیا غلاف مناسب به سرویس مناسب رسیده است؟» فراهم می‌آورد. اولین بار که یک ذی‌نفع داخلی تصمیم خودکار خاصی را بررسی کرد، همه ورودی‌ها را برای آن trace_id گردآوری و هم‌ردیف کردیم؛ کل زنجیره استدلال حدود پانزده دقیقه طول کشید، در حالی که بدون trace_id این زمان یک روز بود. قالب اعلان سیستم، فهرست ابزار و خروجی هر عامل به‌صورت یک CRD سفارشی Kubernetes تعریف شده که توسط Argo CD از Git تطبیق می‌یابد؛ بسته سیاست بازبین در همان مخزن زندگی می‌کند و ارتقاء تغییر یک Pull Request شامل بازبینی کد، ممیزی و قابلیت بازگشت است. 🔁

5. لایه LLM را با یک مدل ناهنجاری کلاسیک gate کنید. اگر هر رویدادی مستقیماً LLM را فراخوانی کند، اقتصاد پلتفرم تحت سلطه هزینه‌های LLM قرار می‌گیرد. ما Isolation Forest با scikit-learn را مقابل عامل‌ها قرار داده‌ایم تا هر نمونه را روی 17 ویژگی در میکروثانیه امتیاز بدهد؛ تنها نمونه‌هایی که بالاتر از یک آستانه تنظیم‌شده باشند به fan-out عامل می‌رسند. LLM فقط روی بخش کوچک و واقعاً مشکوک فراخوانی می‌شود—در واقع همان کاری که یک مهندس تشخیص انسانی انجام می‌داد. این روش هر دو: تأخیر و هزینه توکن را محدود نگه می‌دارد و اندازه‌گذاری لایه LLM را به بخشی از برنامه‌ریزی ظرفیت معمول تبدیل می‌کند. Isolation Forest هر هفته بازآموزی می‌شود و رانش توزیع ویژگی‌ها خود یک متریک Prometheus مانیتور شده است؛ آستانه ناهنجاری یک ثابت نیست بلکه یک پارامتر خط‌مشی است که بازبین هنگام تصمیم‌گیری به آن رجوع می‌کند. 🧠

انسان را در حلقه نگه دارید—نه فقط با پروتکل، بلکه با فرهنگ. هر تصمیم سه خروجی ممکن دارد: اجرای خودکار، رد خودکار یا ارسال به یک تحلیلگر SOC انسانی در Mattermost با زنجیره کامل استدلال و دستورات ChatOps برای تأیید، رد یا بررسی داخلی. مسیر «سومی» یک حالت معمولی است—طراحی شده تا وقتی که اعتماد بازبین زیر آستانه باشد، دارایی در فهرست حساس است، یا اقدام پیشنهادی از محدوده پیکربندی‌شده فراتر می‌رود، فعال شود. حکم «آیا این پرونده باید تشدید شود؟» یک تصمیم قطعی سیاست است که در Git کنترل نسخه می‌شود و SLO و داشبوردهای مخصوص خود را دارد. اگر داستان HITL شما این است که «بعداً یک مرحله تأیید اضافه می‌کنیم» یا «تحلیلگر همیشه می‌تواند دخالت کند»، در واقع هنوز آن فرآیند را ندارید؛ باید آن را طراحی و مستندسازی کنید. ⚖️

چگونگی پیشروی توسعه و عرضه: مدل عملیاتی هنگام حرکت از توسعه به عرضه شبیه هر پلتفرم Kubernetes دیگری است که اجرا کرده‌ایم. هشدارها ساختاری هستند: عدم پذیرش بسته خط‌مشی، p99 تأخیر MCP، رانش پیش از فیلتر ناهنجاری، عمق صف A2A بالاتر از واترمارک—نه «عامل X پاسخ عجیبی داد». اگر عاملی در تکرار افت کند، با آن مثل هر رگرسیون میکروسرویس برخورد می‌کنیم: CR را از طریق Argo CD برمی‌گردانیم، بلیط باز می‌کنیم و اصلاح را از طریق GitOps اعمال می‌کنیم؛ رانبوک‌های ویژه حادثه برای عامل لازم نیست—و این هدف است. 🚑

تأثیر بر تیم SOC: ماهیت کار تغییر می‌کند. تالیف قوانین سال‌ها گلوگاه بوده—انتقال آن بار به لایه عامل هدف صریح ماست. مهندسان به‌جای نگارش مکرر قوانین، سیاست‌های ایمنی بازبین و قوانین استقرار را پیکربندی می‌کنند. مصنوعات روزمره (CRDها، سیاست‌ها، Pull Requestهای GitOps) چیزهایی هستند که تیم‌های SOC و پلتفرم از قبل با آن‌ها آشنا هستند و می‌دانند چگونه مدیریت کنند؛ این باعث می‌شود هزینه مقیاس‌بندی تشخیص به‌جای افزایش تیم‌های تحلیلگر، با استقرار نسخه‌های بیشتر عامل و محکم‌سازی بسته سیاست بازبین حل شود. 📈

نحوه سازماندهی کار بین تیم‌ها و جامعه: هیچ‌یک از این‌ها بدون تیم‌های مشترک کار نمی‌کند. سه گروه هفتگی این سیستم را لمس می‌کنند: SOC (مالک نتایج تشخیص و سیاست‌های بازبین)، تیم پلتفرم (مالک خوشه، GitOps pipeline و runtime) و یک گروه کوچک مهندسی AI (مالک قراردادهای عامل و مدل ناهنجاری). قراردادها را محدود، قابل‌خواندن توسط ماشین و قابل اتکا (CRDها، بسته‌های OPA، طرح‌واره‌های A2A) نگه داشته‌ایم تا تغییر در یک حوزه به یک جلسه هماهنگی در حوزه دیگر نیاز نداشته باشد. نتیجه عملیاتی تنها سرعت نیست بلکه ظرفیت است: پوشش تشخیص بیشتر دیگر لزوماً به استخدام تحلیلگران بیشتر نیاز ندارد بلکه به استقرار نسخه‌های بیشتر عامل و تنظیم سیاست بازبین بستگی دارد. 🤝

این سیستم در یک جامعه نیز وجود دارد: چشم‌انداز CNCF و سیگنال‌های بلوغ پروژه‌ها (Sandbox، Incubating، Graduated و داده‌های پذیرش و حاکمیت) انتخاب‌های فنی ما را شکل می‌دهد. هنگام ارزیابی اجرای سیاست شبکه، صدور هویت یا ابزار ناهنجاری، Landscape به ما نقطه شروع بی‌طرف می‌دهد و بلوغ پروژه مشخص می‌کند آیا می‌توانیم آن را در یک محیط تولید تنظیم‌شده اجرا کنیم. ما مسائل بالادستی را در مخازن A2A و MCP دنبال می‌کنیم، تغییرات را بایگانی کرده و تجربیات را به گروه‌های کاری CNCF بازمی‌گردانیم؛ گفتگوهای KubeCon و CNCF Slack بخشی از حلقه بازخورد هستند، نه افکار بعدی. انتخاب پروتکل‌های Cloud Native زیر کنترل LF به این معنی است که تنها ما نیستیم که پلتفرم را بهبود می‌دهیم. 🌐