DevOps（开发运维一体化）可观测性、容量与故障注入高频追问

本册只编排 DevOps（开发运维一体化）失败场景、证据链、止血、修复、验证与复盘。机制统一回链 模块 32 唯一正文，项目事实等级沿用 模块 15 唯一事实账本。未经源码、配置、运行记录或业务账本证明的数字统一标为 E3（演练设计）或 E0（待核对）。

1. Docker（容器技术）与 Kubernetes（容器编排平台）资源故障边界

1.1 从容器限制到业务容量证据链

Docker（容器技术）把进程放入 namespace（命名空间）并通过 cgroup（控制组）执行资源约束，但共享宿主机内核；Kubernetes（容器编排平台）再以 requests（资源请求）参与调度、以 limits（资源上限）约束运行，并由控制器调和 Pod（容器组）副本。因而“容器还在”只证明进程边界未完全消失，不证明请求可成功、节点有余量或业务数据正确。排障必须同时看镜像与配置、Pod（容器组）状态、节点压力、应用运行时、依赖水位和业务不变量。

sequenceDiagram
    participant U as 用户请求
    participant S as Service（服务）
    participant P as Pod（容器组）
    participant C as cgroup（控制组）
    participant N as 节点
    participant B as 业务账本
    U->>S: 发起导出或支付请求
    S->>P: 路由到就绪实例
    P->>C: 申请 CPU（中央处理器）与内存
    alt 资源在安全线内
        C-->>P: 允许执行
        P->>B: 提交业务结果
        B-->>U: 返回可验证状态
    else 内存越界或 CPU（中央处理器）节流
        C-->>P: OOMKilled（容器内存杀死）或节流
        P--xB: 结果未知或未提交
        N-->>S: 端点变化与重调度
    end

图解读： 正常箭头从用户流量经过 Service（服务）进入就绪 Pod（容器组），资源账本允许执行后才提交业务结果。失败分支说明 cgroup（控制组）可以在业务提交前后终止进程，端点摘除和重调度又存在传播窗口；前提是请求标识、容器终止原因和业务提交记录可关联。结论是恢复判定必须回到导出任务、支付单或告警实例，不能停在 Pod（容器组）重新 Running（运行中）。

数据演绎 1：异步导出为什么会把“内存够用”推成重启。 E3（演练设计）假设单个导出分片平均占用 180MiB（兆字节），Pod（容器组）基础占用 420MiB（兆字节），内存 limits（资源上限）为 2GiB（吉字节），并行 10 个分片时估算峰值为 420 + 10 × 180 = 2220MiB，已超过约 2048MiB（兆字节）的边界；即使平均值未越界，压缩、序列化和网络缓冲重叠仍会提前触发 OOMKilled（容器内存杀死）。若把并行降到 7，估算为 1680MiB，再预留 20% 波动后约为 2016MiB，仍需用压测峰值校验。状态变化为“运行—内存上升—终止—任务租约超时—重领”；观测信号是容器终止原因、工作集、任务重试和重复文件；结论是并行度必须受每任务占用和故障余量共同约束。

失败注入、证据链与项目落地： E3（演练设计）分别注入内存上限降低、CPU（中央处理器）配额收紧、节点磁盘填充、就绪探针超时和单节点不可用。证据包固定变更版本、Pod（容器组）标识、节点、容器终止原因、资源曲线、应用请求号、任务或支付状态。止血先暂停灰度、隔离导出和历史 Runner（执行器）任务，为支付查单与 IoT（物联网）严重告警保留资源；修复 requests（资源请求）/limits（资源上限）、并行度、探针或临时文件生命周期；验证按 10%、30%、60%、100% 恢复，要求资源余量、错误率和业务账本同时稳定。机制为 E2（既有材料映射），生产阈值与收益为 E0（待核对）。参考 Docker（容器技术）资源约束官方文档 与 Kubernetes（容器编排平台）资源监控官方文档。

热门面试题

1. 问题（基础题）：Docker（容器技术）容器与虚拟机的故障边界有什么不同？

   • 考点：共享内核、隔离对象、资源约束与恢复边界。
   • 回答思路：先说进程隔离，再说明共享内核和业务正确性不由容器保证。
   • 详细答案：容器主要以 namespace（命名空间）隔离视图、以 cgroup（控制组）限制资源，启动快但共享宿主机内核；虚拟机通常有独立客体内核，隔离边界更厚但成本更高。两者都不能替代应用幂等、持久化和业务对账。
   • 进阶追问：容器重启成功为什么仍不能宣布恢复？
   • 进阶回答：因为重启前请求可能处于未知态，还要核对任务、支付、通知等副作用并覆盖稳定观察窗。

2. 问题（原理题）：requests（资源请求）与 limits（资源上限）分别影响什么？

   • 考点：调度账本、运行时约束、CPU（中央处理器）节流与内存终止。
   • 回答思路：区分调度承诺与运行上限，并给过小、过大的风险。
   • 详细答案：调度器主要依据 requests（资源请求）判断节点能否承载；运行时由 cgroup（控制组）执行 limits（资源上限）。CPU（中央处理器）超限通常表现为节流，内存超限可能被终止。请求过大造成资源闲置和 Pending（等待调度），请求过小又会过度装箱并放大节点争用。
   • 进阶追问：只把 limits（资源上限）调大可以解决 OOMKilled（容器内存杀死）吗？
   • 进阶回答：不一定，若并行或泄漏无界只会推迟失败，还可能扩大单实例对节点的影响面。

3. 问题（项目题）：异步导出 Pod（容器组）持续重启，如何建立证据链？

   • 考点：任务状态、资源峰值、终止原因、重复执行和文件交付。
   • 回答思路：从任务号关联 Pod（容器组）、节点、运行时和业务产物，先止血再复算并行度。
   • 详细答案：固定任务号、分片号、Pod（容器组）和节点，查上次终止原因、内存工作集、CPU（中央处理器）节流、线程栈、临时文件、对象存储请求与任务租约。止血先降低并发、暂停大任务并保留核心查询；修复流式生成、分片上限和幂等交付；最后核对一个任务只有一个有效文件且失败分片可恢复。
   • 进阶追问：队列积压下降能否证明导出恢复？
   • 进阶回答：不能，还要核对任务终态、文件摘要、下载权限、重复产物和用户可获取性。

2. Jenkins（持续集成工具）、CI/CD（持续集成/持续交付）发布与回滚

2.1 从不可变制品到灰度验证和可逆回退

Jenkins（持续集成工具）流水线应把源码版本、依赖锁定、测试结果、镜像摘要、配置版本、审批和部署记录连成同一条发布证据链，并让同一不可变制品逐环境晋级。CI/CD（持续集成/持续交付）成功只证明自动化步骤按定义执行，不证明新版本满足用户结果；Kubernetes（容器编排平台）Deployment（无状态部署）可调和副本和执行 RollingUpdate（滚动更新），但数据库结构、消息契约、缓存内容和外部副作用可能不可逆，因此回滚必须在发布前设计。

flowchart LR
    A[源码与依赖锁定] --> B[Jenkins（持续集成工具）构建和测试]
    B --> C[不可变镜像摘要与签名]
    C --> D[预发验证]
    D --> E[5% 灰度流量]
    E --> F{技术与业务门禁通过}
    F -- 是 --> G[20%、50%、100% 放量]
    F -- 否 --> H[暂停流量与保存证据]
    H --> I{制品和数据是否可逆}
    I -- 是 --> J[回退稳定版本与配置]
    I -- 否 --> K[向前修复、降级与补偿]
    J --> L[业务对账与观察窗]
    K --> L

图解读： 正常路径让同一镜像摘要从预发晋级并分档放量，每档都同时检查技术信号和支付、导出、告警等业务信号。失败路径先暂停而不是继续覆盖现场，再按数据可逆性选择回滚或向前修复；前提是旧制品、旧配置、迁移脚本和流量切换都可定位。结论是 kubectl rollout undo 只能回退工作负载模板，不能自动撤销已经写入的数据和外部调用。

数据演绎 2：滚动发布为何会在“副本没少”时容量不足。 E3（演练设计）假设稳定版本 10 个 Pod（容器组），单实例安全处理 100 req/s（每秒请求数），峰值 700 req/s（每秒请求数），原余量约 300 req/s（每秒请求数）。若 RollingUpdate（滚动更新）设置 maxUnavailable（最大不可用副本）为 2，而新版本冷启动后前 3 分钟仅能处理 40 req/s（每秒请求数），某时刻 8 个旧实例加 2 个新实例的安全能力为 8 × 100 + 2 × 40 = 880 req/s，余量降到 180；再叠加一台节点故障损失 2 个旧实例，能力变为 680，已低于峰值。观测必须包含就绪副本、单实例有效吞吐、冷启动、节点故障余量和业务成功率；结论是副本数相等不代表容量等价。

失败注入、证据链与项目落地： E3（演练设计）在灰度阶段注入新镜像启动慢、一个可用区不可用、配置版本漂移、数据库字段收缩、消息新旧消费者并存和回滚命令失败。证据固定 Git（版本控制系统）版本、Jenkins（持续集成工具）运行号、镜像摘要、配置摘要、Deployment（无状态部署）修订、流量比例和业务请求号。止血先暂停晋级、摘除异常灰度并冻结第二个变更；修复采用 expand-contract（扩展/收缩）迁移、向后兼容契约和已演练回切；验证覆盖支付回调、导出任务、Runner（执行器）租约和 IoT（物联网）严重告警。参考 Jenkins（持续集成工具）流水线官方文档 与 Kubernetes（容器编排平台）工作负载发布官方文档。

