مهندسی آشوب در سرویس‌های عملیاتی مدل‌های زبانی

آزمون‌های سنتی نرم‌افزار نمی‌توانند رفتارهای غیرخطی و غیرمنتظره‌ی سرویس‌های مبتنی بر مدل‌های زبانی بزرگ را پوشش دهند. مشکلاتی مثل طوفان تخلیه‌ی کش KV، قفل شدن توکن‌ساز با کاراکترهای سمی، یا خطای 429 از سوی ارائه‌دهنده‌ی بالادستی که باعث سرریز حافظه می‌شود، فقط زیر بار واقعی خودشان را نشان می‌دهند.

مهندسی آشوب (Chaos Engineering) برای مدل‌های زبانی چارچوبی فراهم می‌کند تا این نقاط شکست را به‌صورت مهارشده، کنترل‌شده و پیش از آن‌که کاربران با قطعی روبه‌رو شوند شناسایی کنید. در این درس با لایه‌های ایمنی، پیش‌نیازهای ورود به پروداکشن و سناریوهای آزمایشی اختصاصی استنتاج LLM آشنا می‌شوید.

مهندسی آشوب (Chaos engineering) برای مدل‌های زبانی بزرگ، در سال 2026 به یک حوزه‌ی تخصصی مستقل تبدیل شده است. پیش‌نیازهای اجرای آزمایش‌ها در محیط عملیاتی (پروداکشن): داشتن SLI/SLO مشخص، مشاهده‌پذیری مبتنی بر ردگیری محاسبات (Trace) + متریک + لاگ، بازگشت به عقب (Rollback) خودکار، ران‌بوک‌ها (Runbooks) و نوبت پاسخگویی (آنکال). معماری آن از چهار لایه تشکیل می‌شود: لایه‌ی کنترل (اسکژولر آزمایش)، لایه‌ی هدف (سرویس‌ها، زیرساخت، پایگاه‌های داده)، لایه‌ی ایمنی (گاردریل‌ها + توقف اضطراری + فیلترهای ترافیک)، لایه‌ی مشاهده‌پذیری (متریک‌ها + ردگیری‌ها + لاگ‌ها)، و حلقه‌ی بازخورد (Feedback loop) به تنظیمات SLO. گاردریل‌ها (سازوکارهای ایمنی) اجباری هستند: هشدارهای نرخ مصرف بودجه (Burn-rate alerts) در صورتی که نرخ مصرف روزانه‌ی بودجه‌ی خطا از 2 برابر حد انتظار بیشتر شود، آزمایش را متوقف می‌کنند؛ بازه‌های بی‌صداکردن هشدارها (Suppression windows) و تطبیق شناسه‌ی ردگیری (Trace-ID correlation) نیز از شلوغی و تکرار هشدارها جلوگیری می‌کنند. چرخه‌ی اجرا: قناری هفتگی کوچک + بازبینی SLO؛ روز مانور (Game day) ماهانه + گزارش پس از حادثه (Postmortem)؛ ممیزی تاب‌آوری فصلی بین‌تیمی + نقشه‌برداری وابستگی‌ها. آزمایش‌های اختصاصی مدل‌های زبانی: سرریز حافظه، خرابی شبکه، قطعی ارائه‌دهنده، پرامپت‌های مخرب و طوفان بیرون‌اندازی از کش کلید-مقدار (KV cache). ابزارها: Harness Chaos Engineering (پیشنهادهای برگرفته از LLM، کاهش شعاع تخریب، یکپارچه‌سازی ابزار MCP)؛ LitmusChaos (پروژه‌ی فارغ‌التحصیل CNCF)؛ Chaos Mesh (بومی کوبرنتیز در ساندباکس CNCF).

اهداف یادگیری

• نام بردن پنج پیش‌نیاز مهندسی آشوب (SLI/SLO، مشاهده‌پذیری، بازگشت به عقب، ران‌بوک‌ها، آنکال) و توضیح این‌که چرا نادیده گرفتن هرکدام کل فرآیند را مختل می‌کند.
• رسم نمودار چهار لایه (کنترل، هدف، ایمنی، مشاهده‌پذیری) و حلقه‌ی بازخورد به SLO.
• برشمردن پنج آزمایش اختصاصی مدل‌های زبانی (سرریز حافظه، خرابی شبکه، قطعی ارائه‌دهنده، پرامپت مخرب، طوفان بیرون‌اندازی کش KV).
• انتخاب ابزار مناسب (Harness، LitmusChaos یا Chaos Mesh) با توجه به استک فنی موجود.

