The skills required to automate all the things pales in comparison to the challenge of guiding disparate teams with very different objectives.
A typical day can look like:
Working with the business to understand the nature of the service being deployed.
Do we need to support one hundred partners or ten thousand customers?Providing architecture advice to developers that will help them scale.
Should we use Product X or Service Y?
What/when/where should we cache data?
Sometimes the best product, service, or choice does not fit into your larger architecture. The DevOps personnel often have the quarterback view.Train development and infrastructure teams on the benefits and usage of automation.
While they generally understand the value proposition, they often misunderstand the extent to which the other is utilizing it. Overly ambitious automation projects often fail because they skipped too many transition steps.
Start with small steps that both teams can adopt and slowly build on a common foundation together.Demonstrating how technology teams can deliver faster value to the business.
As you slowly develop your automation the teams discover they are able to iterate faster than ever before. This provides opportunity for them to take ownership of smaller releases more often.Developing automation pipelines to enable seamless development, testing, and production environments.
Once you have a good sense of your developer’s workflow you can ultimately build a great development environment. Reproducing or emulating production systems helps with building more reliable software.
Improving the development environment setup is also critical when onboarding new developers. The faster they are productive and contributing the more successful your project will be.Documenting systems requirements so infrastructure teams can develop lifecycle support systems (monitoring, backup, intrusion detection, etc.).
Infrastructure as code helps with this tremendously. However, there is also acquisition of new cloud resources, regulatory tools, and staffing to consider when going live.
The DevOps team can build that bridge to make sure the right tools are procured, and all regulatory, business, and security requirements are being met.Supervise said systems and validate they meet the needs of all team constituents.
Throughout the development and procurement processes the DevOps engineer becomes responsible for validating the pieces fit correctly. Ultimately, they will be the ones calling meetings and developing compromises when difficult architectural decisions have to be made.Develop opportunities for team members to take ownership of different aspects of the automation.
The best running systems are the ones where team members are engaged to the processes and outcome. The best way I have found to do that is develop leaders in different parts of the stack who become subject matter experts.Writing custom tools to serve as the glue between the manual and automated worlds.
Sometimes as a DevOps engineer you just have to write some code. Building the perfect system is impossible and so you are constantly faced with a moving target as your organization moves towards CI/CD.
This means having to write a lot of code to handle assumptions or decisions that were made yesterday that are no longer true.
Despite your DevOps engineers generally being some of your more senior team members their role is not purely technical. In fact, the technical skills required to automate these systems is trivial to any developer.
The actual challenge is working with the stakeholders to:
Enable developer productivity and flexibility.
Increase development speed.
Provide products/services the business can iterate on quickly.
Not completely destroying the infrastructure and lessons learned that are already in place.
Providing training and leadership to infrastructure and developers alike not used to these processes.
For that you need someone who above all else can forge great working relationships with your development, infrastructure, and business teams alike.