78:技术越隐身，故障越没人负责？原创

大家好，我是李福春，今天想和大家讨论一个平台产品中常见的矛盾，业务团队只看到一个发送消息的API，但一旦失败，研发模型、知识库和工具团队都可能被卷进来排。照我的判断是，好的基础设施不是没有复杂度，而是把复杂度变成可观测、可控制、可恢复的能力。技术越引申，越需要平台把证据和责任显性化，否则故障就会变成为人负责的灰色地带。接下来我们先从一个API背后的故障现场讲起。这一页要解决的问题是，业务团队只看到一个统一API，但故障可能发生在检索模型、工具后端或回调任意一段途中。从统一入口出发，经过Z知识检索、LLM模型推理、MCP工具调用、业务后端真实不作用，最后到消息回调，结果通知用户只收到请求失败。

台账团队却不知道该从哪一段开始。抽象可以隐藏视线，但不能隐藏证据、责任与恢复路径。所以我们需要把每个故障域的证据留下来。下一页看没有统一trace ID式牌照，为什么只能靠猜？上一页列出了多个故障域，这一页把同一次业务请求串起来，请求入口的request_ID租户tenant_ID策略route policy version, 提示词prompt version, 知识rag index version, 工具MCP call与art hash, 后端business transaction, 结果call back final stas都要关联到同一条trace上。Trace把同一次业务任务的日志、指标、工具、事件和最终结果串在一起，让跨团队排账有共同语言。这里有一个边界，供应商不提供真实模型ID时记录可获得的响应头时间与网关配置，不伪造可见性。有了请求及证据。

去练下一页补齐trace日志、指标和业务事件四类观测数据。这一页要解决的问题是有了trace ID之后，观测数据怎么组织才能互相定位？图中分四类，Trace链路回答一次请求跨过哪些服务、每段号时重试与父子关系logs日志回答发生了什么，记录结构化错误、版本和业务上下文。Matrix指标回答问题有多大，包括成功率、P95错误率、队列长度events业务事件回答用户最终得到什么，包括任务完成、接管、重复通知和补偿。四类证据互相印证，而不是堆日志，同时只记录排账必须的最小字段、敏感正文、脱敏采样或不落日志。下一页看自动重试为什么可能放大故障？上一页把观测体系拆成四类证据，这一页它有副作用的重置错误。重试链是这样的，超。

同时，为确认结果重试副作用重复一次失败可能被放大成3封邮件。可靠性控制有4道密等键，让同一业务动作只生效一次，退避加抖动，避免故障时从事风暴限流和熔断保护下游依赖补偿和人身处理无法自动撤销的副作用。涉及邮件、支付、通知等副作用时，重试前先判断是否已执行，必要时走补偿和人工审批。这里的关键是重试不是默认安全动作，必须先确认副作用状态。下一页讨论完整的回滚范围，上一页说明重试要考虑副作用，这一页讲回滚范围。Agent阵子的行为不仅由容器镜像决定，还由配置策略模型、路由、Chrome知识索引和工作流定义共同决定。图中列出6层应用代码的镜像与服务版本配置策略的开关、超时限流模型、路由的模型供应商。

参数promp的系统提示词与模板知识索引的数据快照与索引版本工作流的DG scale MCP定义发布前要建立版本清单、兼容关系和回滚演练，回滚后要验证业务副作用与数据一致性，指挥容器镜像行为版本没回故障可能依就下一页把稳定性转成solo指标，上一页明确了回滚对象，这一页定义平台稳定应该如何量化。图中列出六个指标，任务成功率按业务任务定义成功我按HTTP200产品业务最关心P95端到端时延，从用户请求到可用结果，用户体验和R最关心错误预算衡量允许失败的预算与消耗速度。平台和s re最关心MTTR从发现故障到恢复服务的时间，誉为研发最关心变更失败率时导致回滚事故或热修的变更占比。研。

管理最关心重复副作用统计重复邮件、通知、交易等字数，业务负责人最关心先统一分母统计窗口和排除项，没有统一口径的指标不能成为所爱承诺。下一页明确每个故障域谁负责，上一页建立了所有指标，这一页把责任落实到故障域图中，按故障域列出第一责任方必须留下的证据和恢复动作。入口网关由平台团队负责，由trace策略版本限流日志恢复动作是降级或切入，由模型服务，由模型接入方负责，由供应商响应超时错误码恢复动作是备用模型或人工接管。知识检索由知识库负责人负责，由索引版本召回片段ID恢复动作，噬鬼滚索引或记脏版本。MCP工具由工具所有者负责，由工具名密等键执行结果恢复动作是熔断。

补偿或审批业务后端由业务系统负责人负责，由事务ID状态机回调记录恢复动作是对账重放或人工修复，多人参与不等于无人负责，入口涉阻协调人故障预设明确第二下一页通过故障注入验证责任是否真的有效，上一页有了责任举证，这一页用演练验证图中列出五类故障注入与预期行为和验收证据模型不可用实窃备用路由或明确降级验收成功任务率与接管记录，该索引污染时禁用新索引或回滚快照验收索引版本与引用差异，MCP工具超时时熔断、超时预算、不重复执行验收密等键与执行状态业务DB故障实现流排队恢复后对账验收事物ID与重放记录回调重复投递时消费、去除密等确认验收重复副作用次数。

为零目标。每次演练都要记录发泄时间、定位时间、恢复时间和遗留风险。下一页把这些能力汇成可靠性闭环。上一页通过故障注入检查恢复能力，这一页把完整闭环串起来，统一入口，产生trace_ID和tenantt证据观测系统，用trace logs s three发现异常责任矩阵完成归因导服务版本和drri保护机制，用限流、熔断、密等限制故障放大恢复机制执行降级、回滚或补偿，最后通过slow MP tr和复盘改进回滚对象覆盖代码配置、双知识索引工作流和模型路由技术。引申的标准是用户少操心，平台多承担，故障证据和责任不能一起消失。下一页给出本月的四场演练，上一页说明可靠性闭环，这一页把行动做到一个月。

第一周打通trace，统一request_ID ten版本和工具事件，第二周补齐保护密等、退避、限流、熔断和补偿。第三周演列回滚，覆盖PRO、索引、工作流和模型路由。第4周复盘slow，统一口径、责任人、MPTR与错误预算。每场演练都要能回答谁发现、谁定位、谁恢复，凭什么证明恢复？这四场演练不是形式，而是把前面讲的观测、保护、回滚和责任落到可验证的动作上。最后一页总结三个能力，前面从统一API、全链路追踪、重试、副作用、回滚范围、slow和责任矩阵走完了。回到开场的问题，技术越隐身，故障越没人负责。我的结论是，好平台不是没有复杂度，而是让复杂度可见、可控、可恢复。第一，证据链要打通看得见。

第二，副作用要有密等和补偿，控得住。第三，行为版本要能整体回滚并明确责任，退得回，可观测、可归因、可保护、可恢复、可复盘，形成闭环。最后留一个问题，如果只允许你先补一个能力，你会先补trace，密等还是回滚？讨论后反思这个类比点，除了技术，引申的前提不是把复杂度藏起来，而是平台替用户承担。要做到无感知，必须有观测系统采集足够数据，故障时能自动化或联动人工台账。判断标准是用户少操心，平台多承担，证据和责任不能一起消失。验收边界在于隐身，不等于不可见，而是对用户隐身，对平台透明。不是李福春资深架构师把复杂系统做成简单可依赖的产品，下期再见。