Modelling Devops & Seeing the system

21,310
-1

Published on

- Walkthrough the different models people have used to explain devops
- Monitoring mapping description (reverse value stream mapping)
- Sample devops practices related back to 4 areas of devops

Published in: Technology, News & Politics
1 Comment
101 Likes
Statistics
Notes
  • Nice Presentation :) looks like difference between Dev vs Ops
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
21,310
On Slideshare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
479
Comments
1
Likes
101
Embeds 0
No embeds

No notes for slide

Modelling Devops & Seeing the system

  1. Modelling Devops @patrickdebois http://jedi.be/blog http://farm6.staticflickr.com/5291/5540608712_a041894564_z.jpg
  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. Myopic Devops https://twitter.com/dysinger
  7. Damon Edwards http://dev2ops.org/2012/09/use-devops-to-turn-it-into-a-strategic-weapon/
  8. An emerging set of practices Mathias Marschall https://cacoo.com/diagrams/uapwdcN6SDfwClDY-351A0.png
  9. Gene Kim http://www.slideshare.net/dev2ops/you-cant-change-culture-but-you-can-change-behavior-and-behaviorbecomes-culture
  10. 1. “Seeing” the System
  11. Value Stream Mapping
  12. “Monitoring” Stream Mapping aka Reverse Value Stream Mapping
  13. Exercise Preparation • 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
  14. Draw 4 quadrants Start upper right Production
  15. Put all production components on the board Production
  16. Each component = 1 post-it Production
  17. Put all production components on the board Production Components (architecture)
  18. “I don’t know” can be a great conversation starter
  19. Add components outside your control your team depends outside your company (like cloud services) Production External Components (architecture)
  20. Add components outside your control your team depends on inside your company (like firewall, dns, mail, ldap) Production External Components (architecture)
  21. Add the supportive components (backup, monitoring...) Production Supportive Components (architecture)
  22. Explain how these components interact (architecture) Production Components (architecture)
  23. Explain how you know they are working correctly “monitoring” Production Components (architecture)
  24. Add ‘core’ functionalities you’re providing to the end-user Production Components (architecture) EndUser
  25. Map the functionalities to your components (is your monitoring covering all components?) Production Components (architecture) EndUser
  26. Now repeat the process for people/groups involved in support Production Components (architecture) People (process) EndUser
  27. Production Add all groups/people involved for support Components (architecture) People (process) EndUser
  28. Add all external groups/people involved for support Production Components (architecture) People (process) External EndUser
  29. Add all supportive groups/people involved for support Production Components (architecture) People (process) EndUser Supportive
  30. Explain how these people interact (process) Production Components (architecture) People (process) EndUser
  31. How do you the process is working well? (KPI’s) Production Components (architecture) People (process) EndUser
  32. Relate the people/groups to each of the components (who get alerts) Production Components (architecture) People (process) EndUser
  33. Add the enduser support services you offer Production Components (architecture) People (process) EndUser
  34. Relate enduser support to the process and to the components to the functionalities Production Components (architecture) People (process) EndUser
  35. “To fix something we know we have to go through development process”
  36. Production Enter Project Mode Business Components (architecture) People (process) EndUser
  37. Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  38. Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  39. Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  40. Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  41. Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  42. Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  43. Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  44. Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  45. Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  46. Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  47. Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  48. “Seeing the devops system” Dev, Test, QA Business Production Components (architecture) People (process) EndUser
  49. a first step of evolving “common ground”
  50. Some Observations
  51. More mature people consider dev/test/qa as part of production Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  52. More mature dev/test/qa/prod components are the same Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  53. More mature = Less ???? about end-user functionalities Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  54. More mature = > monitoring/ support for external/cloud services Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  55. 2. Focus on Flow
  56. Dev, Test, QA Business Production Components (architecture) People (process) EndUser
  57. Remove friction “Friction: the resistance that one surface or object encounters when moving over another.” [Merriam-Webster dict.] http://philippe.kruchten.com/2013/11/24/friction/
  58. Find your bottleneck(s) = friction Dev, Test, QA Business Production Components (architecture) People (process) EndUser
  59. Dev, Test, QA Production Technical Debt Business Components (architecture) People (process) Social Debt EndUser
  60. 4 areas of improvement DEV OPS http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  61. Area 1: Extend delivery to production DEV OPS http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  62. Area 1: Extend delivery to production DEV OPS Area 2: Extend operations feedback to project http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  63. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production DEV OPS Area 2: Extend operations feedback to project http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  64. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production DEV OPS Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  65. “Layers per Area” Think ‘tags’ of things you do in an area Area X Tools Can you ‘technically’ do it Process Should you do it People (culture) Will you do it
  66. “Area Maturity Level” a way to quantify your progress http://groups.google.com/group/devops/browse_frm/thread/f3de603a4cea493e?scoring=d&
  67. CMMI - Maturity Levels (Process centric) 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
  68. Alternative Maturity Levels (cfr. Continuous Integration Model) Intro Using Source Control ... Novice Builds Triggered by Commit ... Intermediate Automated Deployment to Testing ... Advanced Automated Functional Testing ... Insane Continuous Deployment to Prod ... http://blogs.urbancode.com/continuous-integration/continuous-integration-maturity-model/
  69. Name Area Provision dev/test and prod from the same src Layer Tools DEV delivery to Prod Embed Project knowledge Embed Operations feedback from Prod knowledge Level OPS Intro 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
  70. Different places where we can improve Dev, Test, QA Business Andrew Schaefer Production Components (architecture) People (process) EndUser http://devopsdays.org/blog/2010/05/16/the-panel-experiment-and-ignite-devops/
  71. Some example practices always understand the context before applying
  72. Area 3: Embed Project knowledge into Operations Infrastructure as code Area 1: Extend delivery to production OPS DEV cfengine, puppet chef, ansible, salt, ... Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project http://www.jedi.be/blog/2013/05/24/Infrastructure%20as%20Code/
  73. Area 3: Embed Project knowledge into Operations Infrastructure as code Area 1: Extend delivery to production OPS DEV cfengine, puppet chef, ansible, salt, ... Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Using same technology versioning/testing/... http://www.jedi.be/blog/2013/05/24/Infrastructure%20as%20Code/
  74. Area 3: Embed Project knowledge into Operations Infrastructure as code Area 1: Extend delivery to production OPS DEV cfengine, puppet chef, ansible, salt, ... Using same technology versioning/testing/... Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Executable ‘documentation’ http://www.jedi.be/blog/2013/05/24/Infrastructure%20as%20Code/
  75. Area 3: Embed Project knowledge into Operations Infrastructure as code Area 1: Extend delivery to production OPS DEV cfengine, puppet chef, ansible, salt, ... Using same technology versioning/testing/... Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Executable ‘documentation’ Common language http://www.jedi.be/blog/2013/05/24/Infrastructure%20as%20Code/
  76. Reproduceable environments Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project http://www.hashicorp.com/
  77. Reproduceable environments Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Dev/Test machines are using the same setup as Production http://www.hashicorp.com/
  78. Reproduceable environments Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project 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 http://www.hashicorp.com/
  79. Reproduceable environments Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project 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 http://www.hashicorp.com/ Ops can propagate production changes to dev easily
  80. Area 3: Embed Project knowledge into Operations Monitoring & Metrics Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project #monitoring{love,sucks} Area 4: Embed Operations knowledge into Project
  81. Area 3: Embed Project knowledge into Operations Monitoring & Metrics Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project #monitoring{love,sucks} Enable devs to see the production usage/ problems (graphite) Area 4: Embed Operations knowledge into Project
  82. Area 3: Embed Project knowledge into Operations Monitoring & Metrics Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project #monitoring{love,sucks} Enable devs to see the production usage/ problems (graphite) Area 4: Embed Operations knowledge into Project Devs can add metrics in their code (Statsd)
  83. Area 3: Embed Project knowledge into Operations Monitoring & Metrics Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project #monitoring{love,sucks} Enable devs to see the production usage/ problems (graphite) Area 4: Embed Operations knowledge into Project Devs can add metrics in their code (Statsd) Make non-subjective decisions at the start of the project
  84. Developers wearing pagers Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project
  85. Developers wearing pagers Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Devs you have run operations learn and take it back to project
  86. Developers wearing pagers Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Devs you have run operations learn and take it back to project Devs know the app better and can teach/ train operations people
  87. Developers wearing pagers Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project 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
  88. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project https://github.com/Netflix/SimianArmy
  89. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Experience problems earlier in the pipeline (less costly) https://github.com/Netflix/SimianArmy
  90. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project
  91. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Visualize frequency of production errors and enable extraction of ‘context’
  92. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project https://speakerdeck.com/jnewland/chatops-at-github
  93. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Shared view on the system events https://speakerdeck.com/jnewland/chatops-at-github
  94. (Public) Post-Mortems Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project
  95. (Public) Post-Mortems Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Objective view on problems (think retrospective)
  96. Area 3: Embed Project knowledge into Operations Game Days Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project http://www.youtube.com/watch?v=LCZT_Q3z520&noredirect=1
  97. Area 3: Embed Project knowledge into Operations Game Days Area 1: Extend delivery to production OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Find bottlenecks in procedures/technology http://www.youtube.com/watch?v=LCZT_Q3z520&noredirect=1
  98. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production SadOps OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project http://github.com/railsmachine/sadops
  99. Area 3: Embed Project knowledge into Operations Area 1: Extend delivery to production SadOps OPS DEV Area 2: Extend operations feedback to project Area 4: Embed Operations knowledge into Project Training through simulation http://github.com/railsmachine/sadops
  100. “You build it you run it” Amazon
  101. DEVOPS
  102. 3. Find Feedback loops
  103. Caveat: Differentiate Symptoms vs real cause
  104. Your bottleneck will move
  105. is it even in Dev & Ops ? HR Business MGMT DEV FIN OPS SALES Customer
  106. Beware of the DEVOPS WIZARDS that don’t know your context
  107. Takeways Devops is not just about tools or automation Understanding the system needs to be done together Everbody should care about the whole system
  108. 4. Look for Continuous Improvement
  109. Places to look for ideas
  110. Places to look for ideas (2)
  111. ?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×