Skip to main content

chaos-engineering

Discipline of experimenting on systems to build confidence in their capability to withstand turbulent conditions

Source facts

Repository
ffsshhttiikk/opencode-agents-skills
Last source activity
February 28, 2026 at 22:49
Detected SKILL.md language
English
Stars
3
Forks
2

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
chaos-engineering
description
Discipline of experimenting on systems to build confidence in their capability to withstand turbulent conditions
category
devops
# Chaos Engineering ## What I Do I enable teams to proactively test system resilience by introducing controlled failures. I help discover weaknesses before they cause outages, building confidence in system behavior under adverse conditions. ## When to Use Me - Validating system reliability before production - Testing disaster recovery procedures - Building confidence in microservices architectures - Meeting resilience SLAs/SLOs - Improving incident response procedures - Validating auto-scaling and failover - Regular resilience testing schedules ## Core Concepts - **Chaos Experiments**: Controlled tests that inject failures - **Blast Radius**: Impact scope of the experiment - **Hypothesis**: What you expect to happen during the experiment - **Steady State**: Normal operational behavior baseline - **Abort Conditions**: When to stop the experiment - **MTTR**: Mean time to recovery measurement - **Experiment Runner**: Tools like Chaos Toolkit, Gremlin - **Observability Integration**: Metrics during experiments - **Scope Limiting**: Containing impact to safe boundaries - **Continuous Chaos**: Regular, automated experiments ## Code Examples **Chaos Toolkit Experiment (YCL):** ```yaml title: "Verify database failover works correctly" description: | This experiment verifies that our PostgreSQL cluster can handle primary database failure method: - type: action name: stop_database_primary provider: type: python module: chaosk8s.actions func: kill_pod parameters: label_selector: app=postgresql namespace: database mode: all grace_period: 0 - type: probe name: check_database_reachable provider: type: python module: chaospostgres.probes func: query parameters: query: "SELECT 1" timeout: 10 - type: probe name: verify_write_operations provider: type: python module: chaospostgres.probes func: query parameters: query: "INSERT INTO health_check (timestamp) VALUES (NOW()) RETURNING id" - type: probe name: measure_recovery_time type: timer provider: type: python module: chaosk8s.probes func: deployment_available_replicas parameters: name: postgresql namespace: database steady-state-hypothesis: title: "Database is operational" probes: - type: probe name: database_responsive provider: type: python module: chaospostgres.probes func: query parameters: query: "SELECT version()" rollbacks: - type: action name: restart_database provider: type: python module: chaosk8s.actions func: apply_file parameters: file: config/manifests/postgresql.yaml ``` **LitmusChaos Experiment (YAML):** ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: nginx-chaos namespace: litmus spec: appinfo: appns: default applabel: "app=nginx" appkind: deployment chaosServiceAccount: litmus-admin experiments: - name: pod-delete spec: components: env: - name: TOTAL_CHAOS_DURATION value: '30' - name: CHAOS_INTERVAL value: '10' - name: FORCE value: 'false' - name: PODS_AFFECTED_PERC value: '50' definition: lsecos: - name: pod-delete type: nginx-chaos kind: ChaosEngine --- apiVersion: litmuschaos.io/v1alpha1 kind: ChaosEngine metadata: name: network-chaos spec: appinfo: appns: default applabel: "app=api" appkind: deployment experiments: - name: pod-network-latency spec: components: env: - name: TOTAL_CHAOS_DURATION value: '60' - name: NETWORK_LATENCY value: '2000' - name: JITTER value: '1000' - name: CONTAINER_RUNTIME value: 'docker' - name: SOCKET_PATH value: '/var/run/docker.sock' ``` **Gremlin Chaos Script:** ```python from gremlinapi.probabilistic import ProbabilisticAttack from gremlinapi.targets import GremlinTargetedAttack, ContainerTarget from gremlinapi.attack_importer import attach_chaos_script # Resource attack - CPU stress def cpu_stress_attack(): attack = GremlinTargetedAttack() attack.target( ContainerTarget( name="nginx", labels={"app": "web"} ) ) attack.resource( cpu={ "type": "cpu", "mode": "stress", "workers": 4, "duration": 120 } ) return attack.execute() # Network attack - Packet loss def network_loss_attack(): attack = GremlinTargetedAttack() attack.target( ContainerTarget( name="api-service", namespace="production" ) ) attack.network( packet_loss={ "type": "network", "mode": "loss", "percent": 25, "duration": 60, "corrupt": True } ) return attack.execute() # Shutdown attack for failover testing def kill_leader_attack(): attack = GremlinTargetedAttack() attack.target( ContainerTarget( name="postgres", labels={"app": "database", "role": "primary"} ) ) attack.shutdown( timeout=10 ) return attack.execute() # Latency attack for dependency testing def latency_injection(): attack = GremlinTargetedAttack() attack.target( ContainerTarget( name="redis-cache", labels={"app": "cache"} ) ) attack.network( latency={ "type": "network", "mode": "latency", "delay": 2000, "jitter": 500, "duration": 120 } ) return attack.execute() ``` **Kubernetes Chaos Experiment:** ```yaml apiVersion: chaos-mesh.org/v1alpha1 kind: Workflow metadata: name: multi-layer-chaos namespace: chaos-testing spec: entry: serial-chaos templates: - name: serial-chaos templateType: Serial deadline: 30m children: - pod-failure - network-delay - cpu-stress - name: pod-failure templateType: PodChaos podChaos: selector: namespaces: - production labelSelectors: app: api-server mode: one action: pod-kill gracePeriod: 0 - name: network-delay templateType: NetworkChaos networkChaos: selector: namespaces: - production labelSelectors: app: payment-service mode: all action: delay delay: latency: 2000ms jitter: 500ms correlation: "50" direction: both - name: cpu-stress templateType: StressChaos stressChaos: selector: namespaces: - production labelSelectors: app: worker mode: one stressors: cpu: workers: 4 load: 80 ``` ## Best Practices 1. **Start with non-production** - First experiments in staging 2. **Define steady state** - What does normal look like? 3. **Limit blast radius** - Start small, expand gradually 4. **Set abort conditions** - Know when to stop immediately 5. **Have rollback plan** - How to restore normal operations 6. **Measure MTTR** - Track recovery time improvements 7. **Involve on-call teams** - Include SRE in experiments 8. **Automate experiments** - Regular, scheduled chaos 9. **Document findings** - Learn from each experiment 10. **Gradually increase severity** - Build confidence incrementally
View on GitHub