故障排查方法学

• 掌握 iptables 表与链的结构
• 理解数据包在链中的流转路径
• 掌握排查网络不通的定位方法

iptables 用"表+链"组织规则：表（filter 过滤、nat 地址转换、mangle 修改、raw 原始）按功能划分，链是规则执行的路径。filter 表含 INPUT（入站）、OUTPUT（出站）、FORWARD（转发）；nat 表含 PREROUTING（入站前 NAT）、POSTROUTING（出站后 NAT）、OUTPUT。数据包按方向经过相应链：入站包经 INPUT，出站包经 OUTPUT，转发包经 FORWARD，规则自上而下匹配，命中即生效。排查网络不通时，先确认方向与表链，再用 iptables -L -n -v 查看规则、iptables -S 查看原始规则、-A/-D 增删规则定位；用 iptables -L -v 看计数器（Rule 命中于哪条）。常见问题：DROP 规则拦截、规则顺序错误、未放行回程流量、NAT 规则错误。可临时加 ACCEPT 或清空规则测试，定位后恢复。

面试官关注候选人对包过滤机制的理解。回答应体现表链结构、数据包流转路径、以及用查看规则与计数器定位问题的方法。

• 掌握 SRE 简单性原则
• 理解复杂度对可靠性的损害
• 掌握削减复杂度的实践

SRE 的简单性原则认为"复杂度是可靠性的敌人"——复杂系统更易出故障、更难排查、更慢交付。在可靠性、交付速度与复杂度冲突时，简单性优先：优先设计简单方案，用简单性换取可预测性与可维护性。削减元必要系统的实践：识别并移除未使用的功能、冗余组件、重复工具；合并同类系统；用"如果系统停止运转会怎样"的视角评估价值，无价值即删。削减元必要流程：精简审批链、冗余环节、无价值的检查；用"每步流程是否降低风险"评估。简单性与交付速度的关系：短期看复杂方案可能"快"，但长期维护成本拖慢交付；简单设计让变更更快、故障更少。核心是"用最少的系统与流程满足需求"，把复杂度当作需持续治理的负债。

面试官关注候选人对"简单性"作为工程原则的把握。回答应体现复杂度与可靠性/交付的关系、削减系统与流程的具体做法。

• 掌握 Toil 的定义与特征
• 理解识别 Toil 的方法
• 掌握用指标证明收益

Google SRE 定义 Toil 为"重复、可自动化、无长期价值、与业务增长线性相关"的手工运维工作。识别 Toil 的四个特征：重复（反复做同样的事）、可自动化（机械操作）、无长期价值（不产生持久改进）、线性增长（随业务扩张而增加）。识别方法：盘点值班/日常运维任务，用四特征筛选；追踪高频手工操作（如反复重启、手工配置、重复查询）。用指标证明收益：量化 Toil 占团队工时比例（Google 建议控制在 50% 以内）、统计某类 Toil 的月度频次与耗时、估算自动化投入 vs 节省工时（ROI）。证明收益后推动自动化：优先自动化"高耗时、高风险、可标准化"的 Toil。核心是"用数据识别、用数据论证"，让消除 Toil 的投入有据可依。

面试官关注对 Toil 的量化认知。回答应体现 Toil 四特征、识别方法、用工时占比与 ROI 指标证明收益。

• 掌握容量模型的概念
• 理解自动化对 Toil 的真实影响
• 掌握判断自动化价值的指标

自动化项目有时只是"转移人工成本"而非真正降低 Toil——把手工操作变成维护自动化系统的新工作量。用工程化容量模型判断：建立"总体工作量 = 操作量 + 维护量"的模型，评估自动化前后总工作量变化。关键指标：自动化减少的重复操作量（节省工时）、自动化系统的维护成本（开发、排查、升级的工时）、以及"自动化本身是否引入新的 Toil"（如脚本维护、规则更新）。判断方法：比较"人工处理 N 次操作的总耗时"与"自动化建设+维护的总耗时"，只有自动化后在业务规模增长下总成本下降才是真降低。工程化容量模型强调"自动化要能随业务规模线性受益"，若自动化维护成本随规模上升，则只是转移成本。核心是"自动化要降低总体的单位工作量，而非重分配"。

