菜单
Verify resilience proactively with chaos experiments — a steady-state hypothesis, a controlled fault injection, a blast-radius limit, and a game day — instead of waiting for the real outage. Reach for this to prove (not assume) a system tolerates failure.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/mcorbett51090/RavenClaude --skill chaos-engineering命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Route everyday, well-defined work (single-file edits, test-writing, summarization, mechanical refactors, boilerplate) to a cheaper coding agent (Grok or Copilot CLI) instead of doing it in the main Claude session, escalating multi-file/architecture/debugging/security work to Claude. Opt-in via the `cheap_lane:` comfort-posture knob.
Authors, validates and packages a claude.ai Organization Skill — the intake questions, the trigger and scope exercises, then lint, pack and verify against measured platform constraints. Reach for this when someone wants to publish a Skill to their organization, or when an upload was rejected and the reason is unclear.
Drafts a reply to an inbound customer email, grounded in the account record and the published help-centre articles rather than in recall. Use when a customer emails about billing, a renewal or an outage, when a reply must cite current policy, or when a teammate asks for a first draft to edit.
基于 SOC 职业分类
正在显示 SKILL.md
| name | chaos-engineering |
| description | Verify resilience proactively with chaos experiments — a steady-state hypothesis, a controlled fault injection, a blast-radius limit, and a game day — instead of waiting for the real outage. Reach for this to prove (not assume) a system tolerates failure. |
You don't know a system is resilient until you've broken it on purpose, in a controlled way. Chaos engineering is experimentation to build confidence in a system's behavior under turbulent conditions — the proactive complement to the reactive incident-response practice.
Pick a measurable output that means "the system is healthy" — a business or SLI metric (e.g. checkout success rate, p99 latency), not an internal cause metric. This is what the experiment watches.
State what you believe will happen: "steady state will hold when we inject ." A chaos experiment tests a belief about resilience — if you have no hypothesis, you're just breaking things.
Decide the smallest scope that still tests the hypothesis (one instance, one AZ, a traffic %, a non-peak window), and define the abort conditions up front. Start in staging; earn production. The blast-radius limit is what makes this engineering, not gambling.
Introduce a fault that mimics a real failure mode: instance/pod kill, latency injection, dependency timeout/error, resource exhaustion, network partition, AZ loss. Inject one variable so the result is attributable.
Watch steady state against the hypothesis. If it held, confidence grows. If it broke, you found a resilience gap before a customer did — feed it back as a reliability action item (the same backlog as a postmortem's).
Run the above as a scheduled, cross-team exercise (a "game day"): rehearse a failure scenario end-to-end, exercising both the system's resilience and the team's incident response. A game day is where chaos engineering and the incident-response practice meet.
The resilience patterns being verified (timeouts, retries with backoff, circuit breakers, bulkheads, graceful degradation) are implemented by
backend-engineering; this skill proves they work. Fault-injection automation in the delivery pipeline routes todevops-cicd; cluster-level fault injection tocloud-native-kubernetes. See../../knowledge/chaos-engineering-reference.md.