Get up to 50% off! Limited time only: Learn More.

The DevOps and IT Incident Response Plan

Kelsey Loughman June 03, 2019

DevOps On-Call Collaboration
The DevOps and Incident-Response Plan Template Blog Banner Image

Rapid incident response in DevOps and IT can mean the difference between a 5-minute outage and a 5-hour outage. But, how you respond in real-time isn’t the only part of incident management and response. From alerting to post-incident reviews to communication methods, there are a number of ways you can make incident response more effective. And, one of those ways is to build a comprehensive incident response plan.

From feature planning and development to hosting services in production, you never know when something could go wrong. The inherent nature of complex, highly-integrated systems leads to less certainty around deployment reliability. So, teams need to be prepared for the worst. Has your team put redundancies and failover options in place? Is there a system in place to ensure fast deployment rollbacks in case of an outage?

From the moment an alert is triggered to the final post-incident analysis, you need to streamline communication and visibility. So, we built the DevOps and IT incident response plan to help you do just that. This post serves as a template for proactive incident response – helping teams reduce MTTA and MTTR (mean time to acknowledge/resolve), maintain more reliable systems and ensure better customer experiences – all while simultaneously making on-call suck less for employees.

What makes up an efficient incident response plan?

So, what are the key elements to any good incident response plan? Well, a lot of the specifics depend on the way your team is set up, the processes you’ve implemented and the technology stack you’re working with. But, no matter how you’ve set up your IT and engineering teams, one thing is for sure – incidents are inevitable. So, you not only need to put safeguards in place to proactively detect and prevent incidents, but you need to be prepared for rapid notification and response for the times an incident sneaks past your safeguards. And, you need to measure key incident management KPIs and metrics to ensure incident response is constantly improving.

Incidents are unavoidable

Building a culture dedicated to CI/CD and reliable deployments requires a resilient, flexible mindset. And, this becomes easier when you admit to yourself that incidents are unavoidable. Embrace the fact that a forward-thinking culture of experimentation and testing alongside an agile release pipeline will lead to incidents. By preparing for incident response, you’re allowed to continue pushing the envelope on deployment speed without sacrificing the overall reliability of your services.

Effective monitoring and alerting practices are only part of a resilient architecture. By creating visibility into your technical systems, you can improve incident detection – but you need to empower your people and processes to build a complete system for incident response. To start streamlining incident management and response, you need to understand that every example of an incident flows through five steps – the incident management lifecycle.

The incident management lifecycle

The incident management lifecycle is the step-by-step process that every incident goes through. Whether it’s a cybersecurity incident or an IT infrastructure incident, these five steps will always apply. So, let’s quickly walk through the incident management lifecycle before finding ways to improve the efficiency of your incident response plan.

1) Incident detection

Of course, incident detection comes first. Before you can start fixing the problem, you have to notice the problem. Incident detection is always made easier through continuous improvement of monitoring and alerting tools and practices. Then, with increased visibility into your system’s health and any applicable alert context, you can quickly identify an incident and begin with the next phase – incident response.

2) Incident response

Incident response is all about getting the right people involved quickly. Without alert context, it becomes a bit of a rat race trying to figure out who needs to be involved. Who has the knowledge and capability to quickly start fixing the incident? Are there other systems affected by the incident? Without an incident response plan, it can become convoluted and quite inefficient when trying to respond to critical incidents in real-time. The key to effective incident response is a deeper level of transparency and collaboration – for both technology and humans – across all of your systems and teams.

3) Incident remediation

Fixing the incident is actually pretty easy if you’ve nailed down the detection and response portions of the incident management lifecycle. With the proper context in the hands of the right person, the fix is usually just a matter of how quickly your team can execute the right actions and commands.

4) Incident analysis

But, even after the incident has been resolved, your work isn’t quite finished. It’s important to continuously improve incident management practices by conducting post-incident reviews to learn from what happened. How can you get the information to the right person faster? Were there any blind spots in your monitoring or alerting workflows? Are there any adjustments you can make to processes or systems in order to improve the efficiency of your incident detection, response and remediation? By taking a deep dive into the way your people, processes and technology interact during an incident, you can pull key insights that will lead to a more effective incident response plan.

5) Incident preparation

And, last but not least, your team focuses on preparation. The team can ensure runbooks and other wikis are up-to-date with actionable instructions and information. A great way to test your team’s preparedness is through game days and chaos engineering experiments. Making sure your team is prepared for incidents is the key to shortening the time spent at each of the four phases of the incident management lifecycle. Don’t simply set monitoring and alerting tools and forget them. This approach leads to a reactive approach to incident response – forcing DevOps and IT teams to spend more time fixing problems and less time building new features and services.

How to Make On-Call Suck Less

Improving visibility and communication

So, one theme persists across all the entire incident management lifecycle – visibility and communication are key. No matter which step of the lifecycle you find yourself in, improvements to alert context, workflow transparency and collaboration will reduce MTTA and MTTR. More visibility into features in development as well as systems in production will help both software developers and IT professionals be better at their jobs – leading to a DevOps culture of collaboration and transparency.

Preparedness = resilience

In a world of automation, interdependent architecture and constantly-shifting applications and infrastructure, the only real way to build resilient systems is through preparation. Preparation for both product development, release management and incident response. A DevOps or IT incident response plan focused on preparation – within the context that collaboration and transparency is key – will always lead to more robust software and better customer experiences.

Finding ways to identify, escalate and automate much of the incident response phase will help you surface alert context faster and improve the efficiency of the other four steps in the incident lifecycle. You can’t plan for every little thing that goes into your production systems – so you need to prepare for the likelihood of something going wrong. A prepared team = a resilient team.

Build better DevOps and IT teams with an incident response plan

The way you build out your first incident response plan will depend on the maturity of your incident management processes. Start with a template that can apply to nearly any incident in your system. Then, determine the team or individual who should get notified first. From there, start to define best practices for escalation and the methods of communication that will work best. Once you have a boilerplate template for an incident response plan, you can start to get more granular for specific applications, services and frequent incidents you encounter.

Most of an effective DevOps or IT incident response plan should be focused on working agreements and SLAs/SLOs between different people and teams. What’s an acceptable length of time for a certain alert to sit without being acknowledged? Are a few people getting stuck with the lion’s share of on-call responsibilities and incident resolution work because of historical knowledge?

Build an incident response plan that maintains a balance between employee happiness and customer expectations – of course getting the entire team’s buy-in before implementing the plan. A good incident response plan will lead to on-call that doesn’t suck, more resilient systems and happier customers.

Try a 14-day free trial or request a free personalized demo of VictorOps to start making the most of your incident response plan. See how a holistic on-call and alerting solution for IT and DevOps improves real-time incident context and collaboration – helping you fix issues faster while making on-call suck less.

Let us help you make on-call suck less.

Get Started Now