An Approach to Devops
•
2 j'aime•943 vues
Devops needs a change management thinking. It is way beyond tools and practices.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à An Approach to Devops
Similaire à An Approach to Devops (20)
Dernier
Dernier (20)
An Approach to Devops
- 1. AN APPROACH TO DEVOPS A talk by Kamal Manglani
- 2. Why are we doing Devops? Co-create a vision! Your story is unique to your company…
- 3. Single Operator, Stopped automatically if there was an error
- 5. 1.SLA violations 2. Un-clear requirements/ poor quality delivery/ defects 3.Burnout of specific members 4.Almost no visibility 5.Constant escalations PRE-DEVOPS
- 6. Devops mindset enables high-performing organizations(teams) to have a fast flow of features from dev to ops retaining high quality reliability and stability. The leadership team must be ready for a real change in Infrastructure operations and ensure organizational awareness that ops is an “Internal Customer” to dev, portfolio and product management. Organizations need to realize DevOps is where the value gets realized. Think of it as ValueOps not just DevOps.
- 7. Simplified Roadmap for Devops enablement
- 8. key metrics Lead time: time to enable a feature from concept to release MTTR - average time required to repair a failed service/ component Number of deployments (experiments) & outcomes Customer Satisfaction Examples of monitoring and alerting to get ahead of the problem:
- 9. 3 ways of Devops thinking
- 10. first way: look at the system as a whole. Do not optimize individual components. This implies treat the next application or service using your data/ payload as a customer! (do not pass bad data/ bugs downstream) Bring the downstream application owners/ infra owners to inceptions and sprint reviews Integrate early and often via automation
- 11. Second way: Establish a valid fast feedback loop. Hire fearless members who can give quick feedback and fix things faster. Automate alerts and monitoring Enable small deployments with light weight processes Deploy often AB testing
- 12. Third way: include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience. Automation regression tests reward proactive alerting and monitoring service resiliency e.g. chaos monkey
- 13. Stretch the definition of the DevOps term to fit Product Owners, without them it is just not effective enough.
- 15. In order to minimize the risk of deploying something broken As the team deploying the code We want to spend a few days on an automated deployment system. Verify that all web-based requests get thru the service layers and receive a reply within 2 seconds Infrastructure Story
- 16. Shared tools across Dev & Operations
- 17. Stand ups and Big Visible Information radiators DevOps needs stand ups not within infrastructure but within the value stream. It is tricky to give status to every development team hence a simple visible board to reflect backlog / in-progress (WIP LIMIT) / Review & DONE wi go a long way in improving customer satisfaction and visibility.
- 18. Stand ups or a Daily Ops review
- 21. Information radiators and build failures & shared pipeline we build quality in Developers and Infrastructure must start to talk in the same language through tools.Have a strategy for the deployment pipeline. Don’t just look at it as code line up but as a Value Stream right from Product Management to Deployment. Ensure every team and department managing a high quality deployment pipeline. Every time there is a code failure it must be fixed right then, validated and deployed in the respective environments, this will enable you to keep all your environments in sync with updated with code/bug fixes.
- 22. Remove excessive approval gates in terms of heavy bureaucratic change management meetings
- 23. optimize hand off - no one size fits all Ensure your organization has a decent portfolio management framework that uses the unit of capacity as team not as headcount only. Portfolios should look at whole teams servicing a market/ P&L rather than just headcount and ideally these product-centric teams will remain intact beyond the “project”. This is especially important when you are dealing with large scale. Enable and empower engineers on the team to pick up cross functional skills for example a Sys Admin must be able to work on cloud compute as well as physical hardware, and on various operating systems. Change the performance review process and make it more team centric than individual performance.
- 24. Example of Infrastructure squads at spotify
- 26. There will never be a perfect devops team! Constantly evolving! Goal is to eliminate wait time & hand off.
- 27. Tranformative role - Agile coach: As an Agile Coach you are passionate about communication, group dynamics and coaching and you are not afraid to raise issues and drive change to remove impediments from your team. You should have an insatiable appetite for learning new things and improving existing ones, you pay attention to details and take great pride in your work. Someone who can help management at all levels of the organization to understand the benefits of working agile Someone who has brought the ideas from professional facilitation, coaching, conflict management, meditation, theater, and more, to help the team become a high-performance team - the way you always imagined a high-performance team could be when you allowed yourself to dream
- 28. One approach to enterprise Agile adoption that is gaining traction is to establish an Enterprise Agile Working Group (AWG), a group of people dedicated solely to the implementation of Agile at the enterprise level. An AWG can greatly reduce risk, increase the speed and establish a sustainable engine for growth of the enterprise transition of Agile in the enterprise. What is an AWG? An AWG is a Scrum team whose product is the enterprise implementation of Agile. Although it does not necessarily produce software (it certainly could if it helps add value to the product), it works on a prioritized list of backlog items that is demonstrated to a set of stakeholders in a predictable, set cadence. Let’s have a look at why establishing such a group can be so powerful when implementing Agile at the enterprise level.