مهندسی آشوب؛ راهنمای Chaos Experiment امن

اگر «مهندسی آشوب» را به خاموش‌کردن تصادفی سرور تشبیه کنیم، بخش مهم ماجرا را از دست می‌دهیم. خاموش‌کردن یک Instance بدون فرضیه، معیار، دامنه و توقف خودکار فقط ایجاد اختلال است. آزمایش آشوب واقعی پیش از Fault می‌پرسد: «کدام رفتار پایدار باید ادامه پیدا کند، چرا انتظار داریم ادامه پیدا کند و در چه نقطه‌ای برای محافظت از کاربر فوراً متوقف می‌شویم؟»

مهندسی آشوب (Chaos Engineering) یک فرایند تجربی برای ساخت شواهد درباره تاب‌آوری سیستم است. تیم یک Steady State قابل‌اندازه‌گیری تعریف می‌کند، فرضیه‌ای درباره حفظ آن در حضور رویدادی واقع‌گرایانه می‌سازد، Fault را با Blast Radius محدود تزریق می‌کند و اختلاف Control و Experiment را بررسی می‌کند. نتیجه ممکن است فرضیه را تأیید یا رد کند؛ در هر دو حالت هدف یادگیری و اصلاح است، نه نمایش «خراب‌نشدن» سیستم.

پاسخ کوتاه: مهندسی آشوب چیست؟

Principles of Chaos Engineering آن را رشته‌ای برای آزمایش روی سیستم می‌داند تا درباره توان آن در تحمل شرایط آشفته Production اعتماد مبتنی بر شواهد ساخته شود. فرایند هسته‌ای چهار بخش دارد:

Steady State را با خروجی قابل‌اندازه‌گیری رفتار عادی تعریف کنید.
فرض کنید Steady State در Control و Experiment ادامه می‌یابد.
متغیری شبیه رویداد واقعی—مانند Latency، Crash یا قطع Dependency—وارد کنید.
با جست‌وجوی اختلاف میان دو گروه، سعی کنید فرضیه را رد کنید.

Chaos Engineering برای سیستم توزیع‌شده رایج است، اما به Microservice یا Cloud محدود نیست. هر سامانه‌ای که Failure، Recovery و Dependency رفتار پیچیده می‌سازند می‌تواند از آزمایش کنترل‌شده سود ببرد؛ به شرط آنکه ریسک و هزینه اجرای آزمایش توجیه داشته باشد.

آشوب کنترل‌شده با خراب‌کاری تصادفی فرق دارد

ایجاد اختلال بدون آزمایش	Chaos Experiment
«یک Pod را بکشیم ببینیم چه می‌شود»	Hypothesis و رفتار پایدار از پیش نوشته شده است
Target ممکن است تصادفی و نامحدود باشد	Target، Cohort و Blast Radius دقیق‌اند
نتیجه موفق/ناموفق تعریف نشده	Steady State، Threshold و Stop condition داریم
Rollback به مهارت لحظه‌ای وابسته است	Abort/Recovery پیش از اجرا تمرین شده است
شواهد و Control group نداریم	Before/During/After و Control/Experiment مقایسه می‌شوند
مالکیت مبهم است	Owner، Approver، Operator و On-call مشخص‌اند

Fault injection یک مکانیزم است؛ Chaos Engineering فرایند فرضیه، ایمنی، مشاهده، یادگیری و بهبود پیرامون آن است.

مرز Chaos Engineering با تست‌های نزدیک

روش	سؤال اصلی	تفاوت/هم‌پوشانی
Resilience testing	سیستم چگونه مقاومت، تنزل و بازیابی می‌کند؟	دامنه وسیع‌تر؛ می‌تواند Failover، Backup/Restore و آزمون قطعی بدون روش Chaos را شامل شود
Fault injection	چگونه Failure مشخص را ایجاد کنیم؟	یکی از ابزارهای آزمایش آشوب؛ بدون Hypothesis و Learning loop کافی نیست
Load/Stress testing	رفتار زیر Workload و محدودیت ظرفیت چیست؟	Traffic spike می‌تواند Chaos variable باشد، اما مدل بار و ظرفیت هدف مستقل دارند
Disaster recovery drill	RTO/RPO و بازیابی Region/Data چگونه است؟	ممکن است GameDay/Chaos باشد؛ اما Data integrity و Runbook معیارهای تخصصی دارند
GameDay	تیم و سیستم در سناریوی برنامه‌ریزی‌شده چگونه پاسخ می‌دهند؟	تمرین مشارکتی است؛ می‌تواند چند Chaos experiment یا شبیه‌سازی دستی داشته باشد
Incident response exercise	Detection، Escalation و Communication آماده‌اند؟	روی فرایند انسانی تمرکز دارد و الزاماً Fault واقعی تزریق نمی‌کند

