1 SRE 实践要覆盖什么
顾客点下“提交订单”，页面转了很久，最后提示稍后重试。此时机器可能都在运行，部署平台也显示正常，但顾客没有完成购买。站点可靠性工程（Site Reliability Engineering，SRE）关心的是这种差距：基础设施看起来健康，是否真的意味着服务可用？它把用户体验转化为可测量的目标，再用工程方法管理运行风险，让团队持续交付功能，并承担上线后的可靠性责任。
本课使用 1 个小型订单 API 作为例子。请求经过入口和负载均衡，到达部署在不同可用区的应用实例；应用用自己的服务身份访问订单数据库，并将处理结果写入日志、指标与追踪系统。网络规则控制谁能连接谁，身份权限控制连接之后可以做什么。顾客的订单是否成功，取决于这条路径能否一起工作，不能只看其中某台主机的 CPU。
SRE 实践至少覆盖目标、观测、响应、变更与改进。目标说明怎样才算对用户足够好；观测让团队发现目标正在受到威胁；响应把异常交给能够处理的人；变更管理控制新风险进入服务的速度；改进则减少故障反复发生的机会。自动化连接这些活动，但工具数量不是成熟度的证明。如果告警会响、值班员却不知道怎样止损，可靠性闭环仍然缺了关键部分。
云平台提供了可用区、托管数据库、身份管理等基础能力，却不能替团队决定业务的恢复优先级。例如，数据库故障切换之后，应用可能仍持有失效连接；实例自动重建之后，也可能因权限配置错误而无法访问数据。平台负责的能力和团队负责的应用行为必须相接。采购了某项服务，不等于已经验证了订单路径在故障时的表现。
这里还要区分可靠性与数据正确性。订单 API 返回成功，却没有可靠保存订单，不能算成功；接口迅速返回错误，也不能仅凭响应快就算健康。重复扣款、越权读取、丢失已确认订单等问题有独立的正确性或安全要求。可用性目标不能替代这些约束，更不能把允许少量失败理解为允许损坏数据。设计指标时，应把“成功”的业务含义写清楚。
SRE 也不等于“所有运行工作交给专门的 SRE 团队”。小团队可以由开发和运维共同承担，大团队可以设置专业角色，但服务负责人始终需要了解用户路径。手工重启、重复查日志、逐次修复相同配置等工作，如果频繁发生、容易标准化、只是在维持现状，就应进入消除重复劳动的改进清单。自动化之前仍要弄清原因，避免把错误操作执行得更快。
初学时可以从 1 条关键路径开始，不必给每个内部组件都设置复杂目标。先描述顾客怎样完成操作、哪些依赖参与其中、谁负责响应，再建立少量可信指标和可执行的处置步骤。等闭环运转起来，再扩展到查询、支付回调或后台任务。本课聚焦这些基础机制，跨区域一致性、复杂容量模型和高级告警算法留到后续学习。
2 SLO、错误预算与告警
服务等级指标（SLI）是实际测到的表现，服务等级目标（SLO）是对该指标设定的目标。服务等级协议（SLA）通常还包含对外承诺及未达标后的处理条款，不能与内部运行目标混用。团队可以先建立内部 SLO，观察是否可测、是否有用，再讨论对外承诺。随口说“接口要稳定”缺少测量对象、时间范围和判断标准，无法指导值班决策。
对订单创建接口，可以约定：在滚动 28 天窗口内，符合统计范围的生产请求中，至少 99.9% 在 800 ms 内完成订单持久化并返回业务成功。这里把成功和延迟合成 1 个良好事件条件；另设可用性与延迟指标也可以，但必须分别说明分母。客户端主动取消、认证失败、格式错误和依赖超时怎样计入，需要依据用户体验明确，不能为了得到漂亮数字随意排除失败。
基于请求的 SLI 可以写成“良好请求数 ÷ 有效请求总数”。目标为 99.9% 时，允许的不良比例为 0.1%。假设窗口中有 1,000,000 次有效请求，允许 1,000 次不良请求；已经出现 400 次，则在当前窗口和请求总量下还剩 600 次。滚动窗口会不断纳入新事件、移出旧事件，总请求数也会变化，因此剩余预算必须持续重算，不能把这个示例数字当成固定额度。
错误预算是目标允许的不良事件额度，用来协调可靠性与交付风险。预算耗尽表示服务在所选窗口内已经达不到目标，应触发事先约定的运行策略。它不是可以主动制造的故障配额，也不是事故发生后免于解释的理由。对于基于请求的目标，预算按请求计算；对于基于时间的目标，预算按不良时间计算。低流量时段的 1 次失败与高流量时段的 1 分钟故障，不能未经换算直接比较。
预算燃烧率描述当前不良比例相对允许比例的倍数。若允许比例为 0.1%，某个观测窗口内不良比例为 1%，燃烧率就是 10。它说明预算消耗速度显著高于长期可持续水平，而不是说预算已经消耗了 10%。短窗口有助于发现突发故障，较长窗口有助于确认影响持续存在。初学团队可先设置严重故障快速通知、持续退化稍后通知的分层规则，再根据真实事件调校。
告警应表达需要人采取行动的条件。用户失败率快速升高可以呼叫值班员，磁盘空间缓慢下降可以创建工作项，单次可恢复重试可以只记录。只靠 CPU 阈值会漏掉权限拒绝和数据连接故障，也可能把正常批处理误判为事故。用户路径指标负责说明影响，资源和依赖指标帮助解释原因；它们在告警中承担不同职责。
数据缺失必须有独立语义。指标采集器停止上报时，失败率曲线可能消失，却不代表请求恢复正常。面板要区分达标、违约、无流量与无数据，并为关键观测链路设置健康检查。探测请求可以补充低流量时的盲点，但应标明它只是模拟路径，不能冒充真实订单成功率。目标、预算和告警都建立在可信测量上，测量本身也需要维护。
3 值班、复盘与变更管理
值班是明确的响应责任安排，而不是要求所有人随时查看聊天群。每个服务需要当前主值班、备用联系人、升级路径和交接记录。主值班接到告警后先确认影响范围，再组织止损；备用人员在无人确认、问题超出权限或需要额外协助时接手。轮换频率和响应时间要根据业务要求与人员规模确定，并保证人员有休息和交接时间。
事故处理宜分清协调、技术操作和信息记录的职责，小团队允许同人兼任，但不能让职责消失。协调者维护当前判断和下一步动作；操作者执行有边界的变更；记录者保留时间线与结果。严重事故期间，减少无关发布和重复操作，有助于判断哪项动作产生了效果。对外更新则说明已知影响、正在采取的措施及下次更新时间，避免把猜测当作结论。
先恢复服务，再深入定位，通常比现场追求完整根因更有利。若最新版本上线后订单失败迅速增加，而且回滚路径已验证，可以优先回滚；若旧版本不兼容已经执行的数据迁移，盲目回滚反而会扩大损害。运行手册需要写清动作的适用条件、权限、数据影响与停止条件。恢复动作应尽量缩小影响范围，并保留足够证据支持后续分析。
复盘是在服务稳定之后，重建事实并改进系统。记录应包括用户影响、发现方式、关键时间点、处置动作和恢复验证。讨论“当时有哪些信息让这个决定显得合理”，比停留在“某人为什么犯错”更能找出设计缺口。无责复盘并不意味着没有责任：改进项仍然需要负责人、完成期限和验证方式，只是不把复杂失败简单归结为个人态度。
变更管理的重点是控制风险与缩短反馈，而不是增加审批层数。发布前确认版本、依赖、配置和数据变更的关系；先在小范围暴露流量，观察用户指标与预算消耗，再决定扩大。出现明确失败信号时停止扩量，并执行已经准备好的回退或止损动作。基础设施配置、身份权限、网络规则和数据库结构同样是变更，不应只有应用代码受到管理。
回滚能力必须具体。应用镜像能够切回旧版，不代表数据库结构可以逆转；配置可以恢复，不代表已发送的外部请求可以撤销。因此发布记录应标明可逆范围和补救办法。修改订单表时，可以先引入兼容结构，再切换应用读写，最后清理旧结构。这里不展开迁移技术细节，但要记住：部署成功与回滚安全是不同的验收事项。
值班经验还应进入下次发布准备。如果某种告警每周都会出现，却总靠同样的手工操作恢复，它就是需要工程改进的信号。团队可以定期查看夜间呼叫数、重复事故和恢复耗时，选择最影响用户或最消耗人员的项目处理。不要只统计平均恢复时间就宣称进步；不同严重度、不同影响范围的事件混在一起，平均值可能掩盖实际问题。
4 动手：为一项服务定义 SLO
先为订单创建接口写出用户承诺：“合法请求应在可接受时间内得到明确结果，成功结果对应已可靠保存的订单。”接着画出入口、应用、服务身份、网络连接和数据库的路径，并标记测量位置。若只在应用内部计时，入口排队和网络失败可能被遗漏；若只看入口状态码，又可能看不到应用错误地返回成功。测量边界必须与承诺相匹配。
选择统计范围时，把生产环境、接口路径和请求类型列出来。测试探测应单独标记，健康检查不混入订单请求。客户端参数无效可以排除，但被错误权限配置拒绝的合法顾客请求应计为失败。对于重复提交，要按事先定义的请求口径统计，并通过幂等处理避免重复订单；不能在失败后临时把重试从分母中删掉。排除规则需要理由和版本记录。
接下来定义良好事件。示例沿用“在 800 ms 内持久化订单并返回成功”，时间从已选定的入口接收请求起算。服务端记录成功依据，入口记录响应时长，并通过请求标识关联。记录中不应包含完整支付凭据或敏感个人资料。短期内无法准确关联时，可以先分别观测成功率与延迟，并诚实记录限制，避免把估算包装为精确的端到端指标。
确定目标之前，先收集有代表性的历史数据，覆盖正常日、活动高峰和发布时段。如果当前只能稳定达到 99.5%，直接写下 99.99% 不会自动改善系统，反而会让目标长期失去指导作用。可以先设定符合业务需要的阶段目标，并列出差距对应的改进投入。目标也不能只由现状倒推：顾客无法接受的体验，即使长期如此，仍然需要修复。
将目标写成可计算的规则。本例使用滚动 28 天、99.9%、800 ms 和明确的有效请求集合。若某个演示窗口有 200,000 次有效请求、199,860 次良好请求，SLI 为 99.93%；不良请求为 140 次，允许额度为 200 次，当前剩余为 60 次。再把失败分布按时间展开，检查是否集中在短暂故障期间。窗口总量达标，仍可能隐藏某次严重的局部影响。
建立面板时，至少展示有效请求量、良好比例、预算余额、短期不良比例和观测数据新鲜度。按可用区、版本或关键客户群体查看辅助切片，有助于发现总体平均掩盖的问题，但不要让切片过多导致每条曲线都只有少量样本。指标用于定位异常发生在哪里，日志解释具体错误，追踪展示依赖耗时；这 3 类数据需要共享时间与关联标识。
最后演练告警和响应。在测试环境注入可控错误，或者使用明确标注的历史数据回放，验证阈值触发、通知到达、备用升级和手册入口。让没有编写手册的同事按步骤执行，并检查恢复后是否确实能创建订单。这个练习交付的是可运行的约定：谁测量、谁响应、何时止损、怎样判断恢复。它还不要求在生产环境制造故障；更系统的故障实验会在 C52 展开。
5 功能速度与稳定性取舍
业务希望尽快上线优惠券，团队又担心发布引入故障。若只争论“速度重要”还是“稳定重要”，双方很难形成可执行决策。SLO 提供共同目标，错误预算提供运行反馈，发布策略把反馈转化为动作。预算充足时可以按常规节奏推进，并维持测试和渐进发布；预算持续下降时缩小变更范围；预算耗尽时优先恢复可靠性。具体规则应在事故之前约定。
预算策略不能简单等同于全面冻结。常规功能发布会引入额外风险，但用于恢复服务、修复严重安全漏洞的紧急变更可能仍然必要。例外需要说明目的、影响范围、验证方法和回退安排，并由事先约定的责任人决定。若没有例外机制，团队可能把必要修复也挡住；若所有功能都被标成紧急，策略又会失去约束力。
交互中可以调整 SLO、请求量、当前不良请求数和近期不良比例，观察同一组事实怎样改变预算判断。提高 SLO 会减少允许的不良额度，而不会让系统性能立即提升。增加请求量会改变请求预算的绝对数量，但在相同不良比例下并不会改变是否达标。这能帮助读者区分“失败次数更多”与“服务质量更差”，并理解为什么不能只凭次数作发布决定。
这个模型只展示预算算术，不预测某次发布会失败多少，也不自动批准生产操作。剩余预算为正，不代表当前没有严重故障；预算为负，也不意味着恢复变更必须等待窗口自然刷新。还要检查影响是否集中于重要用户、是否存在数据风险、观测是否完整。预算让讨论有共同依据，但不会替代对事故状态和业务约束的判断。
交付速度也不只由发布频率衡量。变更太大，出了问题难以判断原因；每次都靠人工比对配置，等待与返工也会拉长交付时间。小批量变更、自动化检查、可观察的渐进发布和可靠回退，往往能同时缩短反馈时间并降低影响范围。团队投入这些能力，是在减少每次发布的不确定性，而不是单纯增加发布前的工作量。
稳定性同样有成本。更高目标可能要求更多冗余、更严密的依赖管理、更充足的值班和更多验证。订单创建与推荐列表未必需要相同目标：前者失败会直接阻断购买，后者可能可以暂时显示默认内容。按用户后果划分目标，能够让资源投入有依据。不要因为内部组件“看起来重要”，就为所有服务统一设置最严目标。
周期性回顾时，把功能收益、可靠性投入和运行负担放在一起讨论。如果预算反复耗尽，应检查目标是否合理、实现能力是否不足，以及团队是否持续绕过策略。不能靠频繁降低目标消除违约记录，也不能把过去事件重新分类成无效请求来恢复预算。目标调整需要说明业务理由、适用时间和历史影响，让后续评价保留可比性。
6 常见坑：告警无行动手册
最常见的告警问题并不是阈值不够精细，而是告警到达后无人知道该做什么。“订单服务异常”没有范围、没有面板链接、没有负责人，只会迫使值班员从头搜索。可执行告警应说明哪个用户动作受影响、持续多久、严重程度如何，并提供当前指标、最近变更和对应手册入口。夜间呼叫尤其需要明确的行动理由。
运行手册要从确认影响开始。例如先查看订单创建成功率和请求量，排除监控断流；再比较不同版本和可用区；随后检查近期发布、身份拒绝、网络连接与数据库错误。这个顺序不是固定根因列表，而是让操作者用证据逐步缩小范围。没有用户影响时，可以降低紧急度，但仍要处理观测故障，不能直接把告警关闭了事。
手册中的动作要写到可执行程度。“检查数据库”过于笼统，可以改为“查看连接失败指标及数据库状态；若连接失败集中在新版本，停止扩量并联系发布负责人”。每个高风险动作标明授权角色、操作范围、预期结果和停止条件。需要临时权限时应使用受控流程，不能把长期高权限凭据贴进手册，也不能让值班员靠借用他人身份完成恢复。
另一个常见坑是把重启当成默认答案。重启可能暂时释放连接，却也可能同时清空诊断线索、增加数据库重连压力。若多台实例一起重启，还可能把局部退化变为全面不可用。只有在适用条件明确、影响可控且观察到预期信号时，才继续执行。动作无效就停止并升级，避免在压力下无限重复相同操作。
告警噪声会消耗响应能力。同一依赖故障可能引发大量上游告警，通知系统可以按事件聚合并保留受影响服务列表。维护时段允许临时静默，但需要负责人、原因与到期时间；正在发生的用户影响仍要有人跟踪。删除阈值、永久静默或让所有告警只进无人查看的群，都只是把发现责任从系统转嫁给顾客。
运行手册还会过期。改了入口、换了部署方式或调整了身份权限后，旧步骤可能失效。可在发布检查和事故复盘中触发更新，并定期通过桌面推演或测试环境练习验证。验证内容包括链接是否可用、命令是否仍然适用、备用联系人是否有效，以及操作者是否拥有所需权限。只有更新日期，没有实际演练证据，并不能证明手册可靠。
最后，要允许手册承认边界。遇到疑似数据损坏、跨服务资金异常或未知权限变化时，应停止可能扩大影响的操作，联系对应负责人并保留证据。初级值班员不需要在夜间独自解决所有内部问题，但需要知道什么时候必须升级。好的手册把常见处置变得明确，也把超出经验范围的情况安全交接出去。
7 案例：错误预算耗尽仍强推变更
某订单 API 的滚动 28 天目标为 99.9%。在最近的观测窗口中，有 2,000,000 次有效请求，允许 2,000 次不良请求，实际已经出现 2,300 次，因此当前预算为负。前次事故刚结束，连接池相关改进尚未完成。业务提出当天上线促销功能，团队以“只改了配置”为由跳过预算策略，也没有把配置发布纳入应用发布的检查流程。
新配置改变了应用访问数据库所用的服务身份，但数据库授权没有同步完成。小范围发布阶段已经出现访问拒绝，发布脚本却只检查实例是否启动、健康检查是否通过。健康检查不访问真实订单依赖，因此所有检查仍显示绿色。扩量之后，更多合法订单创建失败，顾客开始重复提交，客服收到投诉。实例数量和 CPU 曲线没有明显异常。
这里的错误预算耗尽不是权限故障的直接原因。故障由身份配置与数据授权不匹配触发，健康检查不足和缺少渐进发布门禁使影响扩大。预算策略本应提示团队暂停普通功能发布、先处理已知可靠性缺口，却被临时绕过。区分触发因素、扩大因素和治理缺口，才能提出各自对应的改进；不能用“预算不足导致事故”替代技术分析。
值班员首先确认订单失败来自新版本对应的身份拒绝，随后停止扩量。由于本次没有改变数据库结构，且旧身份仍有效，团队按已验证路径恢复上一版配置，并观察新旧实例的流量切换。恢复判断同时检查订单创建成功率、延迟和实际持久化结果。仅看到实例健康恢复不足以结束事故，已经失败或结果不明的请求还需要按业务流程核对。
若当时旧身份也已被撤销，回滚应用就无法恢复访问。此时应由具备权限的责任人按受控流程修复授权，限制到订单服务实际需要的操作，并验证审计记录，而不是临时授予整个账号管理员权限。案例中的止损选择依赖明确条件：旧配置可用、数据兼容、授权路径可恢复。把这些条件写入手册，比记住“发生故障就回滚”更有迁移价值。
复盘形成了几项具体改进：发布清单纳入身份和权限差异；在测试环境用实际服务身份验证订单写入；渐进发布观察真实业务成功率；预算策略设置明确的例外责任人；为访问拒绝告警补充配置恢复步骤。每项都有负责人和验收证据。验证时使用最小权限和测试数据，既确认合法请求可完成，也确认服务不能读取不需要的数据。
对已经耗尽的预算，团队不能通过删除事故数据立即恢复常规发布。应先确认当前用户影响结束，推进可靠性修复，并依据预先约定的恢复条件重新开放功能变更。滚动窗口中的旧失败逐步移出，是统计变化；修复经过验证，是工程证据。两者需要一起看。案例的教训是把目标、权限、观测和发布决策真正连接起来，而不是只在看板上展示预算数字。
8 把 SRE 机制写进运营方案
运营方案要让接手的人知道服务承诺、责任边界和行动规则。先列关键用户路径及其负责人，再列云平台、应用团队、数据团队和安全角色各自承担的职责。例如平台可以保障数据库托管能力，应用团队仍需处理连接恢复和请求重试；身份管理员维护授权机制，服务负责人仍需确认所申请权限符合实际需求。边界明确后，升级才不会停留在互相转交工单。
每项 SLO 都应记录指标定义、统计范围、测量位置、窗口、目标与数据负责人。把查询或配置的版本与文本定义对应起来，避免文档写 800 ms、实际面板却使用另一阈值。说明无流量和无数据的处理方式，列出已知盲区。对关键用户群体存在特殊影响时，应保留辅助视图和单独响应规则，防止总体比例掩盖局部不可用。
错误预算策略要写成条件与动作。预算正常时采用常规发布；预算消耗加快时缩小批次、加强观察；耗尽时暂停普通功能变更，优先恢复和可靠性修复。这里的“加快”应在附件中对应可测规则，不能只靠负责人感觉。例外写明适用情形、决定人、验证要求和有效范围，并留下记录供复盘审查。策略的价值来自团队能够一致执行。
值班部分列出覆盖时段、主备轮换、确认时限、升级对象和事故协调方式。行动手册与告警规则应相互链接，交接记录保留未解决风险和正在进行的临时措施。对于恢复动作，特别说明所需身份、权限来源、数据影响和回退边界。若服务需要全天候承诺，方案还必须说明实际人员安排，不能只写“必要时联系开发”。
变更部分把应用、网络、身份和数据变更放进同一风险视野，记录每次发布的版本、操作者、时间与观察结果。测试检查功能正确性，渐进发布检查真实流量表现，回退演练检查恢复路径。对于不可逆的数据操作，需要专门的补救计划和执行条件。不要将“有备份”直接当作恢复已经得到保证；备份是否可读、恢复需要多久，都应有验证依据。
改进部分保留事故复盘与重复劳动清单，把高频人工操作转成有验收条件的工程任务。比如“减少告警”应改成消除某类重复故障或修正无行动价值的通知，并检查是否漏报。每个任务说明希望改变的用户结果或人员负担，避免只统计脚本数量。定期回顾 SLO、值班负担和未完成改进，才能判断运行机制是否真的在积累能力。
验收方案时，可以选择 1 次失败场景进行桌面推演：谁发现、谁确认、依据什么暂停发布、用什么权限恢复、怎样确认订单已可靠保存。若任意环节只能回答“到时候再看”，就补充对应规则或演练。文档不需要穷尽所有故障，但应把最重要路径中的决策接口交代清楚，让陌生接班者也能知道下一步去哪里找证据和帮助。
9 从SRE 实践走向混沌工程（C52）
到这里，团队已经能说明服务目标、测量实际表现、响应告警并控制变更风险。但仍有一个问题：写在方案中的恢复能力，是否真的在依赖故障时成立？例如，应用跨可用区部署了，失去某个可用区后剩余容量是否足够；数据库连接中断后，应用是否按预期恢复；身份服务暂时不可用时，已有请求会发生什么？这些问题需要证据，不能只凭架构图推断。
混沌工程通过有计划、受约束的故障实验检验系统假设。它不是随机破坏生产环境，也不是等事故来证明设计。实验从可证伪的假设开始，例如“测试环境中停止 1 个应用实例后，其余实例能继续满足选定的请求目标”。然后确定注入方式、可观察指标、停止条件和恢复方法。高级故障注入工具可以后学，实验边界与安全停止机制必须先明确。
本课的 SLO 是实验观察用户影响的基础，值班手册提供恢复路径，变更记录帮助排除其他干扰。若指标缺失、权限不清、回退未验证，就先补齐这些条件，再开展实验。测试环境适合验证基本行为，但流量、数据规模和依赖配置可能与生产不同，因此结果需要说明适用范围。是否进入生产实验，要另行评估风险与授权，不能由测试成功自动推导。
进入 C52 前，可以准备 1 张假设卡：选中的用户路径、预期故障、预计影响、观察指标、最大允许范围、停止信号和恢复负责人。不要直接从最难的全区域中断开始，先选择影响可控、结果可解释的场景。实验发现弱点之后，要形成修复和再次验证的闭环；只展示故障注入过程，却不追踪改进结果，不能证明可靠性有所提高。
SRE 实践提供了“什么值得保护、怎样判断变差、由谁采取行动”的运行基础。混沌工程将进一步检查“我们相信的恢复机制是否成立”。两者相接时，学习重点从记住服务名转向理解依赖、证据和决策。先把目标与响应做扎实，再逐步扩大验证范围，才能让故障实验成为可靠性改进的工具。
放进方案里
在订单 API 的运营方案中，先写明关键用户承诺：合法创建请求应在 800 ms 内完成订单持久化并返回业务成功。采用滚动 28 天、99.9% 的 SLO，列出有效请求范围、排除理由、入口计时位置和成功确认依据。指标配置与文档共同维护版本；无流量、无数据和未达标分别展示，避免将监控断流解释成服务恢复。
将请求预算定义为有效请求数的 0.1%，由运行面板持续重算余额与近期燃烧率。预算正常时按常规流程发布，消耗加快时缩小批次并增加观察，耗尽时暂停普通功能变更。恢复服务和紧急安全修复可以走例外流程，由指定责任人记录理由、验证结果和回退条件。任何例外都不删除历史失败，也不自动解除后续限制。
为服务安排主值班、备用人员和升级路径，告警必须链接用户影响面板、近期变更与行动手册。手册从确认影响开始，按证据检查应用版本、身份授权、网络和数据库，写清操作权限、适用范围及停止条件。服务身份仅保留所需权限，恢复操作留下审计记录。每次发布同时检查代码、配置、权限和数据兼容性，并在小范围流量中验证订单结果。
事故结束后形成时间线、用户影响和改进清单，落实负责人、期限与验收证据。定期回顾重复呼叫与人工操作，优先消除反复出现的运行负担。方案附件保留指标定义、预算策略、值班表、手册、发布记录和恢复演练结果；进入混沌工程前，再准备明确假设、影响边界、停止信号与恢复负责人。用这些证据验收机制，而不是只检查文档是否齐全。
10 小结：下一步混沌工程（C52）
SRE 把用户体验转成可测目标，用错误预算协调发布风险，用值班与手册响应异常，再通过复盘和工程改进减少重复故障。目标需要可信测量，告警需要可执行动作，发布需要明确的停止与恢复条件。
可以用 3 个问题检查自己的方案：顾客无法创建订单而实例健康时，谁会发现？预算耗尽时，哪些变更仍可执行，由谁决定？回滚之后，什么证据证明订单已经可靠保存？若答案仍然模糊，先完善对应环节。下一课 C52 将在这些基础上，用有边界的故障实验验证恢复假设。