热门面试题

1. 问题（基础题）：CI/CD（持续集成/持续交付）流水线成功为什么不等于发布成功？

   • 考点：自动化边界、用户结果、业务验证与观察窗。
   • 回答思路：说明流水线只执行步骤，再补线上流量和业务不变量。
   • 详细答案：构建、测试和部署均通过，只能证明门禁覆盖范围内没有发现问题；真实流量分布、外部依赖、数据兼容和低频路径仍可能失败。发布成功应以灰度用户结果、错误预算、业务差异和稳定观察窗共同确认。
   • 进阶追问：冒烟测试通过后可以直接全量吗？
   • 进阶回答：不能，冒烟覆盖有限，应按风险和样本量分档放量，并保留自动暂停和人工回退能力。

2. 问题（原理题）：为什么数据库变更要采用 expand-contract（扩展/收缩）？

   • 考点：新旧版本共存、可逆性与数据迁移。
   • 回答思路：先扩展兼容读写，再迁移验证，最后收缩旧结构。
   • 详细答案：滚动和灰度期间新旧应用会并存，直接删除或改义字段会让旧版本失效，也使应用回滚失去数据前提。先增加兼容结构、双读写或回填并校验，再切换读路径，确认旧版本不再依赖后才收缩，可把不可逆动作延后。
   • 进阶追问：双写多久可以停止？
   • 进阶回答：需覆盖最大消息延迟、任务执行和回滚窗口，并以新旧数据对账及旧版本清零为证据。

3. 问题（项目题）：支付版本灰度后错误率升高，怎样决定回滚还是向前修复？

   • 考点：影响面、错误预算、数据可逆性和未知态。
   • 回答思路：先停放量、裁决资金事实，再按制品与数据可逆性决策。
   • 详细答案：固定版本、流量组、渠道和请求号，比较稳定组与灰度组的成功、延迟、未知态和对账差异。若问题仅在应用或配置且数据兼容，回退稳定摘要；若迁移或外部请求已不可逆，则隔离新路径、保持查单，采用向前修复和补偿。任何决定都先保护支付查询与账务对账。
   • 进阶追问：回滚后错误率恢复是否可以结案？
   • 进阶回答：不可以，还要收敛灰度期未知支付、重复回调和账务差异，并复演发布门禁。

3. 日志、指标、链路与关联取证

3.1 从 Prometheus（监控系统）、ELK（日志系统）到 SkyWalking（链路追踪系统）

日志回答“发生了哪些离散事件和上下文”，指标回答“多大范围、何时异常和趋势如何”，链路回答“一个请求跨服务的因果路径与耗时分布”。Prometheus（监控系统）适合聚合时间序列与告警，ELK（日志系统）适合结构化事件检索，SkyWalking（链路追踪系统）适合服务拓扑和慢调用定位；三者都只是证据视角，不是业务事实本身。要用 service.name（服务名称）、environment（环境）、version（版本）、request_id（请求标识）、trace_id（链路标识）和业务键建立最小关联集，同时控制指标标签基数、日志敏感数据和链路采样偏差。

flowchart TD
    A[用户失败或 SLO（服务等级目标）告警] --> B[Prometheus（监控系统）确认范围与趋势]
    B --> C[按版本、实例、接口和区域切片]
    C --> D[SkyWalking（链路追踪系统）定位慢跨度与依赖]
    D --> E[ELK（日志系统）按链路标识和业务键取事件]
    E --> F[数据库、消息与外部回执核对]
    F --> G{证据是否支持根因}
    G -- 否 --> H[保留竞争假设并补采样]
    H --> B
    G -- 是 --> I[止血、修复、验证与复盘]

图解读： 入口可以是用户反馈或服务等级告警，先用指标定范围，再用链路找因果路径，最后用日志和业务账本验证具体请求。失败分支明确“一条慢链路”不能直接代表总体根因，需要回到指标分布继续证伪；前提是三类信号的资源属性、时间和上下文一致。结论是取证顺序应从影响面到因果再到事件，而不是在海量日志里碰运气。

数据演绎 3：采样为什么会让支付慢请求“看起来不存在”。 E3（演练设计）假设 10 分钟有 1,000,000 个支付查询，整体随机采样率为 1%，其中仅有 200 个来自特定渠道的新版本请求发生超时。随机采样对该小群体的期望命中数是 200 × 1% = 2，实际可能为 0；指标仍能显示该渠道错误率上升，但链路样本可能没有慢请求。若采用 tail sampling（尾部采样）保留错误与高延迟，再对正常请求按 1% 抽样，异常证据完整度会提高，但收集器必须先承受更大的暂存与处理压力。状态变化为“请求—指标聚合—链路暂存—按结果采样—日志关联”；结论是不能用“链路里没搜到”证明故障未发生。

失败注入、证据链与项目落地： E3（演练设计）分别注入日志采集器背压、Prometheus（监控系统）抓取失败、SkyWalking（链路追踪系统）收集端丢弃、异步线程上下文断裂和时间漂移。证据保存采集端队列、丢弃计数、抓取状态、采样配置、链路传播字段、日志位点和业务账本。止血先保护用户结果指标与错误链路，降低调试日志和高基数标签，禁止把监控故障误判为业务恢复；修复结构化关联、缓冲与采样门禁；验证以同一导出任务、支付请求、Runner（执行器）任务和 IoT（物联网）告警实例贯穿三信号。参考 OpenTelemetry（开放遥测标准）信号官方文档、Apache SkyWalking（链路追踪系统）官方概览 与 Elastic（搜索与日志平台）结构化日志官方文档。

热门面试题

1. 问题（基础题）：日志、指标和链路各解决什么问题？

   • 考点：信号边界、关联关系与业务事实。
   • 回答思路：用范围、事件和因果三个关键词回答，再强调交叉验证。
   • 详细答案：指标适合发现影响范围和趋势，日志保留离散事件及上下文，链路展现单请求跨组件的因果和耗时。任何单一信号都可能因采集、聚合或采样失真，最终还要与数据库、消息、外部回执和业务状态核对。
   • 进阶追问：有完整链路后还需要日志吗？
   • 进阶回答：需要，链路通常不承载完整业务事件、审计字段和异常细节，且采样会遗漏请求。

2. 问题（原理题）：为什么 trace_id（链路标识）不适合作为 Prometheus（监控系统）标签？

   • 考点：时间序列基数、内存与查询成本。
   • 回答思路：说明每请求唯一值会持续创建新序列，再给 exemplar（示例关联）或日志跳转方案。
   • 详细答案：trace_id（链路标识）几乎每个请求都不同，放入指标标签会让时间序列数量随请求增长，放大内存、存储、抓取和查询成本。指标保留低基数维度，单请求关联应使用日志、链路或 exemplar（示例关联）。
   • 进阶追问：用户标识能否放入指标标签？
   • 进阶回答：通常不能，既有高基数和隐私风险；应按受控业务分群聚合，个体取证走权限化日志。

3. 问题（项目题）：支付投诉“成功页很慢”，怎样用三信号定位？

   • 考点：用户口径、版本切片、跨服务因果和资金核验。
   • 回答思路：指标定范围，链路找瓶颈，日志与账本裁决结果。
   • 详细答案：先按渠道、版本、区域和接口查看成功率与尾延迟，确认是全局还是灰度组；再从错误或高延迟样本进入链路，定位网关、支付服务、账务或渠道跨度；最后按 trace_id（链路标识）和支付请求号查结构化日志、支付单、分录和渠道回执。结果未知时先查单，不能因页面超时直接重试扣款。
   • 进阶追问：链路显示渠道耗时最高就能认定渠道是根因吗？
   • 进阶回答：不能，还要比较正常基线、调用超时设置、重试放大和渠道原始回执，排除上游排队与采样偏差。

4. SLO（服务等级目标）、错误预算与容量复算

4.1 从用户结果到发布门禁和故障余量

SLI（服务等级指标）必须从用户可观察结果定义，例如“支付请求在时限内得到确定结果”“导出在承诺时间内交付可下载文件”“严重告警在时限内创建告警实例”，而不是只看进程存活。SLO（服务等级目标）给定时间窗内的目标，error budget（错误预算）等于总事件可容忍的坏事件额度，用于约束发布速度与稳定性投入。容量则回答在峰值、增长、发布和一个故障域失效时，系统是否仍能守住该目标。

flowchart LR
    A[业务好事件与总事件] --> B[计算 SLI（服务等级指标）]
    B --> C[比较 SLO（服务等级目标）]
    C --> D[计算错误预算与燃烧率]
    D --> E{预算是否健康}
    E -- 是 --> F[允许受控发布与实验]
    E -- 否 --> G[冻结高风险变更]
    F --> H[峰值、增长、发布、故障容量复算]
    G --> H
    H --> I[限流、扩容、降级或修复]
    I --> A

图解读： 控制环从业务事件而非主机指标开始，错误预算决定变更风险，容量复算决定系统在降级状态下能否继续满足目标。正常路径允许受控创新，失败路径冻结高风险变更并把资源转向可靠性；前提是好事件口径可审计且排除测试流量。结论是错误预算不是允许随意失败的配额，而是发布与稳定性的反馈控制量。