برای آزمون‌های وسیع‌تر مقاومت و بازیابی، راهنمای تست تاب‌آوری مکمل این مقاله است. Intent این صفحه، طراحی و اداره خودِ Chaos Experiment است.

اگر سؤال اصلی ظرفیت، نرخ ورود، p95/p99 یا رفتار زیر Workload است، ابتدا برنامه تست عملکرد و مدل بار را بسازید؛ Traffic spike فقط زمانی Chaos variable است که داخل Hypothesis تاب‌آوری قرار گیرد.

چه زمانی آماده Chaos Engineering نیستیم؟

نداشتن یکی از موارد زیر به معنی «ممنوعیت همیشگی» نیست؛ یعنی آزمایش باید به محیط ایزوله‌تر یا کار آماده‌سازی برگردد:

مالک سرویس و On-call پاسخ‌گو نداریم؛
Steady State کاربرمحور قابل اندازه‌گیری نیست؛
Kill switch یا Recovery path آزمایش نشده است؛
در حال Incident، Deploy پرریسک، Migration یا Peak تجاری هستیم؛
Target و Blast Radius با Tag/Identity قابل محدودکردن نیست؛
Fault ممکن است داده، پول یا طرف ثالث خارج Scope را آسیب بزند؛
Observability نمی‌تواند Control را از Experiment جدا کند؛
مجوز، Change record یا Rules of Engagement روشن نیست؛
Backlog ضعف‌های شناخته‌شده داریم که همان Fault قطعاً آن‌ها را فعال می‌کند؛
تیم نمی‌تواند آزمایش را سریع متوقف و نتیجه را بازیابی کند.

اگر از قبل می‌دانیم Failover کار نمی‌کند، ابتدا آن را اصلاح و با تست قطعی Verify کنید. Chaos برای اثبات دوباره ضعف شناخته‌شده لازم نیست.

Readiness Gate پیش از طراحی آزمایش

Gate	شاهد لازم
Ownership	Service owner، approver، operator و on-call حاضر
Health	Baseline سالم در Window پیش از اجرا و نبود Incident فعال
Observability	Business/technical steady state، experiment tag و dashboard معتبر
Safety	Blast radius، stop alarm، manual kill و rollback تمرین‌شده
Authorization	محیط، Target، Fault، زمان و نقش‌ها کتبی
Data	Invariant، Backup/restore در صورت نیاز و ممنوعیت داده واقعی حساس
Dependencies	طرف ثالث و منابع مشترک داخل/خارج Scope روشن
Communication	کانال، پیام شروع/توقف و escalation تعریف شده

آمادگی Version، Dependency و Smoke محیط در چک‌لیست Test Environment تشریح شده است.

Steady State را از نگاه کاربر تعریف کنید

CPU و Pod count برای Diagnosis مفیدند، اما به‌تنهایی رفتار پایدار سیستم نیستند. اصول رسمی Chaos پیشنهاد می‌کند روی خروجی قابل‌اندازه‌گیری سیستم تمرکز کنیم. نمونه‌ها:

نرخ تکمیل Checkout از میان Attemptهای واجد شرایط؛
درصد درخواست موفق محصول و p95 Latency؛
تعداد اثر مالی Duplicate؛
Backlog age و زمان Reconciliation؛
درصد پیام/Job پردازش‌شده در SLO؛
میزان Graceful degradation و Fallback صحیح؛
زمان Detection، Mitigation و Recovery؛
نرخ کاربرانی که Journey جایگزین را کامل می‌کنند.

Window و Denominator

بنویسید Metric در چه بازه‌ای، با چه Cohort و چه مخرجی سنجیده می‌شود. «خطا کمتر از ۱٪» در Window کم‌ترافیک با دو Request معتبر نیست. داده Control و Experiment را جدا و Baseline چند بازه مشابه را نگه دارید.

Steady State یک عدد تنها نیست

ترکیبی از Outcome کسب‌وکاری، SLI فنی و Safety invariant بسازید. ممکن است Availability حفظ شود اما Duplicate charge ایجاد شود؛ آن آزمایش موفق نیست.