صورت مسئله

آزمون‌های آشوب در استک‌های نرم‌افزاری سنتی کاملاً جاافتاده‌اند؛ اما استک‌های مبتنی بر مدل‌های زبانی، حالت‌های شکست (Failure modes) جدیدی اضافه می‌کنند. یک پرامپت 4K توکنی حاوی یک نویسه‌ی مسموم، فرآیند توکن‌سازی (Tokenization) را به مدت 12 ثانیه مسدود می‌کند. ارائه‌دهنده‌ی بالادستی خطای 429 می‌دهد؛ درگاه (Gateway) شما دوباره تلاش می‌کند؛ و سرویس شما به خاطر افزایش همروندی ناشی از تلاش‌های مجدد، با خطای کمبود حافظه (OOM) از کار می‌افتد. طوفان بیرون‌اندازی از کش KV زیر بار ناگهانی، آبشاری از پیش‌پرکنی‌های (Prefill) مجدد راه می‌اندازد که تمام ظرفیت پردازشی را اشباع می‌کند.

هیچ‌کدام از این موارد در تست‌های واحد (Unit tests) دیده نمی‌شوند. تنها راه شناسایی آن‌ها پیش از مواجهه‌ی کاربران، استفاده از مهندسی آشوب است.

مبانی مفهومی

پیش‌نیازها

پیش از فراهم کردن این موارد، هرگز آشوب را در محیط عملیاتی اجرا نکنید:

1. SLI/SLO — تعیین شاخص‌ها و اهداف مشخص سطح سرویس.
2. مشاهده‌پذیری — ردگیری‌ها، متریک‌ها و لاگ‌های متصل به داشبوردها.
3. بازگشت به عقب خودکار — سازوکار بازگشت به عقب با فلگ خط‌مشی طبق فاز 17 · 20.
4. ران‌بوک‌ها — مستندات ساختاریافته طبق فاز 17 · 23.
5. نوبت پاسخگویی (آنکال) — حضور فردی برای پاسخگویی و واکنش سریع.

نبود هر یک از این موارد یعنی آزمایش آشوب عملاً به یک حادثه‌ی واقعی تبدیل می‌شود.

چهار لایه + بازخورد

لایه‌ی کنترل — اسکژولر آزمایش (جریان کاری Litmus، زمان‌بندی Chaos Mesh، رابط کاربری Harness).

لایه‌ی هدف — سرویس‌ها، پادها، نودها، لودبالانسرها و پایگاه‌های داده.

لایه‌ی ایمنی — سوییچ قطع اضطراری (Kill switch)، بازه‌های بی‌صداکردن، محدودیت‌های شعاع تخریب (Blast radius) و گیت‌های بودجه‌ی خطا.

لایه‌ی مشاهده‌پذیری — متریک‌های استاندارد + تطبیق شناسه‌ی ردگیری برای تفکیک خطاهای ناشی از آشوب از خرابی‌های طبیعی سیستم.

حلقه‌ی بازخورد — یافته‌های آزمایش به بازتنظیم SLO، به‌روزرسانی ران‌بوک‌ها و اصلاح کدهای سیستم بازمی‌گردند.

گاردریل‌ها اجباری هستند

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

پنج آزمایش اختصاصی مدل‌های زبانی

1. سرریز حافظه — با ارسال درخواست‌هایی با زمینه‌ی طولانی و همروندی بالا، طوفان آزادسازی اجباری (Preemption) کش KV راه بیندازید. بررسی کنید: آیا سرویس ترافیک را به نرمی پس می‌زند یا از کار می‌افتد؟

2. خرابی شبکه — اتصال میان درگاه استنتاج و ارائه‌دهنده را قطع کنید. بررسی کنید: آیا طرح پشتیبان (Fallback) در محدوده‌ی زمانی SLA فعال می‌شود؟ (فاز 17 · 19)

3. شبیه‌سازی قطعی ارائه‌دهنده — اعمال 100% خطای 429 از سوی OpenAI. بررسی کنید: آیا مسیریابی به شکل خودکار تغییر مسیر (Failover) را به Anthropic هدایت می‌کند؟ (فاز 17 · 16 و 19)

4. پرامپت مخرب — پی‌لودی ارسال کنید که توکن‌ساز را متوقف کند (مثلاً یونیکدهای عمیقاً تودرتو یا کاراکترهای بسیار حجیم UTF-8). بررسی کنید: آیا یک درخواست منفرد می‌تواند یک ورکر را قفل کند؟

