---
title: "chaos engineering | Skills We Assign For | Azendo"
description: "Chaos engineering in practice — hypothesis-driven failure injection, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/chaos-engineering/"
---

[Skills](https://azendo.co/skills/) Cloud and infrastructure 

# chaos engineering.

Chaos engineering is the practice of deliberately injecting failure into a system to verify that it behaves as designed. It tests the resilience mechanisms teams believe they have, rather than assuming they work.

## Where chaos engineering fits on a long engagement.

The point is not breaking things; it is checking a specific belief. A useful experiment states a hypothesis — "if this instance is terminated, requests continue with no user-visible error" — and then terminates it. Either the belief holds, or an assumption that was going to fail eventually fails now, on a Tuesday, with everyone watching.

Readiness matters more than tooling. A system without reliable monitoring cannot run these experiments, because nobody will be able to tell what the injected failure caused. Chaos engineering is something a mature system does, not a route to becoming one.

## What an assigned team does with chaos engineering.

Starting in production is the common mistake. Staging experiments build the practice and catch the obvious gaps; production experiments with a small blast radius and a tested abort come later, once the team trusts both the process and its monitoring.

Sequencing that properly is part of how reliability work is planned, as described in [how an assignment runs](https://azendo.co/how-it-works/).

## What we use chaos engineering for.

* Verifying failover actually fails over Testing the mechanism deliberately rather than discovering it during an outage.
* Dependency failure handled gracefully Third-party latency and errors injected, so timeouts and fallbacks are proven.
* Monitoring proven adequate Checking that an injected failure is actually visible, which is often the first real finding.

## How chaos engineering capacity is assigned.

Resilience testing is assigned under [devops as a service](https://azendo.co/services/cloud-and-devops/), sequenced after monitoring is trustworthy rather than before.

## Roles we assign chaos engineering for

* [Site Reliability Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/site-reliability-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in cloud and infrastructure

* [Kubernetes — skill we assign for](https://azendo.co/skills/kubernetes/)
* [Docker — skill we assign for](https://azendo.co/skills/docker/)
* [Terraform — skill we assign for](https://azendo.co/skills/terraform/)
* [AWS — skill we assign for](https://azendo.co/skills/aws/)
* [Azure — skill we assign for](https://azendo.co/skills/azure/)
* [GCP — skill we assign for](https://azendo.co/skills/gcp/)
* [Terraform modules — skill we assign for](https://azendo.co/skills/terraform-modules/)
* [Pulumi — skill we assign for](https://azendo.co/skills/pulumi/)

## Tell us what your roadmap needs chaos engineering for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)