数据演绎 4：错误预算与容量如何共同阻止一次危险发布。 E3（演练设计）假设支付查询 30 天有 10,000,000 次，SLO（服务等级目标）为 99.95%，允许坏事件 10,000,000 × 0.05% = 5,000 次；前 10 天已发生 3,500 次，剩余预算 1,500 次。灰度 20 分钟产生 300 次坏事件，若按当前速率持续 2 小时将新增约 1,800 次并耗尽预算，应立即暂停。容量侧峰值 1,200 req/s（每秒请求数），三可用区各安全 500 req/s（每秒请求数），失去一区后仅剩 1,000，已经低于峰值；即使平均错误率尚可，也不能继续全量。输入、公式、燃烧率和故障域余量必须同时进入门禁。

失败注入、证据链与项目落地： E3（演练设计）注入峰值翻倍、单可用区失效、依赖延迟增加、自动扩容冷启动和历史任务抢占。证据保存 SLI（服务等级指标）查询、排除规则、预算窗口、实际成功吞吐、队列年龄、连接池和业务差异。止血优先压低导出与历史 Runner（执行器）流量，为支付确定性和 IoT（物联网）严重告警保留预算；修复容量模型、隔离和自动扩容指标；验证用故障后安全能力而非正常峰值宣告余量。参考 Google SRE（站点可靠性工程）错误预算策略 与 Google SRE（站点可靠性工程）监控实践。

热门面试题

1. 问题（基础题）：SLI（服务等级指标）、SLO（服务等级目标）和 SLA（服务等级协议）有什么区别？

   • 考点：测量、内部目标与外部承诺。
   • 回答思路：分别回答“测什么、目标多少、违约如何”。
   • 详细答案：SLI（服务等级指标）是对用户结果的量化测量，SLO（服务等级目标）是团队在时间窗内希望达到的内部目标，SLA（服务等级协议）是对外合同及违约责任。工程上通常让内部目标严于外部承诺并保留响应余量。
   • 进阶追问：主机可用率能直接作为支付 SLI（服务等级指标）吗？
   • 进阶回答：不能，它只能解释资源状态；支付应以确定结果、时限和资金正确性定义用户结果。

2. 问题（原理题）：错误预算如何影响发布决策？

   • 考点：燃烧率、多窗口告警和风险控制。
   • 回答思路：用剩余额度和消耗速度决定继续、暂停或冻结。
   • 详细答案：预算健康时允许在门禁内发布和实验；短窗高燃烧率提示快速事故，长窗持续燃烧提示慢性退化。预算接近耗尽时应暂停非必要高风险变更，把资源用于修复、容量和自动化，而不是把预算当成故意失败额度。
   • 进阶追问：一次事故没有耗尽预算就不用复盘吗？
   • 进阶回答：不对，若单次影响大、暴露系统性风险或证据链断裂，仍应复盘并跟踪行动项。

3. 问题（项目题）：IoT（物联网）告警风暴来临前怎样复算容量？

   • 考点：峰值、语义聚合、故障余量和通知配额。
   • 回答思路：拆接入、规则、实例、通知四层，按最窄瓶颈计算。
   • 详细答案：用设备事件峰值、重复率、聚合比例、单事件服务时间估算各层并发，再检查消息、数据库、规则线程和通知渠道的安全吞吐；扣除一个故障域和发布冷启动后仍应保住严重、首次、升级与恢复事件。普通重复可以有证据聚合，严重事实不可无记录丢弃。
   • 进阶追问：HPA（水平自动扩缩容）能否替代容量规划？
   • 进阶回答：不能，扩容有采样、调度和启动延迟，也受节点、数据库与外部渠道上限约束。

5. 告警风暴、灰度回滚与故障注入

5.1 从症状告警到有停止条件的实验

告警风暴通常不是“故障很多”这么简单，而是同一根因被实例、接口、区域和依赖维度重复展开，再叠加阈值抖动、重试和通知失败。Prometheus（监控系统）负责规则求值，Alertmanager（告警管理器）负责分组、抑制、静默和路由；治理目标是让值班人员收到可行动的用户症状和根因线索，而不是把真实严重事件静默掉。故障注入则在受控范围内验证探测、隔离、回滚和业务恢复，必须先定义稳态、影响面、停止条件、回滚负责人和数据校验。

flowchart TD
    A[故障或注入触发] --> B[用户症状告警]
    B --> C[按服务、区域和事故键分组]
    C --> D[抑制下游重复与维护静默]
    D --> E[值班确认影响面]
    E --> F{停止条件触发}
    F -- 是 --> G[终止注入、回滚或隔离]
    F -- 否 --> H[继续观察稳态与业务不变量]
    G --> I[验证告警、流量和数据恢复]
    H --> I
    I --> J[复演与规则优化]

图解读： 正常路径从用户症状进入事故分组，再由值班人员确认影响；故障注入不会绕过真实告警链。失败分支在错误预算、核心业务或观测链越界时立即终止并回滚；前提是停止动作不依赖已故障的同一控制面。结论是静默只用于已知维护或重复噪声，不能把没有解决的严重用户影响隐藏掉。

数据演绎 5：一场节点故障怎样放大成 2,400 条通知。 E3（演练设计）假设一个节点承载 80 个 Pod（容器组），每个 Pod（容器组）对 5 个接口各有错误率、延迟、实例存活 3 类规则，理论触发 80 × 5 × 3 = 1,200 条；若两条通知路由重复发送，就是 2,400 条。按 cluster + service + region + incident_class 分组后，可形成 1 条主事故、若干服务摘要，并抑制明确由节点不可用解释的实例告警，但支付错误预算和 IoT（物联网）严重告警送达仍独立保留。观测信号是触发数、分组数、抑制数、通知成功、确认时间和真实用户影响，不能仅以通知减少量评价治理。

失败注入、证据链与项目落地： E3（演练设计）依次注入单 Pod（容器组）终止、节点不可用、网络延迟、ELK（日志系统）采集暂停、SkyWalking（链路追踪系统）采样丢失和通知渠道限流。每次只改变一个主变量，目标限定到测试租户或灰度组；错误预算快速燃烧、支付分录不平、严重告警缺失或回滚控制面不可用时立即停止。止血先保护症状告警与备用通知，修复规则依赖、分组和操作手册；验证要求原始事件可追溯、通知压缩可解释、业务状态闭环。参考 Prometheus（监控系统）告警官方实践 与 Chaos Mesh（混沌工程平台）实验官方文档。

热门面试题

1. 问题（基础题）：告警分组、抑制和静默有什么区别？

   • 考点：通知聚合、因果依赖和计划维护。
   • 回答思路：分别说明是否保留原告警、由谁解释、何时到期。
   • 详细答案：分组把多条相关告警合成通知但保留成员；抑制在上游告警成立时暂不通知被解释的下游告警；静默按标签和时间主动屏蔽通知，适用于已审批维护。三者都不能删除原始证据或改变业务事实。
   • 进阶追问：告警风暴时能否先全局静默？
   • 进阶回答：不应全局静默，应保留用户症状、核心业务和备用渠道，只对已确认重复且有到期时间的范围静默。

2. 问题（原理题）：故障注入为什么必须先定义稳态和停止条件？

   • 考点：可证伪实验、影响控制与恢复门禁。
   • 回答思路：稳态决定比较基线，停止条件限制风险。
   • 详细答案：没有稳态就无法判断注入是否破坏目标，没有停止条件就可能把验证变成事故。稳态应包含用户 SLI（服务等级指标）、资源水位和业务不变量；停止条件要绑定影响范围、预算、数据风险和控制面可用性，并具备独立终止动作。
   • 进阶追问：注入结束后指标恢复就算通过吗？
   • 进阶回答：不算，还要核对未知请求、重复任务、资金和告警实例，并验证原故障可重复、操作手册可执行。

3. 问题（项目题）：IoT（物联网）报警风暴如何降噪但不漏严重告警？

   • 考点：语义聚合、优先级隔离、通知配额和守恒。
   • 回答思路：拆原始事件、告警实例和通知任务，保留关键状态迁移。
   • 详细答案：同设备同规则的一次触发到恢复建立一个告警实例，普通重复聚合次数、峰值和持续时间；严重、首次、升级、恢复及人工确认独立保留，并使用独立队列、线程和通知配额。任何采样或聚合都要记录输入数和输出摘要，恢复后核对实例、回执与工单。
   • 进阶追问：通知成功是否证明严重告警未丢？
   • 进阶回答：不能，还要核对原始严重事件、告警实例、升级链、人工确认和恢复闭环。

6. 事故 SOP（标准操作流程）、业务恢复与复盘

6.1 从止血到导出、支付、Runner（执行器）与 IoT（物联网）验收

事故 SOP（标准操作流程）要把技术排障变成可协作的状态机：先分级并指定 Incident Commander（事故指挥官），再明确影响、冻结无关变更、保全证据、选择可逆止血、修复根因、分档恢复、业务对账和 postmortem（事故复盘）。指挥、操作、沟通和记录应分工，避免多人同时改系统。告警恢复只是技术信号，真正结束事故还要证明导出交付唯一、支付账务平衡、Runner（执行器）任务不重不漏、IoT（物联网）严重告警闭环。

stateDiagram-v2
    [*] --> Detecting: 告警或用户反馈
    Detecting --> Declared: 确认影响并分级
    Declared --> Mitigating: 冻结变更、止血与沟通
    Mitigating --> Repairing: 根因修复或回退
    Repairing --> Validating: 分档放量与业务对账
    Validating --> Mitigating: 指标反弹或差异扩大
    Validating --> Reviewing: 观察窗通过
    Reviewing --> Rehearsing: 行动项完成后复演
    Rehearsing --> [*]: 证据闭环

