We all know that protocols are an essential building block of our craft. What would our jobs look like without TCP/IP or HTTP? While there is room for improvement in all of them, they’re definitely helpful in defining how our systems work together. But systems programming are not the only area where protocols play an important role. Wikipedia talks about protocols in diplomacy, for example: “A protocol is a rule which guides how an activity should be performed”[ 1]. Ah, now we’re getting somewhere. So why not apply the ‘protocol’ idea to Devops? Let’s try and see how the idea of protocols can help us improve the adoption of a Devops culture.

Devops Protocol Definition

Wikipedia has an elaborate definition of protocol. We could re-write it for Devops like this:

The term [protocol] refers to the set of rules, procedures, conventions and ceremonies that relate to relations between discrete departments. In general, [a] protocol represents the recognized and generally accepted system of international , inter-departmental courtesy.

I see a lot of value in collecting such a set of rules, procedures, conventions and ceremonies to convey the fundamental ideas of Devops.

Devops Protocol Examples

• Developers carry pagers after releases: to ensure that developers get unfiltered and timely feedback about the quality of their work, it’s a good idea to have them carry pagers after releases containing their code. If it’s only the admins who need to get up in the middle of the night and sweat the outages produced by a new feature, it will lead to blaming games instead of cooperation. Instead, feeling the same pain and solving problems together will grow a strong bond between everyone involved.
• Log files are accessible to everyone: a developer can only debug a problem if he knows what’s going on. He needs to see how the code behaves in production. If you want to foster collaborative troubleshooting instead of finger pointing, giving everyone access to the production logs is a good idea.
• Everything is under version control: this is most likely already true for all the source code. But it should also be true for server scripts and configuration files. Whatever you run or put on a production box should have a history and a well defined place where anyone can have a look at it.

Building a Devops culture is a challenge, but if we start sharing Devops protocols, maybe we get more dudes who understand what Devops is really about: Collaboration.

Which Devops protocols work for you? Please share them with us in the comments below…