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

Author: Patrick Debois
Summary:

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
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. ?