Developing Better Incident Response Policies
25 May, 2021
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.
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.
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.
Google Cloud Practice lead at Contino
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.
Director of Engineering at Inspire Energy
Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.
Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.
Senior Vice President of Engineering at Usergems
Roland Fiala, Senior Vice President of Engineering at Productsup, highlights the importance of soft skills and shares how he motivates his engineers to further their careers by focusing on personal growth.
Senior Vice President of Engineering at Usergems