1 混沌工程要回答什么
订单页面平时能够打开，不代表服务在故障时仍能完成交易。某个实例退出后，请求是否会转交给健康实例？连接数据服务变慢后，API 会及时返回明确结果，还是把线程和连接都占满？监控显示服务恢复后，用户刚才提交的订单是否仍然完整？混沌工程关心这些故障条件下的实际行为，用受控实验检验关于可靠性的判断。
设想 1 个小型零售服务：入口接收下单请求，订单 API 有 3 个实例，工作负载通过身份凭据访问数据服务，网络规则限定通信范围，监控记录请求结果。部署、身份、网络、数据和可观测性共同决定交易能否完成。任意环节都可能失效，但实验不应同时改变所有环节，否则即使出现错误，也很难解释原因。
团队常说“我们有多个副本，所以能够容忍实例故障”。这句话包含许多未验证的条件：入口能否发现实例失效，其他实例是否有容量，客户端是否会重复提交，数据连接是否会重新建立。混沌工程把这种笼统信心改写为可检验的假设，再主动施加有限扰动，查看真实结果是否符合预期。它提供的是有条件的证据，不是永远可靠的保证。
普通功能测试往往从输入和预期输出出发，例如合法商品能够生成订单。混沌实验则增加环境条件，例如处理请求的实例突然消失时，同样的业务输入还能否得到可接受结果。两者可以共用测试环境和监控，也都需要明确判定标准。区别主要在于实验主动改变了运行条件，并观察系统如何吸收这次变化。
故障演练、灾难恢复演练和混沌工程也有交集。恢复演练可能验证备份能否还原，值班演练可能检查人员是否收到告警。混沌实验可以包含这些环节，但必须有具体假设、受控范围、观测与停止条件。仅仅随机关闭机器，或者制造大量报错后让大家抢修，并不能自动产生可靠性知识。
初学时，问题应当足够窄。例如：“在指定测试环境中，订单 API 移除 1 个实例后，测试交易是否仍满足成功率和延迟目标？”这个问题比“我们的云架构够不够可靠”更容易回答。完成实验后，结论也应保持同样的边界：只说明所测环境、负载、依赖状态和故障类型下的表现，不外推到整座机房失效。
实验的价值还包括发现错误的理解。团队可能以为告警检测的是交易失败，实际却只检测进程是否存活；以为副本相互独立，实际却共同依赖某个网络出口。通过小范围扰动把这些隐藏条件显露出来，通常比在真实流量高峰中发现它们更便宜。学习目标始终是改进服务设计与操作流程，故障数量本身不是成绩。
2 假设、稳态与实验范围
实验假设应同时描述故障、范围、负载和预期。例如：“测试环境订单 API 原有 3 个健康实例；在总计约 30 请求/秒的合成流量下，移除其中 1 个实例，剩余实例接管请求；接下来 120 秒内，交易成功率不低于 99%，请求延迟 p95 不高于 500 毫秒，且没有重复订单。”这些数字只是本课的教学条件，实际目标必须来自服务需求和基线。
稳态是系统处于可接受业务状态的可测描述，不要求所有曲线保持水平。订单服务的请求量本来就可能波动，只要交易结果、延迟和数据正确性仍在约定范围内，就可能处于稳态。因此，CPU 使用率适合帮助解释问题，却通常不足以单独代表稳态。用户能够可靠地下单，才是这个例子需要保护的结果。
成功率还必须说明分子和分母。这里把每个带唯一业务编号的合成下单意图作为统计单位，最终返回可核对的订单结果才算成功。若只统计某次 HTTP 调用是否返回成功，重试可能掩盖首次失败，也可能把重复创建算成额外成功。流量发生端记录用户看到的结果，数据端核对订单数量，才能让指标真正对应业务。
p95 表示样本中约 95% 的请求延迟不超过该值，不是最慢请求的延迟。实验前要确定统计窗口和最小样本量。低流量下，几个请求就能明显改变成功率或分位数；此时不能把曲线的小变化解释成稳定规律。可以延长测试基线、使用合成流量，并保留原始请求记录，避免仅凭仪表盘的聚合曲线下结论。
实验范围至少包含环境、资源集合、请求集合、依赖和持续时间。给资源加上实验标签很有用，但标签只是选择线索，还应在执行前预览实际资源标识，核对副本归属和数量。若选择结果突然从 1 个实例变成 20 个，就必须停止准备。实验中的“爆炸半径”指扰动可能影响的范围，不能只按注入工具直接操作的资源计算。
例如，测试 API 使用独立实例，却与其他服务共享数据库连接额度。让测试请求大量等待，可能耗尽共享连接，影响范围就越出了测试 API。身份凭据、网络出口、队列和告警通道也可能是共享依赖。若无法证明这些依赖隔离充分，就应缩小负载、改用独立依赖，或先在模拟环境验证，而不是把“测试环境”当作天然安全的标签。
实验还需要对照条件。记录注入前的版本、配置、实例数量、流量和依赖状态，尽量在实验期间暂停无关发布。若实验过程中恰好变更了数据库参数，结果即使变差，也不能直接归因于实例故障。能够重述环境条件和变化顺序，比获得好看的曲线更有价值；缺少这些信息，后续复测就没有可靠参照。
最后，提前约定什么算支持假设、什么算反例、什么算证据不足。达到指标且数据核对通过，可以支持当前假设；错误率超限或出现重复订单，可以反驳假设；监控中断、流量不足或目标选错，应标记实验无效。停止得及时不等于假设成立，执行完成也不等于已经获得可用结论。
3 故障注入与护栏
故障注入是有意改变系统条件的操作。入门实验可以选择使 1 个测试实例退出、给指定测试调用增加延迟，或让隔离环境中的某项访问返回拒绝。不同注入对应不同问题：实例退出检查流量接管，网络延迟检查超时与资源占用，身份拒绝检查错误处理与告警。先确定想验证的行为，再选择最小的扰动手段。
这些故障不能随意互相替代。让应用主动返回错误，并没有验证入口如何识别失联实例；增加应用内部等待，也不一定覆盖真实网络连接失败。实验记录应写明故障施加在哪个位置、改变了什么、没有覆盖什么。这样，后续读者才能判断结论是否适用于自己遇到的故障，而不会被“已测试网络故障”这样的模糊标签误导。
护栏负责限制实验失控后的影响。至少要有目标数量上限、持续时间上限、负载上限和业务停止阈值。还要为停止动作指定负责人、操作入口和恢复验证方法。若只有“出问题就回滚”这句话，却没有说明谁能操作、恢复哪项配置、如何确认残留故障已经清除，护栏就仍然停留在口头约定。
持续时间到期应自动撤销可撤销的注入，但自动到期不能替代主动停止。比如网络规则阻断了实验控制器访问目标，控制器可能无法执行撤销。准备阶段就应确认恢复路径不依赖正在被破坏的同一条通信链路，必要时使用独立管理入口。对于实例退出实验，“撤销”通常意味着恢复健康副本数量，并不保证原来的进程能够回来。
权限也要符合实验范围。执行身份只应拥有指定环境和目标所需的最小权限；不应为了方便而授予删除整个项目、修改共享身份策略等能力。实验者需要操作的权限与被测应用的运行权限是不同的责任。将两者混用，会让原本只想验证应用行为的实验变成对整个云环境的高风险修改。
停止条件应早于不可接受损害，并且与假设判定有所区别。假设可能要求成功率不低于 99%；护栏可以另设连续 10 秒低于 98% 就停止，或者任何 1 笔重复订单都立即停止。前者需要观察窗口，后者不应等待汇总。更严格的假设未满足时，实验仍可能在安全范围内结束；护栏触发则意味着应立即收敛影响。
观测失联本身也是停止信号。如果请求结果无法采集，团队就失去了判断安全状态的依据。不要在看不到指标时继续注入，等监控恢复后再猜发生了什么。准备时应试验停止按钮、到期恢复和人工接管，并验证它们确实改变了目标状态。能够点击按钮，只能证明界面响应，不能证明故障已经解除。
对于初次练习，选择可替换的测试实例和可丢弃的合成订单，避免删除持久数据、修改共享密钥或中断真实支付。这里的谨慎来自问题本身：验证流量接管并不需要承担数据丢失风险。更复杂的故障组合、跨地域演练和自动化随机调度，应在基本流程可靠之后再学习。
4 动手：设计一次有限爆炸半径实验
本次练习的交付物是 1 份可执行的实验单，以及对应的观测记录。环境使用专门的订单 API 测试部署，包含 3 个副本、独立测试数据和合成请求入口。若手头没有云测试环境，可以使用交互动画完成桌面推演，并将结果标为推演，不能当作真实运行证据。实施前仍须按照实际平台核对资源和恢复方式。
先填写实验单：问题是验证移除 1 个实例后的流量接管；假设采用前节的成功率、延迟和订单唯一性条件；资源范围是指定部署内的 1 个实例；注入持续观察 120 秒；流量约为 30 请求/秒。记录环境标识、版本、目标实例标识、执行身份和负责人。不要把“任意实例”写进最终执行目标，以免范围在运行时发生变化。
接着采集至少 5 分钟基线。确认 3 个实例健康，入口确实把请求分配到它们，订单数据可以逐笔核对。检查剩余 2 个实例是否有足够容量，并确认实例补充机制的配置。如果自动补充会很快恢复到 3 个副本，实验测到的就是“接管与自动补充共同作用”的结果，应照实记录，不能声称验证了持续使用 2 个副本的能力。
在准备阶段运行合成交易，每次请求携带唯一业务编号，记录开始时间、结果、延迟和订单标识。身份只允许访问测试数据，网络规则使测试 API 不会调用真实支付入口。然后检查停止信号是否可以被独立观察：负载端能看到错误，数据核对能发现重复，值班人员能收到实验通知。任意环节缺失，就先补齐，暂不注入。
执行前再次预览目标，确认只有 1 个测试实例被选中。给记录添加实验开始标记，然后使该实例退出；入口摘除目标、客户端响应和新副本出现的时刻都要记录。观察窗口内不要同时调整超时、扩大流量或修改副本数量，否则很难辨认系统原本的恢复行为。若触发停止阈值，立即终止注入并按预案恢复服务。
观察结果时，至少把用户结果、入口状态和实例状态放到同一时间轴。某个实例已经退出，不代表入口立刻停止向它发送请求；入口已停止分发，也不代表等待中的请求已经结束。还应观察数据连接、重试次数和剩余实例负载。如果成功率看似正常但请求次数翻倍，说明重试承担了额外成本，系统可能正接近容量边界。
到期或人工停止后，确认不再存在活动注入，健康副本数量恢复，入口目标正常，再持续观察至少 5 分钟。核对本次所有合成业务编号的最终结果，区分成功、明确失败和结果未知。结果未知的请求不能直接计为失败后再次创建订单，应该先查询是否已经落库。这既是正确性检查，也是验证业务幂等处理的机会。
最后输出结论。例如：“在指定版本和负载下，移除 1 个实例后，成功率与延迟符合目标，未发现重复订单；实验中自动补充在 40 秒后完成。”若出现 12 秒错误突增，就保留原始记录，写出入口摘除滞后的证据和待验证原因。提出修改后，按相同条件复测；只有复测结果才能说明改动是否解决了观察到的问题。
5 学习收益与生产风险取舍
实验应优先消除有价值的不确定性。若团队从未确认过入口会不会摘除故障实例，简单的实例退出实验就可能提供很大收益。若已经反复验证过同样版本和负载，继续重复相同操作的新增信息可能很少。可以把问题列成清单，比较业务重要性、当前证据缺口和验证成本，优先选择既重要又能安全验证的假设。
测试环境便于控制，却可能与生产环境存在差异，例如流量形状、身份策略、数据规模、网络路径和自动伸缩配置。测试结果能够排除部分缺陷，但不能证明生产中的全部行为。生产实验更接近真实条件，也可能影响真实用户和共享依赖。因此，从测试环境逐步进入生产应当基于证据和组织准备，不是为了让实验显得更“真实”。
范围扩大时，要逐项说明新增了什么风险。由 1 个实例扩大到 2 个实例，会同时改变可用容量和故障覆盖面；由合成请求扩大到真实用户，会增加结果核对与补偿难度；由独立数据库转向共享数据库，会改变其他服务的暴露程度。这些变化不能只用某个总分概括，更不能因为上次成功就自动批准下一档范围。
交互中的容量计算只是教学模型。假设每个实例稳定承载 20 请求/秒，3 个实例共提供 60 请求/秒，移除 1 个后名义容量为 40 请求/秒。面对 30 请求/秒的负载，名义利用率从 50% 升到 75%。真实系统还受流量不均、连接数、数据依赖和恢复速度影响，不能把“低于 100%”解释为安全证明。
生产风险还有人员与时间因素。即使资源范围很小，如果当班人员无法及时判断告警、停止权限由离线人员掌握，风险仍然很高。应选择有足够响应能力的时段，避开业务活动和无关变更，明确谁可以立即中止。实验期间的监控、值班和结果核对也消耗资源，需要纳入成本，而不是只计算注入工具的使用费用。
当服务近期已经出现明显可靠性问题，优先修复已知缺陷往往更有价值。不能因为想学习，就在尚未解决的连接泄漏上继续叠加故障。若服务的可用性目标已经承压，也应重新评估是否推迟生产实验。判断依据是当前承受能力和预期学习收益，不是机械地按日历执行演练。
合理的结果可能是“暂不扩大”。例如，独立环境证实停止流程可靠，但共享数据库的连接影响仍不清楚，就可以先补充依赖隔离与观测。这样的决策已经把风险转化为明确的工程工作。实验计划的成熟度体现在能解释为什么做、何时停、得到什么证据，而不是敢于制造多大的故障。
6 常见坑：无观测就注入故障
最常见的问题是先执行操作，再临时寻找图表。服务报警后，团队发现没有请求级结果，没有实验时间标记，也不知道告警延迟多少秒。最终只能说“好像有短暂抖动”。这种记录既无法确认假设，也难以支持修复。观测必须在注入前准备完成，并用正常合成请求检查数据能否从发生端到达分析界面。
有指标并不等于指标足够。只看实例健康，可能漏掉返回成功但订单未提交的情况；只看 HTTP 错误率，可能漏掉客户端超时后服务继续写入；只看总体平均延迟，可能掩盖少量极慢请求。应从业务结果向下建立证据：用户得到什么结果，入口如何分发，应用在哪里等待，数据最终发生了什么变化。
指标适合显示规模和趋势，日志适合记录具体事件，调用链适合连接请求经过的服务。它们需要共同的实验标识、业务编号和时间基准。这里不要求先搭建复杂观测平台，至少应能把某次失败请求与当时的实例、入口状态和数据结果对应起来。若调用链采样没有覆盖失败请求，就不能据此认定链路没有发生异常。
聚合窗口也容易造成误判。假设错误只集中在 10 秒内，放进 5 分钟平均值后可能显得很轻微。反过来，低请求量下的单次错误也可能让短窗口比例突然很高。实验单应提前规定观察窗口，并保存数量与比例：本窗口共有多少业务请求、多少失败、多少结果未知。这样才能同时判断影响强度和样本是否充分。
还有 1 个陷阱是实验流量与真实流量无法区分。把两者混在同一条曲线里，可能用大量正常流量稀释实验影响；只看实验流量，又可能漏掉共享依赖对其他用户的影响。正确做法是标记实验请求，分别查看目标请求结果和环境整体健康，并把共享依赖的异常纳入停止信号。
不要为了避免打扰而静默所有告警。可以提前通知值班人员，并给预期告警增加实验标记，但仍应保留关键停止告警。若本次目标包含验证告警链路，就应记录告警何时产生、何时送达、何时被确认。监控页面上已经出现红色，不等于负责恢复的人已经收到消息。
观测本身也会失败，例如采集队列堆积、日志延迟或监控身份权限不足。准备阶段应确认数据新鲜度，明确超过多久未更新就停止。实验报告要区分“没有观察到错误”和“观察链路无法报告错误”。证据不足时承认不知道，比把空白图表解释成全部正常更能保护后续决策。
7 案例：实验扩大成真实事故
考虑 1 个教学案例。团队原计划在测试订单 API 上注入 200 毫秒的依赖延迟，持续 60 秒，观察超时与重试。执行者使用了过宽的资源标签，选中了多个服务共同使用的网络出口。目标预览没有显示最终资源清单，团队又只关注测试 API 的仪表盘，因此没有及时发现其他服务也开始等待。
延迟出现后，客户端在尚未确认前次结果时重试，服务端也发起重试。请求数量增长，占用更多连接；共享数据服务的连接额度接近耗尽后，原本没有经过该出口的服务也开始失败。直接注入的对象看似只有 1 个网络组件，但资源竞争把故障传播到了更大范围。这是爆炸半径随依赖关系扩大的具体过程。
团队随后尝试撤销注入，却发现执行控制器也通过受影响的路径访问目标。自动到期动作未能按预期生效，而备选管理入口此前没有验证。与此同时，告警被宽泛地归入“实验预期”，真实用户的错误被延迟处理。实验已经不再受控，应当立即按事故流程组织响应，停止继续收集所谓完整实验数据。
恢复时，负责人冻结新的注入操作，通过已经确认可用的管理入口清除延迟规则，并停止合成负载。服务恢复后继续观察连接与错误，核对未知结果的订单，确认没有残留注入。此时不能仅凭入口恢复正常就宣布结束：排队请求、重复提交以及数据补偿都可能在故障解除后继续产生业务影响。
事后分析应沿着时间线还原事实：最终选中了什么资源，哪些请求先变慢，连接在何时增长，停止信号何时产生，为什么没有触发有效撤销。把“某人选错目标”作为唯一原因，会遗漏允许过宽选择器、缺少数量限制、控制路径不独立和告警分类过粗等系统条件。改进应针对这些条件，减少下次依赖个人警觉的程度。
该案例不能得出“延迟注入都很危险”的结论。更准确的教训是：在共享出口上注入时，必须把所有依赖者计入范围；在有多层重试的系统里，必须观察请求放大；停止能力必须独立验证。还应明确，停止注入只撤掉了外部扰动，内部积压不一定马上消失，所以恢复验证需要持续到业务状态稳定。
改进后的复测先回到隔离环境，使用明确资源标识，把目标数量限制为 1，并验证范围预览和到期清理。随后单独验证观测、告警和人工停止，再恢复原来的延迟问题。不要为了证明整改有效，直接重复同样宽泛的生产实验。只有各项护栏都产生了可核查证据，才有理由讨论更接近真实环境的下一步。
8 把混沌实验写进可靠性方案
可靠性方案中的实验应连接架构决策，而不是作为附加活动。例如，方案选择了 3 个 API 副本，就需要说明它打算容忍什么故障、剩余容量如何估计、怎样验证入口接管。实验则提供对应证据：在什么版本、什么负载、什么故障下，目标是否满足。架构图描述设计意图，实验记录说明设计在给定条件下的实际表现。
建议让每个实验问题对应 1 项关键假设，并链接相关依赖。订单 API 的假设可以涉及实例退出、身份拒绝和数据访问超时，但初期应分成独立实验。将多个故障同时注入会增加解释难度，也使恢复路径更复杂。先建立单项行为的证据，再考虑是否需要学习故障组合带来的额外影响。
实验条目至少写清目标、稳态、基线、资源清单、负载、注入方式、停止条件、恢复动作、观测入口和负责人。基线不是只贴图，还应保留版本与配置。恢复动作也不能只写“恢复原状”，应列出需要确认的业务状态，如健康副本数量、入口分发和订单核对结果，使接手人员能够判断何时真正结束。
证据应能追溯到结论。若报告写“具备实例故障容忍能力”，就应附上实验窗口内的请求结果、故障时间线、数据核对和例外条件。若某些数据不可得，应写成限制。可靠性方案不必保存所有原始日志，但需要给出保存位置、访问责任和保留要求，避免几个月后只剩“上次通过了”的口头记忆。
失败结果也要转成工程工作。可以记录发现的问题、影响、负责人、修复期限与复测条件。例如入口摘除太慢，需要确认健康检查和连接处理；重试放大，需要检查重试层次、次数和整体时限。这些改进涉及实现细节时，可以交给后续专题；本课要求的是让问题具有明确边界和验证方法，避免报告止于“加强稳定性”。
通过的实验同样需要复测触发条件。入口策略、身份权限、网络路径、数据依赖或副本配置发生相关变化后，旧证据的适用性可能下降。是否立即重做，应由变更与假设之间的关系决定。与其安排大量无差别演练，不如把关键假设挂接到影响它的变更，使有限时间优先用于已经变得不确定的行为。
团队还应积累可复用的实验记录，但复用时必须重新核对环境。相同模板不能替代目标审查，相同故障名称也不意味着依赖相同。评估实验工作时，可以关注消除了哪些关键疑问、发现的问题是否闭环、恢复是否得到验证。实验次数和注入强度只能描述活动规模，不能直接代表可靠性提高了多少。
9 从混沌工程走向平台工程（C53）
完成几次实验后，团队会发现重复工作集中在准备和收尾：选择资源、检查权限、采集基线、配置到期撤销、关联日志、整理结果。这些工作如果每次都靠临时文档和人工记忆，实验质量就容易随人员变化。平台工程可以把重复且已经验证有效的能力做成团队可复用的服务，让实验者把精力放在问题和证据上。
例如，平台提供标准测试部署和合成流量入口，自动展示资源归属与共享依赖，限制目标数量和持续时间。提交实验时，系统检查监控是否新鲜、恢复动作是否可用，并把实验标识写入请求与日志。执行结束后汇集时间线和结果，要求明确标记支持假设、反驳假设或证据不足。这样的默认流程可以减少遗漏。
平台也应区分安全检查与业务判断。它可以阻止空目标、过大资源集合或缺失到期时间，却不能单凭成功率曲线判断重复订单是否可接受。服务负责人仍需定义稳态、理解数据语义和承担实验决策。把执行入口集中起来，并不意味着所有业务都应使用相同阈值，更不意味着点击按钮就能获得可靠性保证。
平台能力需要逐步建设。可以先把实验单和证据目录标准化，再封装目标预览、权限检查和撤销功能，最后接入更多环境。若连人工停止都没有验证，就直接开发自动随机注入，自动化只会更快地传播已有缺陷。应优先让正确步骤容易执行，让关键遗漏能够被发现，再考虑增加实验规模。
实验数据还能反过来指导平台改进。如果多个服务都在身份拒绝时丢失关键日志，可能需要标准化错误记录；如果很多团队都无法核对合成订单，可以提供受控测试数据和结果查询能力。这里的平台价值来自共同需求，而不是预先堆砌功能。服务差异仍需保留，并通过明确接口表达。
下一课 C53 将关注平台工程如何组织这些共享能力，以及如何让团队以清晰的使用路径完成部署和运维。混沌工程为它提供了具体需求：资源可识别、依赖可理解、操作有边界、故障可观测、恢复可验证。带着这些需求进入平台设计，才能判断平台是否真正减少了交付与运行中的不确定性。
放进方案里
在订单服务可靠性方案中增加“实例退出验证”条目：验证指定测试部署失去 1 个 API 实例后，入口接管与自动补充能否维持业务目标。环境包含 3 个副本、独立数据和合成下单入口；执行前记录版本、配置、目标资源标识及依赖清单，确认不连接真实支付。共享依赖不能证明隔离充分时，先缩小范围或改用独立环境。
稳态采用唯一业务编号对应的交易结果，注明成功率分母、延迟统计窗口与订单核对方法。先采集至少 5 分钟基线，再以约 30 请求/秒运行，移除 1 个实例并观察 120 秒。教学目标设为成功率不低于 99%、p95 不高于 500 毫秒且无重复订单；正式方案需用业务要求和容量数据替换这些数值。
护栏包括目标数量上限为 1、注入到期结束、负载上限和明确停止条件。连续 10 秒成功率低于 98%、发现重复订单、共享依赖异常或观测失联时立即停止。指定执行人和可独立接管的停止负责人，预先验证管理入口与恢复操作。结束后检查活动注入清零、健康副本和入口正常，并继续观察至少 5 分钟，核对全部合成请求。
证据包保存基线、实际目标、故障与恢复时间线、请求结果、相关日志和数据核对结果。验收时逐笔关联超时请求与最终订单，结果未知的业务编号必须查明去向；入口摘除时刻应有事件记录佐证，不能用新副本启动时间替代。结论只能覆盖本次版本、负载与依赖条件，并明确自动补充是否参与恢复。若违反假设，建立修复事项，写明负责人和复测条件；若观测不足，标记证据不足。入口、身份、网络或副本配置发生相关变更时，重新评估旧证据，安排必要复测后更新方案。
10 小结：下一步平台工程（C53）
混沌工程把“应该能恢复”转化为可检验的假设。有效实验需要业务稳态、明确范围、有限扰动、独立停止能力和完整恢复证据。实验支持的是给定条件下的判断；失败、提前停止和证据不足，都应如实进入后续决策。
自测时，尝试回答以下问题：
- 为什么 3 个 API 副本都健康，仍不能证明订单服务处于稳态？
- 只操作 1 个网络出口，为什么可能影响多个服务？
- 实验停止后，为什么还要核对结果未知的订单？
- 哪些步骤适合由 C53 的平台能力统一提供，哪些判断必须由服务团队负责？
能够说清这些问题，就可以进一步讨论如何把资源选择、权限边界、观测和恢复能力变成可复用的平台路径。