面试官关注对自动化"净收益"的工程判断。回答应体现总体工作量模型、自动化节省 vs 维护成本的比较、以及规模增长下是否真正降 Toil。

• 掌握 SLI 的定义与设计原则
• 理解面向用户旅程的 SLI 设计
• 掌握避免内部资源监控遗漏的方法

SLI（服务级别指标）是衡量服务质量的量化指标，设计应"面向用户真实体验"而非纯内部资源。面向用户旅程的 SLI：从用户的核心操作路径（登录、下单、查询、付款）出发，定义关键步骤的成功率、延迟、可用性，如"下单请求成功率""页面加载延迟""支付成功率"。只监控内部资源（CPU、内存、磁盘）会遗漏真实可用性——资源正常但业务可能已不可用（如依赖故障、代码错误、队列积压）。设计方法：识别用户旅程的关键步骤 → 定义每步的 SLI（成功率、延迟、错误率）→ 用真实请求/合成拨测采样 → 与 SLO 关联。关键是把"用户看到什么"作为指标，内部资源监控作为补充而非替代。用真实链路与拨测结合，捕捉用户侧真实可用性。

面试官关注 SLI 的"用户视角"。回答应体现从用户旅程提取 SLI、内部资源监控的局限、以及真实请求与拨测结合的方法。

• 掌握 SLO、错误预算与发布决策的关系
• 理解闭环的机制
• 掌握可审计性

SRE Book 的闭环是：定义 SLO（服务级目标）→ 用错误预算（错误预算 = 1 - SLO）衡量可用性消耗 → 依据错误预算做发布决策（预算充足可发布，耗尽则减缓/暂停新功能）。接成可审计闭环的关键：量化监控——把 SLO 对应的 SLI 持续采集计算，跟踪错误预算消耗，告警接近耗尽；发布联动——把错误预算状态接入发布流程，预算耗尽时强制放慢或暂停高风险发布，用自动化闸门实现；可审计——所有 SLO 定义、错误预算计算、发布决策记录需可追溯（数据、时间、决策依据），定期评审。核心是"预算状态驱动发布，而非凭感觉"，且决策有据可查。闭环让"可靠性目标"从口号变成驱动研发决策的机制。

面试官关注 SLO 落地的工程闭环。回答应体现 SLO/错误预算/发布决策的关系、自动化闸门联动、以及可审计的数据与决策记录。

• 掌握 FMEA 的方法与流程
• 理解 FMEA 在预防中的应用
• 掌握 FMEA 与 RCA 的区别

FMEA（失效模式与影响分析）是一种"事前预防"方法：对系统/组件系统性识别可能的失效模式、失效原因、对系统的影响，并按严重度（S）、发生频度（O）、可检测度（D）评估风险优先级（RPN=S×O×D），优先改进高风险项。FMEA 用于故障预防：在设计与运维阶段提前识别薄弱点并加固，而非等故障发生。与 RCA（根因分析）的区别：FMEA 是"事前、前瞻性、面向失效模式"的预防分析，回答"可能怎么坏、如何预防"；RCA 是"事后、回溯性、面向具体事故"的分析，回答"为什么坏了、如何避免复发"。两者互补：FMEA 预防未发生的事故，RCA 治理已发生的事故。FMEA 强调系统性扫描与量化优先级，RCA 强调深入根因与改进闭环。

面试官关注对"预防与事后"两种方法的区分。回答应体现 FMEA 的流程与 RPN 量化、预防导向，以及与 RCA 的时点与目的差异。

• 掌握 safepoint 机制与停顿
• 理解 safepoint 日志与 GC 日志分析
• 掌握锁竞争对停顿的影响

