SRE 与可观测性¶

指标、日志、链路和持续剖析分别解决什么问题，如何关联起来？¶

技术说明

SRE¹ 可观测实践中，指标适合回答“是否异常、影响多大”，时间序列可低成本聚合并驱动告警；日志保留离散事件和上下文，适合解释“发生了什么”；分布式链路以 trace/span² 描述一次请求跨服务的因果路径；持续剖析³按栈帧聚合 CPU、内存等资源消耗，回答“代码把资源花在哪里”。四者不是彼此替代：指标会丢失个体细节，日志缺少天然调用拓扑，尾采样会遗漏部分链路，剖析通常不携带单次请求的完整语义。

关联的关键是统一资源属性与传播标识，例如 service.name、环境、区域、版本、trace_id 和部署变更 ID。告警从 SLI⁴ 指标进入，通过 exemplar⁵ 跳到慢请求 trace，再用 span 的 trace ID 查询结构化日志，最后按同一版本和时间窗查看 profile。边界是避免把用户 ID、订单号作为指标标签造成基数爆炸；敏感字段须在采集端删除或脱敏，并对各信号分别制定留存、采样和访问策略。

实践经验

某支付 API 的 p99 突增但错误率正常。指标将异常限定在新版本和一个可用区；exemplar 指向数条慢 trace，显示下游正常而应用内 span 空白较长；同时间窗口日志出现 GC pause，profile 又显示 JSON 反序列化分配陡升。团队先将该区流量降权并回滚，再修复对象复用。若只扩容会暂时缓解却掩盖回归，因此长期增加版本维度的资源 SLI、发布标记和内存 profile 回归门禁，同时约束标签预算。

面试回答要点

如何设计 Prometheus 指标，避免标签基数和语义失控？¶

技术说明

Prometheus⁶ 指标应先按问题选择类型：Counter 只增不减，适合请求数并用 rate()；Gauge 表示可升降瞬时值；Histogram 在采集端按桶累计，能跨实例聚合分位数；Summary 的客户端分位数一般不能正确跨实例合并。名称应含单位和后缀，如 _seconds、_bytes_total，标签值必须来自有限集合。HTTP 指标通常保留方法、规范化路由、状态类别，不放原始 URL、trace ID、邮箱或异常全文。

基数近似为各标签取值数的乘积，还要乘实例、环境和副本数。设计评审应给每个指标设置 series 预算，优先通过 /api/v1/status/tsdb 或在离线数据上运行 promtool tsdb analyze 找大户。count by (__name__)({__name__=~".+"}) 会扫描广泛序列，在已发生基数事故的大实例上可能进一步压垮查询；只能在受控窗口配合超时、并发和扫描限制使用。采集端 relabel 只保留需要的目标和标签，recording rule 预计算常用聚合；删除标签会破坏排障维度，保留过多则耗内存、磁盘与查询 CPU，因此需用 exemplar 承载高基数跳转信息。

实践经验

某网关把完整 path 和租户 ID 放入 http_requests_total，促销时活跃序列暴涨，Prometheus 内存逼近限制且规则评估延迟。证据来自 head series、每指标 series 数和 WAL 增长，而非笼统归因“监控太重”。团队先用 metric relabel 丢弃问题标签并暂停非关键规则，保留原始日志用于取证；随后改用路由模板、租户等级和状态类别，对重点租户通过日志/trace 查询。副作用是临时失去逐租户实时图表，因此增加受控的 top-K 业务指标。

面试回答要点

怎样写可靠的 PromQL 和告警规则？¶

技术说明

PromQL⁷ 查询先明确分子、分母、标签集合和时间窗。例如错误率可写为按服务聚合的错误请求速率除以全部请求速率，并用 clamp_min 或条件保护零流量；直方图分位数必须对 le 保留聚合维度后调用 histogram_quantile。Counter 用 rate/increase 处理重启，不能直接相减；聚合前应确认 on()、ignoring()、group_left 的连接基数，避免静默丢序列或多对多错误。

告警应表达用户症状或即将耗尽的资源，不把每个瞬时尖峰变成页面。规则包含持续时间 for、必要时 keep_firing_for、严重度、owner、runbook、仪表盘链接和影响描述；用单元测试固定边界输入，通过规则评估耗时、missed iterations 和通知链路监控告警系统本身。无数据与零值语义必须显式处理，但 or vector(0) 可能掩盖采集故障，需单独监控 target 健康。

