Chaos Engineering چیست؟ تست پایداری سیستم با Chaos Mesh

در سیستم‌های نرم‌افزاری مدرن، «کار کردن سیستم در شرایط عادی» به‌تنهایی تضمین‌کننده پایداری آن نیست. یک Application ممکن است در زمان عادی کاملاً سالم باشد، اما با قطع شدن یک Database، افزایش ناگهانی Latency شبکه، از دسترس خارج شدن یک Node یا افزایش شدید Traffic با مشکل جدی مواجه شود.

اینجاست که Chaos Engineering وارد می‌شود. Chaos Engineering یک رویکرد مهندسی برای آزمایش رفتار سیستم در شرایط غیرعادی و خرابی‌های کنترل‌شده است تا قبل از وقوع Incident واقعی، نقاط ضعف سیستم شناسایی شوند.

در این مقاله بررسی می‌کنیم Chaos Engineering چیست، چه تفاوتی با تست‌های معمول دارد، چگونه در محیط‌های Kubernetes اجرا می‌شود، Chaos Mesh چه نقشی در این فرایند دارد و چگونه می‌توان یک برنامه اصولی برای تست تاب‌آوری و پایداری سیستم طراحی کرد.

Chaos Engineering چیست؟

Chaos Engineering مجموعه‌ای از روش‌ها و آزمایش‌های کنترل‌شده برای بررسی رفتار سیستم در شرایط خرابی و اختلال است.

ایده اصلی ساده است: به جای اینکه منتظر بمانیم یک خرابی واقعی اتفاق بیفتد و سپس متوجه ضعف سیستم شویم، شرایط خرابی را به صورت کنترل‌شده ایجاد می‌کنیم و بررسی می‌کنیم آیا سیستم مطابق انتظار به آن واکنش نشان می‌دهد یا خیر.

برای مثال می‌توان عمداً یکی از موارد زیر را ایجاد کرد:

• قطع ارتباط یک سرویس با Database
• افزایش Latency شبکه
• Packet Loss
• متوقف کردن یک Container
• از دسترس خارج کردن یک Kubernetes Pod
• مصرف شدید CPU یا Memory
• خرابی یا کاهش ظرفیت یک Node
• افزایش ناگهانی Traffic

سپس رفتار سیستم، Alertها، Auto Scaling، Failover و Recovery آن بررسی می‌شود.

هدف Chaos Engineering چیست؟

هدف Chaos Engineering خراب کردن سیستم نیست؛ هدف آن افزایش اطمینان از توانایی سیستم برای تحمل خرابی و بازیابی از آن است.

در یک سیستم Highly Available، انتظار نداریم هیچ‌وقت Failure اتفاق نیفتد. چنین فرضی در سیستم‌های پیچیده واقع‌بینانه نیست. هدف این است که Failure بتواند بدون ایجاد اختلال جدی در سرویس، مدیریت شود.

Chaos Engineering به تیم کمک می‌کند به جای فرض کردن اینکه سیستم مقاوم است، این مقاومت را با آزمایش واقعی بررسی کند.

Chaos Engineering چه مشکلی را حل می‌کند؟

یکی از مشکلات رایج در Infrastructure این است که معماری روی کاغذ Highly Available به نظر می‌رسد، اما در عمل رفتار مورد انتظار را ندارد.

برای مثال ممکن است معماری شامل دو Application Server باشد و تصور کنیم در صورت خرابی یکی از آن‌ها، Server دیگر سرویس را ادامه می‌دهد. اما یک آزمایش کنترل‌شده می‌تواند نشان دهد که:

• Load Balancer هنوز درخواست‌ها را به Server خراب ارسال می‌کند.
• Health Check درست تنظیم نشده است.
• Sessionها روی یک Instance خاص نگهداری می‌شوند.
• Database به صورت Single Point of Failure طراحی شده است.
• Alert مربوط به Failure ارسال نمی‌شود.
• Recovery زمان زیادی طول می‌کشد.

Chaos Engineering این فرضیات را به سؤال‌های قابل آزمایش تبدیل می‌کند.

Chaos Engineering در برابر تست معمولی

تست‌های نرم‌افزاری معمولاً بررسی می‌کنند Application در شرایط مشخص، خروجی مورد انتظار را تولید می‌کند یا خیر. Chaos Engineering سؤال متفاوتی مطرح می‌کند:

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

