Service Delivery Best Practices?

So… DevOps.  DevOps vs NoOps has been making the rounds lately. At Bazaarvoice we are spawning a bunch of decentralized teams not using that nasty centralized ops team, but wanting to do it all themselves.  This led me to contemplate how to express the things that Operations does in a way that turns them into developer requirements?

Because to be honest a lot of our communication in the Ops world is incestuous.  If one were to point a developer (or worse, a product manager) at the venerable infrastructures.org site, they’d immediately poop themselves and flee.  It’s a laundry list of crap for neckbeards, but spends no time on “why do you want this?” “What value will this bring to your customer?”

So for the “NoOps” crowd who want to do ops themselves – what’s an effective way to state these needs?  I took previous work – ideas from the pretty comprehensive but waterfally “Systems Development Framework” Peco and I did for NI, Chris from Bazaarvoice’s existing DevOps work – and here’s a cut.  I’d love feedback. The goal is to have a small discrete set of areas (5-7), with a small discrete set (5-7) of “most important” items – most importantly, stated in a way so that people understand that these aren’t “annoying things some ops guy wants me to do instead of writing 3l33t code” but instead stated as they should be, customer facing requirements like any other.  They could then be each broken into subsidiary more specific user stories (probably a whole lot of them, to be honest) but these could stand in as “epics” or “pillars” for making your Web thing work right.

Service Delivery Best Practices

Availability

• I will make my service highly available, so that customers can use it constantly without issues
• I will know about any problems with my service’s delivery to customers
• I can restore my service quickly from any disaster or loss
• I can make my data resistant to corruption from runtime issues
• I will test my service under routine disruption to make it rugged and understand its failure modes

Performance

• I know how all parts of the product perform and can measure performance against a customer SLA
• I can run my application and its data globally, to serve our global customer base
• I will test my application’s performance and I know my app’s limitations before it reaches them

Support

• I will make my application supportable by the entire organization now and in the future
• I know what every user hitting my service did
• I know who has access to my code and data and release mechanism and what they did
• I can account for all my servers, apps, users, and data
• I can determine the root cause of issues with my service quickly
• I can predict the costs and requirements of my service ahead of time enough that it is never a limiter
• I will understand the communication needs of customers and the organization and will make them aware of all upgrades and downtime
• I can handle incidents large and small with my services effectively

Security

• I will make every service secure
• I understand Web application vulnerabilities and will design and code my services to not be subject to them
• I will test my services to be able to prove to customers that they are secure
• I will make my data appropriately private and secure against theft and tampering
• I will understand the requirements of security auditors and expectations of customers regarding the security of our services

Deployment

• I can get code to production quickly and safely
• I can deploy code in the middle of the day with no downtime or customer impact
• I can pilot functionality to limited sets of users
• I will make it easy for other teams to develop apps integrated with mine

Also to capture that everyone starting out can’t and shouldn’t do all of this… We struggled over whether these were “Goals” or “Best Practices” or what… On the one hand you should only put in e.g. “as much security as you need” but on the other hand there’s value in understanding the optimal condition.