实践经验

一次错误率规则按 status 聚合分子、按 service 聚合分母，向量匹配失败后仪表盘显示空白且没有告警。工程师通过规则 API、表达式分步执行和合成故障确认不是“无错误”，随后统一聚合标签并添加规则测试。止血期间用日志错误率和入口负载均衡指标旁证。长期将查询模板纳入代码评审，并为告警增加“数据缺失”伴随信号；代价是规则数量和测试维护增加，但避免静默失效。

面试回答要点

生产级日志平台应如何设计？¶

技术说明

应用输出结构化事件到 stdout 或本地可靠通道，采集器补充 Kubernetes/主机元数据，经过解析、脱敏、过滤和缓冲后写入日志后端。字段应稳定：时间戳、级别、服务、版本、事件名、trace ID、错误类型和业务结果；异常栈作为字段而非拼接多行。采集路径要考虑背压、磁盘缓冲、重试、重复与乱序，at-least-once 常意味着查询端按事件 ID 去重，而不是承诺不丢且不重。

索引只放常用且低基数字段，正文进压缩对象存储或列式后端；按热、温、冷分层设置留存。敏感数据在源端或边缘处理，访问按租户和职责授权，并记录查询审计。还要监控采集延迟、丢弃数、解析失败、队列深度、每服务字节率与查询扫描量。调高日志级别可能引发 I/O 和费用事故，动态调试必须有范围、时限和自动恢复。

实践经验

某 Java 服务在异常重试时每次打印完整请求体和堆栈，节点磁盘写满，日志采集延迟 40 分钟。证据链包括容器字节率、采集器队列、磁盘 inode/容量和同一 event ID 的重复次数。团队先限流问题日志、缩短动态 DEBUG 窗口并扩展缓冲，而没有直接删除取证数据；随后改成聚合计数、首次异常样本和 trace 跳转，加入 PII 检测与每服务日志预算。副作用是少量逐次细节丢失，以采样日志和审计开关补足。

面试回答要点

分布式追踪中的上下文传播与采样如何设计？¶

技术说明

入口创建 trace，上下文通过标准头在 HTTP、RPC 和消息元数据中传播；每个 span 记录父子关系、时间、状态和必要属性。异步队列可能不是严格父子关系，应使用 span link 表示一个批次关联多个生产事件。必须防止把不可信外部 baggage 原样传播，限制大小、字段白名单和跳数；跨信任域重新校验，避免 PII 泄漏与头部放大。

头部采样在请求开始时决定，成本低但看不到最终错误；尾部采样在 Collector 收齐 trace 后按错误、延迟、关键租户等策略保留，诊断价值高但需要内存、等待时间和一致路由。组合策略可保留全部错误和高延迟、少量正常基线，并对采样率做权重修正。要监控 orphan span、传播失败、export queue、丢弃、决策延迟和每服务 span 率。

实践经验

订单异步化后，入口 trace 在发布消息处结束，消费者故障无法关联。团队从消息头、消费者日志与 orphan span 比例确认传播库未注入，而非误判 broker 延迟。先以订单事件 ID 在日志中手工关联并提高错误采样，随后统一消息 instrumentation、使用 link 表达批处理关系，并让尾采样保留失败链路。增加属性会提升带宽和敏感信息风险，因此建立属性白名单及采样预算。

面试回答要点

持续剖析如何用于生产性能诊断？¶

技术说明

持续剖析周期性采样调用栈，按服务、实例、版本和时间聚合，可观测 CPU、wall time、分配、堆、锁等待等不同 profile。火焰图的宽度代表样本占比，不等于单次调用耗时；CPU profile 看不到阻塞原因，wall/lock profile 又可能采样开销更高。应选择适合运行时的采样器，先在预生产测开销，再以低频率、限定事件种类部署。

诊断应比较基线而非只看一张火焰图：新旧版本差分、异常区与正常区对照、单位请求 CPU/分配量，并与吞吐、GC、限流和 trace 时间对齐。符号化需要可匹配的构建 ID 和调试信息，源码映射受严格访问控制。profile 可能暴露函数参数或动态代码信息，需明确采集范围、留存和租户隔离。

实践经验