این تست‌ها جایگزین یکدیگر نیستند. یک سیستم Mature معمولاً به ترکیبی از همه این روش‌ها نیاز دارد.

Chaos Engineering و Resilience چه ارتباطی دارند؟

Resilience به توانایی سیستم برای ادامه عملکرد مناسب در شرایط Failure و بازگشت به وضعیت عادی پس از اختلال اشاره دارد.

Chaos Engineering یکی از روش‌های مهم برای اندازه‌گیری و بهبود Resilience است.

برای مثال اگر سیستم شما دارای:

• Redundancy
• Automatic Failover
• Health Check
• Auto Scaling
• Retry
• Circuit Breaker
• Backup
• Disaster Recovery

باشد، Chaos Engineering کمک می‌کند بررسی کنید این مکانیزم‌ها در شرایط واقعی Failure واقعاً درست کار می‌کنند یا فقط در طراحی وجود دارند.

اصول اصلی Chaos Engineering

اجرای Chaos Engineering نباید به شکل تصادفی و بدون هدف انجام شود. یک آزمایش حرفه‌ای باید Hypothesis مشخص داشته باشد.

1. تعریف وضعیت عادی سیستم

قبل از ایجاد Failure باید بدانیم سیستم در حالت سالم چه رفتاری دارد.

برای مثال:

• نرخ خطا کمتر از مقدار مشخصی است.
• Latency در محدوده مشخصی قرار دارد.
• CPU و Memory در محدوده قابل قبول هستند.
• تعداد Requestهای موفق ثابت است.

این وضعیت مبنای مقایسه آزمایش خواهد بود.

2. تعریف Hypothesis

باید مشخص کنیم انتظار داریم سیستم پس از Failure چه رفتاری داشته باشد.

برای مثال:

اگر یکی از Kubernetes Podهای سرویس پرداخت از دسترس خارج شود، Kubernetes باید Pod جدید ایجاد کند و کاربران نباید اختلال قابل توجهی مشاهده کنند.

3. ایجاد Failure کنترل‌شده

در این مرحله Failure موردنظر ایجاد می‌شود. این کار باید با Scope مشخص و در محیط کنترل‌شده انجام شود.

4. مشاهده رفتار سیستم

در زمان آزمایش باید Metrics، Logs، Traces و وضعیت سرویس‌ها بررسی شوند.

استفاده از ابزارهای Monitoring و Log Management در این مرحله اهمیت بسیار زیادی دارد.

5. بررسی نتیجه

پس از پایان آزمایش باید مشخص شود آیا Hypothesis اولیه درست بوده است یا خیر.

6. بهبود سیستم

اگر Failure باعث اختلال شده باشد، باید Root Cause مشخص و Architecture یا Configuration اصلاح شود.

انواع آزمایش‌های Chaos Engineering

Chaos Experimentها می‌توانند بخش‌های مختلف Infrastructure و Application را هدف قرار دهند.

Network Chaos

در این آزمایش‌ها رفتار شبکه دستکاری می‌شود؛ برای مثال:

• افزایش Latency
• Packet Loss
• قطع ارتباط
• Network Partition
• Bandwidth محدود

این آزمایش‌ها برای سیستم‌های Microservices اهمیت زیادی دارند؛ زیرا بسیاری از Failureها در محیط Distributed به دلیل مشکلات Network رخ می‌دهند.

Pod و Container Failure

در Kubernetes می‌توان یک Pod را عمداً حذف کرد تا مشخص شود آیا Deployment، ReplicaSet یا سایر مکانیزم‌های Kubernetes می‌توانند سرویس را به وضعیت سالم برگردانند.

CPU و Memory Stress

در این سناریو منابع سیستم عمداً تحت فشار قرار می‌گیرند تا رفتار Application و Kubernetes بررسی شود.

Node Failure

در Clusterهای Kubernetes می‌توان سناریوهایی را برای بررسی رفتار سیستم هنگام از دست رفتن یک Node طراحی کرد.

Application Failure

در این مدل رفتار خود Application تحت شرایط غیرعادی بررسی می‌شود؛ برای مثال افزایش Error Rate یا ایجاد Dependency Failure.

Chaos Engineering در Kubernetes

