Configuration Management and DevOps with Jez Humble and Bob Aiello

we often face. The operations teams will say, "This sounds very nice, but we have to follow PCI DSS or Sarbanes-Oxley, and they require separation of concerns. How do we do this?" I think that the first thing to point out is that a heavyweight change-management process is actually a poor way to manage risk, because what ends up happening is that people have to fill these documents and they end up short-circuiting the process. I've seen this—heavyweight change-management processes with these huge spreadsheets that the developers fill in and that get sent to another country, and the people who are approving the changes don't know anything about what they're approving. It's a poor way to manage risk.

So, what we say in the book is, if you have a deployment pipeline, and for every change you make to your system it goes through a process of validation to assess the risk of that change, actually that's a better way to manage risk. You can see exactly what the change is. You've got validations in the form of automated tests and manual tests that demonstrate the change is low risk. Then, you can use some of this stuff that's in ITIL v3 —like the concept of standard, pre-approved changes, of electronic just-in-time approvals, of not everyone having to approve every change—and you can have a very transparent, auditable system for managing risk that is actually superior to the very heavyweight risk-management processes.