You can also apply these to existing DevOps teams and level-up your organization.
Let's get started!
Polish your DevOps Philosophy
You must first understand why organizations need DevOps, and how it can work in practice.
DevOps is an enabler role.
It's meant to enable the developers to build, improve, and take ownership over the system.
Let's break it down:
Build = Create something new. Could be a new microservice, a new database, or a new monitoring dashboard.
Improve = Introduce a change into something that exists. Could be fixing a bug, changing a database schema, or changing an alert threshold.
Take ownership = Take charge of problems that arise with what you built and improved. This means when something needs improvement, the owner is the one who does it.
The above are what the developers should do.
Now, DevOps should enable it.
Note, to enable is not to give full permissions and let them have fun.
To enable is to give developers what they need to build, improve, and own the system.
But, do it in a way that focuses the developers' energy in the right direction, and in a safe way.
Understand the DevOps Lead Responsibilities
You have 5 hats as a DevOps Lead:
Product (Platform) Your clients are your company's developers. Provide them with tools, knowledge, and automations. Tools = Polished automations. Automations = Automated knowledge. Knowledge = Hard-earned information & insights. Understand their requirements, and use Tools, Automations, and Knowledge to fulfill them. Understand why they want what they want: Is it because of an underlying issue with the system? If yes, solve it before building anything. If a tool or automation will save time, consider building or implementing it.
Service Don't let your developers wait until you do something "the right way". Sometimes they need immediate help to complete something. Help them first, and invest time later in automation and tooling.
Project Managing your DevOps team requires managing the work it does. Turn the team's philosophy into a mission. Turn the team's mission into goals. Turn the team's goals into a roadmap. Turn the team's roadmap into tasks. Prioritize the tasks. Set simple roles and responsibilities. Hold your team members accountable to progression. Make it easy to inform relevant team members on updates. Make it easy to consult with a teammate on a subject of their expertise.
People Each DevOps team member has type of work and tasks they enjoy more. One enjoys sharing knowledge, another enjoys being of service, and some enjoy building tools. Different teammates are also interested in different subjects: Monitoring, Infrastructure, CI/CD, etc. A team member that's working on what they enjoy is more fulfilled and productive. Strive to overlap each teammate's goals with the company's goals.
Architecture You have 2 architectures to worry about. 1) The company's product architecture (built by the developers). 2) The DevOps platform's architecture (built by the DevOps team). Help the developers understand and control the application's effect on the infrastructure. Enable the developers to make informed decisions by providing context. Finally, build the platform to support the developers requirements. At every step, only limit decisions that damage the company. Examples: High cost, Stability impairment, Restricts observability, etc.
Define Your DevOps Team's Mission Statement
Here's one for you:
"Enable the developers to build, improve, and own the system".
It's pretty minimal, so it's going to help your team stay focused.
A healthy sign it catches on: When the team debates a decision regarding a task, they ask "Does it help us enable the developers to build, improve, or own the system?".
That's when you win.
Set useful DevOps Goals & Practices
Your company's success will be determined by its speed and its product's quality. To make it happen, you should know programming is science, not maths - I'll explain.
People used to think programming will be a mathematical discipline. They thought programmers will write functions and mathematically prove them.
Not what happened - Programming is a scientific discipline. You write code, your test it, and you assume it's good - until one test fails.
In essence, you're experimenting.
You might ask: "wtf? how's this related to setting useful goals?" The answer is that the first thing you want to enable is running experiments easily.
So here are some useful goals:
Developers can easily test their code in a consistent manner
Production and testing environments are identical (Production will benefit from the quality of the tests)
Developers can easily collaborate
Developers can understand the state of the system and the impact of changes
Let's translate those goals into smaller goals or practices that will achieve the goals:
There's a continuous integration process that enables the developers to collaborate by agreeing on the current up-to-date version of the system
Auto-create dashboards and alerts for new services
Set Guiding DevOps Principles
Some useful DevOps principles that help save your team time, improve the speed of delivery, and keep the system healthy:
PoC before doing things "the right way"
Make it work, then make it better
The entire system should be fully recoverable from Git
Use tools with a big community and well-documented interface
Equip key-developers with DevOps knowledge to be the first point-of-contact for their team members (super users)
Define the DevOps team's roadmap & strategy
Roadmap = Goals * Strategy.
Once you set the goals (as mentioned above), you can start prioritizing.
#1 - The DevOps Categories
Enabling developers requires a DevOps Engineer to handle and enable the following:
Provision infrastructure
Deploy workloads
Monitor the system
Recover from issues
Scale up and down
Track & test changes (Codebase Management)
Secure the system
Store & retrieve data
Configure the system
#2 - Examine each goal through each category
Every DevOps goal you set should be examined through the lens of each category.
The reason is that together the categories cover each aspect of the building, improving, and owning of a software operation.
Let's do an example:
Goal: Create a "One-Click Environment Automation"
Categories to address:
How should its infrastructure be provisioned?
How should its workloads be deployed?
How should its metrics and logs be sent, stored, and queried?
...
#3 - Strategic Principles
Reach at least 50% capacity of working on the DevOps goals as soon as you responsibly can - Support the developers and teach them how to self-support to achieve that
Easy to modify > Perfect - When you do something that isn't perfect due to a lack of time, do it in such a way that modifying it later on to improve it is easy
At least moderate foundations quickly, reinforce later, but never weak foundations: If you don't use any boilerplates, or if you are not proficient in something early on, and it's a foundation (like infrastructure), then don't give up and build weak foundations, but also don't over-invest and build strong ones if it's too time consuming. Instead, moderately invest in the foundation, and revisit it later.
Set a definition of done
Also known as a Definition of done.
Ask the following questions for every single component in your system:
Monitoring: Are there metrics, logs, traces, and alerts setup in an actionable way?
Availability: Is there a mechanism to keep it alive during incidents?
Resiliency: Can it recover from an error quickly?
Recovery: Can it be fully restored to a previous state?
Testability: Is it possible to test changes to it?
Deliverability: Is there a process to release changes to it?
Persistency: Will its data persist if the system is hindered?
Integrable: Does it have a consistent and predictable interface allowing integration with it?
Security: Is it accessible only by the parts of the system that absolutely need it?
Dependencies: Are its dependencies fully tracked and managed?
Common DevOps Team Pitfalls
Pitfall: DevOps work blocks developers work Indicator: Developers need to wait for DevOps team changes to complete before continuing work Cause: The DevOps team doesn't utilize its own practices (AKA shoemaker's son always goes barefoot)
Pitfall: Only support developers and maintain the system Indicator: No progress on any DevOps goal or task Cause: Either there are no clear DevOps goals or repeating developers requests haven't been automated
Pitfall: Adopting 'Best' practices instead of 'Suitable' practices Indicator: Introducing methodologies and adhering to principles that go against the company's goals Cause: Prioritizing methodology over company goals, usually because of a disconnect from the company goals or due to lack of DevOps experience
Leverage = Level of DevOps Engineers * Company Resources * Team Focus
Scale = Number of instances of each component * Number of people in the organization
Complexity = Number of components * Number of teams
Hire the right DevOps Engineers
The types of DevOps Engineers:
Barrels vs. Ammo ~ Ammo = People who can complete tasks but won't initiate them ~ Barrel = People who understand what tasks are needed next but won't complete them Interviewer Tip: During the technical interview with a candidate ask about past DevOps accomplishments, and ask how the tasks were created and who did them.
Aspiration-Oriented vs. Prevention-Oriented ~ Aspiration-Oriented = Has goals, positive feedback encourages and focuses them while negative feedback discourages them and kicks them off track. ~ Prevention-Oriented = Avoids problems, positive feedback makes them lay back and reduce capacity while negative feedback focuses them and keeps them on track. Interviewer tip: See if there's a common theme for projects the candidate did in the past. People focused on security tasks and deep attention to specific details are more likely to be prevention-oriented, while people who initiated many projects spanning multiple (DevOps) categories are more likely to be aspiration-oriented.
By clicking "Ok, got it", you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. Privacy Policy for more information.