Kubernetes به دلیل ماهیت Distributed و امکاناتی مانند Self-Healing، Scaling و Scheduling، محیط بسیار مناسبی برای اجرای Chaos Experimentها است.

فرض کنید یک Application سه Replica دارد:

                 Load Balancer
                       |
             +---------+---------+
             |         |         |
           Pod A     Pod B     Pod C
             |         |         |
             +---------+---------+
                       |
                    Database

اگر Pod A را عمداً حذف کنیم، انتظار داریم Kubernetes یک Replica جدید ایجاد کند.

اما صرفاً ایجاد Pod جدید کافی نیست. باید بررسی کنیم:

• آیا کاربران واقعاً بدون اختلال به سرویس دسترسی دارند؟
• آیا Load Balancer Pod خراب را از Pool خارج می‌کند؟
• آیا Health Check درست عمل می‌کند؟
• آیا Requestها در زمان Recovery با Error مواجه می‌شوند؟
• آیا زمان Recovery قابل قبول است؟
• آیا Alert مناسب ایجاد شده است؟

این دقیقاً جایی است که Chaos Engineering از یک «حذف ساده Pod» فراتر می‌رود و به یک تست واقعی Resilience تبدیل می‌شود.

Chaos Mesh چیست؟

Chaos Mesh یک پلتفرم Open Source برای Chaos Engineering است که به‌طور ویژه برای محیط‌های Kubernetes طراحی شده است.

Chaos Mesh امکان ایجاد انواع مختلف Failure و Stress را در Cluster فراهم می‌کند و به تیم‌های Infrastructure و DevOps اجازه می‌دهد Chaos Experimentها را به شکل کنترل‌شده تعریف و اجرا کنند.

یکی از ویژگی‌های مهم Chaos Mesh، استفاده از مدل Kubernetes-native است؛ بنابراین Experimentها می‌توانند مانند سایر منابع Kubernetes مدیریت و Version Control شوند.

Chaos Mesh چه آزمایش‌هایی را انجام می‌دهد؟

Chaos Mesh طیف متنوعی از Chaos Experimentها را ارائه می‌کند که بسته به نسخه و معماری مورد استفاده می‌توانند شامل موارد زیر باشند:

• Pod Failure
• Network Delay
• Network Loss
• Network Partition
• CPU Stress
• Memory Stress
• Disk Stress
• Process Failure
• Container Failure
• DNS Failure
• HTTP Fault Injection

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

یک نمونه Chaos Experiment با Chaos Mesh

فرض کنید می‌خواهیم بررسی کنیم حذف یک Pod چه تأثیری روی سرویس دارد.

یک Experiment ساده می‌تواند مفهومی مشابه زیر داشته باشد:

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-failure
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment

این مثال یک Pod از Application موردنظر را هدف قرار می‌دهد تا رفتار سیستم هنگام از دست رفتن آن بررسی شود.

در محیط Production نباید صرفاً با کپی کردن چنین Configurationهایی Experiment اجرا کرد. Scope، زمان اجرا، معیارهای موفقیت، Rollback و مجوزهای عملیاتی باید از قبل مشخص شده باشند.

Chaos Mesh در برابر ابزارهای دیگر

Chaos Mesh تنها ابزار موجود برای Chaos Engineering نیست و انتخاب ابزار باید بر اساس معماری سازمان انجام شود.

برای محیط‌های Kubernetes، Chaos Mesh و LitmusChaos از گزینه‌های مهم Open Source هستند. انتخاب بین آن‌ها باید بر اساس نیازمندی‌های سازمان، نوع Experimentها، Integrationها و مدل عملیاتی انجام شود.

Chaos Mesh یا LitmusChaos؟

هر دو ابزار برای اجرای Chaos Engineering در Kubernetes طراحی شده‌اند، اما تجربه کاربری، معماری، قابلیت‌ها و Ecosystem آن‌ها متفاوت است.

اگر هدف شما ایجاد Experimentهای Kubernetes-native و Integration مناسب با محیط Kubernetes باشد، Chaos Mesh می‌تواند انتخاب بسیار خوبی باشد.

در مقابل، اگر به Ecosystem گسترده‌تر Chaos Experimentها، Automation و برخی قابلیت‌های خاص نیاز دارید، LitmusChaos نیز ارزش بررسی دارد.

