anitsh
commented
3 years ago DevOps
DevOps is a philosophy and an approach to working.
DevOps is a broad set of principles about whole-lifecycle collaboration between operations and product development.
DevOps is a loose set of practices, guidelines, and culture designed to break down silos in IT development, operations, networking, and security.
DevOps movement originated from collaborations between leaders and practitioners at multiple companies.
Articulated by John Willis, Damon Edwards, and Jez Humble, CALMS — which stands for Culture, Automation, Lean (as in Lean management; also see continuous delivery), Measurement, and Sharing — is a useful acronym for remembering the key points of DevOps philosophy. Sharing and collaboration are at the forefront of this movement. In a DevOps approach, you improve something (often by automating it), measure the results, and share those results with colleagues so the whole organization can improve. All of the CALMS principles are facilitated by a supportive culture.
DevOps, Agile, and a variety of other business and software reengineering techniques are all examples of a general worldview on how best to do business in the modern world. None of the elements in the DevOps philosophy are easily separable from each other, and this is essentially by design. There are, however, a few key ideas that can be discussed in relative isolation.
No More Silos
The first key idea is no more silos. This is a reaction to a couple ideas:
The historically popular but now increasingly old-fashioned arrangement of separate operations and development teams
The fact that extreme siloization of knowledge, incentives for purely local optimization, and lack of collaboration have in many cases been actively bad for business4Accidents Are Normal
The second key idea is that accidents are not just a result of the isolated actions of an individual, but rather result from missing safeguards for when things inevitably go wrong.5 For example, a bad interface inadvertently encourages the wrong action under pressure; a system misfeature makes failure inevitable if the (unarticulated) wrong circumstances occur; broken monitoring makes it impossible to know if something is wrong, never mind what is wrong. Some more traditionally minded businesses possess the cultural instinct to root out the mistake maker and punish them. But doing so has its own consequences: most obviously, it creates incentives to confuse issues, hide the truth, and blame others, all of which are ultimately unprofitable distractions. Therefore, it is more profitable to focus on speeding recovery than preventing accidents.
Change Should Be Gradual
The third key idea is that change is best when it is small and frequent. In environments where change committees meet monthly to discuss thoroughly documented plans to make changes to the mainframe configuration, this is a radical idea. However, this is not a new idea. The notion that all changes must be considered by experienced humans and batched for efficient consideration turns out to be more or less the opposite of best practice. Change is risky, true, but the correct response is to split up your changes into smaller subcomponents where possible. Then you build a steady pipeline of low-risk change out of regular output from product, design, and infrastructure changes.6 This strategy, coupled with automatic testing of smaller changes and reliable rollback of bad changes, leads to approaches to change management like continuous integration (CI) and continuous delivery or deployment (CD).
Tooling and Culture Are Interrelated
Tooling is an important component of DevOps, particularly given the emphasis on managing change correctly—today, change management relies on highly specific tools. Overall, however, proponents of DevOps strongly emphasize organizational culture—rather than tooling—as the key to success in adopting a new way of working. A good culture can work around broken tooling, but the opposite rarely holds true. As the saying goes, culture eats strategy for breakfast. Like operations, change itself is hard.
Measurement Is Crucial
Finally, measurement is particularly crucial in the overall business context of, for example, breaking down silos and incident resolution. In each of these environments, you establish the reality of what’s happening by means of objective measurement, verify that you’re changing the situation as you expect, and create an objective foundation for conversations that different functions agree upon. (This applies in both business and other contexts, such as on-call.)
DevOps improve performance in software development and delivery by
Increase the speed of deployments Improve the stability of your software Build security in from the start
DevOps Status Quick Check
https://www.devops-research.com/quickcheck.html
Measure your DevOps performance with the Four Keys project
https://github.com/GoogleCloudPlatform/fourkeys Through six years of research, the DevOps Research and Assessment (DORA) team has identified four key metrics that indicate the performance of a software development team. Four Keys allows you to collect data from your development environment (such as GitHub or GitLab) and compiles it into a dashboard displaying these key metrics.
These four key metrics are:
- Deployment Frequency
- Lead Time for Changes
- Time to Restore Services
- Change Failure Rate
The Mindset
A DevSecOps approach is based on the idea that security is incorporated throughout the entire software development process, bringing together app dev, operations and security teams.
Enable the business.DevSecOps should be built in the part of the development lifecycle. Get the security outcomes your organization needs: • Reduce time to remediate security vulnerabilities • Improve visibility and control of container contents and lifecycle • Reduce toil for security, compliance, and DevOps teams
Resource