SRE 原则：7条基本规则

七条SRE原则来自一家拥有自己的数据中心、网络、负载均衡器及所有中间代码的公司。你的堆栈可能并非如此。用户体验中的很大一部分运行在你无法SSH访问的基础设施上：CDN、认证提供商、支付网关、DNS、标签管理器、合作伙伴API。

这种差距很重要，因为这些原则在谷歌之外依然适用。但当故障组件不是你可以修复时，若干原则的形态会发生变化。当三分之一的错误预算被他人故障消耗时，错误预算的表现会不同。四个黄金信号从防火墙外看和内部看截然不同。你无法通过工程消除的风险，必须通过测量来管理。

本文按照谷歌SRE书的定义，逐条讲解七条原则，并补充书中未涉及的部分：当依赖的服务不归你控制时，每条原则如何体现。如果你是新手，建议先阅读站点可靠性工程师的职责，然后再回来阅读本文。

SRE原则是什么？

SRE原则是谷歌为大规模运行可靠系统而制定的工作准则：接受并管理风险、服务级别目标、消除重复劳动、监控、自动化、发布工程和简化。它们共同回答一个问题：该服务需要多可靠，怎样以最经济可持续的方式保持这种可靠性？

自2016年SRE书出版以来，列表未变。但平均堆栈已变。微服务、SaaS依赖和第三方脚本意味着部分可靠性现在掌握在其他公司手上。下面每节先介绍书中写的原则，再讲述依赖不属于你的时候会出何问题。最后总结从七条原则中提炼的SRE最佳实践。

原则1 – 接受并管理风险

谷歌的表述：100%可靠性是错误目标。用户通过自身会失败的网络和设备访问你，超出一定点数的额外“9”将花费巨资且用户感觉不到差别。选择业务能支持的可靠性目标，并将该目标与完美之间的差距视为允许花在交付新功能上的预算。接受风险章节详细阐述此点。

在谷歌内部，这行得通因为风险是可调整的旋钮。更多复制，更多冗余，更慢发布：花钱换九。

谷歌之外，这个旋钮部分不通。你不能为支付网关添加副本。你无法调整DNS提供商的故障切换行为。他们的可靠性是一项合约条款，不是工程参数。

因此原则形态变化：对于你拥有的组件，通过工程管理风险；不属于你的，通过测量管理。你需要知道认证提供商从用户网络看真实可用性，而非状态页数字。状态页常常在部分故障时仍显示绿色，一个依赖在其自身数据中心可用，但你的数据中心可能无法访问。独立测量能让“我们认为CDN不稳定”变成有数据支撑的续签对话。这是Dotcom-Monitor这方面的第一职责：对每个关键依赖做外部检测。对提供商的DNS服务器进行DNS检测，对CDN边缘做HTTP(S)检测，对支付网关做API检测。每个检测从全球网络构建自身的正常运行时间和响应时间记录。当数据合理时，绕过风险：第二个DNS提供商、备用支付路径、第三方脚本缓存副本。

如何实施风险管理

• 列出用户请求涉及的每个依赖（DNS、CDN、认证、支付、第三方标签），标明哪些你能工程控制，哪些只能测量。
• 为每个只能测量的依赖创建Dotcom-Monitor设备：指向提供商DNS服务器的DNS任务，CDN边缘的HTTP(S)任务，面向支付或认证端点的Web服务任务。
• 从用户所在区域的多个监测地点运行这些检测，防止某一地区故障被另一地区掩盖。
• 将每个设备的正常运行报告带入供应商沟通，仅在有数据表明风险值得花费时添加路由备选（次级DNS，备用支付路径）。

原则2 – 服务级别目标 (SLA, SLO, SLI)

三个术语经常混淆，解释如下：