برای طراحی شاخص و جلوگیری از KPIهای بازی‌پذیر از راهنمای متریک‌های تست استفاده کنید.

Hypothesis قابل رد بنویسید

فرم ضعیف

اگر سرویس پیشنهادها قطع شود، سایت تاب‌آور می‌ماند.

فرم قابل اجرا

اگر برای Cohort داخلی، ۵۰٪ درخواست‌های Recommendation به مدت سه دقیقه با ۵۰۳ پاسخ دهند، Product Detail و Add-to-cart باید Steady State تعریف‌شده را حفظ کنند؛ Recommendation به Fallback خالی می‌رود، هیچ Error خامی به کاربر نمایش داده نمی‌شود و پس از حذف Fault در دو دقیقه به Baseline بازمی‌گردد.

اجزای Hypothesis

Target و Cohort؛
Fault type، شدت و Duration؛
Expected degradation؛
Steady State و Threshold؛
Recovery expectation؛
Safety invariant؛
شرایط رد فرضیه.

هدف «تأیید سیستم خوب است» نیست؛ باید فعالانه دنبال اختلافی بگردید که فرضیه را رد می‌کند.

Control group و Experiment group

بدون Control، ممکن است افت ناشی از Deploy، کمپین یا شبکه را به Fault نسبت دهید. گروه‌ها باید تا حد امکان مشابه و با یک تفاوت اصلی باشند:

Control: همان Build و Traffic class، بدون Fault؛
Experiment: Target/Cohort برچسب‌خورده با Fault؛
Dashboard و Correlation جدا؛
Exposure و Sampling روشن؛
عدم نشت Fault از Experiment به Control؛
مقایسه Before/During/After در Window همسان.

در سیستم کم‌ترافیک، اجرای متوالی یا Synthetic canary شاید عملی‌تر باشد. محدودیت استنباط را در گزارش بنویسید.

رویداد واقعی را انتخاب کنید

بر اساس Incident و معماری

Dependency timeout یا 5xx؛
Instance/Pod termination؛
Network latency، loss یا partition؛
CPU/Memory/Disk pressure؛
DNS، certificate یا credential expiry شبیه‌سازی‌شده؛
Queue lag، duplicate یا out-of-order event؛
Cache unavailable یا stampede؛
Zone/region failure؛
Traffic spike یا scaling event؛
Clock skew و delayed scheduler؛
Malformed-but-contract-valid response؛
Slow recovery یا partial dependency.

Frequency × Impact × Uncertainty

رویداد را فقط چون Tool آن را پشتیبانی می‌کند انتخاب نکنید. Incident history، Architecture، Change، Business impact و میزان ناشناختگی را امتیاز دهید. Fault بسیار مخرب اما از قبل قطعی و بدون Recovery، اولین آزمایش خوبی نیست.

Data corruption استثنایی است

خرابی داده ممکن است بازیابی‌ناپذیر باشد. ابتدا روی Copy/isolated dataset، با Backup/restore آزمایش‌شده و Invariant صریح کار کنید. تزریق Corruption روی داده واقعی مشتری معمولاً خارج از اولین مراحل و نیازمند اختیار ویژه است. الگوهای Integrity و Restore در راهنمای تست پایگاه داده آمده‌اند.

Blast Radius را چندبعدی محدود کنید

بُعد	نمونه محدودسازی
کاربر	فقط Accountهای داخلی یا Cohort opt-in
ترافیک	۱٪ Tagged requests، نه کل مسیر
منطقه	یک Zone/Region غیرحیاتی
منبع	یک Instance منتخب با Tag دقیق
زمان	سه دقیقه با TTL و Auto-expiry
قابلیت	Recommendation، نه Checkout/Payment
داده	Tenant/Namespace مصنوعی و پاک‌سازی‌شده
شدت	Latency کم یا درصد خطا محدود پیش از قطع کامل

Selection باید Fail closed باشد

اگر Selector یا Tag پیدا نشد، Experiment نباید به Target گسترده‌تر سقوط کند. Dry-run یا Preview باید Resourceهای دقیق را نشان دهد و Operator آن‌ها را تأیید کند.

Blast Radius را مرحله‌ای بزرگ کنید

همان Hypothesis را ابتدا روی یک Target، سپس Cohort کوچک و فقط پس از Remediation/Retest روی دامنه بیشتر اجرا کنید. افزایش Scope خودکار و بدون Gate مناسب نیست.

