2011 09 19 LSPE Dev Ops Cookbook 1a

2,055 views

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,055
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
65
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • How each side Actively impedes the achievement of each other’s goals.
  • http://www.flickr.com/photos/keenepubliclibrary/2435790649/
  • [ text ] My personal goal is to prescriptively define 1) what does Dev need to do to become a reliable partner, 2) what does IT Operations need to do to become a realiable partner, and then 3) how do they work together to deliver unbelievable value to the business.Of course, the goal is more than happy coexistence. It’s to replicate the Etsy and LinkedIn stories:Increase the rate of features that we can put into production, while simultaneously maintaining the reliability, stability, security and survivability of the production environment.
  • Since 1986, I’ve been a QA engineer writing filesystem QA tests, system administrator, developer, infosec, process design, operations research, auditorIncidentally, I almost moved to Seattle to be on Microsoft NT network test team in 1991 (TCP/IP stack)For 13 years, I was the founder/CTO of Tripwire, but my primary passion is studying high performing IT operations and security organizations.When I met Chris 3 years ago, he helped me see clearly one of the primary obstacles for successful transformations. I’ll describe this later.First, let me talk about what I meant by “high performers” back in 1999.
  • 2011 09 19 LSPE Dev Ops Cookbook 1a

    1. 1. The DevOps Cookbook: Codifying Kick-Ass Business Practices That Matter<br />Gene Kim, CISA, TOCICO Jonah#lspeSeptember 19, 2011<br />
    2. 2. Where Did The High Performers Come From?<br />
    3. 3. Higher Performing IT Organizations Are More Stable, Nimble, Compliant And Secure <br /><ul><li>High performers maintain a posture of compliance
    4. 4. Fewest number of repeat audit findings
    5. 5. One-third amount of audit preparation effort
    6. 6. High performers find and fix security breaches faster
    7. 7. 5 times more likely to detect breaches by automated control
    8. 8. 5 times less likely to have breaches result in a loss event
    9. 9. When high performers implement changes…
    10. 10. 14 times morechanges
    11. 11. One-half the change failure rate
    12. 12. One-quarter the first fix failure rate
    13. 13. 10x fasterMTTR for Sev 1 outages
    14. 14. When high performers manage IT resources…
    15. 15. One-third the amount of unplanned work
    16. 16. 8 times moreprojects and IT services
    17. 17. 6 times moreapplications</li></ul>Source: IT Process Institute, 2008<br />
    18. 18. Common Traits of High Performers<br />Culture of…<br />Change management<br /><ul><li>Integration of IT operations/security via problem/change management
    19. 19. Processes that serve both organizational needs and business objectives
    20. 20. Highest rate of effective change </li></ul>Causality<br /><ul><li>Highest service levels (MTTR, MTBF)
    21. 21. Highest first fix rate (unneeded rework)</li></ul>Compliance and continual reduction of operational variance<br /><ul><li>Production configurations
    22. 22. Highest level of pre-production staffing
    23. 23. Effective pre-production controls
    24. 24. Effective pairing of preventive and detective controls</li></ul>Source: IT Process Institute <br />
    25. 25. Visible Ops: Playbook of High Performers<br />The IT Process Institute has been studying high-performing organizations since 1999<br />What is common to all the high performers?<br />What is different between them and average and low performers?<br />How did they become great?<br />Answers have been codified in the Visible Ops Methodology<br />The “Visible Ops Handbook” is now available from the ITPI<br />www.ITPI.org<br />
    26. 26. 2007: Three Controls Predict 60% Of Performance<br />To what extent does an organization define, monitor and enforce the following?<br />Standardized configuration strategy<br />Process discipline<br />Controlled access to production systems<br />Source: IT Process Institute, 2008<br />
    27. 27. The Darkest Moment In My Journey<br />
    28. 28. Tough Love From Ari Balogh<br />
    29. 29. Why Was I So Unsatisfied With The State Of IT Practice?<br />IT operations work continued to be viewed as tactical<br />Information security and compliance programs were sucking all the air out of the room (due to scoping problems)<br />The activation energy for successful improvement programs was still too high<br />The IT operations issues overshadowed by development <br />Issues are amplified 10x in production: outages, findings, lawsuits<br />Technical debt builds up over time<br />IT operations is often the constraint in the organization<br />Linkage of IT performance to business performance not obvious enough<br />“Why doesn’t the business care? I found the pump handle!”<br />
    30. 30. Seeing The Bigger Problem<br />Operations Sees…<br />Fragile applications are prone to failure<br />Long time required to figure out “which bit got flipped”<br />Detective control is a salesperson<br />Too much time required to restore service<br />Too much firefighting and unplanned work <br />Planned project work cannot complete<br />Frustrated customers leave<br />Market share goes down<br />Business misses Wall Street commitments<br />Business makes even larger promises to Wall Street<br />Dev Sees…<br />More urgent, date-driven projects put into the queue<br />Even more fragile code put into production<br />More releases have increasingly “turbulent installs”<br />Release cycles lengthen to amortize “cost of deployments”<br />Failing bigger deployments more difficult to diagnose<br />Most senior and constrained IT ops resources have less time to fix underlying process problems<br />Ever increasing backlog of infrastructure projects that could fix root cause and reduce costs<br />Ever increasing amount of tension between IT Ops and Development<br />These aren’t IT Operations problems…These are business problems!<br />
    31. 31. The Dreaded Disease<br />IT Operations Constipatus (noun)<br />Occurs when IT Operations creates fatal blockages in project flow. Creates blinding pain in Dev organization.Blockage worsens with chronic break/fix and security/compliance work, and when technical debt is never paid off.Causes host to lose energy, become unable to achieve organizational goals. Dangerous to CEOs.<br />Photo credit: http://www.flickr.com/photos/keenepubliclibrary/2435790649/<br />
    32. 32. 12<br />DevOps Can Break A Core Chronic Conflict In IT * <br />Every IT organization is pressured to simultaneously:<br />Respond more quickly to urgent business needs<br />Provide stable, secure and predictable IT service<br />Words often used to describe ITIL process owners:“hysterical, irrelevant, bureaucratic, bottleneck, difficult to understand, not aligned with the business, immature, shrill, perpetually focused on irrelevant technical minutiae…”<br />Source: The authors acknowledge Dr. Eliyahu Goldratt, creator of the Theory of Constraints and author of The Goal, has written extensively on the theory and practice of identifying and resolving core, chronic conflicts.<br />
    33. 33. Framed This Way, Help Can Come From A Surprising Place<br />The VP Application Development will often have the following complaints:<br />IT Operations is the bottleneck<br />We complete the code, but it takes too long for IT Operations to get the code into production<br />Environments are never available when we need them<br />Releases often cause chaos and disruption to all the other production services<br />Turbulent installs have become the norm: 30 min installs take 3 days<br />Due to slow OS upgrades, applications delayed by 2 quarters<br />We are always late getting features to market<br />
    34. 34. A Reframed IT Operations Problem Statement<br />Increase flow from Dev to Production<br />Increase throughput<br />Decrease WIP<br />Our goal is to create a system of operations that allows <br />Planned work to quickly move to production<br />Ensure service is quickly restored when things go wrong<br />How does this relate to Visible Ops?<br />We focused much on “unplanned work”<br />What’s happening to all the planned work?<br />At any given time, what should IT Ops be working on?<br />Now we are focusing on the flow of planned work<br />
    35. 35. What These Breakthroughs Look Like<br />
    36. 36. Goal #1: Decrease Cycle Time Of Releases<br />Create determinism in the release process<br />Move packaging responsibility to development<br />Release early and often<br />Decrease cycle time<br />Reduce deployment times from 6 hours to 45 minutes<br />Refactor deployment process that had 1300+ steps spanning 4 weeks<br />Never again “fix forward,” instead “roll back,” escalating any deviation from plan to Dev<br />Verify for all handoffs (e.g., correctness, accuracy, timeliness, etc…)<br />Ensure environments are properly built before deployment begins<br />Control code and environments down the preproduction runways<br />Hold Dev, QA, Int, and Staging owners accountable for integrity<br />
    37. 37. Goal #2: Increase Production Rigor<br />Define what work is and where work can come from<br />Protect the integrity of the work queue (e.g., are checks being written than won’t clear?)<br />To preserve and increase throughput, elevate preventive projects and maintenance tasks<br />Document all work, changes and outcomes so that it is repeatable<br />Ops builds Agile standardized deployment stories, to be completed after Dev sprints are complete<br />Maintains adequate situational awareness so that incidents could be quickly detected and corrected<br />Standardize unplanned work and escalations<br />Always seeking to eradicate unplanned work and increase throughput<br />Lean Principle: “Better -> Faster -> Cheaper”<br />
    38. 38. Some Principles<br />Because operations is constrained, it is always better to prevent than recover<br />Operations work must be planned<br />We strive to have continual situational awareness<br />We will strive to control as many dimensions of our work as possible<br />We ruthlessly pursue to understand any deviations from normal<br />We expect systems in operations to never stop working<br />We never do one-offs (they must be exceptions, not the rule)<br />We require determinism to enable resiliency<br />We strive for the improvement and mastery of the environment<br />
    39. 39. Creating A System Of Operations<br />Inj: 1. Projects: ensure rapid project releases from Development<br />Inj: 1.1. Created effective centralized work demand queue<br />Inj: 1.2: Protect integrity of work queue (e.g., write only checks that will clear)<br />Inj: 1.3: Release early and often: Freeze projects if necessary, choking materials release to reduce WIP, allow longer runways of work<br />Inj: 1.4: Elevate any deviations or incidents that stop flow of work<br />Inj: 1.5: Standardize product deployments with Development<br />Inj: 1.6: Continually seek ways to increase flow<br />Inj: 2. Ensure reliable IT operations<br />Inj: 2.1: When failures, detect/correct quickly inside the plant (e.g., production)<br />Inj: 2.2. Prevent failures (e.g., maintenance)<br />Inj: 2.3. Study and create projects to reduce/eradicate unplanned work<br />Inj: 2.4. Seek ways to increase production<br />Inj: 3. Subordinate infosec/PMO/etc. to enable Inj 1 & 2<br />
    40. 40. The Prescriptive DevOps Cookbook<br />Capture and codify how to start and finish successful DevOps transformations<br />Create isomorphic mapping between plant floors and IT shops<br />Co-authoring with Patrick DeBois, Mike Orzen, John Willis<br />Describe in detail how to replicate the transformations describe in “When IT Fails: The Novel”<br />Goals<br />How does Development, IT Operations and Infosec become dependable partners<br />How do they work together to solve business problems (and Infosec, too)<br />
    41. 41. Goal Statement<br />Build a system of work where Dev and Ops can be relied upon so that they work together to simultaneously achieve:<br />fast flow of features into production<br />deliver services in production that are:<br />Attributes of Rugged DevOps<br />Scalability, availability, survivability, sustainability, security, supportability, defensibility<br />
    42. 42. Underpinning Principles<br />Agile: increase velocity<br />Lean: reduce WIP<br />Systems thinking: Dev, Test, IT Operations, Project Management, Information Security<br />Lean: implementing effective countermeasures<br />
    43. 43. Cookbook Outline<br />Part 1: Enable IT Operations to become a dependable partner<br />Part 2: Enable Dev to become a dependable partner<br />Part 3: Dev and IT Operations to create breakthrough results<br />
    44. 44. Part 1: IT Ops<br />Enable fast, repeatable and predictable flow of planned work<br />Create single work queue, master list of commitments, master production schedule<br />Create catalog of acceptable work: bill of materials, work centers, routings<br />Runners, repeaters and strangers<br />Create job release function<br />
    45. 45. Part 1: IT Ops<br />Minimize disruption from unplanned work<br />Standardize unplanned work: make it repeatable<br />Modify first response: ensure constrained resources have all data at hand to diagnose<br />Elevate preventive activities to reduce incidents<br />Stories about reducing reliance on Brent<br />
    46. 46. Part 2: Dev<br />Continuous deployment and integration in place<br />Working through some assumptions about Agile methods in place<br />
    47. 47. Part 3: DevOps<br />Pick a pilot project<br />Baseline current performance<br />Create organization<br />Someone needs to see the end-to-end flow from Dev to Production to Incident<br />Enable correct feedback loops<br />
    48. 48. Part 3: DevOps<br />Dev and Ops work together in Sprint 0 and 1 to create code and environments<br />Create environment that Dev deploys into<br />Create downstream environments: QA, Staging, Production<br />Create the Agile information radiator<br />Integrate infosec and QA into daily sprint activities<br />
    49. 49. Part 3: DevOps<br />Embed Ops person into Dev structure<br />Describes non-functional requirements, use cases and stories from Ops<br />Has a vote like other team members<br />Responsible for bringing Ops experiences into “quality at the source”<br />Has special responsibility for pulling the Andon cord<br />
    50. 50. Part 3: DevOps<br />Potentially decouple production releases from Sprint boundaries<br />Issue: how to enable deployments that are more frequent than the typical 1 or 2 week intervals<br />Sprints vs. Kanbans<br />
    51. 51. Part 3: DevOps<br />Put Dev into Ops escalation chain<br />MobBrowser case study: “Waking up developers at 3am is a great feedback loop: defects get fixed very quickly”<br />Determine when SOD is a control being relied upon<br />
    52. 52. The Prescriptive DevOps Cookbook<br /><ul><li>I am seeking fellow travelers who want to capture and codify the best known methods, patterns/anti-patterns, recipes and case studies of how to implement successful DevOps-style transformations.</li></li></ul><li>Questions<br />Are there areas that we’ve neglected to mention?<br />What are the largest barriers to implementing what’s been covered?<br />Do you have any tricks/tips/cookbooks you’d like to share?<br />
    53. 53.
    54. 54. The Theory of Constraints Approach To Visible Ops<br />Dr. Goldratt wrote The Goal in 1984, describing Alex’s challenge to fix his plant’s cost and due date issues within 90 days<br />Some tenets that went against common wisdom:<br />Every flow of work has a constraint/bottleneck<br />Any improvement not made at the bottleneck is merely an illusion<br />Fallacy of cost accounting as operational management tool<br />
    55. 55. When IT Fails: The NovelDay 1<br />Steve Masters, CEO<br />Dick Landry, CFO<br />Parts Unlimited$4B revenue/year<br />
    56. 56. When IT Fails: The NovelDay 2<br />Bill Palmer, VP IT Operations (promoted)<br />Wes Davis, Director, Distributed Systems<br />Patty McKee, Director, IT Service Support Services<br />The payroll outage<br />All salaried employees will get paid, but not the hourlies<br />CISO put in tokenization application in the factories, breaking database query that uses SSN<br />IT Ops thought it was a SAN firmware upgrade failure<br />All HR apps go down<br />CFO is on front page of news, apologizing to community<br />
    57. 57. When IT Fails: The NovelDay 4<br />Chris Allers, VP Application Development<br />Sarah Moulton, SVP Retail Products<br />“We can deploy by next week by cutting some corners, but IT Ops is in the way… again…”<br />“Bill, your team lacks a sense of urgency. We must go. We’ve already bought the newspaper ads – they’re bought, paid for and being printed…”<br />
    58. 58. When IT Fails: The NovelDay 3<br />Nancy Mailer, Chief Audit Executive<br />John Pesche, CISO<br />IT Operations has 980 IT general control deficiencies on critical financial systems, potentially dooming financial statement to having a footnote. Needs management response in 1 week.<br />Bill grapples with who to put on the project. 1 yr of work, just to fix issues, even without Phoenix.<br />
    59. 59. The Goal For IT: Day 10<br />The Deployment<br />Database conversion, the point of no return, taking 1000x longer.<br />In store POS won’t come up by Sat 8am, maybe by next Tuesday<br />Emptying shopping cart shows last successful order credit card #<br />
    60. 60. Resources<br />From the IT Process Institute www.itpi.org<br />Both Visible Ops Handbooks<br />ITPI IT Controls Performance Study<br />“Lean IT” by Orzen and Bell<br />Winner of the Shingo Prize 2011<br />“Inspired: How To Create Products That Customers Love” by Cagan<br />“Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” by Humble, Farley<br />Follow Gene Kim<br />@RealGeneKim<br />mailto:genek@realgenekim.me<br />http://realgenekim.me/blog<br />
    61. 61. Call To Action<br />If you’re interested in reviewing early versions of “When IT Fails: The Novel,” email me.<br />If you’re interested in helping build or review the DevOps Cookbook, email me.<br />I’m genek@realgenekim.me<br />Thank you for allowing me to join your tribe!<br />
    62. 62.
    63. 63. About Gene Kim<br />I’ve spent the last 12 years studying high performing IT organizations, trying to understand:<br />What do they have in common?<br />What is present in successful transformations, absent in unsuccessful transformations?<br />How do we lower the activation energy required to create the transformations?<br />Founder and former CTO of Tripwire, Inc.<br />Co-author of Visible Ops Handbook, Security Visible Ops Handbook<br />Active researcher<br />Co-founder of IT Process Institute<br />Committee member of Institute of Internal Auditors<br />Leader of PCI Security Standards Council Scoping SIG<br />

    ×