O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Winning People to DevOps

2.434 visualizações

Publicada em

How can we communicate the effectiveness of DevOps to technical and business people?
What metaphors and examples help?
What kind of people should we hire?

This presentation was given as an Ignite talk at DevOps Days Europe 2010 in Hamburg.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Winning People to DevOps

  1. 1. Culture Shock Winning People to DevOps 1 Matthew Skelton, Priocept Ltd. DevOps Days Europe 2010, Hamburg
  2. 2. Agenda How can we communicate the effectiveness of DevOps? What metaphors and examples help? 2 What metaphors and examples help? What kind of people should we hire?
  3. 3. Who? Matthew Skelton, Technical Director at Priocept, based in London, UK – Control engineering background – CEng/Eur.Ing. – Thinking and doing elements of “DevOps” for at least 5 years Highly available, content-rich internet systems using .Net and Java – Development teams also responsible for designing and supporting: – Build, deployment, environments, diagnostics, reporting 3 – Build, deployment, environments, diagnostics, reporting – 3rd line support – based on ITIL best practices London Stock Exchange www.londonstockexchange.com (2004+): – Weekly deployments of new features, including e-Commerce – Huge traffic spikes
  4. 4. Why DevOps? Applicability – any large, frequently-changing software system Target is much broader than SaaS (revenue model) 4 Many-user systems; internet-based or internal As much a change in attitude as tools & techniques Respond rapidly and reliably to changing business requirements
  5. 5. Why DevOps? Change vs. Value Change vs. Errors Businessvalue Rateoferror 5 Businessvalue Rate of change Rateoferror Rate of change
  6. 6. Why DevOps? Deliver more value to the organisation, without increasing major errors or failures What does the business care about? 6 – Next product version – Matching or exceeding the competition – Satisfying customers – First-to-market Reliable, frequent changes to software services
  7. 7. Metaphors – Child and Hoop A perfectly round circle is neither necessary nor sufficient Constant input or 7 essentialvermeer.com Constant input or adjustments needed The maker of the hoop knows its faults and quirks The maker is thus best- placed to keep it rolling
  8. 8. Art – Sculpture Expert design and craftsmanship Unique 8 No plans for changing it Difficult and costly to change later Pre-DevOps software systems Rodin
  9. 9. Art – Live Performance Not limited to a single pose Repeatable - daily 9 daily Please the audience Requires orchestration / coordination DevOps-driven software services www.partsuspended.com / Matthew Skelton
  10. 10. Auto Engineering – Concept Car Ideal design Unique No plans for 10 blogs.cars.com No plans for changing parts Pre-DevOps software systems
  11. 11. Auto Engineering – Racing Car Pragmatic design Replaceable components 11 racing.priocept.com components Pit-lane repairs Parts changed every ~30 minutesDevOps-driven software services My boss!
  12. 12. Shock #1 Change. Is. Good. The system will change The system will never be “finished” 12 The system will never be “finished” Aiming for perfection is asking for failure “Perpetual beta”
  13. 13. Shock #2 Operations. Can. Improve. Development. Experience of diagnosing production problems leads to better software 13 “Design for Diagnosis” & “Design for Failure” Culture change needed in Dev teams – Mutually responsible, mutually supportive “Dev > Ops” is dangerous and simply incorrect
  14. 14. Shock #3 Failures. Are. Acceptable. Roll-back vs. roll-forward Failures as an opportunity to learn about the 14 Failures as an opportunity to learn about the system Confidence provided by log and statistic data “Evidence-based testing” – cf. medicine
  15. 15. SLAs, ITIL and Change SLAs often work against change ITIL done badly means risk-averse Concept of a Change Level Agreement (CLA)? 15 Concept of a Change Level Agreement (CLA)? – Up to 5%, 10%, 15% of the system to change – Per day, week, month SLA + CLA to provide a stability-agility metric Admits the need for regular, reliable change
  16. 16. What Skills Do We Need? Generalising Specialists (Scott W. Ambler) – http://www.agilemodeling.com/essays/generalizingSpecialists.htm No big “software guru” or “sysadmin” egos! No more technical silos 16 No more technical silos Excellent communications: – Within team – With other teams – With the client – Across different spoken (and computer) languages Willingness to work with the best technologies, whatever they are
  17. 17. What Skills Do We Need? (2) Understand and expect hardware and environmental limitations Bandwidth, read/write speed, storage limits, inertia, friction, etc. Developers often assume that software will run on “ideal” machines 17 The most beautiful software is useless if such limits are forgotten The “cloud” does not avoid these limits – only makes them – Higher (Petabytes instead of Terabytes) – Softer (elastic up to a certain threshold, but not beyond) cocoatech.com VS. register.co.uk - ventblockers
  18. 18. Who Should We Hire? Mechanical Engineers, Electrical Engineers, Control Engineers – With software training and experience The occasional mathematician or “pure” software developer ☺ 18 businessweek.com, warwick.ac.uk
  19. 19. Summary 1. DevOps allows reliable, frequent changes to software services 2. Think repeatable performances, not one- 19 2. Think repeatable performances, not one- off wonders 3. Hire mechanical engineers, not mathematicians!
  20. 20. Thank you for listening Thanks also to: – London DevOps group (http://groups.google.com/group/london-devops/) – BCS London (http://www.bcs.org/) 20 – BCS London (http://www.bcs.org/) – Rob Thatcher matthew.skelton@gmail.com Priocept: – http://www.priocept.com/ – @Priocept