safepoint 是 JVM 的一个安全点，所有线程在此处同步，供 GC 等全局操作使用；线程到达 safepoint 时可能停顿，若停顿过长会拖慢应用。排查 safepoint 停顿：开启 safepoint 日志（-Xlog:safepoint 或 -XX:+PrintSafepointStatistics），查看各 safepoint 的类型、耗时、触发线程；分析 GC 日志（-Xlog:gc）看 GC 暂停是否过长；结合锁竞争分析——大对象锁、长时间持锁、偏斜锁竞争会导致线程停留 safepoint 附近。优化：减少 safepoint 数量与频率（如避免频繁 GC 触发、合并大对象）、减少同步锁竞争（锁粒度、无锁/并发结构）、调整 safepoint 相关的 GC 参数、避免单线程长时间占用 safepoint。关键是把 safepoint 停顿与具体原因（GC、锁、线程）关联，再针对性优化。

面试官关注 JVM 停顿的深入排查。回答应体现 safepoint 机制、用日志定位停顿来源、结合 GC 与锁竞争分析并优化。

• 掌握 NUMA 架构与本地/远程访问
• 理解 numastat 等工具分析
• 掌握 CPU 亲和性与优化

NUMA（非统一内存访问）架构下，每个 CPU 有本地内存节点，访问本地内存快、访问远程节点内存慢，错误的放置会导致性能下降。排查性能问题：用 numastat 查看各节点内存分配与命中率（local_node/other_node 命中数），numactl --hardware 查看节点拓扑，numactl --show 查看当前策略。若发现大量远程访问（other_node 命中高），说明内存放置不佳。优化：进程绑核（numactl --cpunodebind / taskset）让进程与内存同节点、避免 CPU 迁移导致跨节点访问；用 numactl --interleave 平衡大内存分配；对数据库等大内存应用合理设置 NUMA 策略。结合 perf 看内存访问开销。核心是"让进程的 CPU 与内存尽量落在同一节点"，减少远程访问。

面试官关注对 NUMA 性能问题的排查。回答应体现本地/远程访问差异、numastat 分析、CPU 亲和性与绑核优化。

• 掌握 posix_fadvise 的作用
• 理解对文件缓存与 I/O 的影响
• 掌握缓存命中率低的排查

posix_fadvise 向内核告知应用对文件的访问模式，帮助内核优化缓存策略，不改变数据但影响性能。常用建议：POSIX_FADV_SEQUENTIAL（顺序读，内核可预读并减少缓存压力）、POSIX_FADV_RANDOM（随机读，避免预读浪费）、POSIX_FADV_DONTNEED（明确不再需要，可释放缓存）、POSIX_FADV_WILLNEED（提示即将使用，可预加载）。当大量数据只读一次，用 DONTNEED 可避免污染 page cache；顺序读用 SEQUENTIAL 提升预读效率。缓存命中率低的排查：用 sar -r、free、/proc/meminfo 看 page cache 使用，iostat 看磁盘 I/O 是否高（缓存不足导致大量落盘），vmstat 看缺页。定位是"缓存策略不当"还是"数据量远超内存"。优化：调整 fadvise 提示、扩大缓存、或用缓存友好的访问模式。

面试官关注文件缓存与 I/O 的底层理解。回答应体现 posix_fadvise 的提示作用、对缓存与 I/O 的影响、以及用工具排查缓存命中率低。

• 掌握 preadv/pwritev 的作用
• 理解向量化 I/O 的适用场景
• 掌握分析系统调用行为