• SLA (服务级别协议)：合同。对客户的承诺，违约时有惩罚。
• SLO (服务级别目标)：对服务级别指标的目标，通常是内部目标，比SLA更严格，确保在触发合同违约前发出警报。比如99.9%正常运行，结账完成时间小于3秒等。
• SLI (服务级别指标)：实际测量结果。实际正常运行时间，实际响应时间，观察到的错误率。

SLI做测量，SLO定目标，SLA做承诺。包括你给客户的正常运行时间和SLA报告都依赖SLI的可信度。

这里大多数团队有盲点：错误预算的精度取决于背后的测量。如果检测每5分钟一次，记录的每次故障的起止时间只能精确到5分钟，且持续时间短于检测间隔的故障可能根本不会被发现。下表说明以30天（43,200分钟）为周期，常见SLO目标的月错误预算与5分钟检测间隔带来的影响：

你无法用5分钟检测间隔测量99.99%的月度SLO。一次检测间隔大于你的整个月错误预算。

概率数学同样严苛。检测间隔为I分钟，随机故障持续D分钟且D小于时，捕捉概率约为D/I，假设故障开始时间与检测时间独立。因此一个4分钟故障与5分钟检测间隔对比，被捕捉概率约为4/5，剩下1/5故障完全落在两次检测之间，未被记录。而持续超过检测间隔的故障，平均检测延迟约为间隔一半，5分钟检测平均需要2.5分钟后才会察觉。

注意：此表假设单次定时检测和基于间隔的停机计数。多地点确认和基于请求的SLI会改变细节，但采样问题依然存在。

短故障不是极端情况。Dotcom-Monitor检测的大约38%的故障在5分钟内解决。这些多为网络路由波动、重启、故障转移等自动修复事件，我们的响应过滤器正是基于此不发送警报。但被过滤不等于不记录：这段停机时间仍计入SLA，无论内部还是供应商，都必须追踪。收到警报的故障有超过56%在首次通知后15分钟内解决，约18%持续超过1小时，约3%超过24小时。不同服务类型略有差异，但多数故障属于5分钟检测间隔内难以捕捉的类别。故检测频率是测量决策，不是成本问题：1分钟间隔时，测量门槛仅占99.9%月度预算的2.3%，而且短故障开始显现。在Dotcom-Monitor，检测频率最高可达1分钟，SLA报告基于同一检测记录，确保给客户的数据可信。

如何实施服务级别目标

• 定义两三个用户识别的SLI，例如基于真实浏览器测量的正常运行时间或结账时长，为每项设定Dotcom-Monitor检测作为记录来源。
• 设定比SLA更严格的SLO目标，并依据目标设定检测频率：超过99.9%要求1分钟检测间隔。
• 安排正常运行时间和SLA报告发送给SLA对话的负责人，确保合规数字和警报基于同一检测数据。
• 事先达成错误预算用尽时的应对方案，在未卷入具体事件时达成共识。

原则3 – 消除重复劳动

重复劳动指随服务规模增加的手动、重复工作且无持久价值。消除重复劳动章节定下著名上限：SRE应花不超过半数时间在此，其余时间做让重复劳动消失的工程工作。

抽象定义使重复劳动易于承认难以发现。明确它。在多数团队中如下表现：

• 每天早晨有人登录确认结账流程是否正常。
• 每次部署后有人手动测试注册表单。
• 有人维护SSL证书过期的日历提醒。
• 技术支持票激增时有人手动调用合作伙伴API，判断问题是己方还是对方。

每条都是等待脚本替代的事务，Dotcom-Monitor用实际成果回报它的价值。EveryStep（逐步录制工具）录制的脚本每隔几分钟用真实浏览器执行相同结账路径，任一步骤失败即报警。证书检查监控过期日期，无需日历。API定时检测合作伙伴端点，保持响应时间历史，轻松判定“是我方还是对方”纠纷。

判定优先自动化的标准不是复杂性，而是频率。人每天做的检测，应由机器每分钟执行。

如何实施重复劳动消除

