SLI（服务等级指标）、SLO（服务等级目标）、错误预算与业务技术成功率

本章只讨论可靠性目标的定义、计算与治理，不声明任何生产 SLA（服务等级协议）。所有数量、比例、窗口和阈值均为 E3（演练证据），用于复算方法与面试表达；真实承诺、生产基线和事故效果仍是 E0（待核对）。口径总入口见稳定性口径、信号边界与迁移路线，告警实现与事故协作见 SLO（服务等级目标）、事故响应、容量与综合题。

适用边界

SLA（服务等级协议）回答外部承诺、责任边界和违约后果；SLO（服务等级目标）回答内部希望达到的可靠性水平；SLI（服务等级指标）回答如何从事件计算事实。
技术成功只证明请求、任务或依赖完成了技术动作；业务成功还要证明用户目标、业务终态和不变量成立。两者必须分别建指标，不能用接口返回成功替代支付入账、库存守恒、文件可下载或关键报警可见。
每个 SLI（服务等级指标）都要版本化保存事件、分子、分母、窗口、排除、迟到修正、数据新鲜度、责任人和回算方式。无法复算的仪表盘数字不能驱动发布。
错误预算约束风险动作，不是允许主动制造错误的额度；安全修复、止血、回滚、查单和补偿不能因预算耗尽而停止。

正式时序图

SLO（服务等级目标）错误预算与业务恢复时序

图解读： PlantUML（统一建模语言）源图从业务意图账本建立权威分母，依次经过技术执行、业务核验、SLI（服务等级指标）计算和 SLO（服务等级目标）预算决策。正常分支允许受控灰度；失败分支由多窗口燃尽率或业务红线触发止血，再通过查单、对账、补偿、积压和不变量验证决定是否恢复。前提是口径版本和数据质量可信，结论是告警回落不能替代业务恢复。