Stop Condition و Kill Switch

توقف خودکار

مستندات AWS Fault Injection Service Stop condition را مکانیزمی مبتنی بر Alarm می‌داند که با رسیدن به Threshold آزمایش را متوقف می‌کند. Alarm باید قبل از Fault فعال و با Steady State مرتبط باشد.

نمونه Stop condition

Product Detail error rate از حد ایمنی عبور کند؛
Checkout/Payment control metric افت کند؛
Fault به Cohort یا Region خارج Scope برسد؛
Duplicate financial effect بزرگ‌تر از صفر شود؛
On-call Incident اعلام کند؛
Observability قطع شود و توان دیدن اثر را از دست بدهیم؛
Dependency ثالث یا داده حساس درگیر شود؛
زمان آزمایش از TTL عبور کند.

Kill switch دستی

مسیر Cancel باید مستقل، سریع و قبلاً تمرین‌شده باشد. اگر همان Control plane که تحت Fault است Kill switch را اجرا می‌کند، نقطه شکست مشترک دارید. Operator باید اختیار توقف بدون انتظار Approval تازه را داشته باشد.

توقف با Recovery فرق دارد

Cancel کردن Fault پایان کار نیست. Target، Route، Config، Capacity و Backlog باید به حالت سالم برگردند و Steady State در Window پس از آزمایش تأیید شود.

Production مقصد اجباری نیست

اصول Chaos، Production را به دلیل Traffic و Environment واقعی ترجیح می‌دهد؛ اما مسئولیت کاهش آسیب را نیز صریح می‌داند. تیم باید Ladder متناسب با ریسک داشته باشد:

Unit/Component fault behavior با Test double؛
محیط توسعه یا Ephemeral؛
Resilience environment با Dependencyهای واقعی‌تر؛
Staging با Workload و داده مصنوعی؛
GameDay کنترل‌شده؛
Production با حساب داخلی/Shadow/Canary بسیار محدود؛
گسترش فقط پس از شواهد و Gate جدید.

اگر خطر قانونی، مالی، ایمنی یا حریم خصوصی قابل قبول نیست، در Production اجرا نکنید. Limitation محیط پایین‌تر را صریح گزارش کنید.

Security و Authorization آزمایش آشوب

ابزار Chaos عمداً توان تخریب دارد؛ بنابراین یک سطح کنترل امنیتی مستقل لازم است.

Least privilege

مستندات امنیت Azure Chaos Studio مدل چندلایه Permission، Identity اجرا و Target/Capability onboarding را توضیح می‌دهد و درباره اثر فراتر از انتظار هشدار می‌دهد. اصل عمومی این است: هویت Experiment فقط روی Target و Action لازم مجوز داشته باشد.

Creator، Approver و Operator را در صورت نیاز جدا کنید؛
Start/Cancel permission را محدود و Audit کنید؛
Target onboarding و Fault capability نیازمند Review باشد؛
Credential کوتاه‌عمر و Secret manager استفاده شود؛
پارامتر Experiment محل ذخیره Password/Payment data نیست؛
Agent و Control plane از نظر Supply chain و Network بررسی شوند؛
Execution log و تغییر Roleها Retention مناسب داشته باشند.

قواعد RoE، Stop و Evidence handling در راهنمای تست امنیت نیز قابل استفاده‌اند.

قالب کامل Chaos Experiment

Experiment ID:
Owner / Approver / Operator:
Date / change window:
System / environment / build:

Risk and learning question:
Known weakness excluded:

Steady state:
- business SLI + threshold + window
- technical SLI + threshold + window
- safety invariant

Hypothesis:
Control group:
Experiment group:

Fault:
- type / intensity / duration
- exact targets and selector
- real-world evidence

Blast radius:
- users / traffic / resources / region / data

Preconditions:
- healthy baseline
- no active incident/deploy
- on-call and dashboard ready
- kill switch tested

Automatic stop conditions:
Manual abort authority:
Rollback and recovery:
Expected recovery time:

Observability and evidence:
Security / privacy / third parties:
Communication plan:

Results:
Decision:
Remediation owner / due date:
Retest gate:

مثال: اختلال Recommendation در فروشگاه ایرانی

این Dependency برای شروع Production کم‌ریسک‌تر از پرداخت است: باید قابلیت پیشنهاد کالا تنزل پیدا کند، اما Product Detail و Add-to-cart ادامه یابند.