• 记录团队一周内所有手动检测；频率高于难度，决定优先自动化顺序。
• 将最频繁的检测用EveryStep录制脚本，只需点点鼠标完成流程，然后改为每几分钟运行一次，而非每天一次。
• 用Dotcom-Monitor SSL证书检测替代证书过期日历，将合作伙伴API纳入调度的Web服务检测，避免靠记忆管理。
• 季度跟踪手工检测时间减少，确保自动化工作透明并获得支持经费。

原则4 – 监控与四个黄金信号

分布式系统监控章节提出四个黄金信号：延迟、流量、错误率和饱和度。监控这四项能捕捉多数故障。

章节提及黑盒监控，但大多数团队最终从系统内部监控这四项。换个角度从用户视角监控，其中三项变化：

诚实看表，结论非“外部更好”。而是没有单一视角能看到全部。流量和饱和度归内部工具所有：Prometheus、Datadog、New Relic及你的APM堆栈。用户感知的延迟和错误归外部合成监控。这部分Dotcom-Monitor覆盖。全球网络中真实浏览器检查，加载页面如真实用户般，测量全路径：DNS解析、TLS握手、CDN边缘、页面渲染、用户操作脚本。HTTP(S)、API、DNS、TCP、ICMP的协议检测观察页面相关依赖。这两者非竞争关系，而是同一四信号的不同视角，缺一不可。

实用原则：用户感知的每个信号至少要有一个从用户所在视角测量。APM仪表盘显示正常，但CDN对半个欧洲供应故障页并非假设，恰是内部监控唯一的常见失败模式。

如何实施监控

• 保持流量和饱和度由你的APM或Prometheus监控，延迟和错误交由Dotcom-Monitor的真实浏览器检测，从真实用户所在区域运行。
• 对检测设定内容断言，而非仅靠状态码检查，确保HTTP 200的故障结账被捕捉。
• 用EveryStep脚本录制关键事务（登录、搜索、结账），让监控跟踪用户路径。
• 定期对比内部和外部数据，两者差异即为CDN、DNS和第三方脚本层。

原则5 – 自动化

SRE对自动化的立场是：规模下的一致性。人会忘记步骤，机器不会，凌晨3点必须响应不能依赖人精神状态。

谷歌之外变化是：自动化取决于触发它的信号。故障切换脚本、回滚任务、自动扩缩规则均由检测事件触发，检测延迟一分钟，即自动响应多一分等待。SLO部分的计算直接适用：5分钟检测触发的自动故障切换，故障提前约2.5分钟。

且部分自动化触发只能源自外部。切换备用支付提供商的脚本需知主支付对用户是否故障，而非内部网络健康端点是否响应。Dotcom-Monitor通过其外部检测触发警报和Webhooks，实现以用户视角而非健康端点视角触发故障切换。

如何实施自动化

• 从事故响应阶段已执行的手工操作入手：重启、故障转移、回滚。
• 通过Dotcom-Monitor警报Webhook触发自动化脚本，确保触发基于外部确认故障，而非内部健康端点。
• 配置警报升级组，确保初次通知传达给执行人员或系统，避免凌晨3点无人关注的公共邮箱。
• 用响应过滤器屏蔽自愈短暂故障，防止自动化被误触。每季度对触发规则和误报率进行复查。

原则6 – 发布工程

发布工程是以相同方式构建和交付软件的学科：版本化构建、可重复流水线、经过演练可回滚。

现代CI/CD流水线涵盖大部分：测试通过，产物构建，覆盖特性开关发布。流水线无法告诉你发布后用户体验是否正常。CI能证明构建正确，但不会反映DNS记录是否传播、CDN缓存是否更新、第三方脚本与新代码冲突、生产环境特有配置是否正确。

这就需要发布后验证。用EveryStep脚本从Dotcom-Monitor网络对生产运行核心路径（加载页面、登录、完成事务）检测，是唯一测试用户真实获得内容的方法。实践中将此视为流水线最后环节：部署、外部验证、然后标记发布完成。检测失败时，回滚在影响范围仍为分钟时迅速启动。

