Modelling Devops & Seeing the system
Upcoming SlideShare
Loading in...5
×
 

Modelling Devops & Seeing the system

on

  • 14,887 views

- Walkthrough the different models people have used to explain devops ...

- 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

Statistics

Views

Total Views
14,887
Views on SlideShare
13,967
Embed Views
920

Actions

Likes
86
Downloads
390
Comments
1

16 Embeds 920

https://twitter.com 573
http://www.scoop.it 210
http://hashtaag.com 78
http://localhost 14
http://www.linkedin.com 11
http://harsh.com 10
https://devnetwork.meine-freiheit.de 6
https://mail.google.com 5
http://egap.xunta.es 4
http://192.168.0.25 3
https://home.jolicloud.com 1
http://moderation.local 1
http://www.twylah.com 1
https://tweetdeck.twitter.com 1
https://www.rebelmouse.com 1
http://192.168.33.10 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Nice Presentation :) looks like difference between Dev vs Ops
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Modelling Devops & Seeing the system Modelling Devops & Seeing the system Presentation Transcript

  • Modelling Devops @patrickdebois http://jedi.be/blog http://farm6.staticflickr.com/5291/5540608712_a041894564_z.jpg
  • 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
  • models to explain devops View slide
  • DEV OPS View slide
  • Paul Peisner
  • Myopic Devops https://twitter.com/dysinger
  • Damon Edwards http://dev2ops.org/2012/09/use-devops-to-turn-it-into-a-strategic-weapon/
  • An emerging set of practices Mathias Marschall https://cacoo.com/diagrams/uapwdcN6SDfwClDY-351A0.png
  • Gene Kim http://www.slideshare.net/dev2ops/you-cant-change-culture-but-you-can-change-behavior-and-behaviorbecomes-culture
  • 1. “Seeing” the System
  • Value Stream Mapping
  • “Monitoring” Stream Mapping aka Reverse Value Stream Mapping
  • 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
  • Draw 4 quadrants Start upper right Production
  • Put all production components on the board Production
  • Each component = 1 post-it Production
  • Put all production components on the board Production Components (architecture)
  • “I don’t know” can be a great conversation starter
  • Add components outside your control your team depends outside your company (like cloud services) Production External Components (architecture)
  • Add components outside your control your team depends on inside your company (like firewall, dns, mail, ldap) Production External Components (architecture)
  • Add the supportive components (backup, monitoring...) Production Supportive Components (architecture)
  • Explain how these components interact (architecture) Production Components (architecture)
  • Explain how you know they are working correctly “monitoring” Production Components (architecture)
  • Add ‘core’ functionalities you’re providing to the end-user Production Components (architecture) EndUser
  • Map the functionalities to your components (is your monitoring covering all components?) Production Components (architecture) EndUser
  • Now repeat the process for people/groups involved in support Production Components (architecture) People (process) EndUser
  • Production Add all groups/people involved for support Components (architecture) People (process) EndUser
  • Add all external groups/people involved for support Production Components (architecture) People (process) External EndUser
  • Add all supportive groups/people involved for support Production Components (architecture) People (process) EndUser Supportive
  • Explain how these people interact (process) Production Components (architecture) People (process) EndUser
  • How do you the process is working well? (KPI’s) Production Components (architecture) People (process) EndUser
  • Relate the people/groups to each of the components (who get alerts) Production Components (architecture) People (process) EndUser
  • Add the enduser support services you offer Production Components (architecture) People (process) EndUser
  • Relate enduser support to the process and to the components to the functionalities Production Components (architecture) People (process) EndUser
  • “To fix something we know we have to go through development process”
  • Production Enter Project Mode Business Components (architecture) People (process) EndUser
  • Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  • Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  • Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  • Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  • Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  • Repeat mapping for people/process initiate improvements in production Business Production Components (architecture) People (process) EndUser
  • Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • Repeat mapping for dev/test components Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • “Seeing the devops system” Dev, Test, QA Business Production Components (architecture) People (process) EndUser
  • a first step of evolving “common ground”
  • Some Observations
  • More mature people consider dev/test/qa as part of production Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • More mature dev/test/qa/prod components are the same Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • More mature = Less ???? about end-user functionalities Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • More mature = > monitoring/ support for external/cloud services Business Dev, Test, QA Production Components (architecture) People (process) EndUser
  • 2. Focus on Flow
  • Dev, Test, QA Business Production Components (architecture) People (process) EndUser
  • 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/
  • Find your bottleneck(s) = friction Dev, Test, QA Business Production Components (architecture) People (process) EndUser
  • Dev, Test, QA Production Technical Debt Business Components (architecture) People (process) Social Debt EndUser
  • 4 areas of improvement DEV OPS http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  • Area 1: Extend delivery to production DEV OPS http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
  • 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/
  • 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/
  • 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/
  • “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
  • “Area Maturity Level” a way to quantify your progress http://groups.google.com/group/devops/browse_frm/thread/f3de603a4cea493e?scoring=d&
  • 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
  • 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/
  • 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
  • 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/
  • Some example practices always understand the context before applying
  • 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/
  • 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/
  • 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/
  • 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/
  • 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/
  • 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/
  • 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/
  • 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
  • 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
  • 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
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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’
  • 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
  • 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
  • (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
  • (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)
  • 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
  • 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
  • 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
  • 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
  • “You build it you run it” Amazon
  • DEVOPS
  • 3. Find Feedback loops
  • Caveat: Differentiate Symptoms vs real cause
  • Your bottleneck will move
  • is it even in Dev & Ops ? HR Business MGMT DEV FIN OPS SALES Customer
  • Beware of the DEVOPS WIZARDS that don’t know your context
  • Takeways Devops is not just about tools or automation Understanding the system needs to be done together Everbody should care about the whole system
  • 4. Look for Continuous Improvement
  • Places to look for ideas
  • Places to look for ideas (2)
  • ?