در نهایت «بهترین ابزار» به معماری و نیازهای سازمان بستگی دارد؛ انتخاب ابزار بدون تعریف Use Case معمولاً نتیجه مطلوبی ندارد.

Chaos Engineering و Observability

Chaos Engineering بدون Observability عملاً بخش بزرگی از ارزش خود را از دست می‌دهد.

فرض کنید یک Pod را حذف کرده‌ایم. تنها دانستن اینکه Pod جدید ساخته شده کافی نیست. باید بتوانیم اثر این Failure را در کل سیستم مشاهده کنیم.

برای این کار معمولاً سه سیگنال اصلی اهمیت دارند:

• Metrics: مانند CPU، Memory، Request Rate و Error Rate
• Logs: برای مشاهده خطاها و رفتار Application
• Traces: برای دنبال کردن Request در معماری‌های Distributed

به همین دلیل Chaos Engineering ارتباط بسیار نزدیکی با Observability دارد.

برای اجرای تست‌های حرفه‌ای، زیرساخت Monitoring و Observability باید قبل از اجرای Chaos Experiment آماده باشد.

Chaos Engineering و SRE

Chaos Engineering با فلسفه Site Reliability Engineering (SRE) نیز ارتباط نزدیکی دارد.

SRE تلاش می‌کند Reliability سیستم را با معیارهای قابل اندازه‌گیری مدیریت کند و Chaos Engineering یکی از روش‌هایی است که می‌تواند فرضیات مربوط به Reliability را در شرایط واقعی‌تر آزمایش کند.

برای مثال اگر برای یک سرویس SLO مشخصی تعریف شده باشد، می‌توان Chaos Experiment طراحی کرد و بررسی کرد آیا در هنگام Failure همچنان SLO موردنظر حفظ می‌شود یا خیر.

به همین دلیل Chaos Engineering را می‌توان بخشی از یک برنامه جامع خدمات SRE و Reliability Engineering دانست.

آیا Chaos Engineering همان Stress Test است؟

خیر. این دو روش ممکن است در برخی نقاط با یکدیگر همپوشانی داشته باشند، اما هدف یکسانی ندارند.

Stress Test معمولاً بررسی می‌کند سیستم در برابر افزایش فشار و بار تا چه حد مقاومت می‌کند.

Chaos Engineering دامنه وسیع‌تری دارد و می‌تواند Failureهایی مانند Network Partition، حذف Node، قطع Dependency یا خرابی سرویس را نیز آزمایش کند.

برای مثال:

• افزایش تعداد کاربران → Load/Stress Test
• قطع یک Database Replica → Chaos Experiment
• افزایش Latency شبکه → Chaos Experiment
• حذف Pod → Chaos Experiment

البته می‌توان این آزمایش‌ها را با یکدیگر ترکیب کرد و سناریوهای پیچیده‌تری ساخت.

Chaos Engineering در محیط Production

یکی از سؤالات مهم این است که آیا باید Chaos Engineering را در Production اجرا کرد یا خیر.

پاسخ وابسته به بلوغ سازمان و میزان کنترل روی Experiment است.

اجرای Chaos در Production می‌تواند ارزش زیادی داشته باشد؛ زیرا Production تنها محیطی است که تمام شرایط واقعی Traffic، Dependencyها و رفتار کاربران را دارد.

اما این کار بدون کنترل مناسب خطرناک است.

برای شروع بهتر است:

1. Experimentها ابتدا در محیط Development یا Staging اجرا شوند.
2. Scope آزمایش بسیار محدود باشد.
3. یک Hypothesis مشخص تعریف شود.
4. Monitoring و Alerting قبل از Experiment بررسی شوند.
5. راهکار توقف سریع Experiment وجود داشته باشد.
6. در ابتدا Failureهای کم‌ریسک انتخاب شوند.
7. پس از اثبات کنترل‌پذیری، دامنه آزمایش به تدریج افزایش پیدا کند.

Best Practiceهای Chaos Engineering

از آزمایش‌های کوچک شروع کنید

اولین Experiment نباید قطع همزمان چند سرویس حیاتی باشد. یک Pod، یک Service یا یک Dependency مشخص را هدف قرار دهید.

قبل از Experiment، معیار موفقیت تعریف کنید

اگر ندانیم موفقیت چه معنایی دارد، نتیجه آزمایش قابل اندازه‌گیری نخواهد بود.

Production را بدون Guardrail آزمایش نکنید

