Adjusting your IT monitoring strategy for DevOps requires an operations team to take on some challenges and embrace new best practices.
One of the chief uses of IT monitoring feedback in and outside of the DevOps world is to determine mean time to repair (MTTR) -- the time it takes for feedback to lead to a fix. Customer support requests are a traditional feedback channel for development teams to repair software defects and security weaknesses. DevOps teams accelerate this process when they enable monitoring tools throughout their toolchain to communicate feedback about software tests, security checks and builds, which allows developers to act before they deliver an application to users.
DevOps introduces challenges to IT monitoring. Development, operations and security teams are spread across different business units, each with its own agendas, goals, budgets and key performance indicators that matter most to them. These groups may approach IT monitoring with different strategies and tools, and compatibility and collaboration were never part of their original approaches to monitoring.
Once you corral these groups, set a context for data monitoring. Context is fundamental to ensure you interpret your data correctly through establishing baselines and normal ranges.
Beyond bringing together somewhat disparate groups to cooperate on monitoring, you need to pull their operational views into the systems being used. This provides a picture of what's happening across your environments and lets you see more clearly what elements might break. At this point, you can contemplate how to extend monitoring into the diagnosis of system problems. DevOps toolchains also lend themselves to autoremediation tools that can resolve incidents automatically with limited human intervention.
IT monitoring feedback in the DevOps world occurs throughout the development lifecycle. Feedback is no longer the last stop before you push your software to production. Feedback mechanisms also extend to non-IT staff, such as sales and marketing. To make the most of cross-team feedback, teams must implement processes and tools for monitoring as part of the design of your toolchain and cloud environments.
Alert fatigue is real. The best practice here is to apply automation to gather the right telemetry from your monitoring tools across the DevOps toolchain, and send an alert that either executes an automated process or notifies a person. Analyze technology and business requirements to determine where you add automation. The automation of alerting should be an iterative process. After all, enterprise environments vary in size and scope.
Apply monitoring data to DevOps effectiveness
Monitoring is at the heart of automation. Once you take full advantage of monitoring, then you can move to automation and DevOps.
When you build a DevOps toolchain, pay close attention to monitoring and auditability throughout your application development lifecycle. This new level of monitoring must also extend across any hybrid or multi-cloud deployments where you deploy applications. Include containers and Kubernetes clusters, too.
DevOps monitoring needs a sharp focus. As your teams come together, target monitoring toward specific scenarios that affect your organization. Start by analyzing the monitoring your teams already have in place. Determine which monitoring activities work and which do not. Both groups should cooperate on finding monitoring gaps. Optimize your DevOps monitoring using the best of each team's monitoring target, make incremental improvements where needed, and collaborate on new monitoring targets to close any pre-DevOps monitoring gaps you find. These steps will prevent breakdowns across your toolchains and environments.
A move to DevOps should also spur an organization to phase out any self-built monitoring tools. The delivery velocity of DevOps requires professional-grade tools that deliver accurate reporting with minimal maintenance. Today's generation of IT incident management and alerting platforms offer SaaS and on-premises options plus the APIs you need for the integration.
Another monitoring best practice is to pull metrics about whether your application accomplishes the business goals that your product managers, marketing and sales teams have set for the application. Capturing data about user sessions is a powerful way to learn about user trends. Today's analytics tools can slice and dice user session data to let you create the necessary reports that your management developers, quality assurance and business users require.
Error reporting isn't only for developers and QA teams anymore. Business users can learn a lot about how customers use the application. For example, error reporting can show how customers might try to use your app in unintended ways. Stakeholders such as product managers can use this feedback to refine current features and define new features. Spend the time to develop self-service dashboards that can communicate these metrics to your business users without needing a developer to be involved. DevOps is what lets your company respond quickly to this information.
Shift monitoring left with DevOps
Monitoring needs to become an even deeper part of DevOps transformation. It cannot be an afterthought.
Just as many organizations shift left with security as they go to DevOps, it's time to shift left with monitoring. Make monitoring part of your design. Devote the budget and people to implement and manage the tools and secure the data. Above all, be flexible and iterate on your IT monitoring strategy as conditions change.