图解读： 状态只能在有证据时推进，验证失败必须回到止血而不是强行结案。正常路径包括观察窗、业务对账和复演；失败路径保留回退能力。前提是每次操作有负责人、时间戳、变更内容和预期信号。结论是“根因找到”不是结束，行动项必须可验证并在后续演练中证明有效。

数据演绎 6：技术恢复后仍有 37 个业务未知态如何收口。 E3（演练设计）假设故障窗收到 20,000 个请求，成功账本 19,920 个，明确失败 43 个，剩余 20,000 - 19,920 - 43 = 37 个 Unknown（未知）请求。支付未知态要按原请求号查询渠道并核对分录；导出未知态核对任务、对象摘要和交付记录；Runner（执行器）未知态核对租约、栅栏令牌和业务幂等；IoT（物联网）未知态核对原始严重事件、告警实例和通知回执。只有当 37 个全部归入成功、明确失败、幂等命中、合法补偿或人工有责任人待裁决，守恒等式成立，才能宣布业务恢复。

事故沟通、验证与复盘： E2（既有材料映射）建议每 15 分钟同步影响、止血、风险和下一节点，真实频率由组织约定核对。复盘区分 trigger（触发因素）与根本原因，记录发现延迟、错误止血、观测缺口和恢复瓶颈；行动项必须绑定负责人、期限、成功指标和验证方式。E1（直接证据）只来自原始日志、指标、链路、配置、业务账本和演练输出，文档推断本身不升级为生产事实。参考 Google SRE（站点可靠性工程）事故响应 与 Google SRE（站点可靠性工程）事故复盘文化。

热门面试题

1. 问题（基础题）：事故处理中为什么要设置统一指挥角色？

   • 考点：决策收敛、并发操作、沟通与记录。
   • 回答思路：说明统一优先级和授权，不等于指挥官亲自排查所有技术问题。
   • 详细答案：统一指挥角色负责分级、目标、授权、资源调度和状态推进，技术负责人并行验证假设，沟通负责人同步外部信息，记录人维护时间线。这样可避免多人同时变更、信息冲突和局部优化扩大事故。
   • 进阶追问：最资深工程师一定要做指挥官吗？
   • 进阶回答：不一定，角色需要全局协调和决策能力；最熟悉组件的人可能更适合作为技术负责人。

2. 问题（原理题）：告警恢复与业务恢复为什么必须分开？

   • 考点：聚合信号、异步副作用、未知态与对账。
   • 回答思路：指出指标回落只表示当前流量改善，历史请求仍可能未收敛。
   • 详细答案：告警通常基于时间窗和聚合指标，恢复时旧请求可能仍在重试、队列、外部渠道或数据库事务边界中。必须按故障窗请求守恒，核对成功、失败、幂等、补偿和未知态，才能证明没有静默丢失或重复副作用。
   • 进阶追问：观察窗应该多长？
   • 进阶回答：至少覆盖关键流量周期、最大重试和异步延迟，并结合业务对账周期，不能套固定分钟数。

3. 问题（项目题）：如何做一份有行动力的事故复盘？

   • 考点：无责文化、事实时间线、系统改进与验证闭环。
   • 回答思路：先写影响和证据，再区分触发与根因，最后把改进变成可验证任务。
   • 详细答案：复盘记录影响、时间线、发现方式、触发、根因、有效与无效动作、沟通和证据缺口，不用个人失误替代系统分析。行动项覆盖预防、发现、止血和恢复，绑定负责人、期限、指标和复演场景；没有验证结果的任务不能算关闭。
   • 进阶追问：如何避免复盘变成“加强监控”？
   • 进阶回答：把表述改成具体 SLI（服务等级指标）、阈值、路由、操作手册、自动门禁和演练验收，并明确失败时谁行动。

7. 综合口述题

纯口述统计口径： 每题从 口述答案 字段冒号后的首字符统计到首个 追问 1 之前，移除 Markdown（标记语言）标记、链接与全部空白；硬性范围 570—900 个有效字符。每题配置 4 组追问直答和至少一个真实相对 Markdown（标记语言）详情链接。

1. 问题：异步导出容器频繁 OOMKilled（容器内存杀死），你怎样止血、修复并证明没有重复交付？

   • 考点：容器内存、任务状态机、幂等交付、容量复算与业务验收。
   • 回答思路：先固定任务和容器证据，降低并行止血，再按单任务成本复算并核对产物。
   • 详细答案：不能只把内存上限调大；要关联终止原因、任务租约、分片、对象摘要和交付记录，避免重启后重复生成或覆盖。
   • 进阶追问：容器恢复运行后能否恢复全量并发？
   • 进阶回答：不能，应按实测单任务峰值、节点余量和下游能力阶梯恢复。
   • 口述答案：我先固定导出任务号、分片号、镜像摘要、配置版本、Pod（容器组）、节点和故障时间窗，暂停大任务与自动重试，避免重启风暴继续占满节点。证据先看 Kubernetes（容器编排平台）上次终止原因、事件、内存工作集、CPU（中央处理器）节流和节点压力，再看 JVM（Java 虚拟机）堆外内存、线程、临时文件、对象存储请求和任务租约，判断是单分片过大、并发叠加、泄漏还是探针误杀。止血优先降低分片并行、暂停低优先级导出，为在线交易和支付查单保留资源；已开始任务保持处理中，不直接标失败。修复采用流式读取和写出、分片上限、临时文件生命周期、租约加栅栏令牌以及“任务号加产物版本”的唯一交付，旧执行器即使复活也不能覆盖新结果。容量按基础内存、单任务峰值、并行数和至少 20% 波动余量复算，并用故障压测校验。恢复先放少量任务，逐档观察终止、最老任务、生成耗时、对象摘要和下载成功。还要验证取消与完成竞争、对象上传成功但任务提交失败、下载链接已签发后重试等边界，确保补偿不会删除仍被引用的文件。最后按“请求数等于成功交付、明确失败、取消、合法幂等和人工待裁决”守恒，确保一个任务只有一个有效文件、权限和过期时间正确，再复演提交前后终止。机制为 E2（既有材料映射），真实峰值和收益无原始记录时保持 E0（待核对）。 另外要保存每次任务裁决的操作者、依据与对象版本，便于证明恢复不是人工覆盖。
   • 追问 1：只看 JVM（Java 虚拟机）堆够吗？ 直接回答：不够，还要看堆外、线程栈、文件缓存、临时文件和容器工作集。
   • 追问 2：重启后为何可能重复交付？ 直接回答：旧任务可能已上传但未提交终态，新执行器重领后再次上传，需栅栏与唯一版本。
   • 追问 3：怎样选择分片大小？ 直接回答：用峰值内存、处理时限、失败重做成本和对象存储吞吐压测决定。
   • 追问 4：何时宣布恢复？ 直接回答：资源稳定、积压下降、产物唯一、下载可用且故障窗任务全部裁决后。
   • 对应详细章节：Docker（容器技术）资源治理

2. 问题：Kubernetes（容器编排平台）发布后大量 Pod（容器组）Pending（等待调度）和 CrashLoopBackOff（崩溃循环退避），怎样定位？

   • 考点：调度、资源、配置、探针、启动失败与发布关联。
   • 回答思路：先按状态分流，再用修订版本、事件和业务影响串起证据。
   • 详细答案：Pending（等待调度）与启动后崩溃是不同失败窗口，前者先查调度约束，后者先查容器终止和应用启动。
   • 进阶追问：可以直接删除所有异常 Pod（容器组）吗？
   • 进阶回答：不能，先保留样本和事件；批量删除可能丢现场并放大镜像、配置或依赖压力。
   • 口述答案：我先冻结继续发布，按 Deployment（无状态部署）修订、命名空间、节点和时间把异常分成“从未调度”和“已启动后崩溃”。对 Pending（等待调度）查看调度事件、requests（资源请求）、节点可分配量、污点容忍、亲和规则、拓扑、卷区域和镜像架构，确认是资源账本不足还是约束无解；对 CrashLoopBackOff（崩溃循环退避）保存一个样本的当前与上次日志、退出码、OOMKilled（容器内存杀死）、配置和密钥挂载、启动/就绪/存活探针、依赖连接及端口冲突。再比较稳定修订和新修订的镜像摘要、环境变量、ServiceAccount（服务账户）与配置差异，并用 Prometheus（监控系统）确认用户错误率和有效就绪容量。止血选择可逆动作：若新修订独有且旧版本兼容，暂停并回退；若节点容量不足，先限流、释放非关键 Runner（执行器）和导出，再受控扩容；若探针误杀，先摘流后修阈值，不能关掉健康检查掩盖启动失败。恢复按副本、单实例安全吞吐和单故障域余量分档，验证端点传播、连接排空和业务请求。还应模拟一次节点驱逐与镜像仓库变慢，确认恢复不依赖偶然缓存，且 PDB（Pod 中断预算）和拓扑分布没有把副本集中到同一故障域。最终核对支付未知态、导出任务和严重告警，而不是只看 Pod（容器组）变绿。机制为 E2（既有材料映射），生产版本和影响保持 E0（待核对）。
   • 追问 1：Pending（等待调度）时先看什么？ 直接回答：先看调度事件和节点资源账本，再看亲和、污点、拓扑与卷约束。
   • 追问 2：探针失败一定是应用坏了吗？ 直接回答：不一定，也可能是阈值、依赖、网络或冷启动不匹配，需要与应用成功率交叉验证。
   • 追问 3：回滚后仍有崩溃怎么办？ 直接回答：说明可能是共享配置、节点或依赖问题，应停止反复回滚并转向共同故障域。
   • 追问 4：副本恢复就够了吗？ 直接回答：不够，还要有效吞吐、错误预算、业务未知态和故障余量恢复。
   • 对应详细章节：Kubernetes（容器编排平台）生命周期与排障