برای Experimentهای Production باید محدودیت زمانی، Scope، دسترسی و شرایط توقف تعریف شود.

Chaos را با Monitoring ترکیب کنید

تمام Experimentها باید با Metrics، Logs و Traces قابل مشاهده باشند.

نتایج را مستند کنید

هر Experiment باید شامل Hypothesis، زمان اجرا، Scope، نتیجه، Failureهای مشاهده‌شده و اقدامات اصلاحی باشد.

Experimentها را تکرار کنید

اصلاح یک مشکل به معنی پایان Chaos Engineering نیست. پس از اصلاح Architecture باید همان سناریو مجدداً اجرا شود تا مشخص شود مشکل واقعاً برطرف شده است.

چک‌لیست اجرای یک Chaos Experiment

اشتباهات رایج در Chaos Engineering

خراب کردن سیستم بدون Hypothesis

Chaos Engineering به معنی ایجاد خرابی تصادفی نیست. هر Experiment باید یک سؤال مشخص را پاسخ دهد.

تمرکز صرف روی Kubernetes

ممکن است Kubernetes کاملاً سالم باشد اما Database، Network یا External Dependency نقطه شکست سیستم باشد. بنابراین Chaos باید کل Architecture را در نظر بگیرد.

نادیده گرفتن Business Impact

یک Experiment فنی ممکن است از نظر Infrastructure موفق باشد اما تأثیر قابل توجهی روی Business داشته باشد. معیارهای فنی باید در کنار معیارهای کسب‌وکار بررسی شوند.

نداشتن Observability

اگر ندانیم Failure چه اثری روی سیستم گذاشته، نمی‌توانیم نتیجه Experiment را به درستی تحلیل کنیم.

شروع مستقیم از Production

اجرای Chaos Experimentهای بزرگ روی Production بدون تجربه قبلی و بدون Guardrail می‌تواند خود به Incident تبدیل شود.

Chaos Engineering در معماری‌های High Availability

در معماری‌های High Availability، صرفاً داشتن چند Server یا چند Replica کافی نیست. باید رفتار سیستم در زمان Failure اثبات شود.

برای مثال در یک معماری Database Cluster می‌توان سناریوهایی مانند:

• از دست رفتن یک Node
• افزایش Latency ارتباط بین Nodeها
• قطع ارتباط یک Replica
• افزایش بار روی Primary

را بررسی کرد.

این رویکرد مکمل راهکارهای High Availability و Clustering است؛ زیرا HA بدون Failure Testing ممکن است تنها یک فرض معماری باشد.

Chaos Engineering و Disaster Recovery

Chaos Engineering و Disaster Recovery نیز مکمل یکدیگر هستند.

Backup به تنهایی نشان نمی‌دهد که در زمان بحران می‌توانید سرویس را بازیابی کنید. باید Recovery Process نیز آزمایش شود.

به عنوان مثال می‌توان سناریوهایی طراحی کرد که در آن یک Component اصلی از دسترس خارج شده و بررسی شود آیا سیستم می‌تواند طبق RTO و RPO موردنظر Recovery شود یا خیر.

برای این موضوع، Chaos Engineering می‌تواند در کنار Disaster Recovery و Business Continuity قرار گیرد.

یک برنامه عملی برای شروع Chaos Engineering

اگر سازمان تاکنون Chaos Engineering انجام نداده است، می‌توان فرآیند را مرحله‌ای اجرا کرد:

مرحله اول: شناخت Architecture

Dependencyها، سرویس‌های حیاتی، Single Point of Failure و مسیرهای اصلی درخواست شناسایی شوند.

مرحله دوم: آماده‌سازی Observability

Metrics، Logs، Traces و Alertهای موردنیاز آماده شوند.

مرحله سوم: تعریف SLO و معیارهای موفقیت

مشخص شود در هنگام Failure چه سطحی از Availability و Performance قابل قبول است.

مرحله چهارم: آزمایش Failureهای ساده

برای مثال حذف یک Pod یا ایجاد Latency محدود در شبکه.

مرحله پنجم: اصلاح نقاط ضعف

Failureهای مشاهده‌شده به اقدامات مشخص برای بهبود Architecture تبدیل شوند.

مرحله ششم: افزایش تدریجی پیچیدگی

