Why do you think your DevOps works.
•Download as PPTX, PDF•
1 like•80 views
DevOps metrics. https://www.youtube.com/watch?v=wfIacVTJR3k&feature=youtu.be Let see how can we understand that our methodology works well. Which metrics we can use for tracking DevOps adaption. How do we know the methodology works at large. Why here is no silver bullet? What information we need to move forward.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Why do you think your DevOps works.
Similar to Why do you think your DevOps works. (20)
Recently uploaded
Recently uploaded (20)
Why do you think your DevOps works.
- 1. December, 2017 Borys Drozhak Why do you think your DevOps works?
- 2. Agenda • Why we are doing DevOps • What the problem • What we need • How can we reach it
- 3. Easy to start but hard to keep alive • You are committed to DevOps methodology • Away from waterfall • But, how do you find out how well it works? • How do you know if it’s working at all? • Do you still remember the goal?
- 4. It is all about • Efficiency • Effectiveness • Culture
- 5. Why we need metrics • Observation is fundamental to the scientific method
- 6. Why we need metrics • Not only as a way to measure success • But to find what and how to improve • Not measure just the activities within a pipeline • But the pipeline itself
- 7. Most DevOps metrics fall into three general categories: • People • People-oriented metrics measure such things as turnover, capability, and response time. Always start with people. • Process • In some ways, DevOps is all about process — the continual deployment/operations/support cycle is an ongoing suite of interwoven processes. • Technology • Uptimes, hits, errors rates • Deployments, changes rates
- 8. Here is a lot • Deployment Frequency • Change Lead Time • Change Volume • Change Failure Rate • Customer Ticket Volume • Build duration • Mean Time to Detect (MTTD) • Mean Time to Recovery (MTTR) • Availability
- 9. Here is a lot • Performance • Idle time • Technical debt • WIP • Defects discovered • Time/cost per release • Cost and frequency of outage • Unplanned work time
- 10. Lean metrics • Cycle time • Wait time • Touch time • Time in queue
- 11. Cycle time / Lead Time • Little’s Law: • Lead Time = Cycle Time * WIP • Lead Time = WIP/Throughput
- 12. Idle
- 13. Bonus: Customer value metrics • Customer satisfaction • Feature lead time • Value delivered • Feature usage
- 14. Bonus: Team culture metrics • Employee satisfaction • Employee retention • Cross team collaboration • Education and growth
- 15. DevOps empowerment model • The first way: • – Systems Thinking • The second way: • – Amplify feedback loops • The third way: • – Culture of continual experimentation and learning
- 16. Systems Thinking • Focus on value streams • Think globally • Understand the system as a whole • Stop problems early and often
- 17. Amplify Feedback Loops • Protect the integrity of the entire system of work, versus completion of tasks • Expose visual data so everyone can see how their decisions affect the entire system
- 18. Culture of continual experimentation and learning • Continual experimentation • Tasking risks and learning from failure • Repetition and practice - pre-requisites to mastery • Create rituals that reward risk taking • Introduce faults to increase resilience
- 19. The problem in differences
- 20. The problem in differences
- 21. The problem in differences
- 22. The problem in differences
- 23. The problem in differences
- 24. The problem in differences
- 25. The problem in differences
- 26. Conclusion • No matter what KPIs keep on evolving. • You might be measuring different aspects on your first year and improving in that matter and later on focus on other metrics that might seem more important at that time. • What is important is to be aware of it and to be aware of the fact that it all depends of your business itself. • Your knowledge and preparation are very important when it comes to the success of your DevOps metrics initiative.
- 27. Good read • Basic Operations Self-Instructional Workbook https://hbswk.hbs.edu/archive/hbs-toolkit-basic-operations-self- instructional-workbook • Lead Time vs. Cycle Time https://www.isixsigma.com/community/blogs/lead-time-vs-cycle-time/ • Another 9: https://www.datical.com/blog/9-metrics-devops-teams- tracking/ • https://devops.com/metrics-devops/ • Culture: https://www.slideshare.net/SideraWorks/organizational- culture-discusssions-efficiency-vs-effectiveness
- 28. Thank You ! by Borys Drozhak bdrozhak@softserveinc.com
Editor's Notes
- 18+
- Your organization is now committed to DevOps methodology. You’ve integrated development, operations, and QA, and you have moved drastically away from waterfall and into a fire hose of application development. How do you find out how well it works? How do you know if it’s working at all? Many net new DevOps organizations are surprised to find that it was easier to start then they thought, but hard to keep alive. This can be because of menacing habits, or just because the team is too far into the weeds. In a word, you need metrics
- Reduce cost/risk/operations Ability to add new value to a product Ability for teams to deliver business outcomes
- You need metrics not just as a way to measure the success (or lack of success) of your DevOps program, but also as a way to find out how it can be improved, modified, or extended. Without metrics, you’re flying blind. With metrics, you have a holistic point of view, you know where you are, where you’re going, where you can go, and how to get there. But I am not talking about analytics tools which measure the activities withing the pipeline. I’m talking about measuring the pipeline itself.
- You need metrics not just as a way to measure the success (or lack of success) of your DevOps program, but also as a way to find out how it can be improved, modified, or extended. Without metrics, you’re flying blind. With metrics, you have a holistic point of view, you know where you are, where you’re going, where you can go, and how to get there. But I am not talking about analytics tools which measure the activities withing the pipeline. I’m talking about measuring the pipeline itself.
- People. People are an intrinsic part of any DevOps process. People-oriented metrics measure such things as turnover, capability, and response time. Always start with people. They are the hardest element of any element, and their influence is sometimes hard to spot. Process. In some ways, DevOps is all about process — the continual deployment/operations/support cycle is an ongoing suite of interwoven processes. But some metrics are more clearly process-oriented than others, particularly those involving continuous delivery, response, and repair. Development-to-deployment lead time, for example, is a largely process-oriented metric, as are deployment frequency and response time. Process metrics can be a measure of speed (Where are the bottlenecks, and is the process itself a bottleneck?), appropriateness (Are all steps relevant?), effectiveness (Does it get the job done?), or efficiency (Are the steps in the optimum sequence? is there a smooth flow within the process?). Technology. Technology metrics also play a major role in DevOps, measuring such things as uptime (What percentage of the time is the system running? What about the network, and support applications?) and failure rate (What is the percentage of failed deployments, changes, or units?). Of course, many DevOps metrics involve all three categories to a greater or lesser degree. Perhaps the easiest way to see how metrics play out in practice is to look at the key metrics used by Puppet Labs (Puppet is not a customer of mine, nor am I a customer of theirs) :
- Deployment (or Change) Frequency DevOps practices make frequent or continuous deployment possible; large, high-traffic web sites and cloud-based services make it a necessity. With fast feedback and small-batch development, updated software can be deployed every few days, or even several times per day. In a DevOps environment, deployment frequency can be a direct or indirect measure of response time, team cohesiveness, developer capabilities, development tool effectiveness, and overall DevOps team efficiency.
- Deployment (or Change) Frequency DevOps practices make frequent or continuous deployment possible; large, high-traffic web sites and cloud-based services make it a necessity. With fast feedback and small-batch development, updated software can be deployed every few days, or even several times per day. In a DevOps environment, deployment frequency can be a direct or indirect measure of response time, team cohesiveness, developer capabilities, development tool effectiveness, and overall DevOps team efficiency.
- In a Lean Production system the The touch time is the time that the product is actually being worked on, and value is being added. This is typically only a small proportion of the total production time, most of the time is taken up by moving, queuing etc.
- It is business, not math