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

هفته‌ای پیش در بنگالورو در جمعی از SREهای ارشد، مهندسان پلتفرم و رهبران مهندسی صحبت کردم تا بفهمم موقعیت واقعی SRE کجاست. نتیجه‌ای که دیدم این بود که موضوعات پرزرق و برق کاهش MTTR نبود؛ بیشتر داستان‌های شکست‌های واقعی، نقدهایی به کتاب‌های قدیمی و حافظه‌های سازمانی پراکنده و تیم‌هایی در مقیاسی از «AI به من کمک می‌کند» تا «AI به تنهایی عمل می‌کند» بود که هیچ‌کدام از آن‌ها مطمئن نبودند برای صعود چه نیاز دارند 🤖.

محور تکراری بحث‌ها این بود که بزرگ‌ترین چالش هوش مصنوعی در عملیات، نه محدودیت مدل‌ها بلکه فقدان زمینه (context) است. چارچوبی که من بارها به آن بازگشتم را شروع کردم «مسئلهٔ چهار بدنهٔ SRE» بنامم — چیزی که هم وعده‌ها و هم محدودیت‌های عملیات خودمختار را بهتر توضیح می‌دهد.

چند سال پیش نیمه‌شب روی یک پل حادثه بودم؛ هشت فروشنده پشت خط، یک صفحه‌گستردهٔ RACI دویست ردیفی، و هر داشبورد سبزرنگی برای بخش خودش. دو فروشندهٔ ابر همدیگر را مقصر می‌دانستند؛ یکی از فروشندگان قطع تماس کرد وقتی رقیب وارد دایره شد. ریشهٔ مشکل در تله‌متری شبکه‌ای بود که هیچ‌کس آن را در قابلیت‌مشاهدهٔ خودش ادغام نکرده بود. آن شب فهمیدم که هیچ طرفی تصویر کامل را ندارد و هیچ انسانی، حتی ارشد، نمی‌تواند در ساعت 2:07 بامداد تصویر کامل را حفظ کند ⏰.

هر تصمیم مهم عملیاتی نیازمند استدلال همزمان روی چهار حوزهٔ حقیقت است:

کد: تعهدها، شاخه‌ها، buildها، نسخه‌ها و تغییرهای پیکربندی — چه چیزی و چه زمانی به‌روزرسانی شده است؟

وضعیت زیرساخت: حالت واقعی حساب‌های ابری، شبکه‌ها، کلاسترهای Kubernetes، صف‌ها، پایگاه‌های داده و سیاست‌های IAM — آنچه Terraform می‌گوید باید وجود داشته باشد در مقابل آنچه در واقعیت هست.

سیگنال‌های زمان اجرا: متریک‌ها، لاگ‌ها، tracing، رویدادها، error budgets، SLOها و هشدارهایی که به تجربهٔ مشتری تأثیر می‌گذارند — سیستم همین لحظه چه می‌کند و از چه زمانی رفتار متفاوت شده است؟

دانش عملیاتی: حکمت قبیله‌ای، post-mortemها، سوابق تصمیم‌گیری معماری، runbookهای on-call، رشته‌های Slack و اسناد تاریخی که توضیح می‌دهند چرا یک چیز به این شکل است.

هرکدام از این چهار حوزه تا حدی به‌صورت مجزا با ابزارهایشان حل می‌شوند (Git، Terraform، پشتهٔ مشاهده‌پذیری، Confluence)، اما هر تصمیم واقعی در تقاطع این چهار حوزه رخ می‌دهد. همانند مشکل سه‌بدنه در فیزیک، اضافه شدن یک «بدن» چهارم مسئله را تنها از نظر کمی سخت‌تر نمی‌کند؛ پویایی آن qualitatively متفاوت می‌شود. تنها عدهٔ انگشت‌شماری از مهندسان ارشد هستند که می‌توانند چهار بدنه را هم‌زمان دنبال کنند — منابع گران، کمیاب و ناپایدار.

این خلا را با چیزی که من «بتونهٔ مردمی» می‌نامم پر می‌کنیم: دانش قبیله‌ای در چند نفر و مستنداتی که به‌محض شروع تغییر زیرساخت، بیات می‌شوند. تقریباً در همهٔ جلسات آن روز داستان‌هایی شنیدم از وقت‌هایی که این بتونه ترک برداشت و موجب شکست شد.

در مرکز گفتگوها همیشه یک سؤال بود: تا چه حد می‌توان به یک agent برای انجام یک RCA خودکار اعتماد کرد؟ پاسخ به شدت وابسته به کیفیت داده‌ها و یکپارچگی زمینه‌ای است که عامل از آن استفاده می‌کند. یک RCA سریع‌تر یا یک داشبورد هوشمندتر به‌تنهایی مشکل را حل نمی‌کند؛ مشکل همبستگی بین منابع داده است. عامل‌ها باید قبل از ورود اولین انسان به Bridge، فرضیه‌های RCA را بر پایهٔ SLO آماده کرده باشند و نه صرفاً صفحه‌های نمایش را سریع‌تر کنند.

