Chaos Engineering: When the Network Breaks

Chaos engineering is a disciplined approach to identifying failures before they become outages. By proactively testing how a system responds under stress, you can identify and fix failures before they end up in the news. Chaos engineering lets you compare what you think will happen to what actually happens in your systems. You literally break things on purpose to learn how to build more resilient systems.

Tammy Butow leads a walk-through of network chaos engineering, covering the tools and practices you need to implement chaos engineering in your organization. Even if you’re already using chaos engineering, you’ll learn to identify new ways to use it to improve the resilience of your network and services. You’ll also discover how other companies are using chaos engineering and the positive results the companies have had using chaos to create reliable distributed systems.

Tammy begins by explaining chaos engineering and its principles. She then asks why many engineering teams (including Netflix, Gremlin, Dropbox, National Australia Bank, Under Armour, Twilio, and more) use chaos engineering and how every engineering team can use it to create reliable systems. You’ll learn how to get started using chaos engineering with your own team as you explore the tools to measure success and the chaos tools and new chaos features built into cloud services. You’ll also discover how to use wargame environments to learn about chaos engineering and how to practice chaos engineering on AWS DocumentDB, AWS DynamoDB, AWS RDS, and AWS S3. Other topics include how to use monitoring tools combined with chaos engineering to help you create reliable distributed systems, where you can learn more, and how to join the chaos community.

Transcript

1. 1 Chaos Engineering When the network breaks June 13, 2019 Velocity San Jose Tammy Butow Principal SRE, Gremlin tammy@gremlin.com @tammybutow
2. Every system is becoming a distributed system. THE PROBLEM
4. Chaos Engineering Thoughtful, planned experiments designed to reveal the weakness in our systems.
5. build an immunity
6. proactively
7. Define the Blast Radius
9. Improved Incident Management
11. Measuring the Cost of Downtime Cost = R + E + C + ( B + A ) During the Outage R = Revenue Lost E = Employee Productivity After the Outage C = Customer Chargebacks (SLA Breaches) Unquantifiable B = Brand Defamation A = Employee Attrition Amazon is estimated to lose $220,000/min The average e-commerce site loses $6,800/min
12. Network Chaos
14. Network Chaos Engineering Demos 01 02 Latency Injection Packet Loss 03 Blackhole
15. Hipster Shop Architecture
16. Latency Injection Demo
17. Hipster Shop Datadog Gremlin HTTP 400/500 errors Latency Attack 120 seconds Experiment #3 500ms latency should be a non-issue `frontend` 500ms delay
18. Live Demo
20. Packet Loss Demo
21. Kubernetes Dashboard Datadog Gremlin Rise in errors (400/500s) Packet Loss 60 seconds 70% Experiment #2 `kubernetes-dashboard` Slower responses, but ultimately success
22. Demo
24. Blackhole Attack Demo
25. Hipster Shop Datadog Gremlin HTTP 400/500 errors Blackhole Attack 120 seconds Experiment #1 `paymentservice` Drop all traffic Expect payments to fail and errors thrown
27. Results
29. How to communicate results of your Chaos Engineering experiments?
30. Was it expected? Chaos Engineering uncovers unknown side effects. Was it detected? Ensuring that our monitoring is configured correctly is critical. Was it mitigated? When possible our systems should gracefully degrade.
31. Fix the issues. Whether code, configuration or process - iterate and improve. Can you automate this? Regularly exercise past failures to prevent the drift into failure. Share your results! Prepare an Executive Summary of what you learned.
32. Where can you get started?
33. Join the Chaos Engineering Community gremlin.com/community Join us at Chaos Conf September 26, 2019 @tammybutow @gremlininc
34. gremlin.com/tammy
35. 35 Thank You Tammy Butow Principal SRE, Gremlin tammy@gremlin.com @tammybutow