@andrew – This is definitely meant as a starting point. I’ve found that some companies have already solved the communication problem between dev and ops because the company is organization is setup such that ops and dev people have to work together, but it is more common for companies to have separate dev and ops groups (who, to echo Nikolay, have started down the “… road to standardization, certification and bureaucratic death.”) I’m hoping that we can help the latter companies break down those walls by first increasing communication and then codifying practices in tools and automation. I know in many companies if the ops teamed forced a new tool on development without first talking to development the tool would be roundly rejected without consideration (and this happens the other way, with ops rejecting new code from development when development dumps a new project in ops’ lap). This is a more common situation then having freedom to wholesale change existing process (or the luxury of creating new process from scratch).

Thanks for your comments!

My experience has been that documents don’t stay updated.

Echoing Damon, code don’t lie. Why record in text what you can mandate and enforce with code?

Also, I doubt devs will know half the stuff on the list.

For example, ‘Memory Requirements’ is likely going to depend on load, which no one knows until the thing is live and is not likely a static requirement. It’s all about feedback loops.

I have seen scenarios where lists like this would be an improvement, but I see this as more of a starting point than a goal. The situation that comes to mind is when you have a lot of different dev teams making lots of small internally facing applications to support the general business processes, which are then handed over to a monolithic but highly resource constrained ops team. I’d probably advocate trying to the segment the ops team so they have more knowledge of applications they support when possible. I know one smallish ops team that supports about 80 development teams, but their life is pretty close to hell and I would consider that an organizational failure to recognize the value of or invest in infrastructure. They would love to have this list.

Where the business is outward facing web applications, the ops team managing that better know the ’software purpose’ without looking at a text file and if you need to look up contact info for who to talk with in development or qa, then you probably aren’t talking to them enough.

0.02
Andrew

This post was mentioned on Twitter by adamfblahblah: Communicating with documentation, a new #devops blog post: http://bit.ly/ceVzZo...

Documentation might be a band-aid, but I don’t see how it helps fix your real problems. To me this sounds like the road to standardization, certification and bureaucratic death.

Hm, to finish this rant construcively, documentation might be a starting point for root cause analysis: for each point you document, ask why, why, why and try to get rid of it.

Thanks for the comment!

One thing to keep in mind is the method of both input and submission: While it’s a good candidate for a wiki page, it should be submitted to the Ops organization through another format. People tend to format it the easiest way possible (read: very little extra formatting), which lends itself to difficult to read answers due to the low contrast.

@Damon: I believe the two go hand in hand, but having such a document should definitely be a prerequisite.

Excellent post. I wonder if there is a maturity model that needs to be considered. For example, configuration tools like Puppet or Chef and workflow/coordination tools like ControlTier try to bridge this communication gap by telling everyone to “communicate with code”. Rather than hand documents back and forth, hand executable code that take all (or most of the) ambiguity out of the handoff.

But before you can even get to that point you need to know what all of the procedural and configuration points are… I wonder how many companies would be better off with a step 0 like the “DevOps Dialogue Document” rather than reaching straight for the automation tools.

-Damon
http:dev2ops.org