preadv/pwritev 是向量化（scatter-gather）I/O 系统调用：preadv 一次读取多个不连续缓冲区、pwritev 一次写入多个缓冲区，可减少系统调用次数，适合需要聚合多个分散内存块进行 I/O 的场景（如网络 + 文件混合、协议解析、日志聚合）。与 pread/pwrite 相比，preadv 通过 iovec 数组一次完成多段读写，减少上下文切换与系统调用开销。I/O 问题排查中分析系统调用：用 strace -e trace=read,write,preadv,pwritev 跟踪系统调用、查看调用次数与大小；用 perf 统计系统调用热点；结合 iostat、vmstat 看 I/O 瓶颈。评估是否频繁小 I/O（可改为批量/向量化）、是否系统调用次数过多。核心是"用系统调用分析定位 I/O 模式问题"，再优化访问方式。

面试官关注 I/O 的系统调用层次。回答应体现 preadv/pwritev 的向量化作用与适用场景、用 strace/perf 分析系统调用行为。

• 掌握 epoll 机制与事件处理
• 理解事件丢失与惊群成因
• 掌握定位高 CPU 的方法

epoll 是 Linux 高并发 I/O 复用机制，故障常见为事件丢失、惊群效应与高 CPU。事件丢失排查：检查是否用 level-triggered/edge-triggered 模式（edge-triggered 需保证读尽，否则丢事件）、是否在事件处理中未正确 re-arm、是否多线程并发处理同一 fd 导致竞争；检查是否误用非阻塞语义。惊群效应：多个线程/进程同时 epoll_wait 同一 fd，事件到达时多个被唤醒，只有少数处理；用 SO_REUSEPORT 或 EPOLLEXCLUSIVE 减少唤醒。高 CPU 占用：用 strace/perf 看 epoll_wait 是否频繁返回、空转（busy loop）、事件处理是否阻塞；用 ss/lsof 看 fd 数量与状态。定位思路是"事件到→epoll_wait 返回→处理"，逐环节排查。核心是理解触发模式与并发处理对事件正确性的影响。

面试官关注高并发 I/O 的深入问题。回答应体现事件丢失的触发模式原因、惊群成因与缓解、用工具定位高 CPU。

• 掌握定时器机制与故障表现
• 理解内核观测手段
• 掌握定位与优化

定时器故障常见为延迟（定时器触发晚）、不准（时间漂移）、CPU 飙高（定时器频繁触发）。排查：延迟与不准——检查系统时钟来源（/sys/devices/system/clocksource/clocksource0/current_clocksource、chronyc/ntpstat 看时间同步）、检查高精度定时器（hrtimer）与内核 tick 配置、/proc/sys/kernel 相关参数；检查是否 CPU 负载过高导致定时器无法及时调度。CPU 飙高——用 perf 看定时器中断/软中断热点（timer 软中断、irq）、/proc/interrupts 看定时器中断频率、cat /proc/timer_list 看活动定时器。攻坚手段：perf top/perf record 定位高占用、strace 看应用定时器调用、/proc/slabinfo 看定时器对象。优化：减少过高频率定时器、合并定时器、避免在定时器回调中做重活、合理配置 tick。核心是"定时器问题要结合时钟、中断、负载三层定位"。

面试官关注定时器与内核机制。回答应体现延迟/不准/CPU 飙高的原因、内核观测手段（timer_list、interrupts、perf）与优化。

• 掌握调用链与依赖图的分析
• 理解级联故障的传播
• 掌握定位方法

分布式系统故障常由依赖引发，需依赖分析定位。调用链：用 APM/分布式追踪（如 Zipkin、Jaeger、SkyWalking）还原请求经过的各个服务与耗时，定位哪个环节慢/失败。依赖图：梳理服务间依赖关系（谁调谁、强/弱依赖），识别关键路径与薄弱依赖。级联故障定位：某依赖故障可能导致上游雪崩（超时→重试→堆积→级联），需区分"根因依赖"与"受灾服务"——用错误率、延迟、依赖图定位源头，避免在受灾服务上白费功夫。方法：先看哪个依赖最先异常（时间线）、是否共用同一依赖、是否超时/重试放大。措施：超时、熔断、限流、降级切断级联。核心是"从依赖传播视角定位根因，而非逐服务排查"。

面试官关注分布式故障的系统性定位。回答应体现调用链还原、依赖图识别、级联故障的传播与隔离手段。

