Incidents happen all the time because of bad code deploys. You write some code that passes code review, it then is automatically shipped to production after a test suite passes, and BAM, an outage happens. This fairly common occurrence has ways to prevent it entirely. Using some simple ideas we can defend ourselves from the hidden mistakes that code reviews and chaos engineering sometimes won’t catch.
Defensive programming is great for codifying how a bug could be introduced, and raising an error right before it would happen, or choosing an alternative path.
If you have a style guide that specifies things like
- “Always use concurrent indexes”
- “Always have a timeout on a remote read”
- “Never constrain to the account model in a foreign key”
Then this guide is for you.
This post was originally published on the FireHydrant Blog on July 20, 2019 by Robert Ross.
Top comments (0)