某 Go API CPU 使用率升高但流量未变，扩容后成本继续增长。按版本比较的 CPU profile 显示正则编译热点，分配 profile 同时上升；trace 证明下游延迟无变化。团队先回滚并临时扩容保护延迟，再把正则预编译、增加基准测试与“每千请求 CPU 秒”发布门禁。剖析自身约有可测开销，所以没有长期启用全部 profile 类型，而是常驻低频 CPU/内存、按审批短时开启锁剖析。

面试回答要点

OpenTelemetry Collector 的生产架构与处理流水线怎么设计？¶

技术说明

OpenTelemetry Collector⁸ 流水线由 receiver、processor、exporter 组成，extension 提供健康检查、认证等能力。常见部署是节点/Pod 旁的 agent 收主机和本地信号，区域 gateway 做批处理、尾采样、路由与统一出口；不是所有场景都要两层。memory_limiter 应位于前部，batch 提升吞吐，resource/attributes processor 规范属性，queued retry 与持久队列缓冲后端短暂故障。

容量按每秒 spans/points/log bytes、平均事件大小、峰值倍数和后端延迟估算。尾采样要求同一 trace 到同一决策实例，可用一致性路由；队列不是无限保险，磁盘满仍会丢。Collector 自身需暴露接收、拒绝、排队、重试、导出失败、内存和 CPU 指标，配置做 schema 校验、灰度和回滚。TLS/mTLS、凭证轮换、出口白名单和敏感属性删除应在设计内。

实践经验

可观测后端维护时，区域 Collector 内存持续上涨并被 OOM，应用导出也开始超时。证据显示 exporter 重试队列无上限、memory limiter 未生效，且应用使用同步导出。团队先禁用非关键日志管道、限制队列并将应用改为有界异步导出；后续启用持久队列、分层网关、容量压测和丢弃告警。持久队列增加磁盘 I/O，且只能覆盖计划内中断，因此还明确各信号的降级优先级。

面试回答要点

如何渐进式落地 OpenTelemetry，而不造成双重上报和语义混乱？¶

技术说明

迁移先盘点现有 SDK、agent、日志采集和指标命名，确定资源属性约定与语义版本，再选择一个低风险服务验证。可先通过 Collector 接收现有 Prometheus/Jaeger/OTLP 信号，随后按服务逐步启用自动埋点，再为关键业务补手工 span/metric。自动埋点能快速覆盖框架调用，但不能替代业务边界，且版本升级可能改变属性名或 span 数量。

双写阶段要给新旧数据打来源标签，以请求数、错误率、延迟直方图和 trace 完整率对账；设明确截止时间，避免永久支付两套成本。Metrics temporality、直方图边界、单位和资源到指标标签的映射必须验证。SDK 导出应有超时与有界队列，遥测失败不能阻塞业务；敏感属性、采样和 collector 端变换需通过契约测试。

实践经验

某团队同时启用旧 APM agent 和 OTel Java agent，HTTP 请求被重复计数，告警错误率分母翻倍。通过进程启动参数、span 名称和 exporter 流量确认双埋点，而不是业务请求增长。先关闭一组自动 instrumentation 并标记数据源，重算 SLI；长期建立 instrumentation 清单、金丝雀对账和语义约定版本。迁移期间仪表盘同时展示两套口径会增加认知负担，因此限定双写窗口并逐项签收。

面试回答要点

如何为服务选择真正面向用户的 SLI？¶

技术说明

SLI 是对用户体验的定量观察，常写成 good events / valid events。请求型服务可按成功率、低于阈值的延迟比例、正确性或新鲜度衡量；流处理可用按时处理比例和端到端滞后；批处理关注在截止时间前正确完成。测量点越靠近用户越真实，但入口只能看到传输结果，无法识别业务错误；因此常组合边缘指标与服务端业务事件，并明确排除健康检查、内部流量及用户取消。

先画关键用户旅程，按价值和失败模式选少数 SLI；阈值应来自用户需求与历史分布，而非把 p99 随意写成目标。低流量服务要考虑统计不稳定，可延长窗口或用合成探测补充。SLI 规格须包含事件定义、数据源、查询、延迟、缺失数据处理、owner 和版本，且用日志样本定期校验分子分母。

实践经验