Steady State نمونه

شاخص	Threshold نمونه برای این آزمایش
Product detail success در Cohort	کمتر از Baseline توافق‌شده نشود
p95 Product detail latency	از Safety threshold توافق‌شده عبور نکند
Add-to-cart availability	دکمه و API برای همه Accountهای آزمایش قابل استفاده باشد
Fallback	بخش پیشنهاد پنهان/جایگزین شود؛ Error خام دیده نشود
Safety invariant	Checkout، Price و Inventory effect تغییر نکند
Recovery	پس از حذف Fault در Window توافق‌شده به Baseline برگردد

عددها باید از SLO و Baseline واقعی تیم بیایند؛ نسخه آماده جهانی وجود ندارد.

Hypothesis

اگر برای Accountهای داخلی Tagشده، ۵۰٪ پاسخ‌های Recommendation سه دقیقه ۵۰۳ شوند، Product Detail و Add-to-cart Steady State خود را حفظ می‌کنند، Fallback کنترل‌شده دیده می‌شود، Retry storm ایجاد نمی‌شود و پس از حذف Fault در دو دقیقه Metricها به Baseline برمی‌گردند.

Blast Radius

فقط پنج Account داخلی؛
یک Region و یک Product collection؛
سه دقیقه با TTL خودکار؛
فقط Route Recommendation؛
عدم درگیری Checkout، Payment و کاربران عادی.

Stop Conditions

هر Request بدون Experiment tag تحت Fault قرار گیرد؛
Product Detail error از Safety threshold عبور کند؛
Add-to-cart یا Checkout control افت کند؛
Retry volume از سقف تعیین‌شده عبور کند؛
Telemetry Experiment قطع شود؛
On-call دستور Abort دهد.

شواهد

Timeline دقیق، Config Fault، فهرست Target، Control/Experiment dashboard، Traceهای پاک‌سازی‌شده، Screenshot Fallback، Alarm/Stop state و Recovery window ثبت شوند. نام/شماره تماس/Token کاربر نباید وارد Report شود.

مثال پرریسک‌تر: Timeout درگاه پرداخت

این آزمایش را ابتدا فقط در Pre-production با Gateway Sandbox و تراکنش مصنوعی اجرا کنید:

Latency بعد از پذیرش درخواست ولی پیش از پاسخ تزریق شود؛
Client Retry با همان Idempotency key انجام شود؛
Order به Pending قابل پیگیری برود؛
callback تکراری فقط یک Ledger effect بسازد؛
Reconciliation پس از رفع Fault State را قطعی کند؛
هیچ درخواست به درگاه واقعی یا پیامک مشتری نرود.

Contract، Idempotency و پاسخ خطا را با راهنمای تست API و تعامل Outbox/Queue را با راهنمای تست یکپارچه‌سازی تکمیل کنید.

دسته‌های Fault و Guardrail هرکدام

Process/Instance

Termination، pause یا restart. Guardrail: Replica حداقل، Target tag، PodDisruption/health check و recovery ظرفیت.

Network

Latency، loss، reset، partition و DNS failure. Guardrail: Route/port دقیق، TTL، Control plane مستقل و عدم درگیری Management/kill path.

Dependency response

5xx، malformed response، slow response یا quota. Guardrail: Sandbox/Proxy، Contract-valid variants و عدم جعل پاسخ طرف ثالث در Production بدون اجازه.

Resource pressure

CPU، Memory، Disk I/O یا file descriptor. Guardrail: Limit سخت، Target منفرد، حفظ ظرفیت Control و Stop روی Host health.

Queue/Event

Delay، duplicate، reorder، consumer pause. Guardrail: Namespace تست، ID مصنوعی، Side-effect invariant و Re-drive/cleanup.

Data/Storage

Failover، read-only، slow disk یا restore. Guardrail: Copy، Backup/PITR تأییدشده، Scope غیرمشتری و مجوز ویژه برای هر Corruption.

Configuration/Credential

Feature flag، certificate expiry یا permission deny. Guardrail: Clock/credential مصنوعی، auto-expiry، least privilege و جلوگیری از قطع مسیر مدیریت.

GameDay را چگونه اجرا کنیم؟

نقش‌ها