3. 问题：Jenkins（持续集成工具）显示流水线成功，但线上版本、配置与预期不一致，怎样排查供应链证据？

   • 考点：流水线即代码、不可变制品、晋级、配置漂移与审计。
   • 回答思路：从源码到运行实例逐跳比对摘要，不用任务绿色替代部署事实。
   • 详细答案：成功状态只表示已定义步骤返回成功；若使用可变标签、环境重建或人工改配置，运行态仍会漂移。
   • 进阶追问：重新跑一遍流水线能解决吗？
   • 进阶回答：先定位漂移，否则重跑可能覆盖证据、重复迁移并扩大影响。
   • 口述答案：我先冻结后续晋级和人工改动，固定源码版本、Jenkins（持续集成工具）运行号、参数、Agent（代理节点）、依赖锁文件、测试报告、制品摘要、镜像签名、配置版本、审批人和 Kubernetes（容器编排平台）修订。然后按“源码到构建、构建到仓库、仓库到部署清单、清单到运行容器”逐跳比对摘要，确认是不是可变镜像标签被覆盖、缓存污染、不同环境重新构建、配置中心动态覆盖、GitOps（Git 运维模式）调和滞后或有人绕过流水线修改。止血不直接重跑，而是暂停流量变更，保留控制台、制品元数据和审计事件；若运行制品不可信，回退到已签名且验证过的摘要。修复要求一次构建、多环境晋级，镜像按摘要引用，配置与数据库迁移独立版本化，流水线记录部署前后实际摘要并在不一致时失败。对密钥只留版本和注入证据，不把明文写入日志。验证用独立读取接口确认每个 Pod（容器组）的版本、配置摘要和依赖契约，再做小流量业务探针和回滚演练。还要清理或隔离受污染缓存，用全新 Agent（代理节点）重复构建并比对摘要，确认可复现性；紧急旁路权限完成后立即回收并复核审计。最终将“期望摘要等于仓库摘要等于运行摘要”纳入门禁，并审计所有旁路权限。机制为 E2（既有材料映射），真实漂移原因必须由运行记录升级为 E1（直接证据）。 还要在仓库不可用、缓存清空和凭据轮换场景下重复构建，确认流水线会明确失败而不是降级使用来源不明的制品。
   • 追问 1：镜像标签为什么不够？ 直接回答：标签可被重新指向，摘要才是内容寻址的不可变身份。
   • 追问 2：同一源码为何会构建出不同制品？ 直接回答：依赖、基础镜像、时间、缓存和构建环境未锁定都会改变输出。
   • 追问 3：动态配置如何纳入审计？ 直接回答：记录配置版本、目标范围、审批、发布时间和实例实际加载摘要。
   • 追问 4：怎样防止人工旁路？ 直接回答：最小权限、职责分离、准入策略和漂移检测共同约束，并保留紧急操作审计。
   • 对应详细章节：Jenkins（持续集成工具）与 CI/CD（持续集成/持续交付）

4. 问题：支付服务 Canary（灰度发布）错误率升高，如何设计自动暂停、回滚和资金校验？

   • 考点：灰度分群、对照、错误预算、可逆性和支付未知态。
   • 回答思路：先保证分群可比和资金查询，再由技术与业务双门禁决定动作。
   • 详细答案：错误率上升要先排除渠道和样本偏差；回滚应用前还要判断数据库、消息和外部请求是否兼容可逆。
   • 进阶追问：灰度样本很少时如何决策？
   • 进阶回答：使用最小样本、绝对严重事件门禁和更长观察窗，资金不变量越界可不等统计显著性。
   • 口述答案：我先固定稳定组和灰度组的版本、配置、区域、渠道、用户分群和时间窗，确认路由稳定且没有把高风险渠道只分给灰度。门禁同时看支付确定结果率、尾延迟、Unknown（未知）数量、回调验签失败、账务分录和平衡差异，并用错误预算的短窗燃烧率做快速暂停；单笔重复扣款或分录不平属于绝对停止条件。暂停后保存请求号、trace_id（链路标识）、渠道流水、支付单和分录，关闭自动放量与无预算重试，保留查单和对账能力。若故障只在应用或配置且数据库采用 expand-contract（扩展/收缩）、消息向后兼容，就把流量切回稳定摘要；若新结构已收缩、外部副作用已发生或旧版本无法读新数据，则不能盲目回滚，应隔离写路径、保持查询，采用向前修复和补偿。恢复先逐笔裁决灰度窗 Unknown（未知），再按 5%、20%、50%、100% 放量，每档比较稳定组并覆盖一个渠道回调周期。若灰度样本不足，就使用绝对资金事件、贝叶斯先验或延长观察窗辅助判断，但资金不变量越界不等待统计显著。还要核对回切时连接排空和重试是否把旧请求送到新旧两组，避免版本回退后重复副作用。最终对账渠道成功、支付单、平衡分录和订单状态，复演回执丢失、重复回调与回滚失败。机制为 E2（既有材料映射），真实金额和效果保持 E0（待核对）。 发布记录还要保存每档样本量、决策人、回切耗时与未通过门禁，供复盘判断规则是过松还是过紧。
   • 追问 1：HTTP（超文本传输协议）成功率够吗？ 直接回答：不够，支付要看确定结果、金额币种、分录和渠道事实。
   • 追问 2：何时必须立即停灰度？ 直接回答：资金不平、重复扣款、未知态快速增长或错误预算高燃烧时。
   • 追问 3：回滚会不会重复处理回调？ 直接回答：会重投或重复到达，所以旧版本也必须兼容事件并按支付请求号幂等。
   • 追问 4：怎样证明回滚有效？ 直接回答：不仅错误率回落，还要灰度窗未知态收敛、四方对账平衡并覆盖观察周期。
   • 对应详细章节：配置、发布与回滚

5. 问题：线上用户报错但 ELK（日志系统）查不到日志，怎样避免把“无日志”误判为“无故障”？

   • 考点：采集链、结构化日志、轮转、背压、保留和业务交叉验证。
   • 回答思路：先验证请求事实，再逐段检查产生、采集、传输、索引和查询。
   • 详细答案：日志缺失可能发生在应用未写、容器终止、采集位点、解析、索引、权限或查询时间窗，不能直接否定用户证据。
   • 进阶追问：临时把日志级别开到调试可以吗？
   • 进阶回答：要限定实例、请求和时长，评估敏感数据与磁盘，避免调试日志反过来压垮系统。
   • 口述答案：我先把用户时间、账号范围、请求号、业务键、入口返回和数据库状态固定下来，用网关指标、支付单或任务记录确认请求是否真实到达，而不是先在 Kibana（日志分析界面）里盲搜。然后沿日志链逐段取证：应用是否执行到记录点，标准输出是否在容器终止前刷出，采集器是否发现文件和正确维护 offset（偏移量），轮转与 multiline（多行）是否造成截断，缓冲队列是否背压或丢弃，Logstash（日志处理工具）解析是否进入死信，Elasticsearch（搜索引擎）映射、索引、时间戳、保留策略和权限是否让文档不可见。同步检查采集器自身指标和 Kubernetes（容器编排平台）事件，并用 SkyWalking（链路追踪系统）和 Prometheus（监控系统）确认同时间窗是否存在错误或慢请求。止血时保护错误和审计日志，限制调试噪声，必要时把代表实例摘流并保全本地文件；不能重启全部实例清空现场。修复统一结构化字段、时钟、trace_id（链路标识）、业务键、轮转策略、背压与死信告警，并对敏感字段脱敏。验证主动发起带已知请求号的成功和失败样本，要求产生、采集、索引、查询和业务结果全链可见，同时模拟采集暂停后补传。再用连续样本序号核对输入、采集、索引、死信和缺口，确认恢复不是只对新日志有效。结论保持“日志是证据之一”，缺日志的真实原因未证实时标 E0（待核对）。
   • 追问 1：查不到 trace_id（链路标识）说明请求没到吗？ 直接回答：不能，可能上下文未传播、日志未写或采集链丢失，要用入口和业务事实交叉验证。
   • 追问 2：采集器恢复后日志一定补齐吗？ 直接回答：取决于原文件、位点、缓冲和保留是否仍在，必须按序号或样本核对缺口。
   • 追问 3：时间戳为何会误导查询？ 直接回答：事件时间、采集时间、索引时间和时区可能不同，应保存多时间字段并校时。
   • 追问 4：如何证明没有静默丢日志？ 直接回答：用输入序号、采集位点、输出计数、死信和代表请求端到端核对。
   • 对应详细章节：ELK（日志系统）日志治理

