Achieving High Performance DevOps: A Roadmap for Managers and Decision Makers
•Als PPTX, PDF herunterladen•
3 gefällt mir•139 views
Is your Org struggling to increase the pace of deploying changes? Do you feel like you are rolling the dice when deploying changes? Are you content with the current State of Affairs or do you aspire to raise your game by several levels? Finally, are you willing to make the required sacrifices to achieve high performance DevOps? Warning: This session is NOT about the latest/coolest set of technologies that promise to solve your problem. This session is NOT about a product you can buy. This session is about recognizing and understanding the First Order Principles that underlie successful DevOps. Based on this we are going to develop a set of goals, how to measure them and specific steps on how to achieve them. Furthermore, we will discuss the pitfalls that derail so many Organizations in this endeavor, how to circumvent them and even turn them into opportunities. However, be advised, this session is not for those that look for an easy & quick solution. The session is intended to be interactive, and challenge the way you think. If you are willing to have an open mind and put up the extra effort, by the end of this session, we are going to have built a roadmap with goals and specific steps that lead to High Performance DevOps.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ă„hnlich wie Achieving High Performance DevOps: A Roadmap for Managers and Decision Makers
Ă„hnlich wie Achieving High Performance DevOps: A Roadmap for Managers and Decision Makers (20)
KĂĽrzlich hochgeladen
KĂĽrzlich hochgeladen (20)
Achieving High Performance DevOps: A Roadmap for Managers and Decision Makers
- 2. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Achieving High Performance DevOps A Roadmap for Managers and Decision Makers Vlado Barun Real-World Performance Server Technologies Confidential – Oracle Internal/Restricted/Highly Restricted
- 3. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The following is not intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Confidential – Oracle Internal/Restricted/Highly Restricted 3
- 4. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | What this presentation is NOT about • Something you can buy – The latest/coolest tools – Services (i.e. consulting) • Case Studies* Thus, feel free to leave if you expected any of the above … * ie. DevOps Enterprise Summit videos - events.itrevolution.com/us/
- 5. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | What this presentation IS about • Understanding the root cause of the problem • First order principles common to various approaches to solve the problem • Common pitfalls • Roadmap for achieving high-performance DevOps
- 6. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Introductions • 21 years in IT • Various roles – Database Engineer – DBA – Database Architect – Manager of Database Dev & Ops – Performance Engineer – Organizational Change Engineer Vlado Barun, M.Sc., OCE, OCA, MCP
- 7. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Why are you here? Confidential – Oracle Internal/Restricted/Highly Restricted 7
- 8. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | The Challenges we face • Long Time-to-Market – Time from Business approval to successful production deployment • Agile methods (i.e. Scrum) re-introduce feedback loops Business Development QA Operations Time-to-Market
- 9. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | The Challenges we face • It takes too many resources – Dev and Ops are already stretched thin – Not enough (powerful) hardware • Error prone – 70% of outages due to human errors* – If we fix the error and redeploy, we introduce more delays and contention for resources – If we fix it in-place, risk increases * “Database Administration: The Complete Guide to Practices and Procedures” by Craig Mullins
- 10. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Is Automation the solution? • Pros – Reduces human errors – Reduces time and resources needed for deployments • Sure, but by how much? Event Duration ------------------------ ------------------------- Waiting for Information hours/days 95.77% Preparation minutes/hours 4.16% Execution seconds/minutes 0.07%
- 11. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Is Automation the solution? • Cons – automation of a broken process can itself take a long time and be resource intensive – Maintaining automation of a broken process can be cost prohibitive • First fix the process, then automate it
- 12. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Root cause analysis • Why does it take so long? • Why does it take so many resources? • Why is it so error prone?
- 13. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Time-to-Market vs Stability • Frequent deployments result in – Faster time-to-market => increased business value – Higher probability of new production bugs => decreased stability • Common response to stability issue – Enforce bureaucratic process => reduced frequency of deployments => slower time-to-market
- 14. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | The Solution ?
- 15. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | How? Confidential – Oracle Internal/Restricted/Highly Restricted 15
- 16. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | The Mission Transition from Time-to-Market vs Stability Mindset to Time-to-Market & Stability Mindset
- 17. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | The Vision havehave
- 18. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | DevOps executes the Mission Time-to-Market vs Stability Mindset &
- 19. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Time-to-Market & Stability Mindset “Most successful DevOps teams have a strong rapport between groups and believe that everyone is part of the solution, not the problem.“ - Kellyn Pot’Vin-Gorman Confidential – Oracle Internal/Restricted/Highly Restricted 19 *Source: DBA and DevOps - The Last Frontier
- 20. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Time-to-Market & Stability Mindset “More investors don't copy our model because our model is too simple“* – Charlie Munger “When basic beats flashy”* - Morgan Housel Confidential – Oracle Internal/Restricted/Highly Restricted 20 *Source: Take a Simple Idea and Take It Seriously
- 21. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | What is DevOps? Confidential – Oracle Internal/Restricted/Highly Restricted 21 • A set of practices – Leadership and Organizational Culture – Management • Based on Lean and Agile principles – Technology • Based on Continuous Delivery
- 22. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Where do we start? Confidential – Oracle Internal/Restricted/Highly Restricted 22
- 23. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Metrics Confidential – Oracle Internal/Restricted/Highly Restricted 23
- 24. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Benefits of metrics • Provides a specific definition – Reduces confusion, allows us to talk about the “same thing” • Allows us to set goals • Progress can me measured • Helps with building a case with the “Business” side
- 25. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 4 Key Metrics to start with • Time-to-Market – Change lead time • from code committed to code deployed AND successfully executing in production – Deployment frequency • Stability – Change Failure Rate • % of changes that result in service degradation or requires corrective action – Mean-Time-To-Recover (MTBR) • Time to restore service after an incident occurs
- 26. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | State of DevOps - Performance by Cluster1 Confidential – Oracle Internal/Restricted/Highly Restricted 26 1Source: 2017 State of DevOps Report - bit.ly/2017-devops-report
- 27. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 27 1Source: 2017 State of DevOps Report - bit.ly/2017-devops-report State of DevOps – Time to Market1
- 28. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 28 1Source: 2017 State of DevOps Report - bit.ly/2017-devops-report State of DevOps – Stability1
- 29. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 29 1Source: 2017 State of DevOps Report - bit.ly/2017-devops-report State of DevOps1
- 30. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | What do we do now? Confidential – Oracle Internal/Restricted/Highly Restricted 30
- 31. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Leadership Confidential – Oracle Internal/Restricted/Highly Restricted 31
- 32. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Leadership • By 2020, 50% of the CIO’s that have not transformed their capabilities will be displaced from the digital leadership team2 • Transformational Leadership3 – Vision – Inspirational communication – Intellectual stimulation – Personal recognition – Supportive leadership Confidential – Oracle Internal/Restricted/Highly Restricted 32 2Source: Gartner Predicts 3Source: Rafferty & Griffin: Dimensions of transformational leadership: Conceptual and empirical extensions
- 33. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Culture Confidential – Oracle Internal/Restricted/Highly Restricted 33
- 34. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Culture Confidential – Oracle Internal/Restricted/Highly Restricted 34 4Source: Westrum, R. A typology of organisational cultures How organisations process information4 Pathological (Power oriented) Bureaucratic (Rule oriented) Generative (Performance oriented) Low cooperation Modest cooperation High cooperation Messengers shot Messengers neglected Messengers trained Responsibilities shirked Narrow responsibilities Risks are shared Bridging discouraged Bridging tolerated Bridging encouraged Failure→scapegoating Failure→ justice Failure→ inquiry Novelty crushed Novelty→ problems Novelty implemented
- 35. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | How do you change your Organizational Culture? Confidential – Oracle Internal/Restricted/Highly Restricted 35
- 36. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Lean Management Practices Confidential – Oracle Internal/Restricted/Highly Restricted 36
- 37. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Lean Management Practices • Product Management – Experimentation • Small Batch size – i.e. Earliest Testable Product • Frequent Customer Feedback – i.e. A/B testing – Entrust your team – “…failure and innovation are inseparable twins” – Jeff Bezos • Team Structure 1. Highly Collaborative Teams 2. Dedicated DevOps 3. Interdisciplinary teams Confidential – Oracle Internal/Restricted/Highly Restricted 37
- 38. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Incentives • “Perhaps the most important rule in management is to get the incentives right.” – Charlie Munger • Law of unintended consequences Confidential – Oracle Internal/Restricted/Highly Restricted 38
- 39. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Continuous Delivery Confidential – Oracle Internal/Restricted/Highly Restricted 39
- 40. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Continuous Delivery • Version Control • Continuous Integration and trunk-based development • Left Shift on Security • Test Automation • Deployment Automation Confidential – Oracle Internal/Restricted/Highly Restricted 40
- 41. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Conway’s Law5 "Any organization that designs a system … will inevitably produce a design whose structure is a copy of the organization's communication structure.“ - Melvin Conway Confidential – Oracle Internal/Restricted/Highly Restricted 41 5Source: How Do Committees Invent?
- 42. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Roadmap for Achieving High Performance DevOps Confidential – Oracle Internal/Restricted/Highly Restricted 42 Leadership Culture Metrics Continuous Delivery Lean Management Practices IT Performance Organization Performance
- 43. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | What can I do today? • Time-to-Market & Stability Mindset • Metrics – Find where most of the time is spend then address the top consumers • i.e. change approval -> streamline approval process • i.e. deployment scrip creation/execution –> automation – Find the root cause for failures then fix them • i.e. wrong version/config -> version control/configuration management • i.e. bug count -> Test automation + Formal Inspections • Transformational Leadership Dimensions • Generative Culture • Lean Management Practices – Experimentation Confidential – Oracle Internal/Restricted/Highly Restricted 43
- 44. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Resources • Lean Enterprise • Leading the Transformation • The Phoenix Project • The DevOps Handbook • Continuous Delivery • 2017 State of DevOps Report • How to Build a High-Performing IT Team Confidential – Oracle Internal/Restricted/Highly Restricted 44
- 45. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Resources Confidential – Oracle Internal/Restricted/Highly Restricted 45 • DBA and DevOps - The Last Frontier • Jez Humble on Continuous Delivery • Toyota Kata • How to F Up “Respect for People” & Really Piss Off your Employees • The Agile Mindset - And Beyond • Making sense of MVP • NUUMI 2015 – This American Life
- 46. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 46
- 47. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The preceding is not intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Confidential – Oracle Internal/Restricted/Highly Restricted 47
- 48. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Internal/Restricted/Highly Restricted 48
Hinweis der Redaktion
- Audience makeup Managers or Decision Makers DBAs Developers Architects Formal education in computer science or STEM vs Pshicology , Human Beahviour
- This is a Safe Harbor Front slide, one of two Safe Harbor Statement slides included in this template. One of the Safe Harbor slides must be used if your presentation covers material affected by Oracle’s Revenue Recognition Policy To learn more about this policy, e-mail: Revrec-americasiebc_us@oracle.com For internal communication, Safe Harbor Statements are not required. However, there is an applicable disclaimer (Exhibit E) that should be used, found in the Oracle Revenue Recognition Policy for Future Product Communications. Copy and paste this link into a web browser, to find out more information.  http://my.oracle.com/site/fin/gfo/GlobalProcesses/cnt452504.pdf For all external communications such as press release, roadmaps, PowerPoint presentations, Safe Harbor Statements are required. You can refer to the link mentioned above to find out additional information/disclaimers required depending on your audience.
- Case studies an be vey informative, and very motivating, but it is unlikely that you can replicate their success by just doing the same steps, using the same methodology There is not “best” methodology, it really depends on the specifics of your organization on what is the “best” approach
- Ideas Performance not Magic Get what you deserve Very often we can see the performance mistake/Bad decision made just from your data Inspire relentless excelence
- Time-to-Market = Mean Time To Change Waterfall become popular after 1988 when DOD introduces SDLC standard Discuss disadvantges of waterfall (ie from the 1970 paper) Agile (i.e. Scrum), to the rescue - >cover business/dev interaction and basic premise is to put back the feedback loop. However, its focus is on speed and correctness of development but does not address deployment of changes between environments. This is visible thorough the changing of done is <> shippable and <> shipped https://www.infoq.com/news/2008/02/done-shippable-quality Back to the future: 1970 MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS by Dr. Winston W. Rovce 1988 DOD introduces SDLC standard (good intentions), encouraging waterfall model (bad implementation; due to lack of understanding) how many of them believe that their process meets their need?
- , pg 238
- Automation - Chef, Puppet, Ansible, Terraform Config Management – Jenkins, Control-M Orhestration – Automic Monitoring – New Relic, App Dynamics, Nagios, EM, Solar Winds Monitoring – Splunk, Sumo Logic Packaging/Containers – Docker, Kubernets
- Pitfall #1 pre-mature automation
- As you do the analysis and peel back the layers of the onion, you might get to a point illustrated by this image Fundamental mismatch between the goals of the dev and ops.
- Primary mission of dev is to add new features to meet revenue goals Primary mission of Ops is to meet availability goals
- Pitfall #2 “the Devops movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems.” Devops proposes instead strategies to create better collaboration between functional silos, or doing away with the functional silos altogether and creating cross-functional teams (or some combination of these approaches).” “The fundamental problem is this: Bad behavior arises when you abstract people away from the consequences of their actions. Functional silos abstract people away from the consequences of their actions. In the example above, developers are abstracted away from the consequences of writing buggy code. The essence of Devops, I believe, is to design a system in which people are held responsible for the consequences of their actions - and indeed, one in which the right thing to do is also the easiest thing to do. “ https://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/
- As the mission executes, we get to a state where the needs of both dev and ops are met. And that is what DevOps is about
- Can add a lot of material/time based on https://www.youtube.com/watch?v=DAVFNIFQ1T8 And DOES_forum_metrics_102015.pdf
- Can add a lot of material/time based on https://www.youtube.com/watch?v=DAVFNIFQ1T8 And DOES_forum_metrics_102015.pdf
- We got the metrics, but that might be dangerous. These number will expose inefficiencies, which could lead to pointing fingers and blowbacks, attackes, in-fighting, poltical battles, etc. It is hard to change one owns habits. It is even harder to change somebody else’s habit!!
- Need a leader to rally employees behind a mission and vision. Organizational Change Culture Change Replace bad habits Stories are more powerful than statistics because the most believable thing in the world is whatever takes the least amount of effort to contextualize your own life experiences. People go astray when forgetting that storytelling is like exponential fuel, so a great idea told poorly can be a fraction as powerful as an OK idea told persuasively. The CEO who understands everything about their field except the most important thing – rallying employees behind a mission and vision. http://www.collaborativefund.com/blog/making-sense-vs-being-right/
- Transformational leadership Dimensions Servant leaders focus on their followers' development and performance, whereas transformational leaders focus on getting followers to identify with the organization and engage in support of organizational objectives. leaders inspire and motivate followers to achieve higher performance by appealing to their values and sense of purpose, facilitating wide-scale organizational change. These leaders encourage their teams to work towards a common goal through their vision, values, communication, example-setting, and their evident caring about their followers' personal needs. It has been observed that there are similarities between servant leadership and transformational leadership, but they differ in the leader's focus. Prepare slides THAT BUILD THE ROADMAP
- Leadership beahviour => culture
- How do you change culture? NUUMI
- Entrust=empower, allow them to change the spec and experiment (amazon story) Fail fast and often 1. Easiest, least amount of culture change, thus commonly choosen but also least effective because it usualy ends up as another silo 2. Better, but doesn’t solve the incentive problem 3. Solves incentive problem “You build it, your run it” - https://queue.acm.org/detail.cfm?id=1142065 https://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/ Solves incentive problem!!!!!!!!!!!!!!!!!! “Developers of our services can use any tools they see fit to build their services. Developers themselves know best which tools make them most productive and which tools are right for the job. If that means using C++, then so be it. Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs.” https://queue.acm.org/detail.cfm?id=1142065 “And this argument - that collaboration between silos, or even cross-functional teams, is forbidden by regulation or "best practice" - is an example of what we in the consulting industry call a bullshit smokescreen. So let me be clear about this. Sarbanes-Oxley, ITIL and COBIT nowhere mandate segregation of duties. COBIT v5 doesn't even have a control called "segregation of duties". PCI-DSS does require segregation of duties in its current form, but that doesn't mean people can't collaborate. I recently filmed Michael Rembetsy, director of operations engineering at Etsy, talking about how they implement segregation of duties at Etsy in order to achieve PCI-DSS compliance.” https://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/
- The law of Unintended Consequences Specific examples are the cobra effect (and the rat effect) https://en.wikipedia.org/wiki/Cobra_effect FedEx couldn’t get the planes to shift packages from plane to plane in a timely manner paid per hour => paid per shift(move all packages from plane to plane)
- Despite the name, continuous delivery is not about deploying to production multiple times a day. The goal of continuous delivery is to make it safe and economic to work in small batches. This in turn leads to shorter lead times, higher quality, and lower costs The Fundamentals of Continuous Delivery Continuous delivery is the ability to get changes—experiments, features, configuration changes, bug fixes—into production or into the hands of users safely and quickly in a sustainable way.
- Pitfall #3 – Working on this without addressing Conway’s law Monolithic vs loosely coupled architecture Leadership => Culture => Organizational structure => Architecture (Loosely coupled) => Continuous Delivery
- In PARALLEL
- This is a Safe Harbor Front slide, one of two Safe Harbor Statement slides included in this template. One of the Safe Harbor slides must be used if your presentation covers material affected by Oracle’s Revenue Recognition Policy To learn more about this policy, e-mail: Revrec-americasiebc_us@oracle.com For internal communication, Safe Harbor Statements are not required. However, there is an applicable disclaimer (Exhibit E) that should be used, found in the Oracle Revenue Recognition Policy for Future Product Communications. Copy and paste this link into a web browser, to find out more information.  http://my.oracle.com/site/fin/gfo/GlobalProcesses/cnt452504.pdf For all external communications such as press release, roadmaps, PowerPoint presentations, Safe Harbor Statements are required. You can refer to the link mentioned above to find out additional information/disclaimers required depending on your audience.