Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Developing Better Incident Response Policies

Dev Processes
Team Processes

25 May, 2021

Harrison Hunter
Harrison Hunter

CTO at MaestroQA

Harrison Hunter, CTO at MaestroQA, speaks of his current efforts to develop better incident response policies by introducing automated testing and improving on-call scheduling.

Problem

As we became a more enterprise-focused company, we realized that we have to support higher levels of uptime and ensure greater performance guarantees for our customers. At the same time, the number of people contributing to a codebase was increasing, which consequently implied an increased number of changes. Therefore, we had to make sure that the new layer of changes won’t result in instability and a more significant number of issues for our customers.

Actions taken

The two biggest areas to make improvements and hence make a significant impact on our incident response policies were centered around automation of testing and on-call scheduling.

Automated testing

For starters, we added automation to the process in several places. We already had some unit testing, UI, and click-through testing, but we put a lot more emphasis on testing as such and hired a team to expand the level of automated and end to end testing for an increased number of changes. We particularly expanded testing to include load tests; we didn’t just test under a small load and for the existing size of our customers, but we tested under a large load projecting the future size of our customer base. By doing so, we would catch issues before going into production and thus prevent incidents from happening.

We also added automated status check-ins and tied our tools together. By linking tools together, we ensured that our health checks, database, and server metrics were altering us in the right places. All information was piped into Slack or email, which allowed people to respond quickly to issues and set up a diagnosis in no time with monitors that would be in alarm when things would get wrong. When an alert would be triggered, we would get an indication that something was not working someplace rather than going to each place to check.

Scheduling

To ensure that our policies could be efficiently implemented, we established clear points of contact and communication mechanisms by adding on-call rotation planning, scheduling, and alerting. That required a change that was both cultural and process-related.

We didn’t merely create an on-call schedule and informed people when they would be on call. We created a checklist for people to go through and ensured that everyone had access to all the tools and systems. Also, we set up clear expectations for doing testing incident response, which helped with the cultural aspect of the change.

While this is still a work in progress, we noticed significant improvements. For example, we redefined incidents and created dedicated places for communication. We also organized communication around the incident response playbook that we compiled. Consequently, clear communication resulted in the faster resolution of issues.

Lessons learned

  • Ensure end-to-end testing, not only the regular one but also for a projected scale that will generate a significant load.
  • Make sure that your alerting system is all piped into one place and that all communication is happening there. You should also have a unified view of alerts across the system to be able to respond quickly.
  • When you create an on-call schedule, make sure you also create a checklist for everyone going on call to be comfortable and all set tool- and access-wise. Make sure to refresh those regularly since processes are changing over time, and people should feel comfortable and have access at all times. Also, develop a detailed playbook for people who should be able to apply the right investigation and mitigation techniques in the heat of the moment.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Surefire Ways to Boost Team Morale

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, talks about effective ways to boost team morale when stepping in as a new manager in the team.

Motivation
Team Processes
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

The Right Way to Ship Features in a Startup

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares how he took the risk and shipped features in a startup.

Alignment
Product
Dev Processes
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.