> For the complete documentation index, see [llms.txt](https://playbooks.equalexperts.com/chaos-day-playbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://playbooks.equalexperts.com/chaos-day-playbook/complementary-approaches.md).

# Complementary approaches

Chaos Days are one of many tools for improving system resilience.  Others include:

1. [AWS Game Days](https://aws.amazon.com/gameday/).  AWS runs these days to teach design and diagnosis techniques for improving resilience using an AWS-based fake production service.  They are intense and great fun but don’t teach you anything about your own system.
2. Per feature chaos testing.  When a team builds a new feature, they run manual or automated experiments to explore the feature’s impact on system resilience as part of its testing.  This can be a good way to introduce chaos-engineering principles, as well as help teams [shift-left](https://en.wikipedia.org/wiki/Shift-left_testing) operability thinking (i.e., consider it earlier in the engineering process, instead of when the first product issue hits).
3. [Purple team security exercises](https://playbooks.equalexperts.com/secure-delivery-playbook/practices/operate/security-testing-in-production#use-purple-team-exercises).  These exercises help to identify vulnerabilities and weaknesses in a product by simulating the behaviours and techniques of malicious attackers in the most realistic way possible.
4. Automated failure injection.  Tools such as [AWS's Fault Injection Simulator](https://aws.amazon.com/fis/),  [Gremlin](https://www.gremlin.com/) and [Netflix’s Chaos Monkey](https://github.com/netflix/chaosmonkey) can be used to inject regular but random failures to test the system response on an ongoing basis.
5. Production incidents.  Treat production incidents as learning opportunities, or in the [words of John Allspaw](https://twitter.com/allspaw/status/1233778870635155456), “Incidents are unplanned investments”.  If managed well (see [Google’s SRE book](https://sre.google/sre-book/postmortem-culture/) and [Etsy’s debriefing guide](https://extfiles.etsy.com/DebriefingFacilitationGuide.pdf)), then valuable, firsthand insights can be gained due to everything about the chaos being real!  Live issues can be costly to the business. Therefore, it is beneficial to extract as much business value from them as possible, which can be achieved through a better understanding of the system and possible resilience improvements.
6. Running a mini chaos event, as described next.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://playbooks.equalexperts.com/chaos-day-playbook/complementary-approaches.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.