Experiment lead: Hypothesis و Gateها؛
Operator: شروع/Cancel Fault؛
Safety officer: اختیار مستقل Stop؛
Observer/Scribe: Timeline و Evidence؛
Service owner/On-call: Diagnosis و Recovery؛
Incident commander: اگر وضعیت از آزمایش به Incident تبدیل شد؛
Stakeholder/Support: برای اثر احتمالی کاربر یا ارتباطات.

Timeline

Pre-brief و تأیید Scope؛
Baseline health check؛
Dry-run Target selection و Kill switch؛
اعلام شروع و ایجاد Marker زمانی؛
Fault با کمترین شدت؛
مشاهده Control/Experiment و Stop conditions؛
Cancel/TTL و Recovery؛
Post-check و Cleanup؛
Debrief بدون سرزنش؛
Remediation، Owner، Due date و Retest.

Tool را بر اساس Guardrail انتخاب کنید

دسته	مزیت	ریسک/مسئولیت
Cloud-managed fault service	Integration با Resource/IAM/Alarm و Audit	Cloud lock-in، permission scope و قیمت
Kubernetes chaos operator	Target/Workflow بومی Cluster	CRD/Controller privilege، multi-tenant blast radius
Service mesh/proxy	Latency/error در Route دقیق	فقط بخشی از Failure واقعی را بازنمایی می‌کند
Application-level hooks	Fault دامنه‌ای و State دقیق	Backdoor، Production exposure و coupling
Agent/host tool	CPU/Memory/Process/Network واقع‌گرایانه	Privilege بالا و Host impact
Script دستی	Pilot سریع و شفاف	ضعف Guardrail، Audit، idempotent rollback و تکرارپذیری

معیار PoC

Target preview و selector fail-closed؛
TTL، automatic stop و manual cancel؛
Least-privilege identity و Audit log؛
Dry-run و Experiment template versioning؛
Control/Experiment tagging؛
Rollback/cleanup تکرارپذیر؛
Observability integration و Evidence export؛
Multi-step/parallel fault با محدودیت روشن؛
هزینه، License، پشتیبانی و خروج از Vendor؛
اتصال، پرداخت و دسترسی تیم ایران؛
Data residency و عدم ذخیره Secret در پارامترها.

مستندات فعلی Azure Chaos Studio نمونه‌ای از مدل Workspace/Scenario و Experiment با Target/Action است؛ AWS FIS نیز Stop alarm دارد. این‌ها مثال قابلیت‌اند، نه توصیه خودکار برای معماری شما.

Chaos Monkey را درست جای‌گذاری کنیم

Chaos Monkey نقش تاریخی مهمی در رایج‌شدن Termination تصادفی Instance دارد. مخزن رسمی Netflix Chaos Monkey نیز آن را ابزار تحمل خرابی تصادفی Instance معرفی می‌کند و نسخه موجود به Spinnaker وابسته است. نام مشهور ابزار نباید انتخاب پیش‌فرض شود؛ Target، Platform، Guardrail و نگهداری فعلی را بررسی کنید.

اتوماسیون؛ چه زمانی و چگونه؟

آزمایش دستیِ تازه، پرریسک یا با Hypothesis در حال تغییر را زود Continuous نکنید. Gateهای Automation:

حداقل چند اجرای کنترل‌شده و Retest موفق؛
Stop/rollback مستقل و خودکار؛
Selector دقیق و fail-closed؛
Baseline health check؛
عدم اجرای هم‌زمان با Deploy/Incident/Change ممنوع؛
Owner و Notification فعال؛
Budget ترافیک/زمان/هزینه؛
Evidence و cleanup خودکار؛
بازبینی دوره‌ای Hypothesis و Target drift.

Safe scheduling

Continuous به معنی دائماً و بدون ناظر نیست. Maintenance window، Business calendar ایران، کمپین، پایان ماه مالی، تسویه، Deploy و ظرفیت On-call را لحاظ کنید.

تحلیل نتیجه

فرضیه رد شد

این Failure برنامه Chaos نیست؛ یک یافته است. رفتار کاربر، علت فنی، ضعف Detection/Recovery و Guardrail را جدا کنید. Remediation باید Owner، Deadline و Retest داشته باشد.

فرضیه رد نشد

فقط برای Fault، شدت، Scope، Build و Window آزموده‌شده Confidence بیشتری داریم. نمی‌توان نتیجه را به همه Failureها یا «سیستم همیشه تاب‌آور است» تعمیم داد.

آزمایش Inconclusive

