Improve resilience with automated chaos engineering
summary
Argues that automation scales chaos coverage beyond ad hoc game days and one-offs and demonstrates three concrete patterns: recurring scheduled experiments via a serverless scheduler and Lambda, event‑triggered experiments tied to system or business events, and CI/CD‑integrated experiments run in CodePipeline with Step Functions. Uses AWS Fault Injection Simulator to inject CPU stress on EC2, adds CloudWatch alarms as stop conditions, and shows an alarm stopping an experiment and failing the pipeline so faulty code never reaches production.
AI-written summary · about
chapters (11)
- 0:00Introduction to chaos engineering
- 2:06One-off chaos experiments
- 3:51Chaos engineering in game days
- 4:58Limitations of manual experiments
- 8:33Need for automated experiments
- 10:40Scheduling recurring experiments
- 14:35Event-triggered chaos experiments
- 15:37Chaos in CI/CD pipelines
- 18:49Safeguards and stop conditions
- 22:48Summary and key takeaways
- 24:42Q&A session
related talks
26mA proactive approach to resilience in modern apps
42mChaos Engineering: Why Breaking Things Should be Practiced
57mChaos Engineering Primer
18mFostering Chaos Engineering Culture
33mChaos Engineering, how to increase resilience by injecting chaos
48mChaos Engineering: The art of breaking stuff
40mChaos Engineering at Scale
24mBreaking Serverless Things on Purpose: Chaos Engineering in Stateless Environments