既然有这样要求，那么，SRE 就会有工作超负荷的现象。
那么，如何解决超负荷的问题呢？
场景再现
假设有一个 Connection 服务，它负责前端负载平衡和终止无效地最终用户连接。负责这个服务的 SRE 团队已经确立了每班两次呼叫事件的值班预算，但是在过去的一年中，他们经常每班接收五次呼叫事件。
分析显示，有三分之一的班次超出了其值班的预算。团队成员努力地响应了每天的页面攻击，但还是无法从容应对。
在每一天的时间里，根本没有足够的时间来找到根本原因，并正确解决即将出现的问题。
一些工程师离开了团队，加入了那些运维负担较少的团队。
高质量的事件跟踪活动是很罕见的，因为应对事件的这些 SRE 工程师的时间时间只够用来缓解眼前的问题。
如何解决超负载
解决值班时的高负载的第一步是确定是什么原因造成的。
值班负载受三个主要因素影响:
- 生产环境
- 警报
- 人工流程中的错误
这三个因素中同，每一个因素都会有几个输入，我们将在本节中更详细地讨论其中的一些输入。
1、生产环境:
- 生产中现有错误的数量
- 将新的错误引入生产
- 识别新引入的错误的速度
- 漏洞消除和从生产中删除的速度
2、警报:
- 触发寻呼警报的警报阈值
- 引入了新的呼叫警报
- 服务的 SLO 与它所依赖的服务的 SLO 的对齐
3、人工流程:
- 比较严格的错误跟进与修复要求
- 能收集到的与该警报有关的数据的质量
- 注意传呼机负载趋势
- 人工改变了生产环境
如何应对
1、情况一：对于先前已经存在的 Bug。
没有哪个系统是完美的。生产环境中总会有 bug ，在你自己的代码，构建的软件和依赖的库文件，或它们之间的接口中。
这些错误可能暂时不会引起警报，但是 Bug 肯定存在。
你可以使用一些技术来识别或阻止尚未引起警报的错误:
- 确保系统尽可能不复杂，或者不要再进一步复杂了。
- 定期更新构建系统所基于的软件或库，以利用错误修复。
- 进行定期的破坏性测试或模糊测试(例如，使用 Netflix 的 Chaos Monkey)。
- 除了集成和单元测试外，还执行常规的负载测试。
2、新出现的 Bug
理想情况下，SRE 团队及其对应的合作伙伴，也就是开发团队，应该在将其投入生产环境之前就检测出新的错误。而事实上，自动化测试仍会遗漏许多 Bug，并将其发布到生产环境中。
软件测试是一个被广泛涉及的主题。然而，软件测试技术对于减少到达生产环境的 Bug 数量，以及在生产环境中停留的时间特别有用:
- 随着时间的推移改进测试。特别是，对于在生产中发现的每个 Bug，请自我提问并回答：「我们如何能够在预生产环境中检测到这一类 Bug？」，并确保进行必要的工程跟进。
- 不要忽视负载测试。由于资源和时间原因，与功能测试相比，负载测试的优先级通常较低。然而，许多 Bug 仅能在特定的负载条件下（或在特定的请求混合下）才会显现。
- 在类生产环境中运行场景测试（即：使用类似生产环境的综合性流量进行测试)。
- 在生产环境中执行金丝雀发布。
- 对新错误的容忍度要较低。要遵循「检测/回滚，修复/前滚」的原则与策略，而不是「检测，识别出错误，修复并再次发布，然后重复这个步骤」的策略。这种回滚策略要可预测且频繁的发布，因此，回滚任何一个发布版本的成本都较小。
3、某些错误可能仅是由于更必了客户端行为引起的
例如：
- 仅在特定负载水平下才会显示的错误 —— 例如，3月/9月的开学季流量，黑色星期五，意味着你的更多用户同时处于清醒状态和在线状态。
- 仅在特定的请求混合中才出现的错误 —— 例如，由于亚洲字符集的语言编码，距离亚洲较近的服务器的通信量比较昂贵。
- 仅当用户以意外方式使用系统时才会出现的错误 —— 例如，航空公司预订系统正在使用日历！
因此，重要的是，你需要扩展你的测试方案，来测试那些并不是每天都会发生的行为。