Making it safe to fail

So now, we started to notice these DevOps patterns in our studies, for example, where people were willing to focus on learning together versus blaming and co-designing resilience. Designing systems that are safe to fail is borrowing thinking from flight simulators. The average learner needs to crash several planes in the simulator before flying in real life. The point is to decouple deployment from activation so that we can learn for free without affecting our customers' experience.

When you look at continuous deployment and continuous delivery, we're putting code out there faster. In some cases, code is on a unit test, and then committed, and then through static code analysis, integration tests, fast regression stack and—Bam! Production! Well, why do we do that? Because we know that we have options: blue green deployments, dark deployments, feature toggles, flags, and switches. So, we can turn something off in production if it causes a problem by itself...