«گردش‌کار ایمن‌تر از مدل است»؛ درس‌های یک خطای زیرساختی

تصور کنید یک خطای کوچک در کد زیرساخت، هفته‌ها پس از استقرار در محیط عملیاتی، کل سیستم شما را در لحظه‌ی ری‌استارت متوقف کند. این کابوس هر مهندس DevOps است، اما یک عامل کدنویسی AI (AI coding agent) توانست چنین باگی را پیش از آنکه به محیط Production برسد، شکار کند. این عامل تنها کد ننوشت؛ بلکه محیط را کاوش کرد، ابهامات نیازمندی‌ها را شناسایی کرد و محدودیت‌های ایمنی را پیشنهاد داد که مهندس انسانی آن‌ها را نادیده گرفته بود.

تغییرات زیرساختی به‌ندرت اتفاقاتی ایزوله هستند. در این مورد، وظیفه یک تیکت روتین یا BAU (Business As Usual) بود: ایجاد چند صف پیام (Message Queues)، پیکربندی Dead-lettering و دسترسی‌ها، و در دسترس قرار دادن آن‌ها برای اپلیکیشن. اما پیچیدگی در این بود که بروکر (Broker) بین چندین محیط مشترک بود، اپلیکیشن‌های موجود به آن وابسته بودند و بخشی از پیکربندی‌ها از طریق کد تولید می‌شد. چون یک اشتباه کوچک می‌توانست دامنه‌ی تخریب (Blast Radius) گسترده‌ای داشته باشد، مهندس سیستمی با دسترسی‌های نامتقارن طراحی کرد: عامل می‌توانست تقریباً همه چیز را بخواند، اما بدون تأیید صریح انسان، اجازه تغییر هیچ چیزی را نداشت.

امنیت و نرده‌های حفاظتی (Guardrails)

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل‌ها خطرناک است. در اینجا نیز برای جلوگیری از شکست‌های فاجعه‌بار، مهندس چهار قانون ساده و غیرقابل‌مذاکره برای عامل تعریف کرد:

• محیط‌های Production به‌طور مطلق فقط‌خواندنی (Read-only) هستند.
• هر تغییری در محیط‌های غیر-Production نیاز به تأیید انسانی دارد.
• تمام تغییرات باید قابل بازگشت (Reversible) باشند.
• عامل در صورت مواجهه با ابهام، نباید حدس بزند.

این رویکرد برای مهار دسترسی‌های غیرمجاز حیاتی است، چرا که جداسازی لایه‌ی استدلال از اجرا می‌تواند مانع از اجرای دستورات مخرب توسط عامل‌ها شود.

مکانیسم گردش‌کار (Workflow)

به نقل از گزارش منتشر شده در dev.to، این عامل از یک گردش‌کار صلب و غیرخطی پیروی کرد که هدفش به حداقل رساندن ریسک بود. این فرآیند بسیار مهم‌تر از مدل AI به‌کاررفته بود و شامل مراحل زیر می‌شد:

• کاوش (Explore): اسکن محیط برای یافتن الگوهای موجود و درک ساختار فعلی.
• برنامه‌ریزی و پیش‌بینی شکست (Plan + Pre-mortem): تدوین پیش‌نویس تغییرات و پیش‌بینی حالت‌های احتمالی شکست.
• بازبینی مستقل (Independent Review): یک عامل AI دوم و مجزا، برنامه را ممیزی کرد تا خطاهای احتمالی را بیابد.
• پرسش از انسان (Questions to Human): پاسخ به سوالات مشخص و شماره‌گذاری شده پیش از شروع پیاده‌سازی.
• پیاده‌سازی (Implement): اجرای تغییرات هدفمند و محدود.
• استقرار در محیط تست (Non-production Rollout): انتقال تغییرات به محیط‌های غیر-عملیاتی.
• تست (Test): اعمال فشار (Stress-test) روی سیستم برای اطمینان از پایداری.
• بازبینی (Review): تحلیل نتایج حاصل از تست‌ها.
• تحویل (Handoff): ارائه نتیجه نهایی و مستندات به مهندس.

شکار «بمب ساعتی»

در مرحله کاوش، عامل متوجه شد تیکت مبهم است. بروکر محیط تست بین چندین محیط مشترک بود، اما نام صف‌ها در تیکت فاقد شناسه محیطی (Environment Identifier) بود. اگر عامل کورکورانه آن‌ها را می‌ساخت، محیط‌های تست مختلف از صف‌های یکسانی استفاده می‌کردند و تداخل (Collision) ایجاد می‌شد. عامل با توقف و پرسش درباره اینکه دقیقاً کدام محیط‌ها به این تغییر نیاز دارند، از این برخورد جلوگیری کرد.

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

