3. Devops is a verb
Dev ops (v) The operationalization of application deployments.
@lmacvittie #DevopsSummit
4. Operations
• Error Prone Process
• Difficult to Debug
• Time Consuming
Manual / Scripted Configuration
Application Infrastructure
Application
Security
Identity and
Access
Local Load
Balancing
Application
Performance
Application
Proxies
Web & App
Servers
@lmacvittie #DevopsSummit
5. Operations
• Simplifies troubleshooting & rollback
• Consistent, predictable and repeatable process execution
• Captures tribal knowledge
Scripting and APIs
Application Infrastructure
Application
Security
Identity and
Access
Local Load
Balancing
Application
Performance
Application
Proxies
Web & App
Servers
Automation
and
Orchestration
@lmacvittie #DevopsSummit
6. Proving the Value
48%
say biggest difficult in implementing
devops is “its value is not understood
outside my group”.
2012 DevOps Survey presented by Puppet Labs and IT Revolution Press; Indeed.com
@lmacvittie #DevopsSummit
14. Baseline
1 Define the measurement and the tolerable upper and
acceptable lower limits (ULS and LLS)
2 Collect the data
3 Do the maths
4 Model improvement
@lmacvittie #DevopsSummit
Let’s start by looking at what Devops boils down to.
Captures tribal knowledge – the Campbell soup man expert system story.
"You build an expert system when you have a significant specialized knowledge that exists only in a few people's heads and is acquired through years of experience," said Herrod, who recently attended the Instrument Society of America's annual conference in Philadelphia.
Herrod developed one of his first expert systems for Campbell's Soup Co., where Aldo Cimino, an employee with 46 years of experience in the soup sterilization process, was about to retire.
Cimino was the trouble-shooter for 72-foot-high sterilizers in which 68,000 cans of soup at a time are heated to 250 degrees.
"If one of those breaks down, you're up to your ears in bad soup," Herrod said. "So when there was a problem the people at the plant couldn't fix, they'd call in Aldo. He had a lot of little tricks and knew how to figure out the problem."
Cimino, who worked at the company's Camden, N.J., headquarters, said he was apprehensive when his boss asked him to put everything he knew about his job on a computer disk.
"At first I thought, 'Oh my God, they're going to get rid of me,' " said Cimino. "But then I realized that I was 64 years old and getting ready to go anyway. They just wanted to save some of what I knew.
"It felt weird at first," he said. "But I got used to it. It's like I left a piece of myself at that plant."
It took seven months for a team of so-called knowledge engineers to pump 46 years worth of know-how from Cimino and store it on floppy disks. When they were finished, Cimino retired. He said the company didn't pay him any more money for picking his brain.
2012 DevOps Survey presented by Puppet Labs and IT Revolution Press; Indeed.com
This is a significant obstacle – how do you prove the value of devops without actually “doing” devops? How do you justify the investment in time, tools, training if you can’t prove the value to management or the business people?
Six Sigma is a methodology that relies on measurement, analysis, and optimization of processes. It’s used in manufacturing as well as software development, where the reduction of errors is paramount to improving quality of the resulting product. But it’s basic principles can be applied to any output produced by a process that can be measured.
The most common measurement is defects per X lines of code. Modern measurements might use technical debt as a measurable. With agile you could also use feature completeness per sprint.
1 http://drbenchmark.org/wp-content/uploads/2014/02/ANNUAL_REPORT-DRPBenchmark_Survey_Results_2014_report.pdf
3 Ponemon 2013 Cost of Data Center Outages http://www.emersonnetworkpower.com/documents/en-us/brands/liebert/documents/white%20papers/2013_emerson_data_center_cost_downtime_sl-24680.pdf
The point here is not to become six sigma black belts, but rather to apply its principles to devops. Six Sigma focuses on errors / defects, but its principles can be applied to anything that’s measurable … for devops, we’re going to use CPR.
Consistent: Reduces errors.
Predictable: You know how long it will take.
Repeatable: You can successfully repeat it.
Automation and orchestration enable that shift in part by eliminating human errors.
Enables a significant increase in the productivity of operations teams – repeatable
Pro tip:
Excel has functions you can use.
To get x use AVERAGE
To get sigma use STDEV
To model improvement, use NORMSDIST on the negative value of your sigma level
One of the benefits of six sigma is it allows a standardized method of predicting failure (and conversely, success!) This allows you to model potential improvement based on initiatives you want to undertake: automation, orchestration, even as far as justifying the purchase of API-enabled infrastructure that will fit into a programmatic set of processes better.
You can use the basic Six Sigma formula to demonstrate the probability of meeting expectations for service velocity based on automation providing different levels of process improvement.
An approximately one sigma shift from -2.58 to -1.29 nets a 10% better chance of successfully deploying within expected time frames. Another shift nets you even greater gains.
You can use six sigma principles to model reductions in error rates based on how much time it takes to troubleshoot.
Generally speaking, you aren’t going to tackle the entire process at once. You need to identify which tasks within the process will net you the best results up front to really make an impact and get some buy in. You can use the six sigma principles to do that. Instead of looking at the whole process, look at individual tasks and play with improvement based on automating one or two tasks and see which one brings about the best return.
This also lets you optimize the process. Some of these can be accomplished in parallel… which reduces the overall time to deploy.
Remember, though, that automating poor processes is not going to get you the best results. Part of the whole exercise requires that you DEFINE the processes before you start measuring. It’s there you may find redundancy or inefficiencies that will net you improvements without laying down a line of code.