Redefine the goals of Ops
In an organization, if the interests of relevant stakeholders are inconsistent, there will be many obstacles in the progress of the established process. At this point, the first thing to do is to align the interests of Dev and Ops, thereby reducing Ops' resistance to software delivery. In the speech, John Allspaw and Paul Hammond first challenged the traditional view of
Dev and Ops.
The traditional view is that the work of Dev and Ops is different:
Dev’s job is to add new features
Ops' job is to ensure the stability and high performance of the site
They believe that ensuring the stability and high performance of the site is not the goal of Ops.
Ops' work goal should be to enable the business, which is consistent with Dev.
Ideals are often beautiful, and reality is often cruel. Activating the business will bring more changes, and more changes will cause failures!
Faced with such a problem, a choice needs to be made: to reduce changes in order to ensure stability, or to change in time on demand?
There is an Arab proverb: "If you don't want to do it, you will find an excuse. If you want to do it, you will find a way."
Flicker did not succumb to the pressure, they chose to compromise the problem to the goal instead of the goal to the problem. Their methods are:
Build tools and culture for mutual cooperation
The key to reducing the risk of change is to improve reliability. This is not only in Dev in software development, but also requires Ops to inject reliability into the software development process through non-functional requirements (performance requirements, scalability, security, etc.). Improve delivery quality through built-in quality in the system delivery process instead of post-inspection.
The specific contradictions between Dev and Ops are manifested in the following two aspects:
The Ops review at the downstream of the value stream believes that the non-functional quality of Dev software upstream of the value chain does not meet the requirements, and therefore prevents changes.
Dev in the upstream of the value stream cannot obtain the real operating environment of Ops in the downstream of the value chain, and therefore cannot improve the quality of delivery.
As a result, it has gradually fallen into an endless loop of "cannot improve quality" and "non-functional quality does not meet requirements".
Since the Dev link is concerned with functional requirements, non-functional requirements are often ignored, while Ops is more concerned with non-functional requirements. Therefore, through the built-in quality, operation and maintenance are added to the development feedback loop. Increase the realization and acceptance of non-functional requirements in the development process, and let Ops play the role of the final QA. Thereby improving the delivery quality and speed of feedback.
First, they have improved the quality and efficiency of infrastructure preparation through Automated infrastructure.
Second, they built a bridge between Dev and Ops delivery: Shared Version Control (Shared Version Control) and managed feature release through Feature flags.
Then, through one step build and deploy (One step build and deploy) and frequent small changes (Small frequent changes) to increase the speed of one-way value flow and reduce deployment risks.
Finally, the use of shared operation and maintenance indicators (Shared metrics), and instant messaging tool integration (IRC and IM robots) to improve communication efficiency to achieve timely feedback and improvement.
But these alone are not enough. A culture of cooperation needs to be built. The key to the construction of a cooperative culture is the respect between Dev and Ops, mutual trust, and an attitude of improvement in the face of failure rather than blame.
The first DevOpsDays went further in the direction of inheriting these ideas. The first DevOpsDays attracted more people who focused on this field, and they did not even have a technical background.
The goal of DevOps-to improve the quality of software delivery built-in to accelerate the process
After the first DevOpsDays meeting, as the initiator of the DevOpsDays event and the founder of the word DevOps, Patrick Debois then summarized and wrote the article "Charting out devops ideas", and he made the first DevOpsDays a follow-up DevOps movement The cornerstone of the concept. In this article, Patrick has two important observations from the first DevOps event, namely:
1. DevOps adds a feedback loop to the feedback loop between business, delivery process, and operation and maintenance.
2. Because of such a link, we can improve quality to speed up the process.
In short,
DevOps adds operations and maintenance (Ops) to the feedback loop of the value stream. And by improving the quality of software delivery built-in to accelerate the end-to-end feedback efficiency of the value chain.
To achieve this goal, some means must be adopted.
DevOps means-technology upgrade and process management
At the same time, Patrick found that all the topics of DevOpsDays revolved around two main lines: technology and process management, and these topics were intertwined to form four different feedback loops.
DevOps feedback loop
Development-test feedback loop (black arrow feedback loop):
Technical aspects:
Software architecture driven by non-functional features (scalability, availability): use NO-SQL database or queue system (Queue System) to increase system scalability, and mix programming languages and caching systems like memcache.
Process management:
Close the interaction between software development and system engineering: use agile teams or other forms of multifunctional teams across different departmental walls.
Development-operation and maintenance feedback loop (green arrow feedback loop):
Technical aspects:
System administrators adopt software development techniques: use code warehouses, continuous integration, testing tools, and design patterns to automate the initialization operations of the system.
Deployment configuration management: configuration management and automated configuration tools (Chef, Puppet) are used for deployment and production environment changes.
Test and monitoring assist each other: reuse automated test logic (such as cucumber-nagios) in the monitoring system, and use monitoring means to verify test scenarios in the test environment.
The operation and maintenance team develops new system management tools: Tools are also an important manifestation of the technological gap. Many system administrators develop new tools to handle large-scale deployments, changes, and monitoring.
Process management:
Close the interaction between software development and systems engineering: Agile projects or other methods to form multifunctional teams replace different departmental walls.
The project learns from operation and maintenance: The architecture continuously gets feedback in the project, so that it knows what can be used and what cannot be used. This can result in a better architecture design.
Business-operation and maintenance feedback loop (red arrow feedback loop):
Technical aspects:
New system architecture based on cloud computing and agile infrastructure: Cloud computing and agile infrastructure can obtain better and more advanced automated deployment methods and system initialization methods.
Process management:
The business department should focus on both functional and non-functional requirements: the business should begin to focus on the impact of downtime and data loss.
The operation and maintenance team participates in the upstream of the process rather than a passive role: Kanban is used in the operation and maintenance to interact at the project stage, and can even be used in the pre-project stage (sales, service level management).
The operation and maintenance team self-organizes to meet business challenges: for example, introducing agile into operation and maintenance (agile operations) or introducing lean into operation and maintenance (lean operations).
The business uses operation and maintenance metrics as feedback: to understand what users like and how to act. In order to make better business decisions, performance degradation or failure interruption is becoming an important feedback loop.
Business-user feedback loop (purple arrow feedback loop):
Process management:
Operation and maintenance as the first responder to user problems: Operation and maintenance personnel, like sales personnel, can serve as the first line of handling user problems and feedback to the business department.
Through the above four feedback loops, we found two key points:
1. DevOps is not just a matter for the IT department, it involves departments other than the IT department, including end users. In the context of breaking away from Internet companies like Flicker. Enterprise-level IT departments will encounter more external challenges when adopting DevOps.
2. New technologies, especially the deepening of agile software development concepts and the continuous development of large-scale infrastructure (virtualization, cloud computing, SDN) make it possible for Ops to work in a Dev way.