6. 问题：Prometheus（监控系统）标签基数暴涨并拖慢查询，如何止血和修复？

   • 考点：时间序列基数、标签治理、抓取、存储和业务观测连续性。
   • 回答思路：先找增长标签与发布来源，保住核心 SLI（服务等级指标），再修指标模型。
   • 详细答案：请求号、用户号或设备号进入标签会让序列随流量增长；删除数据前要先保护故障窗证据和核心规则。
   • 进阶追问：增加内存能否解决？
   • 进阶回答：只能延后故障，无法改变无界基数和查询成本，必须修正标签设计。
   • 口述答案：我先冻结最近的指标和采集配置变更，确认 Prometheus（监控系统）实例、抓取目标、Head（头部）序列数、内存、WAL（预写日志）、查询延迟和规则求值是否同时恶化，再按指标名、服务、版本和标签值数量找增长来源。重点排查 request_id（请求标识）、trace_id（链路标识）、用户、设备、订单、异常全文或 URL（统一资源定位符）等无界值是否被放进标签，也检查服务发现和 relabel（重标记）是否重复生成目标。止血先停止问题指标的产生或在采集端丢弃无界标签，暂停高成本临时查询和非关键规则，为支付 SLI（服务等级指标）、容量和严重告警保留资源；不能直接删除全部时间序列或重启而丢故障证据。修复把高维明细迁到日志和链路，指标只保留服务、接口模板、结果、区域等低基数维度，常用聚合用 Recording Rule（记录规则）预计算，并为每个指标定义所有者、基数预算和上线检查。恢复前用离线样本验证查询语义没有改变，再观察序列增长斜率、抓取时长、规则延迟和告警连续性。业务侧用支付成功、导出交付和严重告警好事件核对核心 SLI（服务等级指标）未断档。最后注入一组非法高基数标签，要求准入门禁拒绝或在预算越界前告警。机制为 E2（既有材料映射），生产序列规模保持 E0（待核对）。 还要确认丢弃问题标签没有改变业务聚合分母、告警语义和历史连续性，避免技术容量恢复却让 SLI（服务等级指标）失真。
   • 追问 1：为什么 trace_id（链路标识）不能做标签？ 直接回答：它近乎每请求唯一，会持续创建新序列并放大内存、存储和查询成本。
   • 追问 2：高维数据放哪里？ 直接回答：放结构化日志或链路，指标通过 exemplar（示例关联）跳转到代表样本。
   • 追问 3：Recording Rule（记录规则）能消除源基数吗？ 直接回答：不能，它降低重复查询成本，源指标仍需治理和保留策略。
   • 追问 4：如何防复发？ 直接回答：代码审查、基数预算、预发样本、上线增量监测和指标所有者共同门禁。
   • 对应详细章节：Prometheus（监控系统）指标治理

7. 问题：SkyWalking（链路追踪系统）拓扑显示某依赖慢，但日志和指标不一致，怎样裁决？

   • 考点：采样偏差、上下文传播、时间对齐、聚合与单样本边界。
   • 回答思路：先确认链路完整性和代表性，再与同维度指标、日志和业务结果交叉验证。
   • 详细答案：一条慢跨度只能证明该样本的观察结果，不能自动证明总体根因或依赖责任。
   • 进阶追问：链路采样率提高到 100% 可以吗？
   • 进阶回答：短时限定范围可以评估，但要防收集器、网络和存储过载，并保护敏感数据。
   • 口述答案：我先固定服务、端点、版本、实例、区域和时间窗，查看这条 Trace（链路追踪）是否包含完整父子 Span（跨度）、是否跨线程和 MQ（消息队列）正确传播、客户端与服务端跨度是否配对，以及采样策略有没有只保留错误或慢请求。随后在 Prometheus（监控系统）中用相同版本、接口和依赖维度比较请求量、错误率、Histogram（直方图）分位数、线程池和连接池，确认慢是总体趋势还是少量尾部；再按 trace_id（链路标识）和业务键到 ELK（日志系统）核对排队、重试、超时、请求参数摘要和外部回执。若链路显示依赖耗时高，但服务端指标正常，竞争假设包括客户端连接等待、网络、DNS（域名系统）、重试合并、时钟漂移或跨度埋点范围错误，不能直接归责下游。止血依据用户影响而非工具结论，必要时限制重试、隔离灰度版本或降级非关键调用。修复上下文传播、统一资源属性和时钟，采用错误与高延迟优先的 tail sampling（尾部采样），同时给收集器设置队列、背压和丢弃告警。验证用已知慢点和已知正常请求产生可重复样本，要求指标范围、链路因果、日志事件和业务结果一致。机制为 E2（既有材料映射），单样本推断不能升级为生产根因。 同时统计采样前后的错误保留率、收集器丢弃、队列水位和存储成本，防止为补证据而扩大采样后制造新的观测事故；最后用对照请求再次证伪依赖假设。 所有结论都要保留采样配置版本与查询时间窗。
   • 追问 1：一条慢链路可以定根因吗？ 直接回答：不能，只能形成假设，还要看总体分布、对照组和业务证据。
   • 追问 2：上下文断裂怎么发现？ 直接回答：同业务键出现多个根链路、父子关系缺失，且异步边界日志没有传播字段。
   • 追问 3：客户端跨度慢而服务端快说明什么？ 直接回答：可能是连接、网络、排队、重试或时钟问题，需继续分解。
   • 追问 4：采样后如何保留错误？ 直接回答：可使用尾部策略优先保留错误和高延迟，同时监控收集端压力和丢弃。
   • 对应详细章节：OpenTelemetry（开放遥测标准）与 SkyWalking（链路追踪系统）

8. 问题：一个月 SLO（服务等级目标）为 99.95%，错误预算快速燃烧时你如何调整发布与稳定性工作？

   • 考点：好事件、预算、燃烧率、多窗口和变更策略。
   • 回答思路：先验证口径，再用剩余预算和消耗速度做风险决策。
   • 详细答案：预算不是惩罚机制；它让团队在可靠性受威胁时有客观依据暂停高风险变更。
   • 进阶追问：预算耗尽是否所有发布都禁止？
   • 进阶回答：通常冻结非必要风险变更，但安全修复、事故止血和降低风险的变更需走专门审批。
   • 口述答案：我先验证 SLI（服务等级指标）是否真从用户好事件和总事件计算，测试流量、客户端取消、渠道未知态和重复请求的归类是否正确，避免口径变化制造假燃烧。然后同时看短窗与长窗燃烧率：短窗高值代表需要立即响应的快速事故，长窗持续高值说明慢性退化；把剩余坏事件额度换算成当前速率下还能支撑多久，并按版本、区域、渠道和接口切片。止血先暂停正在放量的高风险发布和故障实验，冻结无关配置，保留安全修复、支付查单、严重告警与事故操作所需变更通道。技术负责人处理主因，产品与业务确认哪些降级仍满足承诺，例如暂停低优先级导出或延迟报表，不能把资金未知态算成成功。修复后不是预算瞬间归零，而是在滚动窗口中通过稳定好事件逐步恢复，因此发布恢复要按门禁和观察窗进行。复盘要检查目标是否可行动、告警是否提前、容量是否含故障余量、依赖是否被错误纳入免责范围，并把行动项绑定下一次发布或演练。机制和公式为 E2/E3（既有材料映射/演练设计），真实预算与事故数据需要 E1（直接证据）。 发布恢复前还要模拟短窗高燃烧和长窗低燃烧，验证路由、分级、自动暂停与人工审批；若发现坏事件被误分类，必须回算历史窗口并公开修正，不能悄悄改分母。预算政策还要说明依赖故障、计划维护和测试流量如何归类，确保团队不会通过改口径规避可靠性工作。 每次例外放行都记录风险接受人、到期时间和撤销条件，避免临时政策永久化。
   • 追问 1：错误预算等于允许失败次数吗？ 直接回答：它是风险控制量，不是鼓励用完的失败配额。
   • 追问 2：为什么需要多窗口？ 直接回答：短窗捕捉快速事故，长窗避免瞬时噪声并识别持续退化。
   • 追问 3：依赖故障是否不消耗预算？ 直接回答：若用户结果受损通常仍应记录，责任与预算政策可另行定义但不能隐藏影响。
   • 追问 4：预算恢复后立即全量发布吗？ 直接回答：不能，要先验证根因、容量和门禁，再阶梯恢复变更速度。
   • 对应详细章节：SLO（服务等级目标）与错误预算

9. 问题：流量预计翻倍且要求单可用区故障仍可服务，怎样做容量复算？

   • 考点：到达率、服务时间、并发、最窄瓶颈、故障余量和敏感性。
   • 回答思路：从业务峰值逐层换算资源需求，扣除故障域后再验证。
   • 详细答案：不能只按 CPU（中央处理器）平均利用率扩实例，数据库、消息、连接、存储和外部配额可能更早到拐点。
   • 进阶追问：压测达到目标吞吐就够吗？
   • 进阶回答：不够，还要覆盖尾延迟、错误、数据正确性、单区故障、冷启动和恢复流量。
   • 口述答案：我先把“翻倍”落到可复算输入：当前与目标峰值到达率、请求组合、单请求大小、平均和尾部服务时间、读写比例、缓存命中、异步比例、增长周期与 SLO（服务等级目标）。用 Little’s Law（利特尔法则）近似并发等于到达率乘服务时间，再逐层计算应用实例、线程池、数据库连接、消息分区、磁盘输入输出、网络和外部渠道配额，所有容量采用业务成功率而不是领取率。然后扣除最大单可用区：三等分区域不能按总能力除以三后仍假设全在，剩余两区必须在安全利用率内承载目标峰值，还要预留发布 maxUnavailable（最大不可用副本）、冷启动、重试和历史积压恢复。建立敏感性表，分别把服务时间增加 30%、缓存命中下降、单区失效和外部限流代入，找最早越界的瓶颈。压测从单组件到端到端，固定数据规模和请求分布，验证尾延迟、错误预算、锁、连接和业务账本；故障阶段主动下掉一区并观察 HPA（水平自动扩缩容）与节点扩容延迟。最终输出容量上限、触发扩容阈值、限流降级顺序、成本和撤销条件。公式为 E3（演练设计），生产参数必须由监控和压测记录核对。 验证报告还要列出测试与生产的数据热度、缓存预热、观测开销和网络差异，并对最敏感输入上下浮动 20% 重算。上线后持续比较预测与实际，偏差越界就降低流量上限并回校模型，不能把一次压测峰值永久当承诺容量。 成本预算也要与可靠性余量一同评审，不能只追求资源利用率。
   • 追问 1：为什么用成功吞吐？ 直接回答：领取或入口吞吐可能包含失败和重试，不能代表业务完成能力。
   • 追问 2：安全利用率设多少？ 直接回答：由排队拐点、故障恢复和成本压测确定，不能套固定百分比。
   • 追问 3：自动扩容为何仍需预留？ 直接回答：指标采样、调度、拉镜像和冷启动都有延迟，下游也未必能同步扩容。
   • 追问 4：如何验算恢复时间？ 直接回答：剩余积压除以安全成功处理率减实时流，并扣除再次失败和暂停时间。
   • 对应详细章节：容量与事故项目案例