Traffic ناکافی، Telemetry ناقص، Control آلوده، Fault اعمال‌نشده یا Incident هم‌زمان نتیجه را نامعتبر می‌کند. آن را Pass ننامید؛ Test design/Observability را اصلاح کنید.

Guardrail زود Stop کرد

بررسی کنید Stop یک کشف واقعی، Threshold حساس یا نویز بوده است. خود عملکرد Stop condition نیز یک Result ارزشمند است.

گزارش آزمایش آشوب

بخش	محتوا
Context	Build، Config، Traffic، Environment و Change window
Hypothesis	متن نسخه‌دار و معیار رد
Fault	Target، selector، شدت، duration و Tool version
Safety	Blast radius، stop، kill، permission و third-party scope
Evidence	Control/Experiment before-during-after، Timeline و Artifact
Outcome	Supported، disproved یا inconclusive
Learning	System، observability، process و people gaps
Action	Owner، due date، priority و retest

گزارش باید Evidence لازم را داشته باشد و Token، PII، داده پرداخت و Credential را حذف کند.

معیارهای بلوغ برنامه Chaos

فرضیه‌های اجراشده به تفکیک Risk، نه صرفاً تعداد Experiment؛
نسبت disproved/supported/inconclusive با تفسیر؛
زمان از Finding تا Remediation و Retest؛
زمان Detection، Mitigation و Recovery در Scope آزمون؛
Stop conditionهای Triggerشده و زمان توقف؛
آزمایش‌های متوقف‌شده در Readiness gate؛
Blast-radius escape یا Target خارج Scope؛
Observability gapهای کشف و رفع‌شده؛
Remediationهای بدون Owner/Deadline؛
Hypothesisهای منقضی پس از Architecture change؛
Incidentهای Production که Failure mode آن‌ها قبلاً/بعداً آزمایش شده؛
Customer harm و Safety incident—هدف باید صفر و هر مورد نیازمند Review ویژه باشد.

کاهش Incident ممکن است هم‌زمان با ده‌ها تغییر دیگر رخ دهد؛ آن را بدون طراحی تحلیلی به Chaos نسبت ندهید. تعداد Failure تزریق‌شده KPI موفقیت نیست.

برنامه ۳۰/۶۰/۹۰ روزه

روز ۱ تا ۳۰: آمادگی

یک Journey و Dependency کم‌ریسک انتخاب کنید؛
Steady State و Dashboard Control/Experiment بسازید؛
RBAC، Target tags، Stop و Kill را آماده کنید؛
Experiment template و RoE را Review کنید؛
اولین اجرا را در محیط ایزوله انجام دهید.

روز ۳۱ تا ۶۰: GameDay و Remediation

همان Hypothesis را در Staging واقع‌گرایانه اجرا کنید؛
Fault severity و Recovery را مرحله‌ای گسترش دهید؛
GameDay با Safety officer برگزار کنید؛
Gapهای System/Telemetry/Runbook را رفع و Retest کنید؛
PoC ابزار را با هزینه و Guardrail بسنجید.

روز ۶۱ تا ۹۰: Canary و Automation محدود

فقط با Gate و Approval، Cohort داخلی Production را بررسی کنید؛
Experiment کم‌ریسکِ پایدار را زمان‌بندی محدود کنید؛
Architecture/Incident جدید را به Hypothesis backlog تبدیل کنید؛
Metricهای Learning و Remediation را مرور کنید؛
Scope گسترش یا توقف را با شواهد تصمیم بگیرید.

اشتباه‌های رایج

کشتن تصادفی Resource بدون Hypothesis و Control؛
تعریف Steady State فقط با CPU/Memory؛
نداشتن Safety invariant برای پول و داده؛
شروع مستقیم از Production یا پرداخت واقعی؛
اجرای آزمایش هنگام Incident، Deploy یا Peak؛
Selector گسترده یا fallback به همه Targetها؛
Kill switch روی همان مسیر آسیب‌پذیر؛
Stop دستی بدون Alarm خودکار؛
Cancel کردن Fault و ندیدن Recovery/Backlog؛
Fault injection به طرف ثالث بدون مجوز؛
نوشتن Secret یا PII در Experiment parameter/report؛
دادن دسترسی Contributor گسترده به Tool؛
انتخاب Tool مشهور پیش از تعریف سؤال و Guardrail؛
خودکارسازی Experiment تازه یا Inconclusive؛
Pass نامیدن نبود Traffic یا Fault اعمال‌نشده؛
تعمیم یک نتیجه به همه Failureها و نسخه‌ها؛
شمردن Experiment به‌جای Learning/Remediation؛
اتکا به Chaos به‌جای Integration، Performance، Security و DR test؛
GameDay نمایشی بدون Owner و Retest؛
سرزنش فرد به‌جای اصلاح سیستم و Guardrail.

