A culture of collaborative and continuous learning. Transparent knowledge sharing. Agile methods and automation as a means of accelerating innovation. Building good software.
These are some of the
core tenets of DevOps. Day in and day out, DevOps teams can expect to drive
application performance management, product roadmap development, and overall, build cool stuff. It’s why they came to the job. What these core tenets don’t include are constant troubleshooting and issues management, but in
SolarWinds® Cloud Confessions: The Trouble with Troubleshooting, data revealed a constant battle that DevOps teams, web product managers (WPMs), and developers are fighting: trying to use technology to innovate, yet spending the majority of the day troubleshooting issues.
Too Much Troubleshooting?
Troubleshooting is a necessary part of
DevOps, but when it spreads its roots across multiple hours in a workday, it can demotivate technology professionals and reduce the availability DevOps teams, developers, and WPMs have to innovate and add features to their solutions. It also detracts from time these tech pros could be spending applying their knowledge, insight, and skillsets to transform organizations.
Too much troubleshooting needs to be elevated to a business priority because of the impact on organizations’ bottom lines. In other words: this is a tangible issue and your organization’s leaders should care enough to
shift the environment back to one that prioritizes innovation. But, there are certain things we technology professionals can take into our own hands.
Shift to the Left
While troubleshooting isn’t going anywhere, it can be lessened with the help of leadership and with the concept of “shift left.” The dichotomy between troubleshooting and building—really, the constant struggle for time—is causing this shift left move. Moving forward, DevOps teams will be pushed more frequently to tackle security and infrastructure consideration in architecture, coding, and preproduction, in order to cut down on troubleshooting later.
What’s more, with the near-daily news of expensive outages and breaches, keeping
infrastructure development efforts siloed outside of the DevOps continuous delivery processes is no longer going to be an acceptable approach. To be successful, DevOps teams are going to need to embrace this shift left and build security, governance, stability, and scalability into applications before they reach production.
Design Thinking, a.k.a. Don’t Kick the Can
The phrase “kicking the can down the street” can sometimes apply to development before shift left entered the scene, when you might notice a potential issue that may arise, but it’s ignored before it hits testing. A DevOps environment can certainly ameliorate some of the traditional team or cultural issues in application development, like siloes. However, there is risk of these issues still popping up in organizations before a DevOps mindset takes hold. For those organizations with a strong DevOps environment and an overall commitment to making high-quality software, the following best practices are usually at play:
- Developers take responsibility for testing. DevOps requires automation and continuous integration and delivery—without quick, automated tests, these user-focused delivery methods aren’t achievable.
- Follow an open-source style method for reviews. In the open-source world, software improves the more developers contribute to the project. In shift left strategies, one person or a team of people must be responsible for reviewing tests on code, with all possible downtime scenarios in mind.
- Build with testability in mind. Shift left strategies mean that developers must think about whether software is testable before they even write a line of code. If developers are responsible for testing automation (see No. 1 above) they will build an awareness of potential issues that arise due to code design.
- Leverage the same tools. Ensure the organization’s toolset—not just for building, but also for observability and management—will support key parts of the DevOps philosophy, including proactive work and automation.
With
uptime and application performance management now a top priority for more complex, business-critical software, leadership must work with DevOps teams to significantly cut down troubleshooting. Still, technology professionals must use their knowledge to adopt a shift left approach to development to help themselves cut down on troubleshooting and build better software. You can read more about shift left and whether
shift left can go too far in this post.