某文件处理平台以 API 200 率作为唯一 SLI，实际大量任务入队成功却在六小时后过期。投诉上升而 SLO 仍为绿色。团队从任务状态表、队列年龄和完成时间证实测量点错误，先对超期任务扩容重跑并通知客户；随后改为“截止时间前产出正确文件”的业务 SLI，API 可用性仅作诊断指标。新 SLI 反馈较慢，因此另设队列年龄领先告警，但不把它冒充用户结果。

面试回答要点

如何制定 SLO、窗口和误差预算？¶

技术说明

SLO⁹ 是在指定窗口内对 SLI 的目标，例如 28 天内 99.9% 有效请求成功；允许失败比例形成误差预算。目标不应默认 100%，而由用户容忍、依赖上限、历史基线和改进成本共同确定。滚动窗口反映持续当前状态，适合运营；日历窗口便于合同或月度报告，但月初重置会产生行为扭曲。多类用户旅程可有不同目标，避免把所有请求平均后掩盖高价值路径。

规范同时写清数据延迟、维护窗口、第三方故障、客户端取消等如何计入；排除必须极少且可审计，否则 SLO 失去可信度。预算可按坏事件数或坏时间消耗，事件型更能反映部分用户受损。建立周/月评审，把预算用于发布节奏和可靠性投资，而不是绩效惩罚；新服务先观察基线再收紧，目标变更需版本化。

实践经验

某内部 API 直接承诺 99.99%，而关键数据库自身只能稳定达到更低水平，团队长期“红色”后开始忽略告警。评审历史事件、依赖目标和用户影响后，先将关键写路径与低价值报表路径拆分 SLO，并在迁移期公布目标阶梯；止血阶段暂停非必要发布、修复最主要超时源。目标放宽可能被理解为降级，因此同步披露当前实际值、改进路线和排除规则，随后以预算消耗验证改造效果。

面试回答要点

如何建立可执行的误差预算策略？¶

技术说明

策略要把预算状态映射到动作，而不是只显示百分比。典型分层包括：健康时正常发布；消耗加快时要求金丝雀和额外审批；预算耗尽时暂停非紧急高风险变更，将容量投入可靠性修复。必须约定例外授权人、紧急安全补丁路径、第三方故障归属和恢复条件。预算按服务/用户旅程治理，不能让一个稳定服务“借预算”给另一个不稳定服务。

执行前应验证 SLI 质量，否则错误数据会冻结交付。策略还要防止两种极端：把预算当可主动花完的额度，或一红就无限期停发。结合长期、短期 burn rate、剩余窗口和预计修复收益做判断，决策留痕。产品、开发和 SRE 共同签署，定期回顾暂停发布是否真正降低风险。

实践经验

某服务月初一次依赖故障耗掉 70% 预算，发布团队主张继续按计划上线。证据显示后续正常 burn rate 已恢复，但两项发布都涉及同一依赖超时路径。事故指挥决定只允许可快速回滚的小批变更，暂停数据库重构，并先加入隔离与降级。这样牺牲部分交付速度，却避免剩余预算被再次击穿。长期把策略写入发布平台，支持例外审批、自动恢复和变更关联，季度检查是否出现“指标博弈”。

面试回答要点

多窗口、多燃烧率告警如何工作？¶

技术说明

燃烧率是实际错误预算消耗速度相对允许速度的倍数：1 表示按窗口恰好耗尽，10 表示快十倍。单一短窗灵敏但容易受尖峰干扰，单一长窗稳定却发现太慢；多窗口告警通常要求长窗和短窗同时超过对应阈值。长窗确认持续影响，短窗确认故障仍在发生，再按“多少时间会消耗多少预算”推导 page 与 ticket 级别，而非死记某组常数。

计算需与 SLO 完全同口径：相同 good/valid event、排除和聚合层级。低流量下比率剧烈波动，应设最小事件数、延长窗口或使用合成信号。规则用历史回放和故障注入验证检测时间、召回与噪声，并展示当前预算、燃烧率和主要错误维度。恢复条件也需滞后，防止告警抖动。

实践经验

某 API 用五分钟错误率阈值分页，批处理流量每小时触发短峰，值班人员逐渐静音。团队回放三个月数据，发现真实事故至少持续 20 分钟，而噪声不足 8 分钟；改为长短窗同时满足的 burn-rate 规则，并用事件数量保护低流量。上线时并行观察两周，真实故障检测只晚两分钟，页面量下降明显。副作用是极短但严重的全量失败可能被延迟，因此另保留“连续完全失败”的紧急探测。

