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