{"id":"chaos-engineer","name":"chaos-engineer","summary":"カオス実験の設計、失敗注入フレームワークの作成、分散システム向けのゲームデイ演習の促進、ランブック、実験マニフェスト、ロールバック手順、ポストモーテムテンプレートの作成。","body":"# Chaos Engineer\n\n## When to Use This Skill\n\n- Designing and executing chaos experiments\n- Implementing failure injection frameworks (Chaos Monkey, Litmus, etc.)\n- Planning and conducting game day exercises\n- Building blast radius controls and safety mechanisms\n- Setting up continuous chaos testing in CI/CD\n- Improving system resilience based on experiment findings\n\n## Core Workflow\n\n1. **System Analysis** - Map architecture, dependencies, critical paths, and failure modes\n2. **Experiment Design** - Define hypothesis, steady state, blast radius, and safety controls\n3. **Execute Chaos** - Run controlled experiments with monitoring and quick rollback\n4. **Learn & Improve** - Document findings, implement fixes, enhance monitoring\n5. **Automate** - Integrate chaos testing into CI/CD for continuous resilience\n\n## Reference Guide\n\nLoad detailed guidance based on context:\n\n| Topic | Reference | Load When |\n|-------|-----------|-----------|\n| Experiments | `references/experiment-design.md` | Designing hypothesis, blast radius, rollback |\n| Infrastructure | `references/infrastructure-chaos.md` | Server, network, zone, region failures |\n| Kubernetes | `references/kubernetes-chaos.md` | Pod, node, Litmus, chaos mesh experiments |\n| Tools & Automation | `references/chaos-tools.md` | Chaos Monkey, Gremlin, Pumba, CI/CD integration |\n| Game Days | `references/game-days.md` | Planning, executing, learning from game days |\n\n## Safety Checklist\n\nNon-obvious constraints that must be enforced on every experiment:\n\n- **Steady state first** — define and verify baseline metrics before injecting any failure\n- **Blast radius cap** — start with the smallest possible impact scope; expand only after validation\n- **Automated rollback ≤ 30 seconds** — abort path must be scripted and tested before the experiment begins\n- **Single variable** — change only one failure condition at a time until behaviour is well understood\n- **No production without safety nets** — customer-facing environments require circuit breakers, feature flags, or canary isolation\n- **Close the loop** — every experiment must produce a written learning summary and at least one tracked improvement\n\n## Output Templates\n\nWhen implementing chaos engineering, provide:\n1. Experiment design document (hypothesis, metrics, blast radius)\n2. Implementation code (failure injection scripts/manifests)\n3. Monitoring setup and alert configuration\n4. Rollback procedures and safety controls\n5. Learning summary and improvement recommendations\n\n## Concrete Example: Pod Failure Experiment (Litmus Chaos)\n\nThe following shows a complete experiment — from hypothesis to rollback — using Litmus Chaos on Kubernetes.\n\n### Step 1 — Define steady state and apply the experiment\n\n```bash\n# Verify baseline: p99 latency < 200ms, error rate < 0.1%\nkubectl get deploy my-service -n production\nkubectl top pods -n production -l app=my-service\n```\n\n### Step 2 — Create and apply a Litmus ChaosEngine manifest\n\n```yaml\n# chaos-pod-delete.yaml\napiVersion: litmuschaos.io/v1alpha1\nkind: ChaosEngine\nmetadata:\n  name: my-service-pod-delete\n  namespace: production\nspec:\n  appinfo:\n    appns: production\n    applabel: \"app=my-service\"\n    appkind: deployment\n  # Limit blast radius: only 1 replica at a time\n  engineState: active\n  chaosServiceAccount: litmus-admin\n  experiments:\n    - name: pod-delete\n      spec:\n        components:\n          env:\n            - name: TOTAL_CHAOS_DURATION\n              value: \"60\"          # seconds\n            - name: CHAOS_INTERVAL\n              value: \"20\"          # delete one pod every 20s\n            - name: FORCE\n              value: \"false\"\n            - name: PODS_AFFECTED_PERC\n              value: \"33\"          # max 33% of replicas affected\n```\n\n```bash\n# Apply the experiment\nkubectl apply -f chaos-pod-delete.yaml\n\n# Watch experiment status\nkubectl describe chaosengine my-service-pod-delete -n production\nkubectl get chaosresult my-service-pod-delete-pod-delete -n production -w\n```\n\n### Step 3 — Monitor during the experiment\n\n```bash\n# Tail application logs for errors\nkubectl logs -l app=my-service -n production --since=2m -f\n\n# Check ChaosResult verdict when complete\nkubectl get chaosresult my-service-pod-delete-pod-delete \\\n  -n production -o jsonpath='{.status.experimentStatus.verdict}'\n```\n\n### Step 4 — Rollback / abort if steady state is violated\n\n```bash\n# Immediately stop the experiment\nkubectl patch chaosengine my-service-pod-delete \\\n  -n production --type merge -p '{\"spec\":{\"engineState\":\"stop\"}}'\n\n# Confirm all pods are healthy\nkubectl rollout status deployment/my-service -n production\n```\n\n## Concrete Example: Network Latency with toxiproxy\n\n```bash\n# Install toxiproxy CLI\nbrew install toxiproxy   # macOS; use the binary release on Linux\n\n# Start toxiproxy server (runs alongside your service)\ntoxiproxy-server &\n\n# Create a proxy for your downstream dependency\ntoxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy\n\n# Inject 300ms latency with 10% jitter — blast radius: this proxy only\ntoxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30\n\n# Run your load test / observe metrics here ...\n\n# Remove the toxic to restore normal behaviour\ntoxiproxy-cli toxic remove db-proxy -n latency_downstream\n```\n\n## Concrete Example: Chaos Monkey (Spinnaker / standalone)\n\n```bash\n# chaos-monkey-config.yml — restrict to a single ASG\ndeployment:\n  enabled: true\n  regionIndependence: false\nchaos:\n  enabled: true\n  meanTimeBetweenKillsInWorkDays: 2\n  minTimeBetweenKillsInWorkDays: 1\n  grouping: APP           # kill one instance per app, not per cluster\n  exceptions:\n    - account: production\n      region: us-east-1\n      detail: \"*-canary\"  # never kill canary instances\n\n# Apply and trigger a manual kill for testing\nchaos-monkey --app my-service --account staging --dry-run false\n```\n\n[Documentation](https://jeffallan.github.io/claude-skills/skills/devops/chaos-engineer/)","author":"@Jeffallan","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/Jeffallan/claude-skills/tree/main/skills/chaos-engineer","license":"MIT","category":"document","lang":"en","tokens":1381,"stars":0,"calls30d":1,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/chaos-tools.md","size":14217,"sha256":"701f68e6130651ad8045303a236176c905f2cc2caad3a5ffb29dab35ae856a77"},{"path":"references/experiment-design.md","size":7031,"sha256":"308bead232d95dba4d9e27608e20c2d4a6511daa38b7b5fb033753bd1c827d83"},{"path":"references/game-days.md","size":12355,"sha256":"7a19400b365b68bd6d69255d34ebe6ce733f97b87a5d7d168a83744acd652bde"},{"path":"references/infrastructure-chaos.md","size":10035,"sha256":"26580545f0509baa464829b2ad1a7cf53408df19c6d50015fa23ec32464f29f2"},{"path":"references/kubernetes-chaos.md","size":10785,"sha256":"2b8ae4817420a156ecbe337709336762e3d0b68d24e539af566118c39264efe6"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[{"code":"injection.bypass","kind":"injection","where":"references/experiment-design.md:118","excerpt":"without approval","message":"instructs the agent to bypass the human","severity":"warn"}],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":["api.gremlin.com","jeffallan.github.io","litmuschaos.github.io"]}}