面试回答要点

如何治理告警噪声并设计分级通知？¶

技术说明

可分页告警应同时满足：用户影响或迫近的硬风险、需要立即人工动作、有清晰 owner/runbook。按 page、ticket、信息事件分级，路由考虑服务、环境、严重度和当班表；去重、分组与抑制用于合并同根因风暴，例如区域断网时抑制数百实例告警。抑制不能只靠静默，必须保留根因与影响视图，静默要有 owner、原因和到期时间。

用每班页面数、可操作率、确认/缓解时间、重复率、自动关闭率和“告警后无动作”比例评估质量。每次事故检查缺失告警，每次无效页面创建删改任务；规则变更像代码一样测试和灰度。值班交接包含已静默项和已知风险，通知链路本身需要合成测试，避免规则正确但呼叫服务失效。

实践经验

一次存储故障同时触发 600 条 Pod、节点和应用告警，首个有效信号被淹没。事件记录显示值班员花 18 分钟寻找共同区域标签。团队先按区域聚合通知并抑制下游症状，保留一条用户 SLO page；长期建立依赖拓扑、告警 owner 与月度“无动作页面”清理。分组过度可能隐藏第二个独立故障，因此摘要必须展示受影响服务数并允许展开，关键安全告警不参与普通抑制。

面试回答要点

如何做容量规划并把不确定性纳入决策？¶

技术说明

容量规划从需求驱动量开始：峰值 QPS、并发、数据增长、消息率或 GPU token/s，而不是只看平均 CPU。建立资源模型，例如单副本在目标延迟下的安全吞吐，乘以增长、季节性、发布开销、单区故障和测量误差的余量。CPU 可用利用率模型，内存、连接、磁盘 IOPS、网络、配额和外部依赖往往是不同硬边界，不能互相折算。

用历史趋势、业务预测和压测三角验证，给出基线/高/低情景与触发扩容的提前期。高可用容量通常要求故障后剩余单元仍能承载目标流量，但昂贵资源可通过降级、排队和预留分层折中。持续跟踪饱和度、排队、拒绝、单位请求资源、预测误差及交付周期；自动扩缩容只能覆盖反应速度允许且供应充足的部分。

实践经验

促销前团队按月均 QPS 乘二备容，演练时数据库连接先耗尽，CPU 仅 45%。证据来自连接池等待、数据库会话上限和 Little 定律估算的并发，而非 CPU 图。团队先限制低优先级请求、调小超时并扩展连接代理，随后以峰值到达率和延迟建模，验证单区失效情景。增加连接上限会提高数据库内存并加剧故障风暴，因此扩容同时限制每实例池大小和总连接预算。

面试回答要点

如何设计能代表生产风险的负载与容量测试？¶

技术说明

先明确目标：找最大安全吞吐、验证 SLO、测扩缩速度或故障恢复。工作负载要匹配生产的请求组合、对象大小、缓存命中、读写比、连接复用和突发性；分阶段做预热、阶梯升压、稳态、尖峰、耐久及降压恢复。只报平均延迟会掩盖排队，应观察 p95/p99、错误、排队时间、拒绝、依赖饱和和单位工作资源。

测试环境需说明与生产的规模差异并建立缩放假设；生产演练则设流量上限、停止条件、隔离租户和回滚负责人。协调遗漏、缓存热度与数据分布都会让结果虚高。用 Little 定律交叉检查并发≈吞吐×响应时间，记录拐点前的安全容量，而非把崩溃峰值当额定值。每次运行固定代码、配置、数据和生成器版本。

实践经验

某服务压测显示可达 20k QPS，真实峰值在 8k 即超时。复盘发现压测只读同一热门键，缓存命中 99.9%，且生成器自身未模拟慢客户端。团队先通过限流保护数据库，再用生产脱敏分布、读写混合和连接抖动重测，发现安全容量约 9k。长期把代表性检查和单区故障加入发布前演练。更真实的测试成本更高且会制造数据，因此使用隔离命名空间和自动清理，生产测试严格限窗。

面试回答要点

成熟的值班体系应包含哪些机制？¶

技术说明

