Failover testing
Prove replicas, zones and regions actually take over when the primary dies.
⚠ Guide
Resilience testing, without building the rig
Resilience testing is deliberately breaking part of your system, a server, a zone, a dependency, to prove the rest keeps serving customers. Run one failure at a time, on infrastructure you own, with a hard time limit. This guide is the hub: every type of resilience test, and how to start without building the tooling.
What resilience testing covers
Disaster recovery testing
Prove you can restore service and data inside your RTO and RPO.
Dependency failure
Make a third-party API slow or dead and watch what your app does.
People drills
Rehearse the incident response itself: paging, runbooks, comms.
How to run a resilience test
1. Pick one thing you believe is true, for example "if one zone dies, checkout still works".
2. Set limits: which targets, how long, and what makes you stop.
3. Inject the failure, watch your dashboards and your customers' view.
4. Write down what surprised you, fix it, and schedule the rerun.
Resilience testing FAQ
+ Is resilience testing the same as chaos engineering?
Chaos engineering is the discipline; resilience testing is the practical act of running the experiments. Most teams just want the test results.
+ Can we test in production?
Yes, once staging runs are boring. Start with a tiny blast radius and automatic abort on your SLOs.
+ How often should we test?
Monthly for critical paths, and after any major architecture change.
Safe by design
Every fault Oh My GDaaS runs is aimed at infrastructure you have proved you own, through a DNS record, a scoped cloud role or a deployed agent. Every run has a blast-radius limit, a hard time limit and an abort button. We are not a booter, stresser or DDoS service and never will be.