DevOps: Chop wood. Carry water.
•Transferir como PPTX, PDF•
0 gostou•179 visualizações
A presentation on the fundamentals of DevOps.
Recomendados
Mais conteúdo relacionado
Mais de Everett Toews
Mais de Everett Toews (20)
Último
Último (20)
DevOps: Chop wood. Carry water.
- 1. DevOps Chop wood. Carry water.
- 6. DevOps != ● DevOps is not just throwing developers and operators together ● DevOps is not a team ● DevOps is not a job title ● DevOps is not tooling !=+
- 8. Principles ● Culture ● Automation ● Lean ● Learning ● Measurement ● Sharing
- 9. Practices ● Continuous Integration ● Continuous Delivery ● Infrastructure as Code ● Monitoring and Logging ● Communication and Collaboration
- 12. Velocity: Increasing productivity with continuous delivery
- 16. Beyond the code: People and processes
- 22. #winning ● BAU doing DevOps ○ ⭐ Special Guest Star ⭐ ● Testing doing DevOps ● Devs doing DevOps!
Notas do Editor
- Initial commit going to give you a brief history of devops as that will help you understand what it is in mid-2000s patrick wanted to learn IT from every angle from agile dev to firefighting and unpredictability of ops at agile 2008 conf in canada andrew proposed a session "agile infrastructure" only patrick showed, not even andrew but eventually they did meet and started a discussion group
- A milestone moment velocity 2009 conf: flickr talk on 10+ deploys per day patrick missed it but founded a conference where he knew he wanted to include dev and ops over a couple of days devopsdays was founded in 2009
- The evolution the term devops was simply dropping the days from devopsdays the discussion continued across the world and new devopsdays confs popped up all over the place it was very much a grass roots movement of people working in many different companies commiserating around the legacy tools and processes they'd been saddled with new open source tools gave them new capabilities
- Critical mass gartner caught on to it devops hit a critical mass and went mainstream DevOps Days devopsdays.org growth rate
- What it isn't DevOps is not just throwing developers and operators together Often the discussion around tooling and pipelines take up all of the oxygen in the room DevOps is not a team DevOps is not a job title DevOps is not tooling
- Agile and DevOps https://www.scaledagileframework.com/devops/
- Principles Culture from practitioners, by practitioners not a product, specification, job title an experience based movement decentralized and open to all Automation Lean Learning Measurement Sharing
- Practices Continuous Integration Continuous Delivery ← Continuous delivery allows for shifts around hidden bottlenecks in the release process Microservices Infrastructure as Code Monitoring and Logging Communication and Collaboration real-time communication fundamental enabler same-page comms ht in http and html incident management reduce email reduce meetings!
- Benefits This pertains to Dragonfly and the new OpenShift Container Platform More responsive to business needs Remove Siloes
- Think Customer Confidence Quality Experience Responsiveness (feedback) Delivery/Release engine (not about what but how) fine tuning our engine How Do We Improve Product Delivery to our Customer? How Do We Respond to Product Feedback More Quickly to Better Satisfy Our Customer? How Do We Recover Quickly in the Event of a Failure to Better Serve Our Customer?
- Velocity Release faster Dragonfly deployment at 8+ hours (most of that is DB time) Test envs get deployed very quickly Release often https://container-solutions.com/increasing-productivity-with-continuous-delivery/ Limiting WIP Resolve faster Releasing hotfixes faster Rapid rollback Faster feedback Every piece of in progress work slows the team down and each change to applications or infrastructure need to pass through multiple phases.
- Leaner processes Value stream mapping Explain it Whitelisting with the proxy Standard change window
- Reliability - Over the wall Older practice. Throwing a zip file over the wall to ops. Slightly less older practice is to copy/paste lines from a word document into container config Pipelines driven by environment config injected into deployments Shift left: explanation and shoutout to Dan's presentation Allows developers to develop more robust applications
- Platform Individual Docker hosts vs a Container Platform What it enables. A lot of these benefits. HA rescheduling - the incident that noone noticed rolling deployments Developer self service - GitOps no steps are missed or forgotten code commits/merges trigger the build and deploy process
- Beyond the Code: people and processes The context switching and WIP Current practice is ad hoc work User stories and planning the work Better managed unplanned work Bringing customer and delivery together for more impact Employee happiness
- Collaboration ← Teaching people to fish Upskilling ← Jenkins, Git, Ansible Cross functional teams and teaching people to fish RTFM (puts the onus on us to WTFM) Community (as opposed to lone wolf/cog in machine), humanity, Trust Better/Safe place to work Engaged/motivated people Bringing everyone along on the journey Establishing cross functional teams and using the principles of DevOps, Agile and Better Every Day to enhance the way we work.... blah blah .... we can build trust and establish better/safer practices Enabling self service - Knowledge sharing through communities of practices - Bringing everyone along on the journey
- Security: what it looks like for you lots of change. Are we being safe?
- Security: What it looks like for us Out of the box security (secure by design) for the platform Security stance from the traditional enterprise security mindset which is VM centric Transition to container-land and meeting in the middle Egress example Assessments have been going well
- ROI employee happiness/retention/recruitment/satisfaction time required for a new employee to deploy code to production employee time spent on new initiatives vs. running existing processes confidence levels customer satisfaction State of DevOps 2018 deployment frequency lead time for changes time to restore service change failure rate overall product availability SRE service level indicators (SLIs): a carefully defined quantitative measure of some aspect of the level of service that is provided service level objectives (SLOs): a target value or range of values for a service level that is measured by an SLI service level agreements (SLAs): an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain
- The next steps Long-term game of creating a world class company Get this thing off the ground The Phoenix Project and The DevOps Handbook Platform Engineering SRE
- Conclusion What DevOps means to EPL thinking customer - quality, feedback, confidence happier, more engaged teams faster, more robust development cycles Chop wood. Carry water.