值班不是“把电话发给工程师”，而是服务所有权、风险控制和人员可持续性的组合。每个轮值应有明确覆盖时间、主备、升级链、响应目标、服务目录和可执行 runbook；交接包含活跃事故、静默、近期变更和容量风险。新人先影子值班、通过演练再独立上岗，团队保证访问权限、设备和安全登录方式在事故前可用。

健康度既看响应时间，也看每班页面数、夜间打扰、可操作率、升级比例、重复事故和补休兑现。超过负担阈值时应削减噪声或调整服务边界，而不是长期靠英雄主义。自动化只能执行可逆、有上限、可观测的动作；高风险数据库切换仍需双人确认。事故中的心理安全、清晰角色和事实记录比追责更能缩短恢复。

实践经验

某共享平台只有一名专家能处理证书故障，连续两次夜间事件都升级给他。排班数据、升级记录和 runbook 执行日志表明这是知识与权限单点，而非当班人员能力不足。团队先建立主备和明确升级时限，随后补齐证书演练、最小权限临时授权及轮岗。短期训练占用项目时间，却显著减少专家中断；同时按季度检查夜间页面和补休，防止系统稳定性建立在人员透支上。

面试回答要点

大型事故中 Incident Commander 如何组织响应？¶

技术说明

事故指挥把“技术排障”和“协调决策”分离。IC 负责目标、优先级、角色和决策节奏；Operations 执行变更；Communications 对内外同步；Scribe 记录时间线、证据与决定；必要时另设客户、供应商和业务联络。第一阶段先确认影响、爆炸半径和安全边界，再选择止血，不急于找完整根因。所有操作走单一指挥频道，明确谁执行、何时回报、如何回滚。

状态更新应固定节奏，包含已知/未知、用户影响、正在验证的假设、下次更新时间，避免给未经证实的恢复承诺。并行分支需各有假设和截止时间，发现无效就关闭；交接时复述当前状态。恢复后先验证用户旅程、积压和数据一致性，再解除事故状态，根因分析留给复盘。

实践经验

某跨区域故障中，多名工程师同时调整 DNS、扩容和回滚，指标短暂改善却无法归因。临时 IC 冻结未登记变更，建立操作员、记录员和 15 分钟更新节奏；证据显示真正瓶颈是故障区连接未快速失败。团队先从流量层摘除该区并延长消息保留，恢复后逐项回放。冻结变更会延迟部分可能有效的动作，但换来可解释性和回滚安全；长期通过季度演练强化角色和决策日志。

面试回答要点

如何用假设驱动法排查复杂生产故障？¶

技术说明

先把症状写成可量化事实：何时开始、哪些用户/区域/版本受影响、哪些未受影响。建立少量可证伪假设，每个假设指定预期证据、查询或实验、负责人和时间盒；优先验证能解释最多现象且成本最低的分支。对照组很重要，如正常区域、新旧版本、同依赖的另一服务。相关性不是因果，变更时间相近也要通过机制和反事实验证。

排障过程中维护证据表，区分观察、推断和决定。高风险实验在镜像流量或隔离实例上进行，生产变更先定义回滚和成功指标。若止血改变了系统状态，要保存日志、配置快照和关键时间序列。复杂系统常有多个促成因素，因此避免在找到第一个异常后停止。

实践经验

某 API 仅在一个区域出现 5 秒阶梯延迟。候选假设包括 DNS、连接池、下游限流和 GC；抓包显示每次延迟前有 DNS 重试，正常区域使用不同 resolver 配置，应用 profile 无异常。团队先切换 resolver 并降低受影响区权重，随后修复网络策略。DNS 是触发点，但无缓存、超时叠加和重试放大是促成因素；长期补充 resolver SLI、合成解析与超时预算，避免把“改 DNS”当完整根因。

面试回答要点

一份高质量无责复盘应怎样写并推动改进？¶

技术说明

复盘包含用户影响、精确时间线、检测方式、响应与恢复、触发因素、技术根因、促成因素、检测/响应缺口和有效做法。时间线使用同一时区并以证据校准，不把“某人操作错误”当根因，而追问为何系统允许、为何审核/测试未捕获。无责不等于无标准：事实要严谨，蓄意违规与正常人因问题按组织制度另行处理。