1. SLA（服务等级协议）、SLO（服务等级目标）、SLI（服务等级指标）、业务成功与技术成功分层 {#53-01-k01}

五个概念按“外部承诺、内部目标、计算指标、技术动作、业务结果”分层。SLA（服务等级协议）通常包含范围、统计周期、例外和后果，必须由业务、法务与客户关系共同确认；研发不能把演练数字擅自写成承诺。SLO（服务等级目标）应比外部承诺保留治理余量，但余量大小也要有事实依据。SLI（服务等级指标）必须可由原始事件重算。技术成功是必要证据之一，业务成功才是用户结果；若支付受理成功但渠道未知，或导出任务完成但文件无权限，技术成功为真、业务成功仍为假或未知。

flowchart TB
  A[外部关系与违约后果] --> B[SLA：服务等级协议]
  C[内部风险偏好与发布治理] --> D[SLO：服务等级目标]
  E[可评价事件与原始证据] --> F[SLI：服务等级指标]
  F --> D
  D -.保留内部余量.-> B
  G[技术成功：调用或任务完成] --> H[业务核验]
  I[业务不变量与用户终态] --> H
  H --> J{业务成功？}
  J -->|是| K[计入好事件]
  J -->|否或未知| L[计入坏事件或未知队列]

图解读： 节点从证据到目标再到承诺，箭头表示约束而非相等关系。前提是原始事件可重算；正常路径把技术动作与业务证据合并后计入好事件，失败路径将未知态显式保留。结论是任何内部目标都不能自动升级为对外承诺，任何技术成功也不能自动升级为业务成功。

概念	核心问题	必备字段	典型反例
SLA（服务等级协议）	对谁承诺什么，违约后果是什么	对象、范围、周期、例外、责任、补偿	开发把演练比例写进客户合同
SLO（服务等级目标）	内部以什么目标治理风险	指标、目标、窗口、预算、动作、责任人	目标存在但预算不影响发布
SLI（服务等级指标）	好事件占可评价事件多少	分子、分母、时间、排除、迟到、来源	只展示一个无法回算的百分比
技术成功	技术步骤是否按协议完成	返回、提交、确认、依赖结果	接口成功就宣称支付完成
业务成功	用户目标与不变量是否成立	终态、账本、产物、时限、审计	文件生成却不可下载仍算成功

数据演绎 1：支付技术成功与业务成功拆分。 E3（演练证据）输入为 10,000 个支付意图，网关技术返回成功 9,970 个，其中确认窗口内渠道终态明确且资金分录守恒 9,940 个，渠道未知 20 个，金额不符 10 个。技术成功率为 9,970 / 10,000 = 99.70%，业务成功率为 9,940 / 10,000 = 99.40%；状态变化是“已受理”继续进入“已确认、明确失败或未知”，观测信号包括渠道回执、支付单、账务分录与对账差异。结论是相差的 30 个事件必须进入查单或差异处置，不能被技术成功率吞掉。

2. 用好事件、坏事件与可评价事件固定分子分母 {#53-01-k02}

SLI（服务等级指标）的基本单位应是用户或业务事件，而不是机器采样点。先定义“可评价事件”，再在其中区分好事件与坏事件；未知事件单独保留，并规定何时转为坏事件。分母要来自独立权威源，例如订单受理表、支付意图账本、导出任务清单或注册设备清单，不能只用成功路径自报计数。重试应按业务意图去重，防止一个失败意图因多次重试放大分母或用最后一次成功冲掉前面损失。

sequenceDiagram
  participant 用户 as 用户或上游
  participant 账本 as 权威事件账本
  participant 服务 as 业务服务
  participant 核验 as 结果核验器
  participant 计算 as 指标计算器
  用户->>账本: 写入业务意图与稳定事件键
  账本->>服务: 执行一次或多次技术尝试
  服务-->>核验: 返回、终态与副作用证据
  核验->>核验: 按业务键去重并判定好、坏、未知
  核验->>计算: 提交可评价事件及判定版本
  alt 证据齐全
    计算-->>用户: 计入好事件或坏事件
  else 证据未齐
    计算-->>账本: 保留未知并等待查证
  end

图解读： 权威账本先登记业务意图，服务尝试只产生证据，核验器按稳定键去重后才进入分子分母。正常路径得到唯一判定，失败路径保留未知并查证。结论是指标计算不能从成功日志反推分母，也不能按尝试次数统计用户损失。

指标类型	分子	分母	去重键与未知规则
请求可用性	返回可接受结果的业务意图	进入服务责任边界的可评价意图	按意图键去重；超确认窗口的未知计坏
支付正确性	终态明确且分录守恒的支付意图	已受理支付意图	按支付意图键去重；查单前保持未知
库存正确性	预占、释放或扣减闭环且守恒的意图	已受理库存意图	按订单行与意图键去重
导出可用性	产物有效、授权正确且可下载的任务	到达交付时限的有效任务	按任务键去重；取消原因需审计

数据演绎 2：重试不能改变用户分母。 E3（演练证据）输入为 1,000 个库存预占意图，其中 20 个因超时各重试 2 次，共产生 1,040 次技术调用；最终 990 个意图正确闭环，6 个明确失败，4 个超过确认窗口仍未知。按调用计算会得到 1,030 / 1,040 等失真结果；按业务意图计算为 990 / 1,000 = 99.00%，并将 4 个未知按预定规则计入坏事件。状态变化从多次尝试归并为一个意图终态，观测信号是意图键、尝试号、库存流水和版本。结论是重试只能影响诊断维度，不能重写用户事件分母。

3. 窗口、事件时间、处理时间与回算版本决定同一数字的含义 {#53-01-k03}

统计窗口必须说明是滚动窗口、自然周期还是发布观察窗。滚动窗口适合持续治理，自然周期适合合同或财务对齐，短观察窗适合发布止损，三者不能混用。事件时间表示业务发生时刻，处理时间表示观测系统看到它的时刻；异步回调、离线对账和设备迟到会让两者不同。正式结果按事件时间归属，实时看板可先给暂算值，但必须显示数据截止时间、迟到水位与口径版本，并在封账后保留回算轨迹。

sequenceDiagram
  participant 业务 as 业务事件源
  participant 接入 as 观测接入
  participant 暂算 as 实时暂算器
  participant 回填 as 迟到回填器
  participant 看板 as 决策看板
  业务->>业务: 记录事件时间与业务键
  业务-->>接入: 事件可能延迟到达
  接入->>暂算: 按处理时间更新实时值
  暂算->>看板: 展示暂算值、截止时间和完整度
  回填->>接入: 拉取迟到回调或对账结果
  接入->>回填: 按事件时间归属原窗口
  回填->>看板: 发布新口径版本与差异
  alt 窗口已封账
    看板-->>业务: 保留原值和修订值，不静默覆盖
  else 窗口未封账
    看板-->>业务: 更新暂算值并标记水位
  end

图解读： 业务事件带事件时间进入接入层，实时暂算与迟到回填是两条路径。正常路径在封账前更新暂算值，失败路径是在封账后仍收到关键证据，此时必须追加修订而非静默改历史。结论是窗口、截止时间和版本必须与百分比一起展示。

窗口类型	适用决策	时间归属	主要风险
滚动窗口	持续发布与预算趋势	每个时刻回看固定长度	相邻时刻高度相关，解释需谨慎
自然周期	外部报告、月度治理	按日历起止封账	月初样本少，跨时区易错位
发布观察窗	灰度晋级与回退	以变更开始和批次划分	样本不足、流量结构不一致
事件时间窗	异步业务最终事实	按业务发生时刻归属	迟到导致暂算与最终值不同

数据演绎 3：迟到支付回调改变正确性但不抹掉时效损失。 E3（演练证据）阈值为确认窗口 15 分钟。某自然日暂算分母 20,000，窗口内业务成功 19,940，明确失败 40，未知 20，暂算成功率为 99.70%。次日对账回填确认 18 个未知实际成功、2 个失败，最终正确性变为 19,958 / 20,000 = 99.79%；但这 18 个事件仍违反确认时效目标。状态变化为暂算版本到封账修订版本，观测信号含事件时间、回调时间、对账批次和版本差异。结论是正确性可回算，时延损失不可被后到成功覆盖。

4. 排除规则、维护窗口、无效请求与未知态必须事前可审计 {#53-01-k04}

排除规则决定责任边界，最容易被用来美化指标。可排除对象应满足：事前定义、可由独立字段识别、有责任归属、设置有效期、能回放审计。非法参数可从服务可用性分母排除，但鉴权系统误拒绝、限流策略错误、慢请求引发的客户端取消不能简单排除。维护窗口只有在承诺允许、用户得到通知且实际影响落在批准范围内时才可按约定处理；超范围影响仍是坏事件。数据丢失时不能把缺失样本排除，应进入观测质量失败和保守治理。

sequenceDiagram
  participant 请求 as 候选事件
  participant 规则 as 排除规则引擎
  participant 审计 as 排除审计账本
  participant 计算 as 指标计算器
  participant 评审 as 口径评审人
  请求->>规则: 提交事件、原因、责任与时间
  规则->>审计: 查询生效规则和有效期
  alt 满足事前规则
    审计-->>规则: 返回规则版本
    规则->>计算: 标记排除并保留原因
  else 不满足或证据缺失
    审计-->>规则: 拒绝排除
    规则->>计算: 计入可评价事件或未知
  end
  计算->>评审: 输出排除率、原因分布与变更差异
  评审-->>审计: 批准、到期或撤销规则

图解读： 排除不是查询时随手过滤，而是经过版本化规则和审计账本。正常路径记录规则依据，失败路径把证据不足事件留在分母或未知队列。结论是排除率本身也要监控，事故后新增规则不能反向改变既有责任。

候选事件	默认处理	允许排除的前提	必须保留的证据
非法业务参数	可排除于服务可用性，另计产品质量	服务尚未受理且错误由调用方造成	请求摘要、校验结果、调用方
客户端取消	先计可评价或未知	证明与服务等待无关且口径事前约定	取消位置、已等待时长、会话
批准维护	按承诺规则处理	已通知、在范围与时段内、无越界	审批、通知、实际影响对象
观测数据缺失	不得直接排除	无	缺失范围、采集水位、回补结果

数据演绎 4：事后排除会虚假恢复。 E3（演练证据）输入为 50,000 个可评价导出任务，交付失败 500 个，初始成功率 99.00%。若事故后把其中 300 个“用户取消”直接移出分母，会得到 49,500 / 49,700 = 99.60%；但审计发现 240 个取消发生在等待超过 E3（演练证据）阈值 30 秒之后，应归因于服务慢。按事前规则仅排除 60 个独立取消，结果为 49,500 / 49,940 = 99.12%。状态变化是候选排除进入审计裁决，观测信号含取消位置、等待时长和规则版本。结论是排除率异常上升应触发口径审查，而不是帮助达标。

5. 数据新鲜度、完整度与口径版本是 SLI（服务等级指标）的前置 SLI（服务等级指标） {#53-01-k05}

指标值正确之前，先要证明数据本身可用。数据新鲜度回答“最新完整事件距离现在多久”，完整度回答“权威分母中有多少对象已进入计算”，一致性回答“独立来源能否对上”，口径版本回答“同一事件按哪套规则判定”。只监控采集器存活会漏掉分区停滞、标签丢失和部分租户缺口。决策看板必须同时展示数据截止时间、完整度、迟到水位和规则版本；任一前置指标失守时，自动发布应转为保守模式。

sequenceDiagram
  participant 权威 as 权威对象清单
  participant 采集 as 事件采集层
  participant 校验 as 数据质量校验
  participant 计算 as 指标计算器
  participant 门禁 as 发布门禁
  权威->>校验: 提供应评价对象与窗口
  采集->>校验: 提供已到事件与采集水位
  校验->>校验: 计算新鲜度、完整度和来源差异
  alt 数据质量满足 E3 演练门槛
    校验->>计算: 放行事件与口径版本
    计算->>门禁: 输出 SLI 与错误预算
  else 数据迟到、缺失或版本混用
    校验->>门禁: 标记数据质量失败
    门禁-->>计算: 禁止自动晋级并要求回补
  end

图解读： 权威清单和采集事件在校验层会合，先判断数据是否有资格驱动决策。正常路径计算 SLI（服务等级指标），失败路径转保守门禁并回补。结论是“指标采集正常”必须由对象完整度和水位证明，而不是由进程存活证明。

前置指标	分子与分母	失败含义	治理动作
新鲜度	在时限内更新对象/应更新对象	数据可能陈旧，实时值不可信	暂停自动晋级、查分区水位
完整度	已进入计算对象/权威对象	存在未观测用户或业务对象	补采、对账、报告未知范围
一致性	来源一致记录/抽样或全量记录	采集、去重或映射存在偏差	比对原始事件和规则版本
版本覆盖	使用目标规则的事件/窗口事件	同窗混用新旧口径	影子回算、延迟切换或回滚

数据演绎 5：高成功率不能覆盖低完整度。 E3（演练证据）权威清单有 100,000 个设备，E3（演练证据）新鲜度阈值为 60 秒；计算器只收到 80,000 个设备事件，其中 79,920 个按规则成功处理，表面成功率为 99.90%。但完整度仅 80,000 / 100,000 = 80.00%，另有 20,000 个设备完全未被评价，不能报告全量健康。状态变化是数据质量失败阻断业务指标发布，观测信号为设备清单、水位、分区偏移和规则版本。结论是先修复覆盖与新鲜度，再解释成功率；缺失对象按风险清单持续跟踪。

6. 分位数、阈值达标率与分布要共同描述尾延迟 {#53-01-k06}

平均值会掩盖尾部等待，单一分位数也可能掩盖多峰、超时截断和低样本抖动。面向用户承诺时，优先使用“在阈值内完成的事件/可评价事件”作为延迟 SLI（服务等级指标），同时用 P50（50 分位响应时间）、P95（95 分位响应时间）、P99（99 分位响应时间）和直方图解释分布。跨实例聚合不能平均各实例分位数，应合并直方图桶或原始分布；超时事件必须落入最高桶或坏事件，不能因没有完成时长而消失。

sequenceDiagram
  participant 请求 as 可评价请求
  participant 实例 as 服务实例
  participant 桶 as 直方图桶
  participant 聚合 as 全局聚合器
  participant 目标 as 延迟目标
  请求->>实例: 记录开始时间和业务键
  alt 正常完成
    实例->>桶: 记录完整耗时与结果
  else 超时或取消
    实例->>桶: 记录超时上界和坏事件
  end
  桶->>聚合: 合并各实例累计桶
  聚合->>目标: 计算阈值达标率与分位数
  目标-->>请求: 输出分布、样本量和窗口

图解读： 每个请求无论完成还是超时都进入分布，实例只上报可合并的桶。正常路径计算阈值达标率，失败路径也保留超时损失。结论是不能平均实例分位数，也不能只统计成功请求的耗时。

表达方式	适合回答	盲点	使用要求
阈值达标率	有多少用户在承诺时限内完成	不展示阈值内部分布	阈值、分母和超时规则固定
P50（50 分位响应时间）	典型用户体验	对尾部不敏感	与高分位和样本量同看
P99（99 分位响应时间）	尾部风险与排队	低流量时抖动大	报窗口、样本量和置信边界
直方图	分布、聚合和多峰	桶边界过粗会丢精度	桶覆盖超时并保持跨实例一致

数据演绎 6：平均实例 P99（99 分位响应时间）会失真。 E3（演练证据）阈值为 2 秒。实例甲处理 9,900 个请求，P99（99 分位响应时间）为 0.4 秒；实例乙处理 100 个热点请求，全部耗时 8 秒。把两个 P99（99 分位响应时间）平均得到 4.2 秒没有统计意义；全局 10,000 个请求中恰有 100 个超过阈值，阈值达标率为 99.00%，全局 P99（99 分位响应时间）落在分布边界附近。状态变化是实例桶合并为全局分布，观测信号包括路由键、桶计数、超时和样本量。结论是先看用户事件分布，再按实例切片定位热点。

7. 错误预算把目标差距转换成可消费风险 {#53-01-k07}

若目标比例为 目标值，窗口内可评价事件为 总事件，则允许坏事件为 总事件 × (1 - 目标值)；已发生坏事件从中扣减，剩余预算不能跨口径随意合并。基于事件的预算适合流量稳定且事件可数的路径，基于时间的预算适合连续可用性探测；两者表达对象不同。预算为负说明窗口目标已失守，不代表可以停止统计，也不代表所有修复动作都被冻结。

sequenceDiagram
  participant 事件 as 事件账本
  participant 目标 as SLO 目标配置
  participant 预算 as 错误预算计算器
  participant 变更 as 变更门禁
  participant 事故 as 事故处置
  事件->>预算: 提交好事件、坏事件与窗口
  目标->>预算: 提交目标值、口径版本与动作表
  预算->>预算: 计算允许、已用、剩余与负预算
  alt 预算健康
    预算->>变更: 允许按常规灰度
  else 预算警戒或耗尽
    预算->>变更: 缩批或冻结高风险变更
    预算->>事故: 允许止血、回滚、修复与核验
  end

图解读： 事件和目标共同进入预算计算器，预算状态同时驱动变更与事故两条路线。正常路径受控发布，失败路径限制高风险变更但保留减险动作。结论是错误预算是治理接口，不是单纯看板数字。

预算对象	计算单位	优点	不能混用的原因
事件预算	坏事件数	贴近用户损失，可按业务切片	流量变化会改变单位时间允许损失
时间预算	不可用时长	适合连续探测和整体服务	无法表达同一分钟内不同用户影响
正确性预算	不满足不变量的业务对象	直接约束资金与库存风险	需要迟到对账，不能用技术错误替代
新鲜度预算	超时未更新对象	适合导出、轨迹和设备状态	必须有权威对象清单

数据演绎 7：计算事件错误预算。 E3（演练证据）窗口有 2,000,000 个可评价事件，E3（演练证据）SLO（服务等级目标）为 99.90%，允许坏事件 2,000,000 × 0.10% = 2,000 个。当前已发生 1,250 个坏事件，剩余 750 个，预算消耗为 62.50%。若下一次 E3（演练证据）灰度预计最坏增加 900 个坏事件，则即使均值预测较低，也应缩小批次或先修复风险。状态变化是预算从健康进入警戒，观测信号为坏事件数、流量预测和灰度切片。结论是发布决策看剩余风险承受力，不看目标值是否暂时仍为绿色。

8. 燃尽率与多窗口告警回答预算会多快耗尽 {#53-01-k08}

燃尽率等于“观察窗口实际坏事件比例/目标允许坏事件比例”。燃尽率为一表示按均匀速度恰好在目标窗口耗尽；大于一表示消耗过快。短窗口发现突发，长窗口过滤瞬时噪声；可靠告警通常要求短长窗口同时越界，并且两者使用同一事件口径。告警阈值是 E3（演练证据）候选，必须按目标窗口、值班响应和业务失败成本校准，不能照抄固定数字。

sequenceDiagram
  participant 事件 as 坏事件流
  participant 短窗 as 短窗口计算器
  participant 长窗 as 长窗口计算器
  participant 路由 as 告警路由
  participant 值班 as 值班与业务负责人
  事件->>短窗: 更新短期坏事件比例
  事件->>长窗: 更新持续坏事件比例
  短窗->>路由: 上报燃尽率和样本量
  长窗->>路由: 上报燃尽率和样本量
  alt 短窗与长窗同时满足 E3 演练条件
    路由->>值班: 触发分级响应并附业务切片
  else 仅单窗异常或数据不足
    路由-->>事件: 继续观察或标记数据质量风险
  end

图解读： 同一坏事件流进入短长窗口，路由器同时检查燃尽率、样本量和数据质量。正常告警要求持续性与突发性证据共同成立，失败路径避免单点尖峰造成风暴。结论是燃尽率告警必须绑定预算动作和业务切片。

场景	短窗口	长窗口	解释与动作
突发且持续	高燃尽	高燃尽	立即止血，暂停放量并核验业务
瞬时尖峰	高燃尽	正常	观察原因，检查是否为真实关键事件
缓慢恶化	中等燃尽	持续升高	提前治理容量、依赖或版本问题
数据缺失	数值异常或无样本	完整度下降	转数据质量告警，禁止报告健康

数据演绎 8：从坏事件比例计算燃尽率。 E3（演练证据）SLO（服务等级目标）为 99.90%，允许错误率 0.10%。E3（演练证据）短窗口 5 分钟内有 20,000 个事件和 100 个坏事件，实际错误率 0.50%，燃尽率为 5；E3（演练证据）长窗口 60 分钟内有 240,000 个事件和 720 个坏事件，错误率 0.30%，燃尽率为 3。状态变化是短长窗口同时进入高风险，观测信号包括坏事件类型、版本和依赖切片。结论是应停止灰度扩展并先定位共同失败，而不是等待整个目标窗口耗尽。

9. 错误预算动作表要把发布、止血、恢复与复盘连起来 {#53-01-k09}

预算治理不能只写“耗尽就冻结”。动作表至少包含预算状态、燃尽率、数据质量、变更类型、审批角色、灰度上限、回退点、观察期和恢复证据。常规功能、容量调整、观测补丁、安全修复和数据补偿的风险不同，应分别决策。支付或库存出现不变量破坏时，即使总体预算充足也应触发红线；相反，预算耗尽后仍要允许能降低风险的受控变更。

flowchart LR
  A[预算、燃尽率、数据质量和业务红线] --> B{风险状态}
  B -->|健康| C[常规灰度与观察]
  B -->|警戒| D[缩小批次、加强审批]
  B -->|耗尽| E[冻结高风险功能变更]
  B -->|不变量破坏| F[立即止血并升级事故]
  E --> G[回滚、修复、安全和容量减险通道]
  F --> G
  G --> H[关键路径、积压、未知态和对账验证]
  H -->|通过| I[分批恢复]
  H -->|未通过| J[继续事故与补偿]
  I --> K[复盘回写目标、动作表和演练]

图解读： 入口同时看预算和业务红线，分支区分常规、警戒、耗尽与不变量破坏。正常路径受控发布，失败路径先止血再通过减险通道恢复。结论是恢复必须由用户结果、积压与不变量共同证明，不能只看告警回落。

状态	功能变更	减险变更	退出条件
健康	常规评审与灰度	正常实施	观察窗无异常
警戒	缩批、延长观察、限制并发变更	优先实施	燃尽回落且数据可信
耗尽	冻结高风险功能与大范围迁移	允许回滚、修复、扩容和观测补丁	关键路径、积压与审计通过
业务红线	立即停止扩散	查单、隔离、补偿与人工复核	不变量恢复且受影响对象闭环

数据演绎 9：预算健康也可能触发业务红线。 E3（演练证据）窗口允许 2,000 个坏事件，当前仅使用 200 个，预算看似健康；但库存对账发现 3 个订单造成可售量小于零。E3（演练证据）动作表将“任一确认超卖”定义为正确性红线，因此立即暂停相关仓与商品的放量，冻结自动补偿，按订单、预占和库存流水核对。状态变化是总体预算健康但局部红线进入事故，观测信号为负库存对象、版本冲突和重复副作用。结论是聚合预算不能覆盖高损失小概率事件。

10. 复合依赖要按关键路径、相关性与降级语义计算 {#53-01-k10}

串行依赖在“相互独立、全部必须成功、无重试和降级”时，端到端可用性才可近似为各环节可用性的乘积；现实中的共享网络、同一数据库、流量峰值会造成相关故障，盲目相乘通常过于乐观。并行候选只有在故障独立、切换及时且结果语义等价时才提供冗余。正确做法是先画用户关键路径，标注必选、可选、旁路、缓存、超时和未知态，再直接测端到端 SLI（服务等级指标），依赖指标只用于归因与容量治理。

sequenceDiagram
  participant 用户 as 用户
  participant 编排 as 业务编排
  participant 账户 as 账户依赖
  participant 渠道 as 外部渠道
  participant 账本 as 业务账本
  participant 指标 as 端到端计算器
  用户->>编排: 提交业务意图
  编排->>账户: 校验或冻结资源
  编排->>渠道: 发起外部副作用
  alt 渠道明确返回
    渠道-->>编排: 成功或明确失败
  else 渠道超时
    渠道--x编排: 结果未知
    编排->>渠道: 按原业务键查证
  end
  编排->>账本: 写终态、不变量与审计
  账本->>指标: 按用户路径判定好、坏或未知
  指标-->>用户: 输出端到端结果与依赖归因

图解读： 用户路径串联内部资源、外部副作用和账本，超时分支通过查证而非换键重试。正常路径直接测端到端结果，失败路径保留依赖归因。结论是依赖乘积只能做 E3（演练证据）估算，正式目标应以真实用户路径事件为准。

依赖形态	E3（演练证据）估算前提	常见陷阱	可靠验证
串行必选	独立且全部成功才完成	共享故障导致乘积过于乐观	端到端事件与联合失败切片
并行任一成功	独立、同时发起、语义等价	两路共享配额或返回冲突	故障注入与结果一致性核验
缓存降级	陈旧结果仍可接受	命中成功但数据过期	同看可用性与新鲜度
异步补偿	用户接受暂态且最终可闭环	受理成功被误算为业务成功	终态时限、未知年龄和对账

数据演绎 10：串行乘积只是独立假设下的估算。 E3（演练证据）三段必选依赖候选可用性均为 99.90%，若独立则端到端近似为 0.999 × 0.999 × 0.999 = 99.70%。但三段共享同一网络故障域，E3（演练证据）窗口中有 200 个请求因共享网络同时失败；将三段失败分别相乘会漏掉相关性。状态变化是依赖局部指标汇聚到端到端事件，观测信号包含共同时间窗、故障域、链路标识和业务终态。结论是直接计算用户路径的好事件比例，并用联合失败矩阵解释共享风险。

11. 低流量、零流量与稀有高损失事件不能只看百分比 {#53-01-k11}

低流量路径中一个坏事件就会让百分比剧烈跳变，零请求时更没有成功率可算。此时要同时报告样本量、坏事件绝对数、最长无样本时长、合成探测、关键对象覆盖和业务红线。扩大窗口可增加样本，但会降低发现速度；合并多个租户可稳定数值，却可能掩盖单一高价值客户。对支付重复扣款、库存超卖和关键设备漏报，应使用逐事件红线或最大未知年龄，而不是等待比例显著。

sequenceDiagram
  participant 路径 as 低流量业务路径
  participant 真实 as 真实事件统计
  participant 探测 as 合成探测
  participant 清单 as 关键对象清单
  participant 决策 as 风险决策器
  路径->>真实: 提交少量好坏事件与样本量
  探测->>路径: 周期执行无副作用或隔离验证
  探测->>决策: 上报技术可达与延迟
  清单->>决策: 上报关键对象覆盖与未知年龄
  真实->>决策: 上报绝对坏事件和窗口比例
  alt 无样本或样本不足
    决策-->>路径: 报告未知，不宣称百分比健康
  else 有逐事件红线
    决策-->>路径: 任一确认事件触发处置
  end

图解读： 真实事件、合成探测和关键对象清单共同进入决策器。正常路径报告样本量与比例，失败路径在无样本时明确未知，红线事件则直接处置。结论是合成探测补技术覆盖，不能替代真实业务正确性。

低流量问题	百分比表现	补充证据	决策原则
单个坏事件	比例剧烈跳变	绝对数、失败成本、事件明细	高损失事件按红线处置
零请求	无法计算或被错误显示满分	无样本时长、合成探测	报告无数据，不报告健康
租户流量不均	总体值被大租户主导	分租户切片和关键客户清单	防止平均值掩盖局部事故
稀有未知态	总体比例近似不变	最老年龄、逐笔查证	超确认窗口立即升级

数据演绎 11：零坏事件不等于高可靠。 E3（演练证据）某低频结算路径一周只有 8 个事件，全部成功，样本成功率为 100%；但这不能证明真实 SLO（服务等级目标）达到任何高比例。下一周 1 个事件失败，样本成功率立即变为 87.50%。状态变化是决策从单一比例改为“样本量 8、坏事件 0、最大无样本时长、合成探测和逐笔对账”，观测信号包括结算批次清单与查证结果。结论是低流量目标使用更长观察、逐事件红线和覆盖证据，百分比只作描述。

12. 支付、库存、导出与 IoT（物联网）需要不同的好事件定义 {#53-01-k12}

四类业务共享事件模型，但成功证据不同。支付以渠道终态、金额币种和分录守恒为核心；库存以同一意图唯一生效、可售量非负和预占最终闭环为核心；导出以任务产物完整、授权正确且在交付时限内可下载为核心；IoT（物联网）以关键设备事件覆盖、新鲜度、去重后仍可追溯和通知回执为核心。接口可用性是诊断层，不能替代这些结果层指标。

sequenceDiagram
  participant 意图 as 业务意图账本
  participant 技术 as 技术执行层
  participant 权威 as 业务权威源
  participant 核验 as 结果核验器
  participant 预算 as SLO 与错误预算
  意图->>技术: 支付、预占、导出或报警处理
  技术-->>核验: 返回技术成功、失败或未知
  权威->>核验: 提供渠道、流水、文件或设备证据
  核验->>核验: 应用对应业务不变量和时限
  alt 业务终态与证据齐全
    核验->>预算: 计入好事件
  else 明确失败或超确认窗口
    核验->>预算: 计入坏事件并触发动作
  else 证据仍在途
    核验-->>意图: 保留未知、年龄和查证任务
  end

图解读： 四类意图先经过技术执行，再与各自权威证据会合。正常路径满足不变量与时限，失败路径计坏并处置，未决路径保留未知。结论是统一平台可以复用计算框架，但不能强迫不同业务共享同一个“成功”定义。

场景	好事件	坏事件或未知	关键权威证据
支付	确认窗口内终态明确、金额币种匹配、分录守恒	渠道未知、重复扣款、金额不符、分录缺失	渠道回执、支付单、账务分录、对账
库存	意图唯一生效、可售量非负、预占闭环	超卖、重复扣减、长期占用、流水不守恒	库存流水、订单行、版本、实物对账
导出	按时生成有效产物、授权正确且可下载	空文件、权限错、任务假完成、交付过期	任务、对象摘要、授权、下载探测
IoT（物联网）	关键事件按时可见、覆盖完整且可追溯	漏报、过期、误聚合、无回执	设备清单、原始事件、规则版本、通知回执

数据演绎 12：四类技术成功率相同，业务结果不同。 E3（演练证据）每类各有 10,000 个业务意图，技术执行均成功 9,990 个，技术成功率均为 99.90%。业务核验后，支付好事件 9,970、库存 9,980、导出 9,940、IoT（物联网）9,900，对应业务成功率分别为 99.70%、99.80%、99.40%、99.00%。状态变化是相同技术结果进入不同不变量判定，观测信号分别来自账务、库存、对象存储和设备清单。结论是平台指标只能提供共同框架，业务目标必须按领域证据落地。

13. 从口径审计到线上排查、恢复验证与项目话术 {#53-01-k13}

线上出现 SLO（服务等级目标）恶化时，先冻结口径版本和变更时间线，再确认分母、新鲜度与迟到是否可信；随后按业务切片判断真实用户结果，利用指标定位趋势、链路定位等待、日志定位上下文、业务审计确认副作用。止血优先缩小影响，支付和库存先阻断重复副作用，导出和 IoT（物联网）先保护关键队列与对象清单。恢复必须验证新流量、历史积压、未知态和不变量，最后把根因、动作和演练写回目标治理。

flowchart TB
  A[冻结口径版本、变更与时间线] --> B{数据可信？}
  B -->|否| C[修复分母、水位、迟到与规则]
  B -->|是| D[按用户路径和业务切片定影响]
  C --> D
  D --> E[指标看趋势与燃尽]
  D --> F[链路与日志找等待和上下文]
  D --> G[业务审计核验副作用]
  E --> H[限流、降级、回滚或隔离]
  F --> H
  G --> H
  H --> I[查单、对账、补偿与清积压]
  I --> J{新流量、历史对象和不变量均通过？}
  J -->|否| K[继续事故并保留失败边界]
  J -->|是| L[受控恢复与复盘回写]

图解读： 排查先过数据可信门，再并行使用技术信号与业务审计。正常路径经过止血、历史恢复和联合验证后受控放量，失败路径继续事故。结论是项目话术要讲口径、动作和证据闭环，不能只讲搭了监控平台。

阶段	核心问题	证据	禁止动作
定界	是真实恶化还是观测失真	分母、截止时间、完整度、版本	先改口径再解释事故
止血	如何阻止新增用户损失	燃尽、业务切片、依赖与容量	无幂等保护的盲目重试
恢复	历史对象是否全部闭环	积压、未知年龄、对账与回放	告警回落即关闭事故
复盘	哪个约束和门禁要改变	时间线、根因、行动项与演练	只写加强意识或增加监控

数据演绎 13：技术恢复后仍需业务验证。 E3（演练证据）支付入口错误在 10 分钟内从 5.00% 回落到 0.10%，但事故窗口留下 600 个未知支付；查单后 570 个确认成功并补齐分录，20 个明确失败，10 个金额冲突进入人工。状态变化是技术告警恢复后，未知队列从 600 降到 10，但业务事故仍未关闭；观测信号包括入口错误、查单命中、分录对账和最老未知年龄。结论是冲突逐笔有结论且无新增差异后，才可宣布业务恢复。

综合题使用说明

以下题目用于长口述训练；答案中的数字与阈值仍遵守 E3（演练证据）边界，追问必须先给结论再说明证据，不以外部链接替代正文。

综合题库

问题：请完整区分 SLA（服务等级协议）、SLO（服务等级目标）、SLI（服务等级指标）、技术成功和业务成功。
口述答案：我会先按责任层次回答。SLA（服务等级协议）是面向客户或上下游的外部承诺，除了可用性还可能包含统计周期、维护例外、责任边界和违约后果，因此不能由研发拿一个看板数字直接宣布。SLO（服务等级目标）是内部风险治理目标，用来平衡迭代速度、可靠性投入和失败成本，通常要给外部承诺留出可验证的内部余量。SLI（服务等级指标）是事实计算规则，必须写清业务事件、好事件分子、可评价事件分母、窗口、事件时间、迟到修正、排除、数据来源和口径版本。技术成功回答某次调用、提交或任务是否完成技术动作，业务成功则要求用户目标在承诺时间内完成且不变量成立。支付接口返回成功但渠道终态未知，库存接口成功但可售量为负，导出任务完成但文件无权限，IoT（物联网）消费者吞吐正常但关键设备漏报，都属于技术成功不能证明业务成功。落地时我会分别建技术诊断指标和业务结果指标，由权威账本提供分母，由渠道回执、库存流水、对象摘要或设备清单核验分子，再让 SLO（服务等级目标）和错误预算驱动发布动作。没有业务、法务和生产数据确认时，任何比例只按 E3（演练证据）说明算法，真实 SLA（服务等级协议）保持 E0（待核对）。
评审时还要让产品、研发、运维和业务拿同一个失败样本逐项判定，确认“可接受结果”“未知态”和“维护例外”没有歧义；若各方结论不同，先修口径，再谈目标值。口径生效后保留原始事件抽样复算，防止看板实现与书面定义逐渐漂移。
- 追问 1：三者谁先定义？ 直答 1：先定义用户结果和 SLI（服务等级指标），再定内部 SLO（服务等级目标），最后由业务与法务确认 SLA（服务等级协议）。
- 追问 2：技术指标还有价值吗？ 直答 2：有，它是领先预警和根因定位证据，但不能替代业务终态。
- 追问 3：明确业务拒绝算成功吗？ 直答 3：对“给出明确结果”的可用性可算可接受，对“交易完成”的业务成功不能算成功。
- 追问 4：面试中没有生产数字怎么办？ 直答 4：明确 E0（待核对），用 E3（演练证据）演绎公式和动作，不虚构承诺。
- 详情：稳定性口径与信号边界
问题：如何为支付链路设计业务 SLI（服务等级指标）与技术 SLI（服务等级指标）？
口述答案：我会从一个稳定支付意图开始，而不是从接口调用次数开始。权威分母是进入支付服务责任边界并持久化的支付意图，按商户、业务单和支付意图键去重；网关调用、回调和主动查询都是技术尝试，只作为诊断维度。技术 SLI（服务等级指标）可以包括受理可用性、接口阈值达标率、回调验签处理率、查单延迟和依赖错误，但业务 SLI（服务等级指标）的好事件必须在确认窗口内取得明确渠道终态，核对商户、金额和币种，支付状态合法推进，唯一账务分录守恒，并且没有重复扣款。超时先进入未知态，等待原业务键查单或对账；超过事前约定的确认窗口，正确性或时效目标按规则计坏，但后续仍继续闭环。明确渠道拒绝可以满足“给出明确结果”的可用性，却不能满足“支付完成”的业务成功，因此至少拆结果明确率、支付完成率和资金正确率。排除只能覆盖未受理的非法参数等事前规则，第三方故障通常仍影响完整产品结果。看板同时展示分母完整度、最老未知、迟到回填、金额差异和错误预算，发布门禁对资金不变量设置独立红线。所有候选窗口和比例都标 E3（演练证据），生产目标需由渠道能力、历史分布、业务成本和合同共同校准。
为验证口径，我会故障注入“渠道已成功但响应丢失、重复回调、查单迟到、金额不符”四类序列，要求无论到达顺序如何都只产生一个有效支付结论。恢复验收还要抽取事故窗口渠道账单与本地分录逐笔比对，确保技术错误回落后没有遗留资金差异。
- 追问 1：回调成功能否直接算业务成功？ 直答 1：不能，还要验签、主动核验金额币种、合法推进状态并确认分录守恒。
- 追问 2：超时为什么不直接算失败？ 直答 2：超时只证明响应不可见，渠道可能已经扣款，必须先按原键查单。
- 追问 3：重复回调如何统计？ 直答 3：用户分母按支付意图去重，重复次数另作技术放大指标。
- 追问 4：单笔重复扣款比例很低怎么办？ 直答 4：按资金正确性红线立即止血，不能被大分母稀释。
- 详情：支付资金正确性与对账恢复
问题：如何为 WMS（仓储管理系统）库存防超卖设计 SLI（服务等级指标）？
口述答案：库存可靠性要先守住正确性，再谈表面可用。分母可以定义为已持久化且需要裁决的库存业务意图，按租户、仓、商品、订单行和意图键唯一；技术调用重试不重复计入。好事件至少满足同一意图只生效一次、条件更新未让可售量小于零、预占流水与库存快照守恒，并且预占最终在业务时限内转为释放或实际扣减。明确售罄是可接受拒绝，可计入“明确结果”目标，但不能计入“预占成功”目标。数据库更新成功只是技术证据，如果消息丢失导致预占长期不释放，或下游仓已出库而本地仍释放库存，业务仍失败。指标应拆预占结果明确率、库存正确率、预占闭环时效、负库存对象数、重复副作用数和最老未知年龄。权威分母来自订单与库存意图账本，分子由库存流水、版本、订单终态和实物或下游仓对账共同核验。低流量热点商品不能只看全局比例，任一确认超卖应触发独立红线。发布时按仓、商品热点和版本切片观察，预算健康也不能覆盖不变量破坏；恢复时既看新预占，也要清理过期占用并复算可售量。候选时限和比例均为 E3（演练证据），不宣称生产效果。
演练还要覆盖支付取消与预占过期并发、消费者重启导致消息重复、热点商品锁竞争和下游仓出库回调迟到。验收不是只看最终库存数，而要从订单意图重放流水，证明每次增加或减少都有唯一原因，异常补偿不会越过已经发生的实物出库事实。上线后还按仓与商品切片复算，避免全局值掩盖热点超卖风险。
- 追问 1：明确售罄算坏事件吗？ 直答 1：对可用性可算可接受结果，对预占成功率则不是成功，两个分子要分开。
- 追问 2：缓存扣减成功够吗？ 直答 2：不够，要看缓存是否权威以及数据库、流水和补偿是否守恒。
- 追问 3：预占长期未释放如何处理？ 直答 3：以最老年龄告警，核对订单终态后按唯一流水幂等释放。
- 追问 4：为什么设置超卖红线？ 直答 4：单笔超卖失败成本高，不能等窗口比例显著后再行动。
- 详情：WMS（仓储管理系统）库存预占与对账补偿
问题：异步导出的技术成功率和业务成功率应该怎样定义？
口述答案：异步导出不能把任务状态“完成”直接当用户拿到结果。分母应来自已受理且未被合规取消的导出任务清单，按任务键去重，并记录请求人、租户、查询条件摘要、数据版本和交付时限。技术 SLI（服务等级指标）可以看任务领取、分片处理、对象上传、通知发送、队列等待和执行器重试；业务好事件则要求在承诺时限内生成完整产物，行数或摘要通过校验，对象存储回读成功，下载授权属于正确用户且在有效期内可访问，必要时通知也有回执。任务完成但空文件、格式错误、对象权限错、下载地址失效或晚于时限，都应进入相应坏事件。用户未主动下载通常不算服务失败，只要结果已按时可用且通知规则满足；但因等待过慢产生的客户端取消不能事后排除。指标应同时展示交付达标率、产物正确率、可下载率、最老任务年龄、重试放大和分母完整度。恢复时先保护高优先级队列，限制大任务并发，再对“任务、分片、对象、权限、通知”逐段对账；补跑必须使用确定性产物键，防止重复文件和重复通知。所有容量、时限和比例只以 E3（演练证据）演练，真实目标由文件大小、租户隔离和用户流程核对。
灰度发布新导出逻辑时，我会选取不同数据规模、字符集、权限角色和租户的样本做影子产物，比较行数、摘要和下载结果，再逐步切流。若任务状态与对象审计出现差异，门禁以业务产物为准，并将假完成任务放入隔离队列而不是继续通知用户。
- 追问 1：任务完成但用户没下载算失败吗？ 直答 1：若文件按时可用且通知成功，用户未操作通常不算服务失败。
- 追问 2：空文件如何发现？ 直答 2：校验行数、格式、大小和内容摘要，并从对象存储回读。
- 追问 3：重跑会不会重复交付？ 直答 3：使用任务与版本派生的确定性对象键，发布前校验既有产物和通知记录。
- 追问 4：队列恢复就能关闭事故吗？ 直答 4：不能，还要证明历史任务产物、权限和通知均已闭环。
- 详情：Runner（执行器）、异步任务与可观测性
问题： IoT（物联网）报警风暴下如何定义业务成功与错误预算？
口述答案：报警风暴最危险的误区是用高吞吐证明可靠。分母不能来自已收到的消息量，而应来自注册设备、规则绑定和关键事件清单；否则完全未上报的设备会消失。技术 SLI（服务等级指标）可以看入口接收率、队列等待、消费者错误、规则执行时延和通知通道可用性。业务好事件要按安全等级定义：关键设备事件在新鲜度时限内被接收，规则版本正确，去重或聚合后仍能回溯原始事件，通知送达责任人并获得所需回执。重复噪声可聚合通知，但原始关键事件覆盖不能减少；误聚合、漏报、陈旧报警、错误租户路由和无回执都应单列。错误预算按关键事件和普通事件分层，关键漏报可以设置逐事件红线，不能被海量普通事件稀释。风暴时动作是设备级去重、时间窗聚合、优先队列、租户限额和非关键降级，同时保护关键事件审计。恢复后不只看积压下降，还要按设备清单补算覆盖、新鲜度、通知回执和最老未知，对保留期边缘事件做重放或人工确认。所有阈值为 E3（演练证据），真实安全等级、通知时限和生产承诺保持 E0（待核对）。
演练需要同时注入重复事件、关键事件与噪声混流、消费者暂停、通知通道限流和规则版本回滚，验证优先队列不会饿死关键对象。恢复报告要列出受影响设备、最后可信事件、是否补送和责任人确认，任何无回执关键事件都保持开放。
为了让方案可执行，我还会准备正常、超时、重复、迟到、依赖失败和观测缺失样本做历史回放，逐项核对分母、结果分类、预算变化与动作是否符合书面规则；发布后抽取原始业务键复算，并将无法解释的差异作为数据质量事故。演练记录保留输入、规则版本、预期、实际、停止条件和受影响对象，下一次变更前复验未关闭问题。若样本或数据源不足，就报告未知与最坏边界，不用推断填补事实，并由业务负责人确认残余风险。
- 追问 1：去重会不会降低分母？ 直答 1：通知分母可按聚合单，原始关键事件分母不能因去重删除。
- 追问 2：设备没上报如何统计？ 直答 2：以注册设备和期望心跳清单发现缺失，而不是从已收消息反推。
- 追问 3：吞吐恢复为何不够？ 直答 3：还要证明关键事件未漏、未过期且通知有回执。
- 追问 4：关键事件很少怎么告警？ 直答 4：使用逐事件红线、最长未知年龄和关键对象覆盖，不只看百分比。
- 详情：Prometheus（监控系统）指标与告警风暴治理
问题：如何设计一个不会被重试和成功日志污染的分子分母？
口述答案：我会先找一个稳定业务意图键和独立权威账本。分母定义为进入责任边界、满足可评价条件的唯一业务意图，而不是所有技术调用；网关重试、服务重试、消息重复和回调重放都挂在同一意图下，另算尝试放大。分子则由业务终态和权威副作用共同判定，例如支付看渠道与分录，库存看流水与守恒，导出看产物与权限。明确失败、未知和排除是互斥分类，未知在确认窗口内单列，超时后按事前规则计坏并继续查证。排除规则必须版本化，只有未受理的非法请求、批准且未越界的维护等可审计对象才可能排除；观测缺失、依赖失败和服务慢导致的取消不能直接删除。为防成功日志污染，分母从订单、任务或设备清单抽取，再与应用事件做左右对账，检查未观测、重复和孤儿记录。实时结果按事件时间与处理水位暂算，迟到证据按版本回填，不静默改历史。最后为分母完整度、排除率、未知率和重复率各建数据质量护栏；任一失守时停止自动发布。这样重试仍能用于容量与故障诊断，却不能把一个用户事件算成多个，也不能让最后一次成功抹掉承诺窗口内的损失。
实施前我会拿一段包含成功、明确失败、超时后成功、重复投递和观测缺失的样本逐条手算，再与计算器结果比对。若权威账本和指标事件无法一一关联，先补关联键与回放能力；没有可复算分母时，宁可报告未知，也不输出看似精确的百分比。
为了让方案可执行，我还会准备正常、超时、重复、迟到、依赖失败和观测缺失样本做历史回放，逐项核对分母、结果分类、预算变化与动作是否符合书面规则；发布后抽取原始业务键复算，并将无法解释的差异作为数据质量事故。演练记录保留输入、规则版本、预期、实际、停止条件和受影响对象，下一次变更前复验未关闭问题。若样本或数据源不足，就报告未知与最坏边界，不用推断填补事实，并由业务负责人确认残余风险。
- 追问 1：为什么分母不能来自成功日志？ 直答 1：失败和未到达事件最容易缺日志，会造成幸存者偏差。
- 追问 2：一个意图多次尝试怎么计？ 直答 2：用户结果只计一次，尝试次数另建放大指标。
- 追问 3：迟到成功能改分子吗？ 直答 3：可修订最终正确性，但不能抹掉已经违反的时效目标。
- 追问 4：如何证明分母完整？ 直答 4：用独立权威清单与观测事件对账，报告覆盖率和孤儿记录。
- 详情：日志、指标、链路与业务审计边界
问题：未知态、迟到事件和封账回算应该怎样共同治理？
口述答案：未知态是证据尚不足，不应提前归为成功或失败。每个业务事件要保存事件时间、处理时间、稳定业务键、最后证据、确认截止和责任人。实时看板先按处理水位给暂算值，同时展示未知数量、最老年龄、数据截止时间和完整度。支付超时、库存下游未知、导出对象上传未确认或设备通知无回执，都进入领域化查证：优先按原键查询、对账或回读，避免换键重试扩大副作用。确认窗口到期后，未知按事前规则进入时效坏事件或正确性风险，但处置任务不能关闭。后续证据到达时按事件时间回填原窗口：如果最终成功，可以修订正确性事实；如果已经超过时限，时效坏事件仍保留。自然周期封账应基于最大合理迟到和决策时效，封账后仍可追加修订版本，但必须保留原值、修订原因、影响事件和当时触发的发布或事故动作。观测系统延迟本身也要有 SLI（服务等级指标），若回填水位异常，门禁进入保守状态。这样既不会把在途业务误杀，也不会用事后成功美化用户当时遭受的等待。
运营上还要为未知队列设所有者、升级路径和人工工作台，记录每次查证使用的来源、结论与下一次时间。若渠道或下游长期不可查询，就收紧自动受理和重试上限，把无法证明的承诺显式暴露给业务决策，而不是让未知无限沉底。
为了让方案可执行，我还会准备正常、超时、重复、迟到、依赖失败和观测缺失样本做历史回放，逐项核对分母、结果分类、预算变化与动作是否符合书面规则；发布后抽取原始业务键复算，并将无法解释的差异作为数据质量事故。演练记录保留输入、规则版本、预期、实际、停止条件和受影响对象，下一次变更前复验未关闭问题。若样本或数据源不足，就报告未知与最坏边界，不用推断填补事实，并由业务负责人确认残余风险。
- 追问 1：未知态多久算失败？ 直答 1：按事前确认窗口和失败成本决定，不能只凭感觉或事故后改规则。
- 追问 2：最终成功是否返还错误预算？ 直答 2：正确性预算可按版本修订，时效预算不返还，原决策记录保留。
- 追问 3：封账后还能改吗？ 直答 3：可以追加修订版本，不能静默覆盖原报告。
- 追问 4：查证也一直失败怎么办？ 直答 4：升级人工和对账，限制新增副作用，并持续跟踪最老未知。
- 详情：支付回调、主动查单与未知态
问题：如何制定不会被事故后美化的排除规则和维护例外？
口述答案：排除规则本质上是责任边界，必须在事故前定义并版本化。每条规则需要事件类型、适用对象、识别字段、生效时间、到期时间、审批人和审计查询，且排除率本身要被监控。非法参数只有在服务尚未受理且能证明由调用方造成时，才可从服务可用性分母排除；鉴权策略误拒绝、错误限流、依赖失败和慢请求引发的客户端取消仍属于产品结果。维护例外还要满足承诺允许、用户已通知、影响对象和时段与审批一致，提前开始、延迟结束或越过范围的事件仍计坏。第三方故障可以在内部依赖指标中归因，但除非外部承诺明确排除，端到端用户 SLI（服务等级指标）仍要反映损失。观测数据缺失更不能当排除项，因为采集失败可能与业务失败同源；此时报告未知范围和保守上下界，停止自动晋级。规则变更先用历史窗口影子回算，列出分母差异和预算影响，经业务、研发与运维评审后从明确时点生效。事故复盘可以发现规则缺口，但新规则不能追溯性地把既有坏事件洗掉。
我还会定期抽样检查被排除事件，确认原因字段不是默认值、维护影响没有越界、调用方责任有独立证据。若排除率在版本发布后突然上升，即使最终 SLI（服务等级指标）改善，也先暂停口径生效并回到原始请求核查，避免规则缺陷伪装成可靠性提升。
为了让方案可执行，我还会准备正常、超时、重复、迟到、依赖失败和观测缺失样本做历史回放，逐项核对分母、结果分类、预算变化与动作是否符合书面规则；发布后抽取原始业务键复算，并将无法解释的差异作为数据质量事故。演练记录保留输入、规则版本、预期、实际、停止条件和受影响对象，下一次变更前复验未关闭问题。若样本或数据源不足，就报告未知与最坏边界，不用推断填补事实，并由业务负责人确认残余风险。
- 追问 1：客户端取消能排除吗？ 直答 1：只有证明与服务等待无关且事前约定时可排除。
- 追问 2：第三方全挂算谁的？ 直答 2：内部可归因第三方，端到端承诺是否排除取决于明确协议。
- 追问 3：维护审批通过就都排除吗？ 直答 3：不，实际影响必须落在通知、时段和对象范围内。
- 追问 4：规则为何要到期？ 直答 4：防止临时例外永久化并持续缩小分母。
- 详情：配置发布、滚动策略与变更治理
问题：当数据新鲜度和完整度不足时，如何避免错误发布决策？
口述答案：我把观测数据质量当作可靠性决策的前置门禁。首先从独立权威清单得到应评价对象，例如支付意图、库存订单行、导出任务或注册设备，再与已采集事件对账，计算完整度、重复、孤儿记录和分区水位。新鲜度使用事件时间而不是采集进程心跳，展示最新完整事件距离当前的延迟；规则版本覆盖则检查同一窗口是否混用新旧分母或排除逻辑。只要完整度、新鲜度或版本一致性低于 E3（演练证据）候选门槛，仪表盘就不能给出确定健康结论，自动灰度晋级暂停，值班人员获得缺失对象、最老水位和影响切片。短期可以切换独立数据源、扩大原始日志保留、按权威账本补算，并报告已观测成功率和最坏上下界；不能把缺失对象从分母删除。回补后按固定口径版本重算，保留修订前后差异及当时采取的动作。长期要为采集链本身设置容量、保留、回放与单故障域演练，防止业务故障和观测故障同时发生。这样即使业务数值看起来绿色，也不会在证据不全时继续放量。
数据质量恢复也要有独立验收：缺失对象清单归零或全部有解释，事件水位追平，跨来源抽样一致，新旧口径回算差异可说明。若只能恢复部分范围，看板必须标出可用切片与不可用切片，发布门禁仍按最保守的受影响路径处理。
为了让方案可执行，我还会准备正常、超时、重复、迟到、依赖失败和观测缺失样本做历史回放，逐项核对分母、结果分类、预算变化与动作是否符合书面规则；发布后抽取原始业务键复算，并将无法解释的差异作为数据质量事故。演练记录保留输入、规则版本、预期、实际、停止条件和受影响对象，下一次变更前复验未关闭问题。若样本或数据源不足，就报告未知与最坏边界，不用推断填补事实，并由业务负责人确认残余风险。
- 追问 1：采集器全绿够吗？ 直答 1：不够，某分区或租户仍可能停滞，要看事件水位和对象覆盖。
- 追问 2：能用样本推全量吗？ 直答 2：可辅助估计，但要证明抽样独立并给边界，关键正确性仍需逐笔审计。
- 追问 3：回补后可以删除原告警吗？ 直答 3：不能，原决策基于当时证据，修订应追加版本。
- 追问 4：门禁会不会拖慢发布？ 直答 4：会增加约束，但能避免在盲区中扩大真实用户损失。
- 详情：OpenTelemetry（开放遥测）与 SkyWalking（链路追踪系统）
问题：如何正确使用平均值、阈值达标率和分位数描述延迟？

口述答案：我会先从用户可接受时限定义延迟 SLI（服务等级指标），分子是在 E3（演练证据）候选阈值内得到可接受结果的唯一业务事件，分母是所有可评价事件，包括超时和因服务慢导致的取消。这个达标率可直接进入错误预算。平均值只适合描述总体资源消耗或稳定分布，容易被大量快请求掩盖少量极慢请求；P50（50 分位响应时间）描述典型体验，P95（95 分位响应时间）和 P99（99 分位响应时间）描述尾部，但都必须附窗口、样本量和业务切片。跨实例不能平均分位数，应让实例上报边界一致且覆盖超时的直方图桶，再合并桶计算全局分位数。超时请求是真实坏事件，即使没有完整结束时间也要记录超时上界、类型和最高桶，不能从延迟样本中删除。低流量下高分位会剧烈跳变，需要同时报告绝对坏事件和置信边界；多峰分布则按缓存命中、区域、版本和依赖切片定位。最终看板以阈值达标率回答目标是否满足，以分位数和直方图解释谁慢、慢在哪里，链路再拆排队、应用和外部等待。阈值没有生产证据时只作为 E3（演练证据），不能宣称真实用户承诺。

为了让方案可执行，我还会准备正常、超时、重复、迟到、依赖失败和观测缺失样本做历史回放，逐项核对分母、结果分类、预算变化与动作是否符合书面规则；发布后抽取原始业务键复算，并将无法解释的差异作为数据质量事故。演练记录保留输入、规则版本、预期、实际、停止条件和受影响对象，下一次变更前复验未关闭问题。若样本或数据源不足，就报告未知与最坏边界，不用推断填补事实，并由业务负责人确认残余风险。

追问 1：为什么不能平均实例 P99（99 分位响应时间）？ 直答 1：分位数不是线性统计量，平均后无法代表全局排序位置。
追问 2：只看阈值达标率够吗？ 直答 2：不够，它适合目标计算，分位数和分布用于发现尾部与多峰。
追问 3：超时没有真实耗时怎么记？ 直答 3：记录大于超时阈值的右删失事实，并计入坏事件和最高桶。
追问 4：低流量能看 P99（99 分位响应时间）吗？ 直答 4：可以展示，但必须附样本量，主要决策依靠绝对事件和更长窗口。
详情：Prometheus（监控系统）指标、直方图与告警

问题：如何为一条既有同步又有异步阶段的链路设计延迟 SLO（服务等级目标）？

口述答案：我不会用一个端到端平均时长统治全部阶段，而是先定义用户等待与最终完成两类目标。同步阶段的用户结果可能是“在 E3（演练证据）候选时限内得到已受理、明确拒绝或可解释的排队状态”，分母是进入同步责任边界的唯一业务意图；异步阶段则定义“在交付时限内达到可验证终态”，例如导出文件可下载、外仓订单已受理或支付未知已确认。技术阶段再拆队列等待、实际执行、外部依赖和通知延迟，用于定位但不替代端到端目标。事件时间从业务意图创建开始，处理时间用于衡量观测迟到；重试挂在同一意图下，不能重置用户计时。同步成功但异步超期时，同步可用性可能达标，最终业务时效仍计坏。对用户明确展示的排队或降级只有在产品事前接受、不会破坏不变量且状态可查询时，才能算同步可接受结果。看板同时给阶段水位、最老任务、阈值达标率、P99（99 分位响应时间）和终态对账；恢复时既验证新请求，也清理旧任务。通过两个层次，系统可以快速释放请求线程，却不会用“异步了”逃避最终交付承诺。

追问 1：异步后同步请求就算成功吗？ 直答 1：只算受理目标成功，最终业务目标仍要等终态。
追问 2：重试会重置时钟吗？ 直答 2：不会，用户等待从原业务意图开始，重试只是技术尝试。
追问 3：排队提示算可接受结果吗？ 直答 3：需产品事前定义、状态可查询且最终交付仍有时限。
追问 4：阶段目标都达标端到端就达标吗？ 直答 4：不一定，阶段间等待和相关故障仍需端到端事件直接验证。
详情：跨境订单履约、面单、轨迹与异常恢复

问题：请现场演绎一次错误预算计算，并说明哪些前提不能省略。

口述答案：我先声明这是 E3（演练证据），不是生产承诺。假设目标窗口内有 1,000,000 个可评价业务事件，E3（演练证据）SLO（服务等级目标）为 99.90%，允许错误率是 0.10%，所以允许坏事件为 1,000,000 × 0.10% = 1,000 个。若已确认坏事件 620 个，超过确认窗口的未知 80 个按规则计坏，已用预算就是 700 个，剩余 300 个，消耗比例为 70.00%。计算前提包括：分母来自独立权威账本并按业务意图去重；好、坏、未知与排除互斥；窗口、事件时间、迟到修订和排除规则固定；数据完整度满足决策要求；目标与事件使用同一口径版本。若存在观测缺失，不能把缺失从分母删除，应报告上下界并暂停自动晋级。剩余预算也不是发布许可证，还要比较灰度最坏损失、业务红线和依赖状态。假设一个变更在 E3（演练证据）压力模型下可能新增 400 个坏事件，即使平均预测较低，也会越过剩余预算，因此应缩小批次、先消除风险或准备回退。后续迟到证据可以修订正确性，但已发生的时效损失和当时的门禁决策保留。

追问 1：未知为什么计入已用预算？ 直答 1：因为已超过事前确认窗口，风险不能继续按成功对待。
追问 2：流量翻倍预算也翻倍吗？ 直答 2：事件预算绝对数会变，但用户损失同样扩大，仍要看失败成本。
追问 3：剩余预算可跨月份使用吗？ 直答 3：除非规则明确，否则不能跨窗口搬运，每个窗口独立复算。
追问 4：数据不完整如何算？ 直答 4：给已知值和保守上下界，停止确定性达标结论。
详情：SLO（服务等级目标）与事故响应闭环

问题：如何设计多窗口燃尽率告警而不制造告警风暴？

口述答案：燃尽率是观察窗口实际错误率除以 SLO（服务等级目标）允许错误率，表达当前速度会多快耗尽预算。我会使用同一业务事件口径的短窗口和长窗口：短窗口快速捕捉突发，长窗口确认持续消耗；只有两者同时满足 E3（演练证据）候选条件且样本量、完整度有效时，才触发高等级响应。对于缓慢恶化，再配置更长观察与较低燃尽条件，提前安排容量或依赖治理。告警负载要包含目标、窗口、燃尽率、已用预算、坏事件类型、版本、区域、租户和依赖切片，而不是只给一个红色数值。路由按用户路径和共同故障域聚合，抑制同一根因产生的实例、线程池、网关和依赖派生告警；支付重复扣款、库存超卖和关键设备漏报等业务红线独立直达，不等待聚合比例。若只有短窗尖峰而长窗正常，可进入观察或低等级调查；若完整度下降，则转为数据质量告警并冻结自动晋级。阈值从目标窗口、允许响应时间、恢复时长和失败成本反推，再用历史回放与故障演练验证误报和漏报。告警必须绑定动作表，否则只是更复杂的噪声。

追问 1：为什么短长窗口要同口径？ 直答 1：否则两者反映不同事件集合，无法共同解释预算消耗。
追问 2：只有短窗高燃尽怎么办？ 直答 2：检查是否真实突发和业务红线，通常先观察而非直接全量升级。
追问 3：业务红线也等双窗吗？ 直答 3：不等，单笔高损失事件按独立规则立即处置。
追问 4：如何减少派生告警？ 直答 4：以用户路径和故障域聚合，把资源告警作为上下文附在主事件中。
详情：Prometheus（监控系统）告警降噪

问题：如何把错误预算真正接入发布、扩容和事故动作？

口述答案：我会把预算状态做成版本化动作表，而不是写一句“耗尽冻结”。输入至少包括剩余预算、短长窗口燃尽率、数据质量、业务红线、变更类型和故障域。预算健康时仍按常规评审、灰度和回退门禁；进入警戒后缩小批次、延长观察、限制并发变更，并优先处理高消耗路径。预算耗尽时冻结的是高不确定性功能、大范围迁移和不可逆数据变更，不是所有动作；回滚、缺陷修复、安全补丁、受控扩容、限流、查单和补偿可以进入减险通道，但每批都要有责任人、影响上限、检查点和业务核验。若支付、库存或关键报警触发不变量红线，即使预算仍充足也立即止血。扩容也不能自动放行：若瓶颈是数据库锁、外部配额或共享网络，增加实例可能放大故障，需要先用容量和依赖证据验证。退出事故要同时满足新流量结果恢复、历史积压下降、未知态闭环、数据质量可信和业务对账无新增差异。临时豁免记录原因、范围、期限与回退，过期自动收回；复盘再把动作效果写回阈值、门禁和演练脚本。

追问 1：预算耗尽能扩容吗？ 直答 1：可以作为减险动作，但要证明瓶颈位置并小批验证。
追问 2：紧急修复需要走门禁吗？ 直答 2：需要简化但更严格的减险门禁，包含回退点和业务核验。
追问 3：谁能批准豁免？ 直答 3：预先约定的业务、研发和事故角色共同接受残余风险。
追问 4：何时恢复常规发布？ 直答 4：预算趋势、关键路径、历史对象和数据质量均满足退出条件后分批恢复。
详情：GitOps（Git 运维模式）、滚动发布与回退治理

问题：错误预算耗尽时，如何避免修复动作反而扩大事故？

口述答案：预算耗尽说明风险承受力已经不足，修复不能靠一次大变更碰运气。我会先冻结时间线、口径版本和受影响对象，停止扩大副作用的自动重试与全量发布；随后把动作分成可逆止血、缺陷修复、数据恢复和结构性改造。可逆止血如限流、关闭非关键功能、回滚已验证版本或按渠道隔离，优先小范围执行。缺陷修复先在隔离数据和最小流量验证，明确回退点；支付和库存变更还要检查幂等、状态机和账本不变量。数据恢复使用确定性任务、检查点和分批对账，绝不直接覆盖历史事实：支付通过查单和追加分录，库存通过唯一流水补偿，导出通过版本化产物重跑，IoT（物联网）通过原始事件隔离重放。每批后重新计算新增坏事件、未知年龄、积压和对账差异，异常即停在上一个稳定检查点。观测系统若缺样，自动晋级关闭，改用权威账本和人工审批。事故沟通明确哪些已知、哪些推断和哪些未知，避免为了“尽快恢复”跳过证据。最终只有新流量和历史对象都通过，才逐步解除限制；长期重构另走正常评审，不在事故中混入。

追问 1：为什么不直接全量回滚？ 直答 1：回滚也可能遇到数据不兼容或依赖变化，需验证可逆性和范围。
追问 2：补偿为什么要分批？ 直答 2：限制重复副作用和依赖冲击，并能在每批后对账。
追问 3：可以直接改支付状态吗？ 直答 3：不可以，应基于渠道事实查证并追加可审计分录或调整事实。
追问 4：何时做结构性重构？ 直答 4：先完成止血和业务闭环，再按正常方案评审与演练推进。
详情：取消、退款、冲正、对账与恢复

问题：复合依赖的端到端 SLO（服务等级目标）应该如何设计？

口述答案：我先画真实用户关键路径，把每个依赖标成必选、可选、并行候选、缓存旁路或异步补偿，并注明超时、重试、降级和未知态。正式端到端 SLI（服务等级指标）直接从用户业务事件计算，因为串行乘积只有在依赖相互独立、全部必须成功且没有降级时才是近似；共享数据库、网络、机房和流量峰值会造成相关故障，盲目相乘通常过于乐观。并行双路也只有在故障独立、切换足够快、结果语义等价且副作用幂等时才提高可靠性，否则会产生重复支付、状态冲突或配额放大。缓存返回可提升可用性，但陈旧结果必须同时受新鲜度目标约束。内部依赖 SLO（服务等级目标）用于容量和供应方治理，应根据端到端预算反推目标与超时，而不是把各团队目标随意相加。观测上用业务键串联网关、服务、依赖与账本，建立联合失败矩阵，按时间、故障域、版本和渠道识别相关性。故障演练覆盖单依赖失败、共享域失败、切换迟滞和降级过期，最终仍以端到端好事件、未知态与业务不变量验收。

追问 1：三个 99.9% 能直接相乘吗？ 直答 1：只能作为独立必选假设下的 E3（演练证据）近似。
追问 2：双路并发一定更可靠？ 直答 2：不一定，还要处理共享故障、配额、结果冲突和重复副作用。
追问 3：缓存成功算端到端成功吗？ 直答 3：仅当陈旧度在产品可接受范围内且结果语义明确。
追问 4：依赖目标如何分配？ 直答 4：从用户目标、路径贡献、恢复能力和失败成本反推，并用端到端数据校准。
详情：服务治理、韧性与依赖边界

问题：低流量服务如何避免用百分比制造虚假的高可靠？

口述答案：低流量场景首先承认统计证据有限。分母很小时，一个坏事件会让比例剧烈跳变，零事件时比例根本没有定义，所以看板必须展示样本量、坏事件绝对数、最长无样本时长和置信边界，不能把零请求显示为满分。扩大窗口可以增加样本，但会降低发现速度，因此还要组合逐事件业务红线、最老未知年龄、关键对象清单和合成探测。合成探测用于验证技术可达、鉴权和基础路径，不能证明真实资金、库存或数据副作用；真实低频支付与结算仍需逐笔对账。多租户服务不能只看全局事件加权比例，大租户会稀释小流量高价值客户的事故，应设置可行动的租户、区域和渠道护栏，同时按共同故障域聚合告警，避免切片爆炸。若一周只有少量事件全部成功，只能说该样本没有观察到坏事件，不能宣称达到某个高比例生产目标。发布决策结合历史窗口、故障演练、依赖状态和回退能力，风险高时采用小批人工确认。低流量不是降低治理标准，而是从百分比转向逐事件、覆盖和演练证据。

追问 1：零请求显示什么？ 直答 1：显示无数据或不适用，并报告无样本时长。
追问 2：扩大窗口够吗？ 直答 2：不够，发现会变慢，还需红线、未知年龄和合成探测。
追问 3：合成探测成功能证明业务成功吗？ 直答 3：不能，它通常不覆盖真实副作用与数据权限。
追问 4：低流量还能做错误预算吗？ 直答 4：可以描述，但决策应更多依赖绝对事件和失败成本。
详情：稳定性口径中的低流量与证据边界

问题：零流量、流量未到达和服务完全不可用如何区分？

口述答案：三种情况在应用成功率看板上都可能表现为没有样本，因此必须建立从上游意图到入口再到服务的覆盖链。正常零流量是业务清单和上游事件都没有应到请求；流量未到达是上游存在意图，但网关、路由、鉴权或消息入口没有对应记录；服务完全不可用则入口已有请求，服务未返回可接受结果或根本未采集。排查时先对比订单、任务、设备或调度权威清单，再看域名解析、网关计数、负载路由、队列生产与消费水位，最后看实例与依赖。合成探测从外部按固定频率验证网络、鉴权和最小无副作用路径，可发现应用无真实流量时的技术不可达，但不能替代真实业务事件。看板对空分母显示“无数据”，同时展示上游意图差、入口覆盖和探测结果；若上游有意图而入口为零，应按高风险路由或采集事故处理，不能报告健康。恢复后还要查漏失期间的业务意图：支付是否需查单，任务是否需补投，设备事件是否越过保留期。这样零样本不会成为监控盲区，也不会因为探测成功就忽略真实流量断链。

追问 1：应用无请求为何可能是事故？ 直答 1：上游可能有业务意图，但流量在域名、网关、鉴权或消息入口前丢失。
追问 2：合成探测放在哪里？ 直答 2：从用户边界覆盖关键路由，同时避免真实资金和库存副作用。
追问 3：探测全绿但真实流量为零怎么办？ 直答 3：检查上游意图、租户路由和业务参数，探测只证明自己的固定路径。
追问 4：恢复入口后还做什么？ 直答 4：对断链窗口的业务清单补投、查证或人工确认。
详情：可观测性四信号与项目入口

问题：线上 SLO（服务等级目标）突然恶化，你会如何从指标走到业务根因？

口述答案：我会同时推进保护用户和验证证据。第一步冻结变更、口径版本和事故时间线，确认恶化来自真实坏事件还是分母、采集水位、迟到回填或规则切换；若支付重复扣款、库存超卖等红线已出现，不等待数据调查完成就先隔离风险路径。第二步按用户路径、租户、区域、版本、渠道和故障域切片，比较坏事件绝对数、燃尽率、未知年龄与数据完整度，确定影响边界。第三步用指标看趋势、容量和依赖共振，用链路定位排队与外部等待，用日志查询业务键、错误分类与重试，用业务审计确认渠道、账务、库存、文件或设备终态。第四步选择最小可逆止血：回滚、限流、降级、渠道隔离或暂停自动重试；外部结果未知时先查证，不换键盲目重做。第五步处理历史对象，按权威清单清积压、补偿和对账，并持续观察是否新增差异。只有新流量结果恢复、历史未知闭环、数据质量可信和不变量通过，才小批恢复。最后复盘为什么目标、告警或门禁没有更早阻断，把行动项写成负责人、期限、验证方式和下一次演练，而不是只写增加监控。

追问 1：先查根因还是先止血？ 直答 1：高损失或持续扩散时并行推进，优先选择可逆止血。
追问 2：指标正常但审计异常信谁？ 直答 2：业务终态以权威审计为准，同时把指标缺口作为观测事故。
追问 3：依赖报错是否就是根因？ 直答 3：不一定，要看用户路径、重试放大和共同故障域证据。
追问 4：何时关闭事故？ 直答 4：新旧业务对象、积压、未知态与不变量全部达到退出条件后。
详情：线上事故、容量与项目案例

问题：技术告警恢复后，如何证明支付、库存、导出和 IoT（物联网）业务真正恢复？

口述答案：我会为四类业务使用同一恢复框架，但核验不同权威证据。共同框架是先验证新流量的用户结果，再检查事故窗口历史对象、队列与重试，随后关闭未知态和业务差异，最后确认观测完整度。支付要按支付意图查渠道终态、金额币种、唯一确认与账务分录，对未知查单，对重复或金额冲突建差异并受控冲正；入口错误回落不能替代资金对账。库存要核对订单行、预占、释放、扣减与可售量，处理长期占用和重复副作用，确认任一负库存对象都有结论。导出要把任务、分片、对象摘要、授权和通知串起来，合成下载验证可访问，不能只看执行器队列清零。IoT（物联网）要以设备和关键事件清单复算覆盖、新鲜度、规则版本和通知回执，积压变短不等于漏报已补。每类恢复都保留受影响对象清单、处理动作和复算结果；无法自动确定的进入隔离人工，不因流量恢复而关闭。放量按故障域分批，每批观察新增坏事件和历史差异。所有 E3（演练证据）门槛只用于方法展示，真实退出条件需由业务负责人和生产证据确认。

追问 1：支付最关键的恢复证据是什么？ 直答 1：渠道事实与本地支付、账务分录逐笔一致。
追问 2：导出队列为零够吗？ 直答 2：不够，还要验证产物、权限、下载和通知。
追问 3：IoT（物联网）如何发现漏报？ 直答 3：用设备和关键事件权威清单与已处理、已通知记录对账。
追问 4：人工单未清零能恢复吗？ 直答 4：只有风险已隔离且不会扩散时可小批恢复，事故仍保持开放。
详情：支付资金正确性恢复

问题：一张可靠性看板必须展示什么，才能避免绿色误导？

口述答案：看板的第一屏应围绕用户路径而不是实例列表。每个 SLI（服务等级指标）显示名称、业务定义、好事件、可评价事件、目标窗口、口径版本、数据截止时间、完整度、迟到水位、当前值、错误预算剩余和短长窗口燃尽率。结果指标至少区分技术成功、业务成功、明确失败与未知，延迟同时给阈值达标率、P50（50 分位响应时间）、P95（95 分位响应时间）、P99（99 分位响应时间）和样本量。第二层按版本、区域、租户、渠道、仓或设备等级切片，但只保留有行动意义的维度，避免标签基数和切片噪声。第三层关联队列、连接、依赖和资源诊断，供根因定位；支付、库存等还要展示不变量红线、差异单和最老未知。任何空分母显示无数据，任何完整度或新鲜度失守都覆盖绿色结果并阻断自动晋级。排除率、规则变更和迟到修订可下钻到原始事件，事故标记与发布批次叠加在同一时间轴。看板只负责呈现证据，动作由版本化策略执行；用户应能从一个坏事件跳到业务键、链路、日志和审计，而不是在多个系统手工猜测。

追问 1：第一屏放 CPU（中央处理器）吗？ 直答 1：通常放在诊断层，第一屏优先用户结果、预算和数据质量。
追问 2：空分母显示满分吗？ 直答 2：不能，应显示无数据和最长无样本时长。
追问 3：切片越多越好吗？ 直答 3：不是，只保留业务关键、故障可归因且能采取动作的切片。
追问 4：为何显示口径版本？ 直答 4：防止规则变化被误解为系统性能变化，并支持历史复算。
详情：Prometheus（监控系统）指标与告警设计

问题：如何把 SLO（服务等级目标）和错误预算接入灰度发布门禁？

口述答案：发布前先确认目标口径和观测数据可用于决策，包括分母完整度、事件水位、规则版本、基线窗口和回退能力。每个变更声明影响的用户路径、故障域、最坏坏事件上限、业务红线和数据兼容风险。灰度开始后按批次记录制品、配置、流量、开始时间和业务切片，比较灰度与对照的技术成功、业务成功、延迟达标、未知态和燃尽率。E3（演练证据）候选门槛只作为初始策略，需由历史回放和故障演练校准。预算健康允许常规晋级，警戒时缩小批次并延长观察，耗尽时停止高风险功能扩展；支付重复扣款、库存超卖、关键漏报等红线无论预算多少都立即回退或隔离。数据质量失守时不能把无告警当成功，自动晋级暂停。修复、回滚、安全和容量减险走单独通道，但同样要求最小验证集和业务核验。晋级不仅看短窗无异常，还要确认样本覆盖主要租户、区域与依赖路径；低流量场景增加合成探测和人工核验。回退后继续处理该批次产生的历史副作用，不能把流量切回就视为恢复。门禁决策、豁免和结果都写入审计，供复盘改进。

追问 1：无告警能自动晋级吗？ 直答 1：还要满足样本量、完整度、关键切片和业务红线条件。
追问 2：预算健康为何仍要灰度？ 直答 2：预算是风险承受力，不证明当前变更没有新故障模式。
追问 3：回退后任务结束了吗？ 直答 3：没有，还要核验该批次产生的未知态、积压和数据副作用。
追问 4：低流量如何晋级？ 直答 4：扩大观察、合成探测、关键对象人工核验，并限制批次上限。
详情：发布、滚动策略与 GitOps（Git 运维模式）治理

问题：多租户、多区域和多渠道系统如何切片 SLO（服务等级目标），又不造成指标爆炸？

口述答案：切片的目标是发现全局平均掩盖的局部用户损失，而不是穷举所有标签组合。我会先从业务承诺和故障域选择少量关键维度：租户等级或关键客户、区域、支付或物流渠道、仓、版本和业务类型。全局 SLI（服务等级指标）用于总体预算，每个关键切片设置护栏、绝对坏事件或最老未知；低流量切片报告样本量和无数据，不强行承诺高精度百分比。选择维度时要求它能解释不同责任或动作，例如单渠道异常可以隔离，单区域异常可以切换，单版本异常可以回滚；无法行动的高基数标识只保留在日志和审计下钻，不进入指标标签。告警按共同故障域聚合：同一渠道导致多个租户燃尽时，发一条主事件并附受影响清单，抑制派生实例告警。为防大租户主导全局值，定期比较事件加权和租户覆盖，两者分别回答总体事件损失与受影响客户范围。规则变更和新租户上线先影子计算标签基数、样本分布与门禁影响。最终每个切片都要有责任人、动作和退出条件；没有这些就不是有价值的 SLO（服务等级目标）切片。

追问 1：是否给每个租户一个 SLO（服务等级目标）？ 直答 1：只对合同或业务关键租户建明确护栏，其余用分层与下钻。
追问 2：高基数业务键放哪里？ 直答 2：放日志、链路和审计索引，不直接做指标标签。
追问 3：全局达标但区域失败怎么办？ 直答 3：按区域护栏处置，不能用全局预算压过局部事故。
追问 4：如何减少告警数量？ 直答 4：按渠道、区域或版本等共同故障域聚合，并附受影响对象。
详情：跨境履约的渠道隔离与恢复

问题：没有生产基线时，如何提出可信的 SLO（服务等级目标）候选而不虚构承诺？

口述答案：我会明确把所有候选数字标为 E3（演练证据），真实生产基线、客户合同和历史事故保持 E0（待核对）。方法从业务结果和失败成本开始：支付关注资金未知与重复扣款，库存关注超卖与长期占用，导出关注交付时效，IoT（物联网）关注关键漏报。先定义事件、分子、分母、窗口、排除、迟到和数据质量，再收集可获得的开发环境、压测、供应商文档和既有材料，只把它们当边界输入。使用 E3（演练证据）量级构造正常、峰值、单故障域、依赖超时和观测缺失场景，计算错误预算、燃尽速度和恢复所需时间，检查候选目标是否能在值班响应前止损、是否有足够容量与成本支撑。候选发布后先影子计算，不驱动外部承诺；积累真实分布、业务投诉、对账差异和演练结果，再由产品、业务、研发、运维与法务共同校准。输出必须写清假设、证据等级、适用范围、复审日期和触发重算条件。面试中我可以展示完整复算过程和动作设计，但不会说“线上一直达到某比例”或“提升了某比例”，除非有 E1（直接证据）支持。

追问 1：可以引用行业常见数字吗？ 直答 1：可作 E3（演练证据）参考，不能直接变成本项目承诺。
追问 2：先定目标还是先有数据？ 直答 2：先有业务风险假设和候选目标，再用影子数据迭代校准。
追问 3：压测结果能当生产目标吗？ 直答 3：不能，环境、流量结构、依赖和故障域不同。
追问 4：如何对面试官表达？ 直答 4：明确事实等级，给公式、场景和验证计划，不夸大上线事实。
详情：案例事实卡与 E3（演练证据）边界

问题：如何防止团队通过改分母、排除事件或切换窗口来“做绿”SLO（服务等级目标）？

口述答案：我会把口径当成受治理的产品，而不是看板查询语句。每个 SLI（服务等级指标）有负责人、版本、事件定义、权威分母、排除清单、迟到规则、生效日期和历史回算说明；变更必须经过业务、研发与运维评审，并在新旧版本上影子计算，列出受影响事件和错误预算差异。分母来自独立账本或对象清单，成功日志只能参与分子核验；排除规则要事前批准、可独立识别、有有效期，排除率异常本身告警。窗口同时保留滚动治理、自然周期和发布观察的明确命名，不能在结果不佳时临时换一个更好看的窗口。看板显示原始计数、未知、完整度、数据截止和口径版本，使单一百分比无法隐藏缺口。封账后的迟到修订追加新版本，不删除原事故和门禁动作。审计定期抽取原始事件手工或脚本复算，并让渠道账单、库存流水、对象存储与设备清单交叉验证。绩效不只奖励目标达标，也评价数据质量、事故发现和恢复能力，避免诱导隐瞒。若口径争议影响用户保护，先采取保守动作，再通过证据解决，而不是投票选择更绿的算法。

追问 1：谁能修改口径？ 直答 1：负责人提出，业务、研发和运维按版本化流程共同评审。
追问 2：事故后发现规则错了怎么办？ 直答 2：修订并回算，但保留原值、差异和当时采取的动作。
追问 3：如何发现分母被缩小？ 直答 3：用独立权威清单对账，并监控完整度与排除率。
追问 4：目标绑定绩效有风险吗？ 直答 4：有，应同时评价数据质量、透明度和改进闭环，降低度量博弈。
详情：稳定性目标、证据等级与迁移路线

问题：请用项目话术完整讲一次 SLI（服务等级指标）、SLO（服务等级目标）和错误预算治理方案。

口述答案：我会从业务问题讲起：跨支付、库存、导出和 IoT（物联网）的共同风险是接口返回成功却没有形成可验证业务结果，因此我先统一事件框架，不统一成功语义。每条链先落稳定业务意图和权威分母，技术尝试按意图归并；支付用渠道终态和账务守恒判好事件，库存用唯一扣减、可售量非负和预占闭环，导出用产物摘要、权限和可下载，IoT（物联网）用关键设备覆盖、新鲜度和通知回执。每个 SLI（服务等级指标）保存窗口、事件时间、确认期限、排除、迟到修订、数据完整度和版本，技术成功与业务成功分开展示。SLO（服务等级目标）先作为 E3（演练证据）候选影子运行，不宣称 SLA（服务等级协议）；错误预算将目标差距转换成发布风险，多窗口燃尽率驱动常规灰度、缩批、冻结高风险变更或止血，资金、超卖和关键漏报另设业务红线。依赖可用性不盲目相乘，端到端直接测用户路径；低流量显示样本和绝对事件，零流量不报满分。事故中先确认数据可信并冻结口径，再按业务键串联指标、链路、日志和审计，限流、回滚、查单、补偿。恢复同时验证新流量、历史积压、未知态与不变量，复盘把动作写回门禁和演练。真实阈值与收益仍需 E1（直接证据）核对，这样既能讲清方案，也不虚构生产承诺。

追问 1：方案最关键的设计是什么？ 直答 1：权威业务分母与业务终态核验，避免技术成功替代用户结果。
追问 2：最危险的失败边界是什么？ 直答 2：数据不完整、低流量误判和不变量未进入目标会制造错误安全感。
追问 3：错误预算最大的价值是什么？ 直答 3：把可靠性事实连接到发布、止血、恢复和投入决策。
追问 4：如何证明没有夸大项目？ 直答 4：所有阈值标 E3（演练证据），生产事实与效果没有证据就保持 E0（待核对）。
详情：稳定性口径、信号边界与迁移路线

SLI（服务等级指标）、SLO（服务等级目标）、错误预算与业务技术成功率

SLI（服务等级指标）、SLO（服务等级目标）、错误预算与业务技术成功率

适用边界

正式时序图

1. SLA（服务等级协议）、SLO（服务等级目标）、SLI（服务等级指标）、业务成功与技术成功分层 {#53-01-k01}

热门面试题

2. 用好事件、坏事件与可评价事件固定分子分母 {#53-01-k02}

热门面试题

3. 窗口、事件时间、处理时间与回算版本决定同一数字的含义 {#53-01-k03}

热门面试题

4. 排除规则、维护窗口、无效请求与未知态必须事前可审计 {#53-01-k04}

热门面试题

5. 数据新鲜度、完整度与口径版本是 SLI（服务等级指标）的前置 SLI（服务等级指标） {#53-01-k05}

热门面试题

6. 分位数、阈值达标率与分布要共同描述尾延迟 {#53-01-k06}

热门面试题

7. 错误预算把目标差距转换成可消费风险 {#53-01-k07}

热门面试题

8. 燃尽率与多窗口告警回答预算会多快耗尽 {#53-01-k08}

热门面试题

9. 错误预算动作表要把发布、止血、恢复与复盘连起来 {#53-01-k09}

热门面试题

10. 复合依赖要按关键路径、相关性与降级语义计算 {#53-01-k10}

热门面试题

11. 低流量、零流量与稀有高损失事件不能只看百分比 {#53-01-k11}

热门面试题

12. 支付、库存、导出与 IoT（物联网）需要不同的好事件定义 {#53-01-k12}

热门面试题

13. 从口径审计到线上排查、恢复验证与项目话术 {#53-01-k13}

热门面试题

综合题使用说明

综合题库

复习与审计清单