DevOps is a very charged word in the industry right now. There is a lot of information and opinions available and not everybody wants to go read several books just to get an idea of what we are talking about (a TL;DR problem). Because of this, I think a lot of people have developed conflicting or mistaken understandings of what DevOps actually is.

This is not meant as a comprehensive list of all things DevOps, but it is an attempt to distill the concept to key talking points based on what I've learned from various sources and experienced in my own career. There are no real absolutes – although this list is written in such a manner, it is meant to start the conversation. Figuring out which apply to your needs and constraints is what makes for interesting conversation.

First, let’s talk about what it is not:

DevOps is not Dev Owned Ops – It isn’t the removal of Operations (or as the Phoenix Project calls it, No-Ops). See Fox in the Henhouse for a more in-depth exploration of this challenge.
DevOps is not another name for System Administrator – If you have a DevOps team to do the specialized "DevOps" work or to act as an intermediary, you might be missing the point (it just depends upon how the team integrates and empowers).
DevOps is not automation or testing, although these play a critical role in DevOps.
DevOps is not ad-hoc free reign in production for everybody – There is a difference between Developers can access and manage production with automation, and Developers have ad-hoc administrative access to production. Because of inevitable security requirements, ad-hoc becomes an anti-pattern to DevOps.

To the last point: DevOps can be done in a secure and regulated/compliant manner if it is understood and done right. Many people have a mistaken belief that the two things are opposites. This is untrue.

At the most simple level, DevOps is:

Everybody owns Production

This means it is a shared responsibility between both Development and Operations. We respect and value both sides of the equation, their capabilities, and input. I worked at an organization where the ops side of the house felt like they were considered second-rate citizens to the developers, who could do no sin, and this sentiment was felt by indirect statements all the way from the top. This is detrimental to healthy DevOps.

DevOps is a change to how we behave. I think there are four basic principles, with sub principles around each:

1. Continuous Flow (Inside-Out)

Continuous Integration (CI) – code must automatically pass continuous integration testing, including quality and security tests before it can become part of the deployed code base.
Maintain fast automated test suites – not manual testing or QA processes.
Continuous Delivery (CD) – small and frequent deliveries triggered by the owner of the change, with post delivery automated testing and validation and easy rollback capability. See also: Sisyphus and Continuous Delivery, and Avoiding Calamitous Data Migrations.
Loose Coupling – Do not tightly couple services together, and when a breaking change in an interface is made, support previous versions so external dependencies do not have to be orchestrated in parallel to your change.
Kata – iterate and repeat your processes, making incremental improvements.
Flexible systems – create systems where it is easy to create environments on demand.
Infrastructure as Code can help, making it easier for flexible systems without ad-hoc access.
DevSecOps – everybody owns security, and is trained to understand it to the proper degree.
Scoped Security – Know what is your sensitive data, what its lifecycle is, and how you maintain a separation of duties around it. Your compliance and security requirements are clearly scoped, along with how this impacts your systems. Do not let compliance over-run things unnecessarily, but respect the requirements that are there.

2. Ownership & Visibility (Outside-In)

Direct Ownership – The team or person most able to address the problem is responsible for it (the owner). This can be development or platform.
Tools to Empower – remove bureaucracy: individuals can configure/maintain their own systems and tooling. Inserting people in the middle of processes to help can instead hinder. This doesn't mean everybody chooses their own tooling, but it does mean once the tooling is available, they own their part of it, and do not have to work through somebody else to effect a change (like changing a monitor service or updating a code repo).
Pipeline Stops on Errors – The continuous flow pipeline stops when there is a problem, no circumventing.
Test actual services with real health checks, not just “is it up” type pings.
The right people are contacted on call – Pain is first directed to those who can fix the problem. If everything goes through an ops-team or NOC to triage, you aren’t doing DevOps.
Notifications are actionable. The message needs to be clear as to the problem and environment affected, and the person being contacted should be able to do something about it most of the time.
Visibility is provided to the owner of the service, on how things are running, and they can improve it themselves (Tools to Empower).

3. Planning & Time Management

Understand your work centers – where is your work constrained? what types of work is it? Break out your work centers as needed help avoid bottlenecks.
Manage your work types and flow – understand the difference of product work and internal work. Manage "Yak Shaving" and take things in small increments, figure out how to not do it all at once. There are a number of project management processes available, pick one, understand it, and use it (I'm a fan of the hybrid Kanban/Scrum blend).
Elevate the improvement of routine work efforts over doing routine work – i.e. can you automate a routine task that has become a bottleneck?
Do not get comfortable with status-quo – question it constantly, but don’t be defensive when somebody questions your status-quo.
Be ready to change – Either your technology or others, take risks (like deploying frequently), but be able to react and recover.
Learn from your mistakes – Conduct regular post-mortems, don't be afraid to admit mistakes. Apply what you have learned.
Allocate time for non-product work and improvements (at least 20%) and encourage and highlight improvements in these areas, just as you celebrate improvements in your product. (And product work includes supporting products).

4. Culture

Build a culture that celebrates all of the aspects of DevOps
Don’t tolerate rock stars – Those people who must be at the center of attention and promote a “not built here” mentality. They arrive and want to do things the way they know, rather than taking the time to respect and understand the trials others have already gone through to get here.
Everybody owns Production – Has anybody ever stated or felt, “This isn't what I was hired for,” when presented with owning a part of production (such as being on-call)?
Understand the diversity of your team – expecting everybody to be amazing at all layers of your stack is too stressful. Instead, build a diverse team with people of different strengths and disciplines, and respect their contributions equally (front-end, back-end, platform).
Increase trust – get away from fear-driven command-and-control / over-the-fence operations, and allow others to take responsibility for themselves. See also: Delegate with Success and The Power of Sustainment.

So what is a DevOps Engineer?

The industry doesn't make it easy on us, and part of that is the trend to advertise for a DevOps Engineer as a position. Is this a contradiction of everything just discussed? Possibly, but it is the world we have. Somebody aspiring to be in a DevOps career might focus on:

Software development processes and practices (and having experience doing it is good)
Platforms, lower level systems, and how they come together.
How to use automation in bringing it all together.
How security plays a role in all of this, and how to manage it so it doesn't get out of control.
The above principles, and how they apply to your work flow as an integrated team, not as an isolated group.

How do I learn more?

These principles cover, at a high level, what DevOps really is. There are many other resources to read if you want to learn more, such as The Phoenix Project. To help with the design, work-scoping, and culture side, the book Activator describes Design Thinking, which is how Architects think. Design Thinking covers many of the same principles and is based on years of study and understanding. The Activator brings Design Thinking to the technology industry, with real-world and practical explanations. It is a valuable tool to use in team training, to help understand how DevOps can come into your organization.

Thoughts? Did I miss anything? Please share!

Image courtesy of Ayo Ogunseinde