行动项应具体、带 owner、截止日期、风险优先级和验证方法，覆盖消除、减小爆炸半径、提前检测、加速恢复，而非只写“加强培训”。进入统一跟踪系统，逾期升级，完成后用演练或指标验证。复盘还应输出可复用模式并检索其他相似系统，避免只修事故服务。

实践经验

一次配置误推导致 40 分钟不可用，初稿结论是“工程师未仔细检查”。证据回放发现预览环境没有生产规模规则、审批页面隐藏删除数量、回滚又依赖同一故障控制面。会议据此改写系统因素，先增加删除上限和离线回滚，再补规模化测试与双人审批。额外门禁会降低紧急变更速度，因此保留有审计的 break-glass。行动项两月后通过故障演练验证，而非以代码合并即结案。

面试回答要点

如何安全地开展混沌工程？¶

技术说明

混沌工程是用受控实验验证稳态假设，不是随机破坏。先定义稳态指标和假设，例如“失去一个区时结账成功率仍高于目标”，再明确范围、最大爆炸半径、自动停止条件、观察窗口和回滚。成熟路径从测试环境、单实例、影子流量逐步扩大到生产；涉及数据破坏、不可逆依赖或合规边界的实验须额外审批或用仿真替代。

实验前确认值班、仪表盘、依赖 owner、备份和通信，避免与高风险发布重叠。执行工具必须有租户/资源白名单、时限、并发上限和审计。结果不仅看是否“扛住”，还看告警是否及时、runbook 是否可执行、自动恢复是否造成放大。失败实验先修复能力再扩大范围。

实践经验

团队假设缓存节点故障会自动摘除，先在非关键租户杀一副本；错误率迅速上升，停止条件在两分钟触发。证据显示客户端 DNS 缓存超过故障转移时间且重试无抖动。团队恢复副本、降低实验流量，随后修复发现机制和退避，并再次验证。实验本身短暂影响少量请求，所以预先取得业务同意并设置预算；长期把验证纳入季度游戏日，而非持续无界注入。

面试回答要点

当前 DORA 软件交付绩效指标如何定义和正确使用？¶

技术说明

截至 2026 年初，DORA¹⁰ 官方当前模型为五项：吞吐侧的变更前置时间、部署频率、失败部署恢复时间；不稳定性侧的变更失败率、部署返工率。失败部署恢复时间聚焦由部署引发且需立即干预的故障，不应与所有事故的泛化 MTTR 混为一谈；部署返工率衡量为修复生产问题而发生的非计划部署。定义会随研究演进，指标仓库应记录口径版本，不能照搬旧“四项”仪表盘而不说明。

这些指标适合在同一应用/服务上下文中观察趋势和瓶颈，不适合跨差异巨大的团队做个人排名。数据需关联 commit、流水线、部署、事故和回滚，明确“部署”“失败”“恢复”的业务口径，并抽样审计。配合可靠性、质量和开发者体验信号使用，避免为提高频率拆出无价值部署或隐瞒失败；目标是改善系统，而不是把分位档位当 KPI。

实践经验

某组织按团队部署次数排名，出现空提交和拆分流水线刷数，变更失败又因未关联事故而被低报。审计部署事件、回滚记录与事故时间线后确认 Goodhart 效应。团队停止排名，按单一产品价值流重建五项口径，用季度趋势定位评审等待和回滚困难；同时展示 SLO 与满意度。指标短期变差，因为历史漏报被纠正，但这提升了决策可信度，且每年按 DORA 官方定义复核版本。

面试回答要点

RED、USE 和四个黄金信号怎样组合用于监控？¶

技术说明

RED 与 USE¹¹ 分别面向请求型服务和资源：RED 是 Rate、Errors、Duration，USE 是 Utilization、Saturation、Errors；黄金信号通常概括延迟、流量、错误和饱和。它们是提问框架而非固定仪表盘。顶层先展示用户 SLI 和关键旅程，再用 RED 定位服务边界，以 USE 下钻 CPU、连接池、磁盘、队列等资源，结合依赖拓扑判断症状与原因。

利用率高不一定有害，饱和意味着已排队或拒绝；延迟需区分成功/失败、客户端/服务端及尾部。每层控制标签数量，并提供从服务、区域、版本到实例的逐级下钻。页面告警优先基于用户影响或 burn rate，资源告警用于有明确耗尽预测和动作的情况，避免 CPU 70% 之类静态阈值泛滥。

