Hacker News Reader

Comment by sp332 | Hacker News Reader

Chaos experiments are costly to implement relative to unit and integration tests and so are a poor choice for detecting issues unit or integration tests could. Instead, Chaos experiments should be designed to find the truly hidden flaws which only surface in real world usage with real user traffic and production environment configuration.

This is in case you didn't quite articulate or verify your real requirements. The more confident you are that your test environment matches your prod environment, the less you need this.

View on HN

I'm not unrealistic - functional requirements are hardly ever complete, and they're almost always better than scalability and capacity planning.

Call me old fashioned, but I don't like messing around with production. I think you can reasonably scale down production environments and simulated wan networks packet loss/latency. I can't imagine a platform moderate importance not having some sort of benchmarking and scalability as part of their pre-prod pipeline automated acceptance criteria. It feels like this work would fall under that engineering role (again, performance test engineer or devops/sre).

Anyway, I think I chafe at the name more than anything. I know nonlinear dymanics, stress testing, queuing theory, et al and it just feels overly glib for what should be the most serious sort of activity a company considers.

If I may be pedantic for one moment for the sake of clarity:

> The more confident you are that your test environment matches your prod environment, the less you need this

I'd also add "workload" alongside "environment", which is often challenging to accurately simulate.

That's great, until your service scales to the point where it's not possible to simulate prod in test.

chaos testing can be part of SRE practice, its mostly around reliability of systems. I am not sure why someone in the comments is confusing it with functional testing or load testing.

Reply on news.ycombinator.com