What DevOps means, minus the job adverts

DevOps began as an answer to a specific dysfunction. Developers were measured on shipping changes and operations on keeping things stable, so the two were structurally in conflict. Every release was a negotiation between people with opposite incentives.

The answer was to make the same people responsible for both, or at least to give them the same goal. Everything else follows from that.

The practices that matter. Version control for everything, including infrastructure and configuration. Automated testing. Automated deployment. Monitoring that the people who write the code actually look at. Small, frequent releases rather than a large quarterly one.

Why small releases are safer, which is counterintuitive. A release containing one change has one possible cause when it breaks. A release containing two hundred changes takes a day to bisect. Frequency reduces risk; it does not increase it.

Blameless post mortems. When something breaks, find the cause in the system rather than the person. A process that allowed one mistyped command to take production down is a process problem. Blaming the person guarantees the next person hides the mistake, and hidden mistakes are how small incidents become large ones.

What DevOps is not. A job title for one person who does the deployments. A team called DevOps that everyone throws work at. A set of tools. Buying Kubernetes does not make an organisation good at this, and plenty of organisations with none of the fashionable tools are excellent at it.