• 掌握四类排障工具的分工
• 理解组合应用的方法
• 掌握按场景选工具

排障工具链按"指标→日志→追踪→抓包"分层组合：指标（Prometheus/Grafana、监控）看趋势——发现异常、定位时间范围与大致模块；日志（ELK、Loki）看细节——深入具体错误、堆栈、事件；追踪（Jaeger、SkyWalking）看链路——还原请求经过的服务与耗时，定位瓶颈；抓包（tcpdump、Wireshark）看协议——检查网络层内容、报文、重传。组合应用：先看指标定位"哪里、何时"异常，再下钻日志看"发生了什么"，用追踪看"链路哪个环节慢"，必要时抓包看"协议层是否正常"。按场景选工具：性能问题先指标+追踪，错误问题先日志，网络问题先抓包。核心是"用对工具看对层次"，避免单一工具误判，按需组合快速收敛。

面试官关注排障工具链的组织。回答应体现四类工具的分工与下钻顺序、组合应用方法、按场景选型。

• 掌握故障档案、runbook、排查手册的组织
• 理解知识沉淀的机制
• 掌握保持更新的方法

排障知识沉淀是把"这次怎么解决的"变成"下次可复用的"。故障档案：记录每次故障的现象、根因、处置、恢复、教训，作为历史参考。runbook：针对已知故障的标准化处置步骤，含触发条件、排查步骤、处置动作、回滚。排查手册：系统性的排查方法论（按症状分模块的排查路径、常用命令）。组织上三者互补：故障档案是"历史案例"，runbook 是"标准处置"，排查手册是"通用方法"。保持更新：故障复盘后把新案例入档案、把新处置沉淀为 runbook、把共性经验更新进手册；纳入版本管理、定期评审、随系统变更联动。核心是"让排障经验可检索、可复用、可更新"，避免"每次重新摸索"。

面试官关注排障经验的沉淀。回答应体现三类文档的分工与组织、复盘驱动的更新机制、可检索复用。

• 掌握排障沟通的状态更新频率
• 理解升级条件与时机
• 掌握信息同步渠道

排障沟通的目标是"让相关方知道进展、让能力更强的人及时介入"。状态更新频率：初期高频（每 15-30 分钟更新一次），进展关键节点即时更新，稳定后降低频率；用统一状态页/频道记录，避免重复询问。升级条件：超过预设时间未解决、超出本人能力范围、影响扩大、需要更高权限/资源时升级；升级路径预定义（值班工程师→专家→管理层），升级时正式交接（含当前状态、已试方法、未决问题）。信息同步渠道：统一事故频道（即时通讯）+ 状态页 + 定期同步会，重大节点协调。核心是"信息透明、升级及时、渠道统一"，避免工程师埋头排查而相关方不知情、卡在能力边界不升级。

面试官关注排障中的协作与时效。回答应体现状态更新频率、升级条件与时机、统一信息同步渠道。

• 掌握科学排查流程
• 理解假设与验证
• 掌握避免跳跃式结论

故障排查应遵循科学方法避免"凭感觉定义根因"。流程：现象收集（完整收集现象、报错、时间、影响范围、变更记录，不遗漏）→ 假设生成（基于现象与知识提出多个假设，区分主次）→ 验证实验（用最小验证排除/确认假设，每步有明确预期）→ 根因确认（确认假设与现象吻合，排除其他可能）。避免跳跃式结论：不因"看起来像"就定根因，务必用实验验证；把"猜测"与"证据"区分；考虑变更相关性（排查最近变更）；验证能复现。常见错误：只凭单个现象下结论、忽略时间线、不做验证就改配置。核心是"用证据一步步收敛，而非跳跃到自认为的根因"，同时记录排查过程便于复盘。

面试官关注排查的方法论严谨性。回答应体现现象→假设→验证→确认的流程、用证据避免跳跃、考虑变更与复现。