بحث دربارهٔ شکست‌های عامل‌ها نشان می‌داد که محصولات فعلی اغلب با خطاهایی مواجه‌اند: عامل‌هایی که با اعتماد به نفس مشکل اشتباه را رفع می‌کنند، در برخورد با یک حادثهٔ واقعی فرو می‌ریزند یا استدلال‌شان بعداً قابل بازسازی نیست. وقتی زمینهٔ استدلال عامل تکه‌تکه باشد، شکست نه تنها محتمل است بلکه به‌صورتی غیرقابل‌پذیر رخ می‌دهد. runbookهای قدیمی گاهی از هیچ بهتر نیستند چون به اقدامات اشتباه و قطعی دعوت می‌کنند. بیشتر سازمان‌ها امروز بین حالت co-pilot و full-autopilot قرار دارند؛ تقریباً همه در میانهٔ مسیر صعود هستند و سؤال این است که پلهٔ بعدی چیست.

نتیجه‌ای که من و بسیاری در آن اتاق به آن رسیدیم این بود که گلوگاه کیفیت مدل نیست؛ گلوگاه زمینه و زیرلایهٔ داده‌هاست. شما نمی‌توانید یک agent را بالای چهار سیستم جدا و مشکوک قرار دهید و انتظار اعتماد داشته باشید. یک عامل به‌اندازهٔ زمینه‌ای که درباره‌اش استدلال می‌کند قابل‌اتکا است.

راه‌حل بنیادی ساختن بستری است که عامل‌ها آن را می‌خوانند و می‌نویسند: یک knowledge graph یکپارچه و بلادرنگ که چهار بدن و لبه‌های بین آنها را نشان دهد. ارزش در لبه‌هاست: یک commit سرویس را تغییر می‌دهد، Terraform زیرساختی فراهم می‌کند، Kubernetes استقرار را اجرا می‌کند، tracing از OpenTelemetry و متریک‌های Prometheus افزایش تاخیر را نشان می‌دهند — و این نمودار باید بتواند آن رویداد را به یک حادثهٔ مشابه در شش ماه قبل و راه‌حل آن مرتبط کند 🔗.

این نمودار باید فعال و versioned باشد، چون دیدگاه دیروز لزوماً نمایانگر دنیای امروز نیست؛ و هر تصمیم عامل باید بر اساس یک snapshot مشخص گرفته شود تا بتوان آن را بازپخش و ممیزی کرد. بدون چنین نموداری، agentها نمایشی، نرم و غیرقابل‌اعتماد خواهند ماند؛ با آن، آنها می‌توانند استدلال در چهار حوزه را انجام دهند، در محدودهٔ سیاست و blast radius عمل کنند و نتایج را به عقب بنویسند تا حلقهٔ بعدی بهتر شود.

اعتماد در نهایت یک trace از تصمیم است. اگر زیرلایهٔ نمودار وجود داشته باشد، چیزی که اعتماد را جلب می‌کند قابلیت ممیزی است: برای هر اقدامی که agent انجام می‌دهد باید یک رکورد پایدار وجود داشته باشد — ورودی‌هایی که مشاهده کرده (snapshot نمودار)، سیاست‌های مؤثر، نسخهٔ مدل، فرضیه‌هایی که بررسی یا رد شده‌اند، اقدام انجام‌شده و نتیجه. این تنها حسن‌تطابق نیست؛ این چیزی است که CISO، افسر ریسک و تنظیم‌کننده از یک agent که در تولید کار می‌کند، ابتدا می‌خواهند. استقلالی که نتوانید از آن دفاع کنید، در واقع استقلال نیست.

وقتی agentها به‌طور مداوم روی چهار بدنه استدلال کنند و نه فقط بعد از مرگ ماجرا یادداشت بنویسند، حادثه‌ها نادرتر می‌شوند و نوبت‌های اضطراری ساعت دو بامداد استثنا خواهند شد. متریکی که باید دنبال کنید از سرعت بازیابی به سمت فراوانی شب‌های بد کمتر تغییر می‌کند — اما این نتیجهٔ ساختن زیرلایه و آثار آن است، و نه نقطهٔ شروع.

پس راه پیش چیست؟ دو اصل ساده:

1) عملیات را به‌عنوان داده ببینید. اجازه ندهید کد، وضعیت زیرساخت، سیگنال‌های زمان اجرا و دانش عملیاتی به‌صورت چهار پشتهٔ سیلو شده و مشکوک باقی بمانند. آن‌ها را در یک knowledge graph یکپارچه که قابل پرس‌وجو، نسخه‌بندی و استدلال باشد، ادغام کنید.

2) عامل‌ها بعد از زیرلایه می‌آیند، نه قبل از آن. بدون این بستر هیچ عاملی به‌اندازهٔ کافی قابل‌اطمینان نخواهد بود تا در مسیر بحرانی قرار گیرد. عامل‌ها باید در مسیر تولید مستقر شوند و نه صرفاً پس از حادثه: آنها باید به‌صورت یک حلقهٔ استدلال مداوم روی کد، Infrastructure-as-Code، حالت Kubernetes، تله‌متری OpenTelemetry، متریک‌های Prometheus و حافظهٔ عملیاتی عمل کنند و برای هر تصمیم یک trace اضافه کنند تا تصمیم بعدی بهتر باشد ✅.

آیا تا 2026 به عملیات کاملاً خودمختار می‌رسیم؟ خیر. اما مسیر روشن است و با فراهم آوردن زمینهٔ بهتر و عامل‌های قابل‌اعتماد که بر اساس آن عمل می‌کنند، می‌توان مقیاس را افزایش داد. از agentها شروع نکنید؛ از نمودار شروع کنید. با چهار بدنه آغاز کنید، سپس agentها دنبال خواهند شد و وقتی آماده شوند، واقعاً کار خواهند کرد 🙌.