بحرانی‌تر از آن، شناسایی یک پیش‌فرض خطرناک در پیکربندی صف بود. عامل متوجه شد در سناریوی شکست مورد انتظار، پیام‌ها می‌توانند در حافظه انباشته شوند در حالی که مصرف‌کننده (Consumer) در دسترس نیست. اگر تعداد پیام‌ها بیش از حد زیاد می‌شد، می‌توانست حافظه حفاظتی بروکر را تحریک کرده و اپلیکیشن‌های کاملاً بی‌ربط را مختل کند. عامل پیشنهاد داد یک محدودیت اندازه (Size Limit) اضافه شود و سیاست ذخیره‌سازی تغییر کند تا این ریسک کاهش یابد.

قدرت بازبینی چند-عاملی (Multi-Agent Review)

بزرگ‌ترین دستاورد، نتیجه‌ی بازبینی توسط عامل دوم بود که در نقش بازبین عمل می‌کرد. این بازبین یک خطای «بحرانی» (CRITICAL) را شناسایی کرد: یک عبارت منظم (Regex) حاوی یک نقطهٔ Escape شده مانند amq\.default. این عبارت در Regex کاملاً درست است، اما وقتی مقدار آن در نهایت وارد یک فایل JSON می‌شد، توالی \. یک توالی Escape معتبر در استاندارد JSON نبود.

این باگ به‌شدت فریبنده و خطرناک بود چون در زمان استقرار یا اعتبارسنجی‌های معمول خطا نمی‌داد. بروکر تنها هنگام ری‌استارت (Restart)، آن پیکرباری خاص را می‌خواند. این یعنی تغییرات می‌توانست با موفقیت استقرار و تست شود، اما هفته‌ها بعد، در اولین ری‌استارت یک گره (Node)، باعث سقوط سیستم شود.

این کشف منجر به یک تغییر بنیادین در فرآیند تیم شد: آن‌ها به‌جای اعتبارسنجی قالب (Template)، شروع به اعتبارسنجی آرتیفکت (Artefact) نهایی کردند که سیستم واقعاً مصرف می‌کند. قانون جدید این است که آرتیفکت رندر شده و برای هر محیط پارس (Parse) شود تا صحت آن تضمین گردد. این تجربه نشان می‌دهد که شکاف عمیقی میان صحتِ پیاده‌سازی کد و صحتِ عملکردی سیستم در عامل‌های کدنویس وجود دارد.

تست کردن مرزها

پس از تأیید برنامه، عامل تغییرات را به‌صورت هدفمند اجرا کرد. او به‌جای وارد کردن (Import) کل فایل پیکربندی، فقط روی ایجاد اشیاء خاص و تغییر دسترسی‌های مورد نیاز تمرکز کرد و بقیه موارد را دست‌نخورده باقی گذاشت. این کار دامنه‌ی تخریب را در مقایسه با دستوراتی که کل پیکربندی را به یک وضعیت خاص می‌برند، به شدت کاهش داد.

سپس تست‌های سخت‌گیرانه‌ای را با استفاده از هویت واقعی اپلیکیشن اجرا کرد:

• مسیر موفق (Happy Path): بررسی چرخه کامل: انتشار $\rightarrow$ مصرف $\rightarrow$ شکست $\rightarrow$ تلاش مجدد $\rightarrow$ تلاش مجدد $\rightarrow$ تلاش مجدد $\rightarrow$ صف Dead-letter.
• موارد منفی (Negative Cases): تأیید اینکه اپلیکیشن نمی‌تواند به منابعی که مجاز نیست دسترسی داشته باشد یا آن‌ها را ایجاد کند. به‌طور خاص تست شد که آیا اپلیکیشن می‌تواند اشیائی را بسازد که اجازه ساختشان را ندارد یا خیر.
• تست فشار (Stress Testing): عامل عمداً صف را پر کرد تا زمانی که به حد تعیین‌شده رسید. مهندس اشاره کرد محدودیتی که هرگز تحریک نشده باشد، هنوز تا حدی یک تئوری است.

شکست و ایجاد حفاظ جدید

پیش از انجام ری‌استارت غلتان (Rolling Restart) گنه ها، عامل تفاوت‌های پیکربندی بین مخزن (Repository) و سیستم زنده را بررسی کرد. همچنین شناسایی کرد که یک صف حاوی پیام‌هایی است که در ری‌استارت از بین می‌روند و برای ادامه عملیات از انسان اجازه گرفت.

پس از ری‌استارت، داشبورد مانیتورینگ سبز بود، تمام گنه ها سالم بودند و رپلیکاها همگام شده بودند. اما اپلیکیشن از کار افتاده بود. یک مصرف‌کننده (Consumer) متوقف شده بود، در حالی که Pod آن سالم بود. ری‌استارت باعث شده بود اپلیکیشن دوباره متصل شود و صف خود را تعریف (Redeclare) کند، اما چون صف از قبل با تنظیماتی کمی متفاوت وجود داشت، بروکر درخواست تعریف مجدد را رد کرد.

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

تبدیل اشتباهات به سیستم‌ها

هر شکست در این آزمایش به یک قانون سخت برای گردش‌کار عامل تبدیل شد تا سیستم یک اشتباه را دوبار تکرار نکند:

• مشکل: ری‌استارت باعث شکست مصرف‌کننده شد $\rightarrow$ قانون: هرگاه رفتار کاربر نهایی تغییر کرد، فوراً به انسان اطلاع بده.
• مشکل: خوشه سالم بود اما کلاینت خراب $\rightarrow$ قانون: وضعیت کلاینت را قبل و بعد از عملیات مقایسه کن.
• مشکل: تشخیص Drift فقط بر اساس وضعیت فعلی Git بود $\rightarrow$ قانون: پیش از اعلام Drift، تاریخچه Git را بررسی کن.
• مشکل: بازبین‌ها حقایق برنامه را تکرار می‌کردند $\rightarrow$ قانون: بازبین‌ها باید حقایق مهم را به‌طور مستقل تأیید کنند.
• مشکل: ادعاهای محتمل بدون دلیل بودند $\rightarrow$ قانون: هر حقیقت مهم باید یک دستور، کوئری یا منبع پشتوانه داشته باشد.
• مشکل: پیکربندی فقط بعد از ری‌استارت شکست خورد $\rightarrow$ قانون: دقیقاً همان آرتیفکتی را اعتبارسنجی کن که سیستم مصرف می‌کند.

این رویکرد نقش مهندس DevOps را تغییر می‌دهد. به‌جای صرف صبح‌ها برای خواندن تیکت‌ها، جستجو در Git و نوشتن YAML، انسان به یک تصمیم‌گیرنده تبدیل می‌شود که بر سوالات سطح بالا تمرکز می‌کند: واقعاً چه چیزی باید تغییر کند؟ چه چیزی ممکن است خراب شود؟ چگونه بفهمیم که عملیات موفق بوده است؟ و چه چیزهایی هرگز نباید اجازه اجرا داشته باشند؟

استراتژی پیاده‌سازی تجاری

برای سازمان‌هایی که قصد پذیرش DevOps عامل‌محور را دارند، نویسنده یک شروع تدریجی و محتاطانه را پیشنهاد می‌کند:

۱. دسترسی فقط‌خواندنی: اجازه دهید عامل‌ها ابتدا بررسی کنند. بگذارید لاگ‌ها و متریک‌ها را تحلیل کنند و تغییرات را آماده کنند بدون اینکه توانایی خراب کردن چیزی را داشته باشند. شما می‌توانید بدون دادن دسترسی Write، چیزهای زیادی درباره توانایی‌های عامل بیاموزید.
۲. گیتینگ اعتبارنامه‌ها (Credential Gating): به‌جای تکیه بر پرامپت‌هایی مثل «به Production دست نزن»، از کنترل‌های واقعی استفاده کنید؛ جایی که اعتبارنامه محیط Production به‌طور فیزیکی و سیستمی اجازه تغییر ندهد.
۳. گیت‌های تأیید انسانی: انسان را در نقطه‌ای قرار دهید که دامنه‌ی تخریب آغاز می‌شود. عامل آماده می‌کند، انسان تأیید می‌کند. پس از درک حالت‌های شکست، می‌توانید به‌تدریج اتوماسیون بیشتری اضافه کنید.
۴. ارتباط بهینه: از عامل بخواهید سوالات را در یک لیست شماره‌گذاری شده دسته‌بندی کند تا از «خستگی ناشی از وقفه» (Interrupt Fatigue) جلوگیری شود. یک عامل خوب باید لیستی تجمیعی ارائه دهد، مثلاً:
- کدام چهار محیط به صف‌ها نیاز دارند؟
- آیا باید از الگوی موجود A استفاده شود؟
- آیا سیاست مصرف حافظه اعمال شود؟
- آیا با وجود پیام‌هایی که در ری‌استارت از بین می‌روند، ادامه دهد؟
۵. تبدیل اشتباهات به حفاظ: هر خطا نباید صرفاً یک ارور باشد؛ بلکه باید منجر به یک قانون جدید شود تا نه AI و نه مهندس بعدی، آن اشتباه را تکرار نکنند. اینجاست که اتوماسیون عامل‌محور واقعاً جذاب می‌شود.

این آزمایش ثابت می‌کند شما به AI نیاز ندارید که به‌طور خودمختار یک مرکز داده را اداره کند؛ بلکه به AI نیاز دارید که یک قطعه کار تعریف‌شده را از یک فرآیند ایمن و تکرارپذیر عبور دهد و در لحظات حساس، تصمیم‌گیری را به انسان ارجاع دهد.

نکات نهایی برای DevOps

حتی بدون عامل AI، سه عادت از این تجربه ارزش پذیرش دارند:

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

گام بعدی شما

• اگر از ابزارهای کدنویسی AI استفاده می‌کنید، یک «عامل بازبین» (Reviewer Agent) مجزا با پرامپت متضاد تعریف کنید تا خروجی عامل اول را به چالش بکشد.
• در محیط‌های تست، سناریوهای «شکست عمدی» (Negative Testing) را به گردش‌کار اتوماسیون خود اضافه کنید.
• لیست دسترسی‌های AI خود را بازبینی کنید و دسترسی Write را از محیط‌های حساس به‌طور کامل حذف نمایید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.