چک‌لیست Chaos Experiment امن

Risk، سؤال یادگیری و دلیل انتخاب Fault روشن است.
Steady State کاربرمحور، فنی و Safety invariant دارد.
Hypothesis قابل رد و Control/Experiment قابل تفکیک‌اند.
Target preview، selector fail-closed و Cohort دقیق داریم.
شدت، Duration، TTL و Blast Radius محدودند.
Baseline سالم و Incident/Deploy/Peak فعال نیست.
Owner، Approver، Operator، Safety و On-call حاضرند.
Permission کمینه، Audit و Target onboarding کنترل شده‌اند.
Automatic stop، manual kill و Recovery تمرین شده‌اند.
Control plane و Kill path تحت همان Fault نیستند.
طرف ثالث، پول، داده و PII خارج Scope/محافظت‌شده‌اند.
Evidence before/during/after و Timeline ثبت می‌شود.
نتیجه supported/disproved/inconclusive طبقه‌بندی می‌شود.
Remediation، Owner، Deadline و Retest تعریف شده‌اند.
Automation فقط پس از اجرای پایدار و Gate دوره‌ای فعال می‌شود.

پرسش‌های متداول

آیا Chaos Engineering باید حتماً در Production اجرا شود؟

خیر. Production نمایندگی بیشتری از Traffic و Dependency دارد، اما اختیار، ریسک و الزامات قانونی تعیین‌کننده‌اند. با محیط ایزوله شروع کنید و فقط پس از Readiness، Stop/Recovery و Approval به Canary محدود Production بروید. گاهی Production هرگز انتخاب قابل قبول نیست.

تفاوت Fault Injection و Chaos Engineering چیست؟

Fault injection روش ایجاد Latency، Error، Crash یا Resource pressure است. Chaos Engineering آن را داخل یک آزمایش با Steady State، Hypothesis، Control، Blast radius، Stop condition، Evidence و Learning loop قرار می‌دهد.

اولین Chaos Experiment چه باشد؟

یک Dependency غیرحیاتی با Fallback روشن و Blast Radius کوچک انتخاب کنید؛ مانند Recommendation برای Accountهای داخلی. Payment، Data corruption، Region failure و سرویس ثالث واقعی برای اولین آزمایش مناسب نیستند.

اگر Stop Condition فعال شد، آزمایش شکست خورده است؟

ابتدا Fault را متوقف و Recovery را Verify کنید. سپس مشخص کنید Threshold یک ضعف واقعی، نویز یا تنظیم حساس بوده است. Outcome ممکن است Hypothesis disproved یا Experiment inconclusive باشد؛ عملکرد درست Stop condition خود یک کنترل موفق است.

آیا ابزار Chaos به‌تنهایی تاب‌آوری را افزایش می‌دهد؟

خیر. ابزار فقط Target و Fault را Orchestrate می‌کند. تاب‌آوری با فرضیه درست، Guardrail، مشاهده، Remediation و Retest بهتر می‌شود. Experiment بدون اصلاح ضعف، صرفاً همان مشکل را تکرار می‌کند.

جمع‌بندی

مهندسی آشوب برنامه‌ای برای شکستن سیستم نیست؛ روش تجربی برای شکستن فرض‌های غلط با کمترین خطر است. Steady State را از نگاه کاربر تعریف کنید، Control و Experiment بسازید، Fault واقعی را روی Target محدود اعمال کنید و پیش از شروع Stop، Kill و Recovery را آماده داشته باشید. Production فقط یکی از پله‌های بلوغ است و هرگز مجوز آسیب به کاربر یا داده نیست. ارزش نهایی نیز در تعداد Faultها نیست؛ در ضعف کشف‌شده، Remediation انجام‌شده و شواهدی است که نشان می‌دهد یک Failure مشخص در یک Scope مشخص دیگر به همان شکل Steady State را مختل نمی‌کند.

تست نرم افزار, سطوح تست

مهندسی آشوب چیست؟ طراحی Chaos Experiment امن