10. 问题：IoT（物联网）告警风暴触发数千通知，怎样治理告警风暴并证明严重告警未丢？

• 考点：症状告警、分组抑制、语义聚合、优先级隔离和业务闭环。
• 回答思路：先保严重事实与通知能力，再压缩可解释重复并做守恒。
• 详细答案：通知减少不是成功标准，必须保留原事件、告警实例、升级、恢复和人工确认链。
• 进阶追问：把阈值调高能否快速降噪？
• 进阶回答：可能漏掉真实影响，应先按事故键分组和根因抑制，阈值变更需用历史回放验证。
• 口述答案：我先把指标触发、告警实例和通知任务分开统计，固定设备、规则版本、严重级别、实例号、区域和时间窗，确认是同一根因被多维展开、阈值抖动、重试放大还是通知渠道失败。止血时保留用户症状、严重、首次、升级、恢复和人工确认，使用独立队列、消费者、连接池与备用通知；普通重复按设备加规则加一次触发到恢复的实例聚合为次数、峰值和持续时间。Prometheus（监控系统）规则使用持续时间和恢复滞后减少抖动，Alertmanager（告警管理器）按事故键分组，在上游根因成立时抑制可解释下游，静默只用于有审批和到期时间的维护范围。任何聚合都记录原始输入数、实例数、被抑制数、通知成功和失败，不能捕获后丢弃。修复根因后，历史普通通知以摘要限速发送，实时严重流始终优先；渠道 Unknown（未知）按原请求号查回执。验证注入节点故障、重复事件、渠道限流和恢复乱序，核对原始严重事件、告警实例、通知回执、工单和恢复终态，并证明压缩数量可解释。机制为 E2（既有材料映射），生产设备量和降噪收益无原始账本时保持 E0（待核对）。 规则上线前还要回放一段已知历史流量，对比治理前后的触发、分组、抑制、确认和漏报；备用渠道同样验证限额与幂等，防止主渠道恢复后双重通知。值班确认时间下降只能作为辅助效果，严重事件完整率和业务闭环才是硬门禁。 每条静默必须自动到期并有责任人复核，防止恢复后继续漏通知。
• 追问 1：分组会不会丢告警？ 直接回答：分组只合并通知，原告警成员和标签仍应可查询。
• 追问 2：抑制何时解除？ 直接回答：上游告警恢复后重新求值，下游若仍异常必须重新通知。
• 追问 3：普通重复可以直接丢吗？ 直接回答：应做有输入计数和摘要的语义聚合，无证据删除不允许。
• 追问 4：通知成功为何不等于闭环？ 直接回答：还要确认告警实例、升级、人工响应、工单和恢复状态。
• 对应详细章节：Prometheus（监控系统）告警风暴治理

11. 问题：请设计一次 Kubernetes（容器编排平台）单节点故障注入，并说明停止条件和验收。

• 考点：稳态假设、爆炸半径、控制面、故障余量、业务不变量和复演。
• 回答思路：先限定对象和基线，再单变量注入，按技术与业务双门禁停止和验收。
• 详细答案：故障注入不是随机删 Pod（容器组）；必须有负责人、审批、独立终止路径、数据快照和可复算预期。
• 进阶追问：可以直接在生产执行吗？
• 进阶回答：优先隔离或影子环境；生产需先通过低风险演练、限定租户和流量，并具备自动停止。
• 口述答案：我先选择无状态但能代表真实依赖的灰度服务，所有量级标 E3（演练设计），记录节点、Pod（容器组）分布、PDB（Pod 中断预算）、亲和规则、当前峰值、单实例安全吞吐、错误预算和业务样本。稳态定义为请求成功与尾延迟达标、剩余两区容量有余量、支付未知态不增长、严重告警链可用；停止条件包括错误预算快速燃烧、核心业务不变量越界、剩余容量低于峰值、观测链失效或删除实验对象无法恢复。执行前指定 Incident Commander（事故指挥官）、操作者、记录人和回滚人，确认终止动作不依赖目标节点，并冻结其他发布。注入只改变一个主变量，先终止一个普通 Pod（容器组），再让目标节点不可用，保存事件、端点传播、调度、拉镜像、探针、流量、连接排空和业务请求。若触发停止条件立即删除实验、隔离节点或回切流量。验证不以副本恢复为止，还要看调和时间、错误预算、单区余量、未知请求、重复任务和业务账本。最后恢复节点，覆盖稳定观察窗，复演操作手册，并把发现延迟、错误动作和容量缺口变成有负责人、期限和再次演练条件的行动项。原始演练输出可作为 E1（直接证据），方案本身仍是 E3（演练设计）。 实验报告保存目标选择器、参数、控制器事件、开始结束时间和人工动作；若实际影响与预测不同，先修模型再扩大范围。下一轮才叠加网络延迟或依赖故障，单点结论未稳定前不做组合故障，避免无法判断因果。
• 追问 1：为什么先终止单 Pod（容器组）？ 直接回答：先验证探测和恢复最小闭环，再扩大到节点故障，便于隔离变量。
• 追问 2：PDB（Pod 中断预算）能防节点故障吗？ 直接回答：它主要约束自愿中断，不能阻止非自愿节点故障，仍需副本和故障域分布。
• 追问 3：停止条件由谁执行？ 直接回答：自动门禁优先，Incident Commander（事故指挥官）有人工立即终止权限。
• 追问 4：演练成功标准是什么？ 直接回答：故障被及时发现、影响受控、业务不变量守住、恢复可重复且行动项可验证。
• 对应详细章节：事故、演练与项目案例

12. 问题：线上事故同时出现错误率、延迟和队列积压，你如何组织 SOP（标准操作流程）？

• 考点：事故指挥、影响定界、竞争假设、可逆止血、沟通和验证。
• 回答思路：先统一指挥与用户影响，再并行取证，单线决策止血并用业务守恒结案。
• 详细答案：三种现象可能同源也可能互相放大，不能每个团队各自扩容、重启和回滚。
• 进阶追问：最先做回滚还是扩容？
• 进阶回答：由变更关联、可逆性和最窄瓶颈决定，先执行影响最小且可验证的止血动作。
• 口述答案：我先声明事故、分级并指定 Incident Commander（事故指挥官），把技术排障、操作、沟通和记录分开；冻结无关发布、自动扩容改参和历史回放，避免多人同时改变系统。影响定界以用户结果为准：哪些版本、区域、渠道、接口和业务键受影响，支付是否出现 Unknown（未知），导出与 Runner（执行器）最老任务多大，IoT（物联网）严重告警是否仍送达。技术组建立竞争假设：新版本变慢、数据库连接或锁饱和、消费者重试放大、单节点故障、外部依赖限流；用 Prometheus（监控系统）定范围、SkyWalking（链路追踪系统）看因果、ELK（日志系统）取事件，再和数据库、消息和外部回执交叉。止血选择可逆动作，可能是暂停灰度、限制重试、隔离历史流、降级非关键功能或回退稳定摘要，并一次只改一个主变量。每次记录操作者、时间、预期和实际信号，固定节奏同步影响与风险。修复后按 10%、30%、60%、100% 放量，要求错误、尾延迟、积压年龄和下游水位稳定。最后按故障窗请求守恒，裁决成功、失败、幂等、补偿和未知态，覆盖完整业务周期后复盘，不能用队列清空替代业务恢复。 对暂时无法裁决的请求建立责任人、期限和查询证据，事故可结束响应阶段但不能抹去业务债务。复盘重放时间线，验证告警是否先于用户、止血是否可逆、沟通是否一致，并把最慢恢复环节变成下一次演练目标。
• 追问 1：为何要冻结自动扩容改参？ 直接回答：它会改变证据和负载，可能把下游饱和放大；需纳入统一决策。
• 追问 2：如何避免沟通拖慢修复？ 直接回答：独立沟通角色按固定模板同步，技术人员只提供事实和下一节点。
• 追问 3：什么时候升级事故等级？ 直接回答：影响面、持续时间、数据风险、预算燃烧或恢复不确定性越界时。
• 追问 4：何时结束事故？ 直接回答：用户影响停止、业务差异收敛、观察窗稳定且后续责任人明确后。
• 对应详细章节：事故响应与复盘

13. 问题：应用已经回滚，错误率也下降，但支付与导出仍有数据差异，怎样恢复？

