Computing DevOp Summit
Download as PPTX, PDF0 likes536 views
The document discusses the four pillars of DevOps at Hiscox: culture, process, people, and technology. It describes how each pillar is implemented at Hiscox, including establishing cross-functional teams, shared goals and incentives, emphasis on automation and continuous integration/delivery, and measuring everything. The goals are to break down silos, increase agility and the pace of change, and align teams to work together seamlessly across the software delivery lifecycle. A Platform Services Group is also discussed which helps standardize processes and tools to further enable DevOps practices across teams.
More Related Content
What's hot (19)
Similar to Computing DevOp Summit (20)
Recently uploaded (20)
Computing DevOp Summit
- 1. The four pillars of DevOps at Hiscox Jonathan Fletcher Enterprise Architect, Technology and Platform Lead
- 2. Me • Jonathan Fletcher • Architect in Hiscox Group IT since 2012 • Ex Dev • Ex Ops • http://enterprisedevops.blogspot.com • http://www.devops.com • @FletcherJofanon 2
- 3. Why DevOps ? • From our IT Strategy – – “Be nimble in responding to market opportunities” – “Flexible technology at the heart of the business”
- 4. Common complaints • “Throw it over the wall” behaviour - it’s not my problem • Lack of holistic understanding of the software delivery lifecycle • Slow pace of change • Expensive cost of change • Late discovery of issues in the project lifecycle • Unaligned goals and incentives – pulling in different directions 4
- 5. DevOps friction Moreprocessreviews Morechangecontrol reviews Moredeployment freezes Morestandardscontrol boards Morefrequentchanges Lowertolerancefor outage Morecomplex applications Morecomplex deployments Do more! Do less! RFC’s CAB Deployment guide Rollback guide Daily status calls Staff availability Issue tracking Environment booking Escalation processes Emergency processes Small change processes etc etcMr. Dev Mr. Ops
- 6. IT today 6 I’m a business analyst I’m a DBA I’m a developer I work in support I’m an infrastructure engineer I’m a business stakeholder I’m a release manager I’m a security consultant
- 7. Is DevOps the right name? • Why do we think the issue of working well together and aligning goals is limited to Development and Operations? • Shouldn’t everyone involved in the change process should work together to accomplish shared goals? • DevTestBizThingyOps should be the real name © J.Fletcher
- 8. DevOps – so what is it? 8 • “Bad behaviour arises when you abstract people away from the consequences of their actions” – Jez Humble • DevOps is a culture of empathy, shared goals and incentives
- 9. Disclaimer 9
- 10. The four pillars 10 Culture Process People Technology Culture – the things people do when there is no one around to tell them what to do Process – you need to have processes that support different silo's working together to achieve a fast pace of change People - if you don't have the right people then it doesn't matter how great your technology is Technology - what are the building blocks you need to be a mature DevOps enterprise?
- 11. 11 People
- 12. People • Restlessnes (relentlessly looking to improve themselves, others, processes etc) • Good technical ability across a broad skill set (understand as much of other people's jobs as possible) • Everyone can code and use version control • Everyone understands the test triangle • Organised in small product focused teams rather than technology silo's (align teams to the business not the technology) • Common incentive schemes • Favour automation and repeatability above anything else • CIO/CTO are DevOps biggest guardians & SME's and seek to destroy anything that affects that culture • Natural face-to-face influencers rather than endless emailers • Natural sharers of information • Take an interest in their specialism outside of work (i.e. go to conferences and take part in the wider community) 12
- 13. BermudaUS Europe London MarketsUK Hiscox yesterday (ish!)ITcapability Group development Group support Group infrastructure Group testing Group DBA Group release and deployment Group architecture
- 14. Hiscox tomorrow (ish!) Europe Dev Support Testing DBA Release and deployment Architecture UK Dev Support Testing DBA Release and deployment Architecture London market Dev Support Testing DBA Release and deployment Architecture USA Dev Support Testing DBA Release and deployment Architecture Bermuda Dev Support Testing DBA Release and deployment Architecture
- 15. Hiscox Model • Federated • Cross skilled teams • Cradle to grave responsibilities • Shared goals and incentives • Underpinned by the Platform Services Group
- 16. 16 Culture
- 17. Culture • Measure everything, always • Individuals have empathy for the rest of the team (i.e. they don't pass the buck) • Shared goals and incentives • Don't reward the fire fighter, reward the fire preventer • Reward innovation and challenging the status quo • Don't punish people when they try something new but fail • There is no IT and "business". IT as much "the business" as the sales people. • Seeking to break down silo's • "It's not my job" doesn't exist • "Its my server/code/network/database" doesn't exist • Individuals are empowered to make decisions • Top-up management rather than top-down 17
- 19. Shared goals, incentives, empathy & transparency 19
- 20. 20 Process
- 21. Process • Agile • Continuous Integration • Continuous Delivery • Lean • Fail-early, fail often • Release management team are facilitators of change not guardians of change (i.e. they try and aid change rather than stopping/slowing it) • All change (I mean all) goes through the pipeline from left to right (dev, test, acceptance, production) • Knowledge sharing and "just enough" documentation is part of the process • Measuring success and failure is part of the process • Retrospectives are part of the process 21
- 22. 22 Technology
- 23. Technology • TDD/BDD everything (including Puppet etc) • Everything is in version control (code, automated tests, server config etc) • Release automation tooling • Convergent desired state tooling • Public Cloud • The same trending, monitoring & alerting solutions available through nonprod & prod • Application Performance Management • Service Virtualisation • Continuous Integration • Continuous Unit tests • Continuous Service level tests • Continuous GUI tests • Performance testing 23
- 24. Platform Services • Growth of the business is challenging IT to find new and better ways to do things – Means working smarter not harder. Doesn’t mean an ever increasing head count • Platform Services helps break down silo’s between teams by providing a change platform that is re- usable between multiple teams • Help others use the platform (they don’t implement themselves!)
- 25. Core platform capabilities • Source code management • Artefact management • Automated application deployment • Automated server configuration • Load performance test • Automated functional test • Continuous Integration and automated code build • Application Performance Management • Agile planning • Defect management • More...
- 26. Be careful... You don’t solve a silo issue by creating another silo! BAD Having a team that evangelises DevOps ideas, concepts and tooling is GOOD
- 28. Just some of the benefits… • 150 deployments in the last 3 days in one application alone • The week before go-live on our biggest ever change program we reduced 17.5 man days of effort to about 10 minutes • Help enable changing a 10 week change cycle down to 2 weeks • We went from 1 person knowing how to do to do a release to thousands (kind of!) 28
- 29. DevOps has visibility at the highest levels 29 Project Sponsor My Bosses boss
- 30. DevOps – how – top 5 hints? 30 1. Employ the right people in the right team structure 2. Empower the team – let them make the right decisions 3. There are processes and tools that help align working practises to achieve empathy and shared goals (such as increasing the pace of change) 4. Commonly large amounts of automation is prevalent in a DevOps environment to create metrics, reduce manual wasted effort and increase the pace of change 5. Keep those 4 pillars in mind. DevOps isn’t just a technical challenge
- 31. Thanks and any questions? 31
Editor's Notes
- #4: Speed to Market and Pace of Change Self Service = predictable and reliable change Mis-aligned team objectives were hindering our ability to deliver
- #10: Utopia and what good looks like – we are there in parts and some are ambitions
- #11: 4 table legs doesn’t have the same impact
- #16: Not here yet but working towards it
- #26: If it has a silly name we own it
- #27: Jarjar – Phantom Menace Empire strikes back - Hoth
- #31: Lots of other people going to talk to you about the how today – tools and processes
- #32: Nothing to do with my DevOps but its my fav films