What do OPS teams need in the software you’re producing?

The Tweet from Bob has been “redirected” by Steve so I accept the challenge to loose some words about this topic.

The Initial Question was :

When did you last ask your ops team(s) what they need in the software you’re producing? Kudos for answering e.g. “every day”.

— Bob Marshall (@flowchainsensei) May 13, 2012

So what does a Operations Team (if you’re hipster enough you call it DEVOPS-Team) need in software wich has to be supported and maintained after the developing teams handed it over?

1. DOC-U-MEN-TA-TION (refers to code comments *#thisisacomment or //thisisalsoacomment* and written documentation)
   Yes, this word stands for what we usually care the most. Immagine a team which hands over’s a huge project to another team without being allowed to talk or having a conversation about the product.
   IF the receiving team can pick up the work with minimal effort by just reading the documentation your team wrote you diserve an award!
2. Monitoring
   After your beloved OPS Team has started to work on the project it’s common to monitor the system (usually even prior to product launch). I refer to #1 you should document it, how and what should be monitored.
3. Core-Hacks
   I don’t want to loose many words about core hacks but if you hand over stuff to me and i see that you hacked the core… i’ll set you on fire. (editor’s note: sometime i loose my temper about this point…)
4. Log Files
   Fun fact: OPS Teams never eat… they take their energy out of logfiles which are written to the production servers.
   Now seriously, if you encounter a exception in your application you should log this to a file.
5. Stage and Live Systems
   Having a stage-system is sometimes a pain because you have to maintain your application two times. But hey if something went’s wrong you can fix the bug first on a cold system instead of fixing it on the hot production system. Some people love the thrill that comes with fixing bugs in a live system (i personally enjoy it – sometimes). But normally there should be a stage system.
   Side note : If you have important production systems there are sometimes not just a stage and a production system. There are two additional systems one for development and one additional for testing purposes.
6. Understand what you do
   This point is intended to be a hint for developers. Working on cutting edge technology  is cool, but you should not focus just on your code you write you should also gain some knowledge about your newest shiny technology you use. It will not kill you and if it gets OPS-style just speak up and ask your friendly operations guy next door™. I write this point down because i’ve seen sometimes that dev’s use the newest technology and stuff without even caring for the technology itself. If someone gains access to your database/crm/backend be sure that he does not only type admin:admin as username password combination to get access to it, because nobody cared about reading the documentation of the technology you  use.
7. Security
   Embrace security in everything you code and specify. It’s okay to be worried about security. This point relates directly to #6

These are just a few point’s that came across my mind after reading the Tweet from Bob. There are plenty more, just follow the advice of Bob and ask your Teams what they need. There is always a operations sight of the project and not just the customer point of view.