上文已经讨论过，Google将 SRE 团队的运维工作限制在50%以内。SRE 团队应该将剩余时间花在研发项目上。在实践中，SRE管理人员应该经常度量团队成员的时间分配，如果有必要的话，采取一些暂时性措施将过多的运维压力转移回开发团队处理。例如∶将生产环境中发现的Bug 和产生的工单转给研发管理人员去分配，或者将开发团队成员加入到轮值 on-call体系中共同承担轮值压力等。这些暂时性措施应该一直持续到运维团队的运维工作压力降低到50%以下为止。在实践中，这种措施实际形成了一个良性循环，激励研发团队设计、构建出不需要人工干预、可以自主运行的系统。只有整个产品部门都认同这个模式，认同 50%的安全线的重要性，才会共同努力避免这种情况的发生。

SRE 处理运维工作的一项准则是∶在每 8~12 小时的 on-call 轮值期间最多只处理两个紧急事件。这个准则保证了on-call工程师有足够的时间跟进紧急事件，这样SRE 可以正确地处理故障、恢复服务，并且要撰写一份事后报告。如果一次轮值过程中处理的问题过多，那么每个问题就不可能被详细调查清楚，运维工程师甚至没有时间从中学习。如果小规模部署下还无法做到合理报警，规模扩大之后这个情况就会更严重。相对而言，如果一个项目的紧急警报非常少，能够持续稳定运行，那么保持这么多 on-call 工程师可能就是浪费时间。

所有的产品事故都应该有对应的事后总结，无论有没有触发警报。这里要注意的是，如果一个产品事故没有触发警报，那么事后总结的意义可能更大∶ 因为它将揭示监控系统中的漏洞。事后总结应该包括以下内容∶事故发生、发现、解决的全过程，事故的根本原因，预防或者优化的解决方案。Google 的一项准则是"对事不对人"，事后总结的目标是尽早发现和堵住漏洞，而不是通过流程去绕过和掩盖它们。

上文已经讨论过，Google将 SRE 团队的运维工作限制在50%以内。SRE 团队应该将剩余时间花在研发项目上。在实践中，SRE管理人员应该经常度量团队成员的时间分配，如果有必要的话，采取一些暂时性措施将过多的运维压力转移回开发团队处理。例如∶将生产环境中发现的Bug 和产生的工单转给研发管理人员去分配，或者将开发团队成员加入到轮值 on-call体系中共同承担轮值压力等。这些暂时性措施应该一直持续到运维团队的运维工作压力降低到50%以下为止。在实践中，这种措施实际形成了一个良性循环，激励研发团队设计、构建出不需要人工干预、可以自主运行的系统。只有整个产品部门都认同这个模式，认同 50%的安全线的重要性，才会共同努力避免这种情况的发生。

SRE 处理运维工作的一项准则是∶在每 8~12 小时的 on-call 轮值期间最多只处理两个紧急事件。这个准则保证了on-call工程师有足够的时间跟进紧急事件，这样SRE 可以正确地处理故障、恢复服务，并且要撰写一份事后报告。如果一次轮值过程中处理的问题过多，那么每个问题就不可能被详细调查清楚，运维工程师甚至没有时间从中学习。如果小规模部署下还无法做到合理报警，规模扩大之后这个情况就会更严重。相对而言，如果一个项目的紧急警报非常少，能够持续稳定运行，那么保持这么多 on-call 工程师可能就是浪费时间。

所有的产品事故都应该有对应的事后总结，无论有没有触发警报。这里要注意的是，如果一个产品事故没有触发警报，那么事后总结的意义可能更大∶ 因为它将揭示监控系统中的漏洞。事后总结应该包括以下内容∶事故发生、发现、解决的全过程，事故的根本原因，预防或者优化的解决方案。Google 的一项准则是"对事不对人"，事后总结的目标是尽早发现和堵住漏洞，而不是通过流程去绕过和掩盖它们。