Top 10 DevOps Tips
Focus on your people.
The people who focus on tooling in DevOps are selling you a product.
DevOps is a philosophy and practices that focuses on people — most importantly engineers.
Happy engineers make great software. Period. And in order to create a culture in which your engineers will thrive, you must focus on creating a collaborative work environment focused on mutual respect, learning, and engineer empowerment.
Embrace the 5 core principles of DevOps.
I talk about people, process, and technology when I speak on DevOps. And the priorities go in that order. If you prioritize technology before process, you'll end up automating failure, which is never good. And if you put process or technology before your engineers, you'll lose out on the potential acceleration of highly collaborative and communicative engineers. (Not to mention your trouble acquiring and retaining talent.)
Underpinning those DevOps priorities are 5 core tenets, shortened to CALMS:
Culture: Highly effective DevOps teams embody a culture of ownership and healthy communication. Engineers respect each other, understand each other's work, and operate cross-functionally.
Automation: DevOps organizations reduce toil — manual, reactive, and often rote work — through automation. If you have to do something twice, there's a good chance it can be automated.
Lean: Engineering organizations that adopt DevOps are agile (and often scrappy). These teams center the customer and iterate rapidly by embracing a growth mindset.
Measurement: You can't know how successful you are unless you measure your progress. But be careful; progress should be measured as a team and never used to evaluate individual performance.
Sharing: DevOps originates out of the friction that exists between operations engineers and developers in traditional engineering teams. DevOps removes the barriers between those groups and enables everyone to share knowledge, learn, and respect each other's contributions to overall team performance.
In traditional engineering organizations, the incentives of each team is different. This can cause extreme friction between engineers, eventually evolving into animosity. (Or what I like to call good ol' Southern passive aggressiveness. This is plight can be identified by rolling eyes and audible sighs.)
In order to avoid this, DevOps focuses on eliminating silos of responsibility. For example, it used to be that developers wrote code and tossed it over the operations folks to deploy and support. If there was a problem in the code, it was up to the ops person to prevent the bad code from being released to customers. And you can imagine the irritation this might cause your average developer. (Operations isn't the only team impacted by this. Security suffers equally, if not more.)
Rather than measure developers by one criteria and operations engineers by another, unify the team by evaluating the velocity of the entire organization, together.
Micromanagement is one of the quickest ways to undermine the potential of your engineering team.
If you hire talented engineers, your job as a manager is to remove the friction from their day-to-day work. Not to review every single little thing they do. They're talented. Step back and let them do what they do best: engineer solutions.
Extrinsic motivators are typically expressed through money. You should absolutely pay your employees a fair market wage. But be careful not to leverage salaries, bonuses, and stock options as your only tools to motivate engineers.
Instead, look at job satisfaction and professional growth. Try to strike a balance between challenging your engineers with exciting opportunities and stressing them out with unrealistic expectations (or deadlines).
Trust your employees. Enable them to exercise their passion for their work. Give them space to experiment. And protect them from external pressure.
Make iterative progress.
It's easy to get started on a DevOps transformation, see everything you're doing "wrong," and want to make significant changes across your organization.
Don't. Don't boil the ocean because you feel behind. I guarantee you're not as far behind the average as you think you are. If you make too many changes too quickly, you risk alarming your engineers. You could find yourself in an all-out revolt, or what I like to call Mutiny on the Binary. And you'll likely miss the small wins that can help propel you through challenges.
Instead, be realistic about your current progress and start measuring your team's velocity. Change one thing at a time and evaluate the benefit. This will enable you to quantitatively show your progress to executives (not to mention make everyone feel good).
Learn from failure.
The startup world loves the term failing fast, but few actually implement the customer-focused rapid iteration the original phrase embodied.
At the center of failing fast is learning from mistakes. Something I like to think of asfailing well. For me, the key to failing well is to ensure your team seeks to learn rather than blame when something goes wrong. It also requires you to control the blast radius when taking risks. In other words, when you experiment, make sure it's in isolation so mistakes don't cascade into massive incidents or outages.
Kaizen is an ancient Japanese practice of continuous improvement. In DevOps, this means to a focus on iterative (and never-ending) process improvement.
You'll never go from zero to perfect. That's impossible. Instead, I encourage you to make graduate change. When you focus on making one thing better, and then another, and then another, you'll soon find you've made massive progress toward you long-term goals.
The key to learning from failure is a growth mindset. Making a mistake doesn't make you're stupid. It simply means your human. Avoiding failure at all costs simply means you'll be unprepared when something unexpected (or catastrophic) eventually happens. Preparing and learning from failure is what separates DevOps organizations from those who consistently fail to take the risks required to innovate.
DevOps isn't a title.
Except when it is.
DevOps was never intended to be a job title or role. It was a philosophy for all engineers to adopt and embody in their work.
But thanks to resume driven development (RDD), the role of DevOps engineer is increasingly common. And for good reason, simply adding DevOps to your job title can boost your salary by up to $40,000 per year. I say go for it!
There are a few ways of integrating DevOps into your engineering organization's hierarchy. Some companies choose to form a dedicated DevOps team. More often than not, this is just a renamed operations team. Others choose to focus on aligning the functional teams that already exist. When opting for alignment, it's critical that every team is involved in the planning process and has ownership over the end product. The other way companies solve this challenge is to create cross-functional product teams. In these teams, there may be two developers, one operations engineer, a security expert, and a designer. In another, you may add a site reliability engineer, frontend developer, or project manager.
However you choose to structure your teams, emphasize the values and practices of DevOps over job titles. Make room for people to switch teams and pursue different areas of expertise. And don't forget to enable space for tribes to form — groups of engineers who come together naturally out of a shared expertise or passion. These unofficial tribes can help people to form relationships with colleagues from other areas of the organization and share ideas.
Create resilient systems.
With the recent focus on site reliability engineering (SRE), the concept of reliability has come to the forefront of operations considerations. How do you build systems that are consistently available and tolerant of service outages?
The answer lies at the start of the software delivery lifecycle in the planning process. In DevOps, you must bring everyone to the table to think through potential risks and architecture decisions before a single line of code is written. This empowers everyone to share their unique perspective and prepare for their role in the eventual product.
Unplanned disruptions are part of software. There's simply no way you can predict the millions of ways your system can fail (from minor blips in your monitoring to full-on outages).
From the technical point of view, architectural decisions like implementing decoupled microservices can enable services to fail independently without impacting other areas of the system. And public cloud services can create redundancy and elastic scaling (among other benefits). But the processes you adopt are equally important, especially your incident management plan. Ensure everyone has a clear understanding of monitoring, alerting, on-call rotations, and how the team will respond to incidents.
Choose your DevOps tools carefully.
I deprioritize tooling in DevOps — and rightfully so — but it is still an important aspect. The technologies you choose to utilize will impact your DevOps success.
Choose tools that align with the style, knowledge, and (sometimes) comfort of your team. There are times where everyone must stretch beyond their comfort zone. But I do recommend taking advantage of the knowledge your team already possesses. Learning, while critical, does take time.
I recommend trying out several different solutions and seeing which one fits. Dedicate a few weeks of engineering resources to a minimum viable product (MVP). Believe me, it won't be a waste. It will be significantly more expensive to adopt a tool haphazardly and eventually have to undo it.
DevOps is not a one size fits all solution. It's not prescriptive. Which means you and your team must embrace some flexibility in aligning the principles and practices of DevOps to the specific needs of your team.
Every group of humans is a little bit different. And you'll learn how to adapt DevOps advice to your unique engineering team. The trick is to take everything as a suggestion, experiment, and identify through which changes your team benefits the most.
Just get started. That's the important part. Measure your progress, prioritize culture over technology, and empower your engineers to do what they do best. I believe with DevOps you can have real impact on our industry. And especially on your team.
DevOps for Dummies