DevOpsDays Cuba 2016: Workshop: Devops Modelling (Theory, Practice and Caveats)

DevOpsDays Cuba 2016: Workshop: Devops Modelling (Theory, Practice and Caveats)

Author: Patrick Debois
Summary:

D5db2dc3cc883df3479797edb63b581b?s=128

DevOpsDays Cuba

October 18, 2016
Tweet

Transcript

  1. Modelling Devops http://farm6.staticflickr.com/5291/5540608712_a041894564_z.jpg @patrickdebois http://jedi.be/blog

  2. This presentation ๏Devops ‘Models’ in the wild ๏Seeing the system

    ๏‘Monitoring Stream Mapping Technique’ ๏Observations ๏Focus on Flow ๏Identifying 4 areas of improvement ๏Example practices
  3. models to explain devops

  4. DEV OPS

  5. Paul Peisner

  6. https://twitter.com/dysinger Myopic Devops

  7. http://dev2ops.org/2012/09/use-devops-to-turn-it-into-a-strategic-weapon/ Damon Edwards

  8. https://cacoo.com/diagrams/uapwdcN6SDfwClDY-351A0.png Mathias Marschall An emerging  set of practices

  9. http://www.slideshare.net/dev2ops/you-cant-change-culture-but-you-can-change-behavior-and-behavior- becomes-culture Gene Kim

  10. 1. “Seeing” the System

  11. Value Stream Mapping

  12. “Monitoring” Stream Mapping aka Reverse Value Stream Mapping

  13. • Cross-Silo Group exercise • (both dev, test, ops ...)

    • Use a big wall • preferred near their officespace • preferred permanent • Whiteboard/Long Paper for drawing • Post-it with different colors Exercise Preparation
  14. Production Draw 4 quadrants Start upper right

  15. Production Put all production components on the board

  16. Production Each component = 1 post-it

  17. Production Components (architecture) Put all production components on the board

  18. “I don’t know” can be a great conversation starter

  19. Production Components (architecture) External Add components outside your control your

    team depends outside your company (like cloud services)
  20. Production Components (architecture) External Add components outside your control your

    team depends on inside your company (like firewall, dns, mail, ldap)
  21. Production Components (architecture) Supportive Add the supportive components (backup, monitoring...)

  22. Production Components (architecture) Explain how these components interact (architecture)

  23. Production Components (architecture) Explain how you know they are working

    correctly “monitoring”
  24. Production EndUser Components (architecture) Add ‘core’ functionalities you’re providing to

    the end-user
  25. Production EndUser Components (architecture) Map the functionalities to your components

    (is your monitoring covering all components?)
  26. Production People (process) EndUser Components (architecture) Now repeat the process

    for people/groups involved in support
  27. Production People (process) EndUser Components (architecture) Add all groups/people involved

    for support
  28. Production People (process) EndUser Components (architecture) External Add all external

    groups/people involved for support
  29. Production People (process) EndUser Components (architecture) Supportive Add all supportive

    groups/people involved for support
  30. Production People (process) EndUser Components (architecture) Explain how these people

    interact (process)
  31. Production People (process) EndUser Components (architecture) How do you the

    process is working well? (KPI’s)
  32. Production People (process) EndUser Components (architecture) Relate the people/groups to

    each of the components (who get alerts)
  33. Production Components (architecture) People (process) EndUser Add the enduser support

    services you offer
  34. Production Components (architecture) People (process) EndUser Relate enduser support to

    the process and to the components to the functionalities
  35. IGNITE

  36. “To fix something we know we have to  go

    through development process”
  37. Production Components (architecture) People (process) EndUser Business Enter Project Mode

  38. Production Components (architecture) People (process) EndUser Business Repeat mapping for

    people/process initiate improvements in production
  39. Production Components (architecture) People (process) EndUser Business Repeat mapping for

    people/process initiate improvements in production
  40. Production Components (architecture) People (process) EndUser Business Repeat mapping for

    people/process initiate improvements in production
  41. Production Components (architecture) People (process) EndUser Business Repeat mapping for

    people/process initiate improvements in production
  42. Production Components (architecture) People (process) EndUser Business Repeat mapping for

    people/process initiate improvements in production
  43. Production Components (architecture) People (process) EndUser Business Repeat mapping for

    people/process initiate improvements in production
  44. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Repeat mapping for dev/test components
  45. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Repeat mapping for dev/test components
  46. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Repeat mapping for dev/test components
  47. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Repeat mapping for dev/test components
  48. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Repeat mapping for dev/test components
  49. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    “Seeing the devops system”
  50. a first step of evolving “common ground”

  51. Some Observations

  52. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    More mature people consider dev/test/qa as part of production
  53. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    More mature dev/test/qa/prod components are the same
  54. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    More mature = Less ???? about end-user functionalities
  55. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    More mature = > monitoring/ support for external/cloud services
  56. 2. Focus on Flow

  57. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

  58. Remove friction http://philippe.kruchten.com/2013/11/24/friction/ “Friction: the resistance that one surface or

    object encounters when moving over another.” [Merriam-Webster dict.]
  59. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Find your bottleneck(s) = friction
  60. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Technical Debt Social Debt
  61. OPS DEV http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ 4 areas of improvement

  62. OPS DEV Area 1: Extend delivery to production http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/

  63. OPS DEV Area 2: Extend operations feedback to project Area

    1: Extend delivery to production http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  64. OPS DEV Area 2: Extend operations feedback to project Area

    1: Extend delivery to production Area 3: Embed Project knowledge into Operations http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  65. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  66. Tools Can you ‘technically’ do it Process Should you do

    it People (culture) Will you do it “Layers per Area” Think ‘tags’ of things you do in an area Area X
  67. “Area Maturity Level” a way to quantify your progress http://groups.google.com/group/devops/browse_frm/thread/f3de603a4cea493e?scoring=d&

  68. Initial Unpredictable poorly controlled and reactive Managed Focused on project,

    often and reactive Defined Focused on organization and proactive Quantitatively Managed Measured and controlled Optimizing Focus on Improvement CMMI - Maturity Levels (Process centric)
  69. Intro Using Source Control ... Novice Builds Triggered by Commit

    ... Intermediate Automated Deployment to Testing ... Advanced Automated Functional Testing ... Insane Continuous Deployment to Prod ... Alternative Maturity Levels (cfr. Continuous Integration Model) http://blogs.urbancode.com/continuous-integration/continuous-integration-maturity-model/
  70. Name Area Provision dev/test and prod from the same src

    DEV delivery to Prod Embed Project knowledge Embed Operations knowledge feedback from Prod OPS Tools Intro Layer Level Practice: Use a configuration mangement system like chef/puppet to provision dev,test and prod from the same source Pattern: Automation, reuse of code Principles: By reusing the code it gets tested more && often more frequent/earlier feedback
  71. Production Components (architecture) People (process) Dev, Test, QA EndUser Business

    Different places where we can improve http://devopsdays.org/blog/2010/05/16/the-panel-experiment-and-ignite-devops/ Andrew Schaefer
  72. Some example practices always understand the context before applying

  73. http://www.jedi.be/blog/2013/05/24/Infrastructure%20as%20Code/ cfengine, puppet chef, ansible, salt, ... OPS DEV Area

    4: Embed Operations knowledge into Project Area 2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations Infrastructure as code Using same technology versioning/testing/... Executable ‘documentation’ Common language
  74. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations http://www.hashicorp.com/ Reproduceable environments Dev/Test machines are using the same setup as Production When your app requires changes on the system you can try them and change them ourself Ops can propagate production changes to dev easily
  75. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations Monitoring & Metrics #monitoring{love,sucks} Enable devs to see the production usage/ problems (graphite) Devs can add metrics in their code (Statsd) Make non-subjective decisions at the start of the project
  76. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations Developers wearing pagers Devs you have run operations learn and take it back to project Devs know the app better and can teach/ train operations people Better Tests to prevent production problems/ pain
  77. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations https://github.com/Netflix/SimianArmy Experience problems earlier in the pipeline (less costly)
  78. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations Visualize frequency of production errors and enable extraction of ‘context’
  79. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations https://speakerdeck.com/jnewland/chatops-at-github Shared view on the system events
  80. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations Objective view on problems (think retrospective) (Public) Post-Mortems
  81. OPS DEV Area 4: Embed Operations knowledge into Project Area

    2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations Find bottlenecks in procedures/technology Game Days http://www.youtube.com/watch?v=LCZT_Q3z520&noredirect=1
  82. Training through simulation OPS DEV Area 4: Embed Operations knowledge

    into Project Area 2: Extend operations feedback to project Area 1: Extend delivery to production Area 3: Embed Project knowledge into Operations SadOps http://github.com/railsmachine/sadops
  83. “You build it you run it” Amazon

  84. DEVOPS

  85. 3. Find Feedback loops

  86. Caveat: Differentiate Symptoms vs real cause

  87. Your bottleneck  will move

  88. is it even in Dev & Ops ? MGMT FIN

    SALES HR Business Customer OPS DEV
  89. None
  90. Devops is not just about tools or automation Understanding the

    system needs to be done together Takeways Everbody should care about the whole system
  91. 4. Look for Continuous Improvement

  92. Places to look for ideas

  93. Places to look for ideas (2)

  94. Places to look for ideas (3)

  95. ?