پس از موفقیت Experimentهای ساده، سناریوهای پیچیده‌تر مانند Node Failure، Network Partition یا Dependency Failure آزمایش شوند.

آیا Chaos Engineering برای همه سازمان‌ها ضروری است؟

نه لزوماً با یک سطح از شدت و پیچیدگی.

برای یک Application کوچک با یک Server، اجرای آزمایش‌های پیچیده Chaos Engineering ممکن است ارزش عملی محدودی داشته باشد. اما هرچه سیستم Distributedتر، حیاتی‌تر و پیچیده‌تر شود، اهمیت این رویکرد افزایش پیدا می‌کند.

به‌خصوص در سازمان‌هایی که از Kubernetes، Microservices، Multi-Cluster، Multi-Data Center و معماری‌های High Availability استفاده می‌کنند، Failure Testing می‌تواند بخش مهمی از برنامه Reliability باشد.

سؤالات متداول درباره Chaos Engineering

Chaos Engineering چیست؟

Chaos Engineering روشی برای آزمایش کنترل‌شده Failureها و بررسی توانایی سیستم برای حفظ سرویس و Recovery در شرایط اختلال است.

آیا Chaos Engineering به معنی خراب کردن Production است؟

خیر. Experiment باید کنترل‌شده، دارای هدف، Scope مشخص و مکانیزم توقف باشد. Production نیز تنها یکی از محیط‌هایی است که می‌توان در آن Chaos Experiment اجرا کرد.

Chaos Mesh چیست؟

Chaos Mesh یک ابزار Open Source و Kubernetes-native برای اجرای Chaos Experiment در محیط‌های Kubernetes است.

آیا Chaos Mesh رایگان است؟

Chaos Mesh یک پروژه Open Source است و می‌توان آن را در محیط‌های تحت کنترل سازمان اجرا کرد. هزینه واقعی پیاده‌سازی به زیرساخت، نگهداری، Monitoring و فرآیندهای عملیاتی بستگی دارد.

Chaos Mesh یا LitmusChaos کدام بهتر است؟

هر دو گزینه‌های قدرتمندی هستند و انتخاب مناسب به Architecture، نوع Experimentها و نیازهای عملیاتی سازمان بستگی دارد. برای انتخاب ابزار، ابتدا Use Caseها و نیازمندی‌ها را مشخص کنید.

آیا Chaos Engineering فقط برای Kubernetes است؟

خیر. Chaos Engineering می‌تواند در سطح Application، Infrastructure، Network، Database و Cloud نیز اجرا شود. Chaos Mesh بیشتر برای محیط‌های Kubernetes طراحی شده است.

آیا Chaos Engineering جایگزین Load Testing است؟

خیر. Load و Stress Testing روی رفتار سیستم تحت بار تمرکز دارند، در حالی که Chaos Engineering بیشتر توانایی سیستم برای تحمل Failure و Recovery را آزمایش می‌کند.

آیا Chaos Engineering بخشی از DevOps است؟

Chaos Engineering می‌تواند یکی از practices مهم در DevOps و SRE باشد و به افزایش Reliability، Resilience و آمادگی سیستم در برابر Failure کمک کند.

جمع‌بندی

Chaos Engineering یک رویکرد عملی برای پاسخ به یکی از مهم‌ترین سؤالات زیرساخت مدرن است: «اگر بخشی از سیستم خراب شود، چه اتفاقی خواهد افتاد؟»

به جای تکیه بر فرضیات، می‌توان Failure را به شکل کنترل‌شده ایجاد کرد و رفتار واقعی سیستم را اندازه‌گیری کرد.

در محیط‌های Kubernetes، ابزارهایی مانند Chaos Mesh امکان اجرای Experimentهایی مانند Pod Failure، Network Delay، Packet Loss و Resource Stress را فراهم می‌کنند.

با این حال، ابزار به‌تنهایی Chaos Engineering ایجاد نمی‌کند. یک برنامه موفق نیازمند Architecture مناسب، Observability، SLO، Hypothesis مشخص، Guardrailهای امنیتی و فرآیند مستندسازی و بهبود مستمر است.

در نهایت، هدف Chaos Engineering «خراب کردن سیستم» نیست؛ هدف این است که سیستم قبل از اینکه یک Failure واقعی کسب‌وکار را غافلگیر کند، خودش آن Failure را تجربه کرده باشد.