preface
Originally published on Patrick Debois’ official website, Portal
The whole story revolves around operations, emphasizing the need for operations and developers to work together, which is probably the core value of the DevOps concept. Probably because the author is from Belgium. The translation is still a bit difficult. As far as possible to ensure the original taste, shortcomings, please correct!
Writing background
The LISA (Large Installation System Administration) Summit in 2011 had a theme about “DevOps.”
The attendees had been around automation for a long time, and many thought they were working on DevOps every day.
Then they wanted to hire me for Usenix; Login Magazine has written an article explaining DevOps from a system administrator’s perspective. Since reading this article also requires a subscription to the magazine, I simply posted it on my website for other readers to read.
introduce
Although there is no real definition of DevOps, DevOps can be broken down into four key points (CAMS) :
- Culture
- Automation
- Measurement indicators
- Sharing
In this article, we can see how these four elements affect system administrators.
As a systems administrator, you’re probably familiar with both Automation and Measurement, and there are industry best practices that make automated work faster and more repeatable. In addition, in order to ensure that the system runs more smoothly, collect some system operation indicators, take some necessary monitoring measures have become an indispensable part of the daily work.
Pain points
For a long time, operations (usually part of a system administrator’s job) has been seen as the last step in software delivery.
Throughout the project, developers coded independently of operations, and once the software was developed, they decided it was time to hand it over to operations.
Many problems were exposed during the development process. In development and test environments, some typical use cases do not work in production environments, or lack an effective backup and restore strategy. It was too late to change the system architecture and code structure during the development of the project, and the developers could only come up with temporary solutions.
This friction has led to a lack of respect between developers and operations. Developers think operations people don’t know anything about the software they’re developing, and operations people think developers don’t know anything about server running.
Managing the two units independently, with little communication between them, has created a Wall of Confusion between them.
The Art of Collaboration
In fact, DevOps is driven by two factors:
The first is agile development. The agile development model has led many companies to deploy their operations staff more than ever before. (Small trial and error, fast iteration)
The second is the operational requirements of cloud computing and cloud storage on a large scale, where development and operations require closer collaboration.
Whenever a problem arises, companies often create a multi-tasking team to solve a production problem. The reality is that today’s IT infrastructure environment is far too complex to be managed by a single person or organization. So instead of keeping development and operations separate, as they had been before, merge them.
If it’s hard, do it more often, we believe.
The DevOps philosophy is that software is valuable only when it is released to production, and a server running no software is worthless.
R&d and operations share a common goal of serving customers, not acting separately.
Although systems administrators have collaborated with other departments, this collaboration has never been considered a strategic advantage. The core cultural value of DevOps is to better meet business needs and promote continuous collaboration across departments. DevOps is a way to reduce conflict and promote cross-departmental/interdisciplinary communication.
A good place to start collaborating is to discuss areas of frequent improvement: deployment, packaging, testing, monitoring, build environments.
These can be thought of as “boundary objects”, and everyone has their own interpretation of them. It is also the epicenter of technical debt accumulation, so it also covers the pain points of everyday work.
Culture of Sharing
There are all kinds of gaps in companies, not just between developers and operations, but even within operations: the network, security, storage, servers, etc. don’t work well together, each operating in its own world. This is called the “ops-ops” problem, so in geek language, DevOps is actually described as DevOps *. (Translator’s note: The development department needs to connect with multiple operations departments)
DevOps does not mean that system administrators need to know how to program, nor does it mean that all developers need to know how to deploy servers. From the point of view of the cooperation itself, the staff of the two departments can learn from each other and respond to each other in time in daily work. This is a means of communication between developers and testers in agile development. DevOps can be seen as an extension of bringing system administrators into agile development projects.
Sometimes it takes a certain amount of courage for developers and operations to start a conversation, but it’s worth it considering the benefits: as your app grows, you learn along the way, and you can actively shape it with your own investment.
System administrators have a lot to offer developers: you know what the production environment looks like, so you can build a more representative development/test environment based on that. Echoing the pain points section), you can participate in stress testing, failover testing, or you can install a monitoring system so developers can see what went wrong. In addition, you can develop log access rights for the production environment so that developers can know how the application is actually running in the production environment.
A great way to share information and knowledge is to pair up with a developer or colleague: when you deploy, he does an impact assessment of the code being deployed, and you can ask him questions directly.
Such interactions can be very valuable in getting to know each other’s work.
Review Automation (Revisiting Automation)
As the Agile Manifesto puts it, DevOps values “individuals and interactions over processes and tools.” The great thing about tools is that they are concrete and can benefit directly from culture.
It’s hard to appreciate the impact of virtualization and the cloud without actually getting started. Tools can shape the way we work, which in turn changes our behavior.
Configuration Management and Infrastructure as Code are good examples.
Many people praise automation for its power and flexibility, but if you think about it in terms of time savings, it has a very big benefit: creating a “shared” language that allows you to communicate with other colleagues about how to manage systems, and even publish cookbooks on GitHub.
Because we (operations) know some of the concepts of version control and testing, we have some common problems with developers. Most importantly, automation frees us up from trivial things and allows us to discuss and focus on the things that really matter.
Review Metrics (Revisiting Metrics)
The index of collaboration can not be simply measured by the number of communication, after all, no amount of communication will necessarily mean better results. It’s similar to a black hole, and you have to look at nearby objects.
So, how do you look at whether things are improving?
As an operations engineer, you collect metrics about the number of production accidents, deployment failures/successes, etc. Rather than keep this data internally, share it with other parts of the company so that people in other parts can learn from it as well. Conduct a post-mortem with all stakeholders and make improvements.
At the same time, this changes the focus of measurement and monitoring from quick fixes by operations to timely feedback throughout the organization. The goal is to optimize for the whole, not just the parts of your job.
The secret sauce
Several “new” companies are leading the way in these practices.
Google’s Two-Pizza Team and Flick’s 10 Deploys a Day are pioneers in this area.
But many traditional companies, such as National Instruments, see value in this culture of collaboration.
These companies see this collaboration model as a “secret sauce” that will give them an edge over their competition.
Why is that?
Because it recognizes that the individual is not a resource, but an intelligence to deal with the challenges that exist in this complex world.
The attached:
References:
1. John Willis, What Devops Means to Me
Damon Edwards, What is Devops
3. Israel Gat, Boundary objects in Devops
4, Amazon Architecture
John Allspaw, 10 Deploys per day-dev and Ops cooperation at Flickr
Jesse Robbins, Operations is a competitive advantage
Share daily dry goods, deliver valuable information of the Internet world, all in “Technology pool”