实践经验

某接口 p99 上升，CPU 与内存均正常，团队一度认为“资源够”。USE 面板补充连接池等待后发现 saturation 已满，RED 又显示仅写请求受影响。先限流低优先级写入并回退池配置，长期增加连接等待、数据库会话预算和写路径 SLI。连接池指标增加了维度成本，因此仅按服务/实例暴露，不带 SQL 文本；这显示框架需覆盖真正排队资源，而非只看主机四项。

面试回答要点

如何治理可观测性成本而不破坏排障能力？¶

技术说明

先拆成本驱动：指标活跃序列与查询、日志摄入/索引/留存、trace span 量和采样、profile 样本、跨区传输及对象存储。按服务、租户、信号和环境分摊，结合每次请求/交易的单位遥测成本。优化顺序通常是消除无 owner 数据、控制源端高基数和重复、分层留存，再做压缩/后端采购；直接统一砍留存可能令事故窗口无证据。

指标用标签预算和 recording rules；日志把常用低基数字段索引、正文冷存；trace 用错误/延迟优先尾采样和正常基线；调试数据通过短期动态开关采集。每项削减要定义“可回答的问题”和恢复开关，用历史事故回放验证。隐私与合规留存是硬边界，不能仅以成本覆盖。

实践经验

账单季度增长 80%，分摊显示一个测试环境占日志摄入近半，另有用户 ID 指标制造百万序列。团队先限速测试 DEBUG、删除重复 sidecar 日志并丢弃问题标签，保留安全审计流；再实施热七天、冷九十天和按错误尾采样。成本下降但正常 trace 样本减少，故用合成请求和动态采样补偿。季度用过去事故问题清单验证仍能回答“何时、谁受影响、哪个版本、哪个依赖”。

面试回答要点

如何识别并系统性减少 SRE toil？¶

技术说明

Toil¹² 是手工、重复、可自动化、战术性且随服务线性增长的运维工作；必要但低频的架构评审不必算 toil。先在工单、页面、发布和访问请求中分类记录耗时、频次、等待和错误风险，避免仅凭抱怨选项目。优先自动化高频、高风险且规则稳定的任务，先标准化输入和决策，再写工具；不稳定流程自动化只会更快地产生错误。

自动化应提供幂等、dry-run、权限边界、审计、速率限制、失败回滚和人工接管。衡量结果不仅是节省工时，还包括等待时间、失败率、页面量和服务采用率；省下时间应明确投入可靠性工程。对于低频高风险动作，完善 runbook 和演练可能比全自动更合算。

实践经验

团队每周手工创建数十个数据库账号，复制命令常出现权限过宽。数据表明审批等待占大部分前置时间。团队先定义角色模板和到期策略，再建设自助流程，接入审批、短期凭证和审计；上线初期保留人工复核。处理时间从天降到分钟，但平台成为新关键依赖，因此设置降级人工路径和 SLO。未自动化特殊永久账号，避免把模糊例外固化。

面试回答要点

如何建立可靠性评审与治理机制？¶

技术说明

可靠性评审覆盖上线前和运行期：服务分级、关键用户旅程、依赖、SLO、容量与 N-1、数据一致性、降级、备份恢复、值班、runbook、安全和变更策略。高风险服务需生产就绪评审，风险项有 owner、期限和接受人；低风险服务用轻量模板，避免一刀切会议。评审应验证证据，如压测报告和恢复演练，而非勾选“有备份”。

运行期结合预算消耗、重复事故、容量预测、依赖变化和行动项逾期做周期检查。设置最低护栏与例外机制：例外注明风险、补偿控制和到期时间，由能承担业务风险的人批准。中央 SRE 提供标准和咨询，服务团队保留所有权，防止“可靠性外包”。治理成效看事故影响、恢复能力和交付流，而非模板数量。

实践经验

某新服务按时上线却没有恢复演练，主库故障时才发现备份账号已过期。评审追溯显示清单仅要求填写“已启用备份”，无恢复证据。团队先修复凭证并做隔离恢复，随后将关键级服务门禁改为最近演练时间、实际 RTO/RPO 和证据链接；临时例外自动过期。门禁增加前期工作，因此按服务等级分层，并提供标准演练环境，避免治理变成发布瓶颈。

面试回答要点