如何实施发布工程

• 每次构建都版本化，将回滚从临时动作变为一键演练操作。
• 以Dotcom-Monitor网络中对生产执行的EveryStep事务作为部署流水线的最终阶段，确保DNS、CDN缓存和第三方脚本纳入测试。
• 将检测警报Webhook指向流水线，使失败的发布后检测自动触发回滚，而非留到第二天处理。
• 在发布间保持相同检测运行，以其历史作为部署对性能影响的基准线。

原则7 – 简化

简化章节指出可靠性与复杂性此消彼长：每增加一组件即增加故障点，软件复杂度应刚好满足需求。

这同样适用监控堆栈，因为复杂性在这里悄然积累。团队常拥有APM工具、日志平台、正常运行时间检测、状态页服务和三套无人使用的仪表盘。各工具各自警报，最终造成警报疲劳：重要通知被淹没。

让监控供应商建议精简工具数量，是个少见而值得采纳的建议。监控堆栈简化标准有两个问题：第一，每个被监控内容出现冲突时，你知道哪个工具是权威吗？第二，触发的每条警报都有负责人跟进吗？工具对所有监控均未满足这两条，则非监控，是带订阅费的噪声。将正常运行监控、事务、API和基础设施检测整合在一平台、统一警报路径，是简化优先于采购的决策。Dotcom-Monitor即为此架构：集中检测，统一警报路径，与内部APM工具协同，而非替代。

如何实施简化

• 梳理监控工具清单，列出每个权威监控的唯一内容。
• 删除无负责人和无操作关联的警报；无人响应即噪声。
• 整合外部检测（正常运行、页面、事务、API、基础设施）入Dotcom-Monitor平台，统一警报路径，让你的APM负责内部监控。
• 每年复审一次，监控堆栈复杂度会自然增长。

SRE最佳实践

原则给出目标。以下适用于不能掌控整个堆栈团队的实践：

• 以用户体验为SLO对象，而非服务器指标。“真实浏览器结账时长不超过4秒”是用户易识别的SLO，“API p95低于200ms”是其输入。
• 按SLO调整检测频率。参见上述错误预算表：99.95%以上，5分钟检测间隔对应月预算消耗已达23%以上，99.99%更全超预算。99.95%以上应考虑1分钟检测间隔。
• 对依赖进行监控，如同监控自身。DNS、CDN、支付、认证：对每关键依赖做外部检测，维护独立响应时间记录。供应商状态绿灯，用户体验崩溃时数据说话。
• 花费错误预算前先写好策略。预算用尽做何准备：功能冻结、可靠性冲刺、事故复盘优先级。无策略的预算图表无意义。
• 演练事故响应。轮班、升级路径、无责复盘等详见我们的SRE事故管理指南。
• 保持工具数量合理。每年审核监控堆栈，基于简化的两个问题。我们的SRE工具汇总涵盖实用类别。
• 养成可靠性报告习惯，而非临时应付。定期正常运行及SLA报告，让合规对话基于共享数据，而非事后挖日志。

总结

七条SRE原则经谷歌走出而存续。未存续的是背后假设：执行团队掌控整个堆栈。你不掌控，工作发生变化。无法工程消除的风险须测量。错误预算依赖检测间隔。内部工具负责流量和饱和度，用户感知的延迟和错误只能外部观察。发布后验证必须从外部执行，因为那是系统全貌。

共同点是外部测量。七条原则在不属你控制组件组成的堆栈中，均需独立视角：风险需依赖逐项检测；错误预算需1分钟间隔；黄金信号采集用真实浏览器；事务和发布自动化需脚本化；简化需整合至一个平台。这即是Dotcom-Monitor整合七条原则所扮演的角色。非工具推荐，而是原则要求，当堆栈不再由你掌控。

常见问题解答