5. طوفان تخلیه‌ی کش KV — با پر کردن سقف بلاک‌های vLLM، تخلیه‌ی اجباری ایجاد کنید. بررسی کنید: آیا LMCache بازیابی می‌شود یا کیفیت سرویس دچار افت خواهد شد؟

چرخه‌ی اجرا

• هفتگی — آزمایش‌های قناری کوچک در محیط Staging، یا احتمالاً روی 5% ترافیک پروداکشن.
• ماهانه — روز مانور زمان‌بندی‌شده روی یک سناریوی خاص؛ با حضور تیم‌های مختلف؛ همراه با گزارش پس از حادثه.
• فصلی — ممیزی تاب‌آوری بین‌تیمی؛ به‌روزرسانی نقشه‌ی وابستگی‌ها.

ابزارها

• Harness Chaos Engineering — تجاری؛ پیشنهاد سناریوهای آزمایشی با هوش مصنوعی؛ کاهش شعاع تخریب؛ یکپارچه‌سازی ابزار MCP.
• LitmusChaos — پروژه‌ی فارغ‌التحصیل CNCF؛ مبتنی بر جریان‌های کاری کوبرنتیز.
• Chaos Mesh — ساندباکس CNCF؛ سبک بومی کوبرنتیز با CRD.
• Gremlin — تجاری؛ با پشتیبانی گسترده.
• AWS FIS / Azure Chaos Studio — سرویس‌های ابری مدیریت‌شده.

شروع کوچک

اولین آزمایش: در شرایط ترافیک پایدار، یکی از رپلیکاهای رمزگشایی (Decode) را متوقف کنید (Pod-kill). تغییر مسیر ترافیک و بازیابی را زیر نظر بگیرید. اگر موفق بود و سیستم پایدار ماند، سراغ آشوب شبکه بروید.

اولین آزمایش اختصاصی مدل‌های زبانی: به مدت 5 دقیقه، خطای 429 از سمت ارائه‌دهنده اعمال کنید. عملکرد طرح پشتیبان را بسنجید. بیشتر تیم‌ها در همین گام متوجه می‌شوند طرح پشتیبان‌شان هیچ‌وقت کامل تست نشده بود.

اعدادی که باید به خاطر بسپارید

• چهار لایه: کنترل، هدف، ایمنی، مشاهده‌پذیری.
• شرط توقف با نرخ مصرف بودجه: 2 برابر نرخ مصرف بودجه‌ی مجاز روزانه.
• چرخه‌ی اجرا: قناری هفتگی، روز مانور ماهانه، ممیزی فصلی.
• پنج آزمایش مدل زبانی: حافظه، شبکه، ارائه‌دهنده، پرامپت مخرب، طوفان کش KV.

به کار بگیرید

فایل code/main.py سه آزمایش آشوب را به همراه گیت‌های لایه‌ی ایمنی شبیه‌سازی می‌کند. این اسکریپت گزارش می‌دهد که کدام آزمایش‌ها باعث فعال شدن توقف اضطراریِ ناشی از مصرف بودجه می‌شوند.

تحویل پروژه

خروجی این درس فایل outputs/skill-chaos-plan.md است. این مستند با توجه به استک و بلوغ سیستم، سه آزمایش اول و ابزار مناسب را انتخاب می‌کند.

تمرین‌ها

1. اسکریپت code/main.py را اجرا کنید. کدام آزمایش گیت نرخ مصرف بودجه را فعال می‌کند و چرا؟
2. پنج آزمایش آشوب اول را برای یک سرویس RAG مبتنی بر vLLM طراحی کنید. معیارهای موفقیت را هم بنویسید.
3. هشدار نرخ مصرف، یک آزمایش را متوقف کرده است. چگونه ریشه‌ی خطا را پیدا می‌کنید؛ ناشی از آشوب بوده یا اتفاقی طبیعی در سیستم؟
4. استدلال کنید که آیا آشوب باید در پروداکشن اجرا شود یا فقط Staging؟ در چه شرایطی اجرای آن در پروداکشن تصمیم درستی است؟
5. سه حالت شکست اختصاصی مدل‌های زبانی را نام ببرید که با آشوب معمولی شبکه بازتولید نمی‌شوند.

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• DevSecOps School — Chaos Engineering 2026 Guide
• Ankush Sharma — Observability for Large Language Models (Apress, 2026)
• LitmusChaos (CNCF)
• Chaos Mesh (CNCF)
• Harness Chaos Engineering
• AWS FIS