| Status | Published |
|---|---|
| Author | Steven Thurgood |
| Date | 2018-02-19 |
| Reviewers | David Ferguson |
| Approvers | Betsy Beyer |
| Approval Date | 2018-02-20 |
| Revisit Date | 2019-02-01 |
服务概述
示例游戏服务允许Android和iPhone用户彼此玩游戏。后端代码的新版本每天发布一次。每周都会推送新版本的客户。此策略同时适用于后端和客户端版本。
目标
该政策的目标是：
-
保护客户免受重复的SLO遗漏
-
鼓励平衡可靠性与其他功能
非目标
此政策无意作为对丢失的SLO的惩罚。停止更改是不可取的；该政策允许团队专注于
示例错误预算政策
当数据表明可靠性比其他产品功能更重要时的可靠性。
SLO小姐政策
如果服务在其SLO或更高的性能下运行，则将根据发布策略继续进行发布（包括数据更改）。
如果该服务超出了前四个星期的错误预算，我们将停止所有更改并发布P0 1问题或安全修补程序以外的其他问题，直到该服务返回其SLO之内。
根据SLO未命中的原因，团队可能会投入更多资源来进行可靠性工作，而不是进行功能工作。在以下情况下，团队必须致力于可靠性：
-
代码错误或程序错误导致服务本身超出错误预算。
-
事后总结表明有机会软化严格的依赖关系。
-
错误分类的错误无法消耗可能导致服务错过其SLO的预算。
在以下情况下，团队可能继续研究非可靠性功能：
-
中断是由公司范围内的网络问题引起的。
-
中断是由另一个团队维护的服务引起的，另一个团队冻结了发布以解决其可靠性问题。
-
错误预算被用户超出了SLO的范围（例如，负载测试或渗透测试仪）。
-
错误分类的错误会消耗预算，即使没有用户受到影响。
停运政策
如果单个事件在四个星期内消耗了错误预算的20％以上，则团队必须进行事后调查。事后总结必须包含至少一个P0操作项以解决根本原因。
如果一类中断在一个季度中消耗了超过20％的错误预算，则团队必须在其季度计划文档中有一个P0项目2，以解决下一季度的问题。
升级政策
如果各方在错误预算的计算或其定义的具体措施上存在分歧，则应将此问题上报给CTO做出决定。
背景
本节是样板，旨在向不熟悉这些错误预算的人简要概述错误预算。
错误预算是SRE用于平衡服务可靠性和创新步伐的工具。变更是不稳定的主要来源，约占我们中断的70％，功能开发工作与稳定性工作竞争。错误预算构成了一种控制机制，可根据需要转移对稳定性的关注。
错误预算为1减去服务的SLO。99.9％的SLO服务的错误预算为0.1％。
如果我们的服务在四个星期内收到1,000,000个请求，则99.9％的可用性SLO会为我们提供该期间1,000个错误的预算。