• 考点：回滚边界、历史副作用、未知态、补偿和对账。
• 回答思路：先承认制品回滚不撤销数据，再按业务键逐类裁决并用新动作补偿。
• 详细答案：回滚只恢复运行代码与部分配置，数据库写入、消息、外部调用和对象文件不会自动倒带。
• 进阶追问：能否回滚数据库到故障前快照？
• 进阶回答：在线交易通常不能全库倒回，否则会丢失故障后合法数据；应按业务记录修复和补偿。
• 口述答案：我先把“错误率下降”只视为当前流量止血成功，固定灰度起止、版本、配置、数据库迁移、消息位点和外部调用窗口，建立受影响业务键清单。支付按渠道流水、支付单、账务请求号和分录裁决：渠道成功但本地未推进要补事件，分录重复要由唯一键吸收，结果 Unknown（未知）按原请求号查单，不能换号重扣；任何修正使用新的补记或冲正动作关联原单，不改写历史。导出按任务、分片、租约、对象摘要和交付版本核对：已上传未提交的对象先隔离，重复执行只能有一个有效产物，取消与完成竞争按状态机裁决。再检查回滚版本是否仍能读取新字段和消费新消息，若不能就保留兼容层或用向前修复，不强行缩表。恢复时暂停自动全量重放，先代表样本影子验证，再按批次限速处理，每批计算“受影响数等于成功、明确失败、幂等命中、补偿完成和人工待裁决”，并监控再次失败。业务差异归零或进入有负责人和期限的人工裁决后，覆盖渠道对账、文件下载和消息最大延迟观察窗，再复演应用回滚与数据补偿。机制为 E2（既有材料映射），真实差异量保持 E0（待核对）。 还要防止补偿与迟到原事件竞争：补偿动作使用独立唯一键和更高业务版本，迟到事件只能补证据，不能把已裁决状态倒退。每批保存前后摘要和审批，差异扩大就暂停；最终把不可逆迁移、消息兼容与业务查证纳入发布门禁。 人工裁决也必须双人复核、记录依据，并能从原单追到补偿单和最终余额。
• 追问 1：回滚为何不撤销消息？ 直接回答：消息已由独立系统持久化和投递，应用版本变化不会自动回收历史事件。
• 追问 2：补偿为何用新动作？ 直接回答：保留原事实和审计链，避免篡改历史并支持补偿自身幂等。
• 追问 3：导出孤儿文件怎么处理？ 直接回答：先按任务和摘要隔离，确认无有效引用后按审计策略清理。
• 追问 4：差异暂时无法裁决怎么办？ 直接回答：保持 Unknown（未知），分配责任人和截止时间，禁止猜测成功或失败。
• 对应详细章节：配置发布与不可逆边界

14. 问题：Runner（执行器）扩容后重复执行、积压和告警同时出现，怎样定位并安全恢复？

• 考点：租约、栅栏令牌、有效吞吐、资源隔离、告警关联和业务幂等。
• 回答思路：区分领取与成功，沿任务代次和租约取证，再限制并发和历史流。
• 详细答案：扩执行器可能超过数据库、外部依赖或分区能力，旧租约执行器复活还会造成重复副作用。
• 进阶追问：把队列消费者再翻倍可以吗？
• 进阶回答：先找最窄瓶颈；若成功吞吐不升、重试和连接等待上升，继续扩容只会恶化。
• 口述答案：我先固定任务号、分片、调度版本、Runner（执行器）实例、领取代次、租约、Fencing Token（栅栏令牌）、开始结束时间和业务幂等键，区分“重复领取但被拒绝”“重复执行但无副作用”和“真实重复写入”。同时把生产率、领取率、成功率、重试率、最老任务年龄、线程池、数据库连接、锁、外部限流和节点资源对齐，判断扩容是否跨过下游拐点。止血先停止继续扩容和立即重试，暂停报表与历史回放，为支付补偿和严重告警保留独立资源；失租执行器立刻停止提交，新执行器的更高栅栏令牌必须被资源端校验。修复租约续期、失租中断、任务状态条件更新和业务唯一键，外部调用使用稳定请求号并对 Unknown（未知）结果先查询。容量按成功处理率减实时到达率计算积压恢复，历史流只使用剩余余量。告警按任务类型、依赖和事故键分组，不能把重复执行告警静默掉。恢复先少量任务，逐档观察成功吞吐、重试放大、最老年龄和下游水位，每批核对输入任务等于成功、幂等、合法取消、再次失败和人工待查。最后注入失租、进程重启和数据库变慢，证明旧执行器无法越权提交。机制为 E2（既有材料映射），生产规模为 E0（待核对）。 还要模拟调度中心短暂不可用和时钟漂移，确认租约判断使用可靠时间语义、资源端始终以栅栏令牌裁决。复盘比较扩容前后成功吞吐、重试成本与恢复时间，若有效能力没有提升就回退并修最窄瓶颈。 任务优先级调整同样保留审计。
• 追问 1：租约为何还要栅栏令牌？ 直接回答：旧执行器可能暂停后复活，只有资源端拒绝旧令牌才能阻止迟到提交。
• 追问 2：领取率升高为何不是好事？ 直接回答：领取可能转成失败和重试，应看业务成功率与下游水位。
• 追问 3：任务幂等键怎么选？ 直接回答：选择稳定业务意图，如任务号加分片与动作版本，而不是执行实例号。
• 追问 4：积压清空如何验收？ 直接回答：还要业务结果唯一、未知态收敛、下游有余量且故障复演通过。
• 对应详细章节：SLO（服务等级目标）、容量与项目案例

15. 问题：请完整串讲一次“发布导致支付抖动并触发告警风暴”的证据链、止血、修复、验证和复盘。

• 考点：发布审计、三信号、错误预算、容量、回滚、业务对账和复盘闭环。
• 回答思路：用变更和用户结果定界，竞争假设取证，按可逆性止血，最终以资金不变量收口。
• 详细答案：完整回答必须覆盖制品与配置、流量组、指标日志链路、依赖容量、未知态、回滚边界和行动项复演。
• 进阶追问：最容易犯的错误是什么？
• 进阶回答：看到时间相关就立即认定发布根因并全局回滚，忽略共享依赖、数据不可逆和未知支付。
• 口述答案：我先声明事故并冻结第二个变更，固定 Jenkins（持续集成工具）运行号、镜像与配置摘要、Kubernetes（容器编排平台）修订、灰度分群、渠道和时间窗，以支付确定结果、Unknown（未知）、分录平衡和错误预算定义影响。Prometheus（监控系统）比较稳定与灰度的请求、错误、尾延迟、连接和重试，SkyWalking（链路追踪系统）定位排队或渠道跨度，ELK（日志系统）按 trace_id（链路标识）和支付请求号取事件，再与渠道回执、支付单和分录交叉；同时检查告警是否因实例维度、阈值抖动和通知重试形成风暴。若证据支持新版本且数据兼容，暂停灰度并回切稳定摘要；若外部副作用或数据库收缩不可逆，则隔离新写入、保持查单，向前修复和补偿。告警侧保留用户症状与资金不变量，按事故键分组并抑制可解释的实例噪声，不全局静默。修复后先裁决故障窗 Unknown（未知），再按 5%、20%、50%、100% 放量，每档检查燃烧率、容量余量和四方对账。复盘区分触发与根因，记录发现延迟、错误动作、采样和回滚缺口；行动项落到不可变制品、兼容迁移、灰度门禁、告警路由和故障注入，并由下一次演练验证。事实按 E1（直接证据）至 E0（待核对）表达，不把时间相关性当因果。 每次决策都保存证据与反例，验证自动暂停是否早于人工发现、备用通知是否可达、回滚后的数据补偿是否可重复；没有原始复演输出的行动项不标完成，也不把一次时间相关性写成生产根因。
• 追问 1：如何证明是发布而不是渠道？ 直接回答：用稳定/灰度对照、版本切片、渠道分层和回切后的可重复变化共同证伪。
• 追问 2：为何不能全局静默告警？ 直接回答：会隐藏支付真实影响，应只聚合重复并保留症状和资金告警。
• 追问 3：回滚成功后先做什么？ 直接回答：裁决灰度窗 Unknown（未知）并做渠道、支付单、分录和订单四方对账。
• 追问 4：复盘如何验收？ 直接回答：行动项有负责人、期限、指标和复演结果，且原故障门禁能自动阻断。
• 对应详细章节：DevOps（开发运维一体化）综合题库

8. 复习与现场表达清单

• 能区分 Docker（容器技术）隔离、Kubernetes（容器编排平台）调和与业务正确性的边界。
• 能从源码、Jenkins（持续集成工具）运行、制品摘要、配置版本一路核对到运行实例。
• 能说明 RollingUpdate（滚动更新）、Canary（灰度发布）、Blue-Green（蓝绿发布）和向前修复的适用边界。
• 能按指标定范围、链路找因果、日志取事件、业务账本裁决的顺序排障。
• 能用 SLI（服务等级指标）、SLO（服务等级目标）、错误预算燃烧率和故障域余量控制发布。
• 能用到达率、服务时间、成功吞吐和实时流复算并发、积压与恢复时间。
• 能区分告警分组、抑制和静默，并用业务闭环证明告警风暴治理没有漏报。
• 能为故障注入写稳态、范围、停止条件、独立终止、数据校验和复演标准。
• 能按“现象—假设—证据—止血—修复—验证—复盘”组织事故 SOP（标准操作流程）。
• 能把异步导出、支付、Runner（执行器）和 IoT（物联网）分别落到可验证业务不变量。
• 能区分 E1（直接证据）、E2（既有材料映射）、E3（演练设计）和 E0（待核对），不把建议方案表述为生产事实。