第14章 支持场景案例集

对应简历：贯穿全部技能与项目——工作职责实-2「承担平台日常技术答疑与问题处理……按'记录—处理—转派—跟踪—闭环'流程协同华为原厂解决疑难问题」、实-3「负责平台日常巡检、监控告警响应」、技能第 1 条「一线问题响应、记录跟踪与客户沟通的完整经验」。 用法：每个案例按"场景 → 处理过程（命令+讲解）→ 根因 → 解决 → 预防 → 面试讲法（完整 STAR ≥250 字）"六段背。来源标注：【真实项目】= 我在生产亲手处理；【真实场景】= 支持场景改编自真实经历，细节脱敏；【经典故障】= 通用故障库案例，讲的时候用"我处理过类似的"口径。术语：Kubernetes（下文简写 K8s）。

14.0 支持场景回答万能框架（先响应 → 再止损 → 再定位 → 后复盘）

支持岗和纯技术岗的故障回答有一个关键差别：支持岗的第一动作不是技术动作，是响应动作。面试官抛出任何场景题，第一句话永远是框架第一句：

1. 先响应客户（0-5 分钟）：确认收到、了解四要素（现象、时间、范围、最近变更）、同步预期——"我看到了，正在处理，X 点前给您第一份进展"。支持岗的信誉从第一句话开始建立；影响面大的同步按通报模板走（第 7 章 7.8）。
2. 再止损恢复（最优先的技术动作）：故障第一目标是恢复业务不是找根因——有备切换备、能回滚先回滚、影响面大先摘流量；宁可恢复后再慢慢查，不让业务陪着排查。
3. 再定位根因（体现技术）：从入口往里、分层收敛——第 9 章命令树、第 1/3/4/5/6 章各章排查树；看监控+看日志+看变更（60% 故障和变更相关）；单一假设验证再前进。
4. 后复盘闭环（体现素养）：技术层验证+业务层验证+客户确认关单；写复盘（时间线/根因/响应评价/改进）；个案沉淀成 FAQ、SOP、告警——我的知识库和避坑清单就是这么来的。

兜底句式（答不出根因时）："当时先按 XX 恢复了业务保证客户可用，事后复盘定位到 XX 层面，更深的原理我理解到 XX，可以会后补。"

案例速查总表（被问"遇到过什么故障/难搞的客户"时扫一眼选 1-2 个展开）：

#	场景	第一个动作	结果一句话	来源
S1	批量登录失败	分层排查链收敛到数据库主备切换	40 分钟恢复+巡检项沉淀	真实
S2	情绪激动客户	先接情绪+15 分钟一次信息同步	发火客户变成认可客户	真实场景
S3	原厂协同疑难	七件套证据包+NTP 时间线对齐	原厂破案，模板成团队标准	真实
S4	工单积压五连报	影响面×紧迫度×成本三维排序	全部闭环且共因合并处理	真实场景
S5	重复问题知识库化	高频 TOP 统计→FAQ→RAG 入库	重复答疑量明显下降	真实
S6	夜间重大告警	确认影响→保守处置→按级升级	20 分钟闭环业务零中断	真实
1	CPU 打满	top 按 P	死循环定位+重启恢复	经典
2	内存 OOM	dmesg | grep -i oom	泄漏曲线+限额治理	经典
3	磁盘满	df -h && df -i	truncate+轮转基线	经典
4	502/504	ss -lntp 看后端	502 后端挂 504 后端慢	经典
5	节点 NotReady	CNI Pod 状态	九成是镜像拉取	真实
6	全量重启 Pending	describe 看 FailedScheduling	分批拉起	经典
7	证书 SAN 缺失	openssl x509 -text	补 certSANs 重签	真实
8	认证时好时坏	timedatectl 对比	时间不同步 chrony 修	真实
9	SSH 登录慢	ssh -v 分段计时	UseDNS 关闭	经典
10	网络不通	命令树逐层	分层收敛到层	经典
11	上传卡死（存储挂载）	df -h 看哪个挂载点卡	NFS 硬挂载无限等待	经典
12	VIP 时通时断	两台分别 ip addr	Keepalived 脑裂	经典

框架示范（60 秒标准回答，以"用户报系统打不开"为例）： "我处理这类问题的原则是先响应客户、再止损、再定位、后复盘。用户报打不开，我先问四要素——现象（报什么错）、时间（几点开始）、范围（一个人还是所有人）、最近变更（平台有没有发布）——同时回复他'正在排查，十分钟内给第一份进展'。假设是所有人打不开，我按入口往里查：入口地址通不通（ping/telnet）、Nginx 和证书状态、后端进程和端口、后端日志的数据库 Redis 连接——五分钟内定位到层。这一单如果发现是后端连不上数据库，先看能不能快速恢复（重启服务或切连接），恢复优先于修根因；恢复后验证业务、同步用户，最后把根因和预防写进工单和 FAQ。整个过程的沟通节奏是：开始时给预期、中间同步进展、结束给根因和预防——支持岗处理故障，一半是技术一半是节奏。"

案例讲述节奏表（面试现场的时间分配）：

讲述阶段	时间占比	要点
框架句（先响应/止损/定位/复盘）	10%	第一句话建立素养信号
情境与任务（S/T）	15%	两三句讲清"什么坏了、影响谁、我的目标"
行动（A）	55%	分层排查+关键命令+为什么这么做+沟通动作
结果与沉淀（R）	20%	恢复数据+客户反馈+检查项/SOP/知识库收尾
追问应对	—	每条命令讲得出"排除了什么"，卡壳用兜底句式

---

14.1 支持场景案例（六个，每个 STAR ≥250 字）

S1 客户报障处理全流程：批量登录失败 【真实项目】

场景：工作日早上，多个部门用户陆续报平台登录失败，报障量在爬升。 处理过程（讲解）：我先做响应动作——工单群回复"收到，正在排查，10 分钟内给第一份进展"，同时问清四要素：现象是登录页面报错、时间从 9 点前后开始、范围是多个部门、平台最近变更只有例行巡检无发布。然后走登录六层排查链（第 12 章实-2 问②）：用户侧网络正常（部分用户部分网络都报，排除客户端侧）；Nginx 存活、443 证书在有效期；后端 Java 进程在、8080 监听正常；到依赖层抓到证据——后端日志大量数据库连接失败；查 Vastbase 发现主备在凌晨 4 点发生过切换，应用连接串指向的旧主节点没有跟着更新——根因锁定。根因：数据库主备切换后应用连接配置未跟随，连接持续失败导致登录全挂。解决：协调应用侧更新连接配置、滚动重启服务，恢复期间我对报障部门逐个同步进展；恢复后逐部门确认登录正常。预防：把"数据库主备切换后检查应用连接串"写进巡检清单和 FAQ，后续主备切换演练也加了这个检查项。 面试讲法（STAR 完整版，约 320 字）： 情境是工作日早上突然收到多个部门报平台登录失败，报障还在增加。任务：尽快恢复业务并定位根因。我的行动分四步：第一步响应——群里回复收到并承诺 10 分钟内给第一份进展，同步问清现象、时间、范围、变更四要素，这一步让客户从"没人管"的焦虑里先出来；第二步分层排查——按我沉淀的登录六层链走：用户侧网络正常、入口 Nginx 和证书正常、后端进程端口正常，到依赖层抓到了关键证据，后端日志大量数据库连接失败；第三步根因确认——查 Vastbase 发现凌晨发生过主备切换，应用连接串没跟着更新，连接持续失败，根因锁定；第四步恢复与闭环——协调应用侧更新配置重启服务，恢复过程我每十几分钟向报障部门同步一次，恢复后逐部门确认登录正常，全程约 40 分钟。复盘我做了三件事：把"主备切换后检查连接串"写进巡检清单、把这个案例写进 FAQ 和给客户运维的培训教材、在我的知识库里存了完整决策树。这单的价值点：响应先于排查、分层收敛有链路、闭环后防复发——支持岗的三段价值在一单里全体现了。

S2 情绪激动客户应对 【真实场景（改编自真实经历，细节脱敏）】

场景：一次系统割接后客户反馈系统变慢，客户方对接人在工作群里发了措辞很冲的消息，质疑平台质量，并@了多方。 处理过程（讲解）：我第一时间做的不是在群里辩解，而是私聊加电话——第一句话是"您的心情我理解，系统慢确实影响大家工作，我现在全力处理，15 分钟内给您第一个进展"。排查很快收敛：割接后新环境的缓存配置未调优，高峰期响应拖长。修复动作一小时完成，期间我每 15 分钟同步一次：已定位层面、正在做什么、预计恢复时间——信息透明本身就是灭火器，客户第二次同步时语气已经缓下来。恢复后我做了两件修复关系的事：一份简要说明（发生了什么、为什么、已怎么解决、后续怎么防）、一次单独复盘电话，承认割接前的容量验证不够充分，给出了改进项。根因：割接后配置基线核查不完整。解决：调优恢复+割接检查单新增"性能基线验证"项。预防：割接类变更的验证清单固化。 面试讲法（STAR 完整版，约 320 字）： 情境是一次割接后客户反馈系统慢，对接人在群里发了很冲的话还@了多方，气氛很紧张。任务：快速恢复系统，同时把客户情绪和多方围观的压力处理掉。我的行动四步：第一步先接情绪不对抗——我没有在群里辩解，第一时间私聊电话过去，第一句话是"理解您的心情，系统慢影响工作，我全力处理，15 分钟内给第一个进展"——激动的时候讲道理是火上浇油，先让对方知道有人认真在管；第二步信息透明降焦虑——每 15 分钟同步一次进展：定位到哪层、在做什么、预计多久，客户发火的根源大半是"不知道发生了什么"，第二次同步时他的语气就缓下来了；第三步快速解决——排查收敛到割接后新环境的缓存配置未调优，高峰期响应拖长，调优后一小时恢复，我又观察确认了业务平稳；第四步事后修复关系——出了一份简要说明并单独电话复盘，主动承认割接前性能验证不够充分，给出改进项。结果：系统恢复，客户后来专门跟我们的负责人说"问题虽然出了，但他一直在"——这个客户后来成了最配合我的人。沉淀：情绪激动是客户在表达在乎，接住它、用信息透明和专业把它转化为信任；同时把"性能基线验证"加进了割接检查单，让同类问题不再发生。

S3 跨部门/华为原厂协同推进 【真实项目】

场景：BCS 平台某组件间认证间歇性失败，应用层和配置层排查全部正常，问题反复复发，业务方开始担心数据安全。 处理过程（讲解）：我按排查树把应用层（日志、配置、版本）和基础设施层（网络连通、证书有效期、资源）全部排除后，命中两条转判标准——层级越界（产品组件内部机制）+ 反复复发，启动原厂协同。证据包我打了七件套（问题概述、环境版本配套、原始日志、告警记录、已做尝试、复现条件、期望约束），其中两个关键动作：把组件日志时间戳和 NTP 校准后的标准时间对齐（消除了"日志对不上"的排查噪音），给出稳定复现的规律。转案后每半天跟进一次、每阶段向客户同步一次。根因：组件间时钟偏差导致基于时间的证书校验间歇失败——正是时间线对齐帮原厂锁定的。解决：原厂给出校准与补丁方案，我在变更窗口配合实施、验证、归档。预防：时间同步检查进所有环境初始化基线；"复现条件"从证据包可选项变成必填。 面试讲法（STAR 完整版，约 330 字）： 情境是平台组件认证间歇性失败，我按排查树把应用层、配置层、基础设施层全部排完都正常，问题反复复发，业务方已经开始担心。任务：定位并推动跨组织解决。行动分三段：第一段转判决策——命中"产品层+反复复发"标准，决定协同华为原厂，我打了一份七件套证据包：概述、版本配套、原始日志、告警、已做尝试、复现条件、期望约束——一次给全，因为原厂最烦挤牙膏式补充，材料质量决定二线速度；第二段关键取证——我特意做了两件事：把组件日志时间戳和 NTP 校准后的标准时间对齐（后来证明这正是破案关键：组件间时钟偏差导致证书校验间歇性失败），并给出了稳定复现的时间规律；第三段跟踪闭环——转案后我每半天跟进一次进展、每阶段向客户同步一次，原厂定位后给出补丁方案，我在变更窗口配合实施、验证恢复、归档工单。结果：问题闭环，业务恢复稳定；沉淀两条——时间同步检查写进了所有环境的初始化基线（我移动云集群的避坑清单里同源的那条），证据包模板沉淀成团队标准，复现条件变成必填项。这个案例我常讲它背后的道理：跨组织协同里，证据质量就是话语权、跟进节奏就是信任——一线的价值不是自己什么都会修，是把问题送到最短路径上并盯到闭环。

S4 工单积压优先级决策 【真实场景（周一早高峰）】

场景：周一早上 9 点，工单池同时进来五个报障：①核心业务系统全体用户登录异常；②某部门打印机连不上；③一位领导问历史数据导出方法；④某应用接口偶发超时（用户少量报障）；⑤一台监控报警的服务器磁盘 88%。 处理过程（讲解）：按"影响面 × 紧迫度 × 处理成本"三维排序。⑤磁盘 88% 是"满了就是事故"的刚性风险且清理动作成熟（truncate 日志+prune，20 分钟），先派给同事并行处理（或在等待响应的间隙做）；①登录异常影响面最大，立即进入排查（事后确认是 S1 同源的主备切换问题）；④接口偶发超时影响面中、需要时间排查，建单转二线跟进；③导出咨询是快赢——FAQ 有现成步骤，三分钟回复；②打印机是单部门影响、桌面类，转桌面支持并告知用户预期。全部五个单两小时内闭环或移交，且①和④后来确认共因（同一存储链路问题），合并处理。根因/解决：单点问题各自归因；流程上的沉淀是"共因合并"——多个报障背后同一个根因时，合并处理效率翻倍。预防：高峰期分诊动作模板化。 面试讲法（STAR 完整版，约 300 字）： 情境是周一早高峰工单池同时进来五个报障——有全体用户登录异常、有打印机故障、有领导咨询、有接口偶发超时、还有磁盘 88% 的告警。任务：在有限人手下把五个单排好序、都闭环，且不让任何一个客户觉得被冷落。我的行动四步：第一步快速分诊——每个单问清现象、范围、时间，两分钟定性，这是排序的原料；第二步三维排序——影响面 × 紧迫度 × 处理成本：磁盘 88% 是刚性风险且处置动作成熟，派同事并行先清掉；登录异常影响面最大，我立即进入排查；接口超时建单转二线；咨询类是快赢，FAQ 三分钟回复；打印机转桌面支持并给用户明确预期——快赢的先清掉，工单池肉眼可见地在缩小，客户感知就好；第三步透明沟通——每个报障人都拿到"排在第几位、预计什么时候处理到"的答复，等待不可怕，不知道等多久才可怕；第四步记录复盘——五单全部进工单，事后复盘发现登录异常和接口超时是同一存储链路的共因，合并处理。结果：两个小时内五单全部闭环或移交，无一投诉。沉淀两条：P1 级无条件插队、承诺的时间点必须兑现——排序可以灵活，信用不能动。这题面试官考的其实是"资源有限时的决策框架"，我的答案是三维排序加透明沟通加共因合并。

S5 重复问题知识库化 【真实项目】

场景：内部 IT 支持期间，同类问题反复出现——软件安装报错、打印机配置、网络连接、账号权限，每周消耗大量响应时间；售前与研发侧的方案类咨询同样高度重复。 处理过程（讲解）：我的处理分三步递进。第一步统计选题：从工单和被问频率统计高频 TOP 问题——数据说话，不拍脑袋选题；第二步标准化沉淀：每个问题按"现象、原因、解决步骤、截图"四段式写成 SOP/FAQ，写完念给非技术同事听一遍、听不懂就重写——可读性是自助化的生命线；第三步升级自助化：IT 知识库稳定运行后，把这套打法升级到 RAG——文档入库、切分调优、系统提示词压幻觉、评测集验证（第 11 章全流程），检索问答替代了翻文档。根因：重复的根源是"知识只存在于处理者脑中"。解决：知识外置为可检索资产，"第二次出现就写下来、第十次出现让用户自己查到"。预防/度量：四指标运营面板（使用规模、命中率、节省工时、内容健康度），重复答疑量实打实下降。 面试讲法（STAR 完整版，约 310 字）： 情境是我做内部 IT 支持时，同类问题反复出现——软件报错、打印机、账号权限，每周吃掉大量时间；售前研发侧的方案咨询同样重复度很高。任务：把"重复消耗"变成"自助服务"。行动三步递进：第一步统计选题——从工单记录统计高频 TOP 问题，让数据决定知识库先写什么，不拍脑袋；第二步标准化——每个高频问题按"现象、原因、步骤、截图"四段式写成 FAQ，我有个自检习惯：写完念给非技术同事听一遍，听不懂就重写——自助文档的读者不是专家，可读性是生命线；第三步升级自助化——传统知识库稳定后，我把全部文档升级进了 RAG 智能问答：敏感信息脱敏入库、切分参数调优、系统提示词加"不知道条款"压幻觉、20-50 题评测集验证，检索问答从此替代翻文档。结果：重复答疑量明显下降，新员工学习周期从"翻一个月文档"缩短到两三周，售前答疑从"等人回复"变成"秒级自查"；更重要的是形成了正循环——问题处理完沉淀进库，库越厚被打断越少。这个案例我讲的时候会点题：它是我简历"降低重复答疑成本"的来路，也是我认为支持岗最有价值的进阶方向——不是把问题处理得更快，而是让一类问题不再需要被处理。

S6 夜间值班重大告警响应 【真实项目】

场景：凌晨 1 点，值班手机收到磁盘告警——某业务服务器磁盘使用率 92% 且持续上涨，若写满将影响业务写入。 处理过程（讲解）：按告警响应七步的夜间版执行。确认（2 分钟）：看告警详情确认真实且增速快，非误报非维护窗口；定级：影响面是"即将写满导致业务写入失败"，P1 处理但按夜间纪律动作保守；定位（10 分钟）：df -h 锁定分区，du 下钻加 docker system df，确认是应用日志堆积（日志无轮转上限）；处置：先做安全清理——truncate 日志文件原地释放（不用 rm 防句柄问题）、悬空镜像 prune，不碰业务数据，磁盘回落到 60% 以下；通报：按模板向值班群和客户值守人通报"现象、已处置、水位回落、明日补根因"；闭环：第二天补根因——应用调试日志未关加无轮转配置，配 daemon.json 日志限额、应用侧关调试日志，处置过程记录归档并完成交接说明。根因：日志无上限+调试级别未关闭。解决：清理释放+限额根治。预防：日志限额进基线、磁盘告警三级前移（80/85/95）。 面试讲法（STAR 完整版，约 300 字）： 情境是凌晨一点值班手机响了，磁盘 92% 且持续上涨，写满就会影响业务写入——这是少数"拖不得且后果不可逆"的告警。任务：在半睡半醒的状态下安全处置，不把问题变大。我的行动按夜间纪律四步：第一步确认——两分钟内确认告警真实、增速快、不在维护窗口，定级 P1；第二步定位——df -h 锁定分区，du 下钻加 docker system df 十分钟内确认是应用日志堆积，日志没有轮转上限；第三步保守处置——只做安全动作：truncate 原地清空日志立即释放（不用 rm，防进程持句柄不释放）、清理悬空镜像，全程不碰业务数据、不做任何重启变更——夜里做止损和保底，不做创新和激进动作，这是我驻场两年刻进本能的纪律；第四步通报闭环——磁盘回落到 60% 以下后，按模板向值班群和客户值守人通报处置结果，第二天补根因：应用调试日志未关加无轮转配置，配上了日志限额、应用侧关了调试日志，全过程记录归档完成交接。结果：从告警到水位安全 20 分钟，业务零中断，客户第二天看到的是一份完整处置报告而不是一次惊魂。沉淀：日志限额进基线、磁盘告警三级前移到 80%。这个案例我讲的价值点：夜间应急的最高境界不是处理得多漂亮，是让问题停在它该停的大小。

---

14.2 通用技术案例（12 个，STAR 压缩版，讲"我处理过类似的"）

C1 CPU 负载高定位 【经典故障】

排查：uptime 对比核数（8 核 load 超 8 才是真满载）→ top 按 P 拿进程 → 看 us/sy/wa 分布（us 高查应用、wa 高查磁盘 IO）→ top -Hp 下钻线程。单线程打满大概率死循环。 根因：应用死循环/异常进程（挖矿）/IO 传导。 解决：重启止损、dump 线程栈交开发；异常进程 kill 并查入侵入口。 预防：CPU 分级告警（70/85/95）、可疑计划任务巡检。 STAR 讲法（约 250 字）："我处理过类似的。值班时收到 CPU 持续 90% 的告警，业务响应变慢。我先 uptime 确认真的超了核数、不是误报；top 按 P 定位到一个 Java 进程 us 接近满载——方向从系统收敛到应用；top -Hp 下钻发现单线程打满，典型死循环特征。止损动作重启服务恢复业务，事后 dump 线程栈配合开发定位到一段正则回溯爆炸。复盘给服务加了分级告警，推动开发上了热点代码 review。这单我常讲的经验：CPU 四个指标的分布比总数信息量大——us/sy/wa 告诉你去查谁。"

C2 内存不足与 OOM 【经典故障】

排查：free -h 看 available → dmesg -T | grep -i "out of memory" 拿 OOM killer 记录（被杀进程、时间）→ ps aux --sort=-%mem 找内存大户 → vmstat 1 5 看 si/so 换页。 根因：内存泄漏（RSS 缓慢爬升曲线）/堆配置过大。 解决：重启止损、调限额；泄漏转开发。 预防：内存 80% 告警、容器统一 memory limit、RSS 趋势监控。 STAR 讲法（约 250 字）："我处理过类似的。一个业务进程周期性莫名被杀，开发查了几轮代码没结果。我介入先找证据：dmesg 里明确有 OOM killer 记录、被杀的就是那个进程——直接定性系统内存耗尽而非应用崩溃；free 看 available 见底、ps 锁定一个 Python 服务 RSS 异常，回看监控曲线是三天从几百兆爬到 4G——缓慢爬升，典型泄漏形状。止损加了定时重启临时方案，根因复盘是代码缓存无上限，修复后我把内存趋势告警加了进去。经验句：OOM 类故障 dmesg 是第一证据源，泄漏靠曲线斜率发现而不是等 OOM。"

C3 磁盘满（含 inode）【经典故障】

排查：df -h && df -i 分清容量满还是 inode 满 → du -sh /* | sort -h 逐层下钻 → lsof | grep deleted 查已删未释放句柄。 根因：日志无轮转堆积/镜像层堆积/句柄未释放。 解决：truncate 释放（比 rm 安全）、prune 清镜像、句柄问题重启进程。 预防：logrotate 7 天保留、80% 告警、清理进 crontab。 STAR 讲法（约 250 字）："我处理过类似的。磁盘 100% 告警，我第一个动作同时跑 df -h 和 df -i——海量小文件场景 inode 先耗尽，只看 df -h 会误判'没满啊'。这次是容量满，du 逐层下钻锁定一个几十 G 的日志文件，日志切割配置没生效。释放我用 truncate 而不是 rm——rm 后进程持句柄空间不回来，truncate 原地清空立即生效、对在线服务安全。复盘三件事：logrotate 按天切割、磁盘 80% 告警、'清大文件先 truncate'写进 SOP。这单讲的是工具行为差异也是运维知识——rm 和 truncate 看似都是删，工程效果完全不同。"

C4 服务 502/504 【经典故障】（结合银行平台真实经历）

排查：先分诊——502 是后端连不上/挂了、504 是连上了但超时；tail nginx error.log（connect() failed=502，upstream timed out=504）→ ss -lntp 看后端监听（重点看是不是只听 127.0.0.1）→ curl 本机直连后端绕开 Nginx 验证。 根因：502——后端挂/监听地址错；504——慢 SQL/依赖慢/线程池耗尽。 解决：502 拉起后端修监听；504 定位慢源，临时放大超时只缓解不治本。 预防：后端多副本+健康检查、超时标准化、慢查询监控。 STAR 讲法（约 270 字）："这个我在银行平台真实处理过。用户报接口报错，我按从入口往里走：curl 入口通——Nginx 活着；telnet 后端 8080 通——网络没问题，502 那种'连不上'排除了；jps 确认 Java 进程在、监听正常，疑点收敛到应用内部，翻日志看到数据库连接报错；顺藤摸瓜是 Vastbase 主备切换后连接串没更新——和 S1 是同源根因，修正配置重启恢复。总结两条：502/504 第一判断永远是分清'连不上'还是'连上了但慢'，方向完全不同；从入口一层层收敛，每步排除一层，比跳着猜快得多。"

C5 K8s 节点 NotReady（真实：镜像拉取）【真实项目】

排查：kubectl describe node 看条件 → kubectl get pods -n kube-flannel -o wide 看 CNI 状态——ImagePullBackOff 一目了然 → describe 看拉取失败的具体镜像和报错。 根因：内网海外镜像不可达→CNI 起不来→节点网络未配置→NotReady（九成 NotReady 是镜像问题）。 解决：kubectl edit daemonset 全局替换成内网仓库镜像；三层镜像策略（内网仓库/公共仓库/二进制兜底）。 预防：先 CNI 后 worker 的部署顺序、镜像清单预导入。 STAR 讲法（约 260 字）："这是移动云项目真实踩的。worker join 后全部 NotReady，部署卡住。我先看范围——三台全 NotReady 指向共性问题；直接看 kube-flannel 的 Pod，ImagePullBackOff——九成的 NotReady 到这步见分晓；describe 确认海外镜像内网拉不下来。解决是 edit DaemonSet 把镜像全局替换成内网仓库地址，Pod 起来后节点几分钟内 Ready。沉淀两条写进了避坑清单：先 CNI 后 worker 的顺序铁律、镜像清单预导入。这个案例我讲的时候会给出经验句：遇到 NotReady 先查 CNI Pod 的镜像状态，九成问题在那里终结。"

C6 Pod 全量重启变 Pending（话术案例）【经典故障】

排查：kubectl get pods -A 看全局大面积 Pending（"全量"分布本身就是线索）→ describe 看 Events：FailedScheduling、Insufficient resources。 根因：公共 Secret 变更触发 200+ Pod 同时重启，瞬时资源需求远超集群容量。 解决：分批拉起——每次一个模块约 20 个，稳定 3 分钟再下一批，约 10 批半小时恢复。 预防：公共配置变更改滚动（每批 10 个）、预留重启水位、低峰窗口。 STAR 讲法（约 260 字）："我处理过类似的，原型是经典话术案例。一次改公共挂载的证书 Secret 触发两百多个 Pod 同时重启，全部 Pending，业务中断。我看到的是全命名空间大面积 Pending——'全量'这个分布本身就是线索，不是单应用问题；describe 任一 Pod 明确写着 FailedScheduling、资源不足——问题不在 Pod 在调度层，全量并发重建挤爆了集群。恢复策略分批拉起：每批 20 个、稳定 3 分钟再下一批，十批左右半小时恢复。复盘把公共配置变更改成滚动方式并预留重启水位。这单背后的道理我特别爱讲：K8s 的声明式自愈在'全量并发重建'场景反而是放大器——自动化越强越要敬畏变更。"

C7 证书 SAN 缺失（真实：多 master 改造）【真实项目】

排查：两条命令定分叉——curl -k https://VIP:16443/version 通（网络/负载均衡/apiserver 全正常）+ kubectl 报 x509（问题锁定证书校验层）→ openssl x509 -in apiserver.crt -text 看 SAN 字段：没有新 VIP 和 master02/03。 根因：kubeadm 证书 SAN 范围在签发那一刻固定，后续新增入口不在里面。 解决：补 certSANs → 移走旧证书（不移不会重建）→ kubeadm init phase certs apiserver 重签 → 杀 apiserver 容器让 kubelet 拉起 → SAN 回写配置。 预防：改集群入口先想证书；初始化就把 VIP 写进 certSANs（移动云项目这么做了，坑没再出现）。 STAR 讲法（约 280 字）："这是我印象最深的真实故障，因为它把'两句话定位'的价值体现到极致。单 master 升三 master 后用 VIP 连集群报 x509。我先 curl -k 跳过校验访问——正常返回，两秒证明网络和 apiserver 全好，问题精确切割到证书层；openssl 看证书 SAN，果然只有老地址。解决按三步：改 kubeadm 配置补全 certSANs、移走旧证书（不移 kubeadm 不会重建）、init phase certs 重签后重启 apiserver，kubectl 恢复；最后 SAN 回写配置防续期再丢。教训规则化：证书的有效范围在签发那一刻就定了——后来移动云初始化直接把 CLB VIP 写进 certSANs，这个坑彻底消失。把踩过的坑变成团队的前置设计，是故障复盘最大的价值。"

C8 时间不同步认证失败（真实）【真实项目】

排查：间歇性故障先找"变化的变量"——多节点逐个 timedatectl 对比，个别节点偏差秒级 → chronyc sources -v 发现问题节点没配源或服务没起。 根因：TLS 证书校验对时间敏感，时间偏差让校验落在有效窗口外，认证时好时坏。 解决：全节点 chrony 统一指内网 NTP，偏差回到毫秒级。 预防：时间同步检查进初始化基线和巡检；证书类问题排查清单第一步固定"先对时间"。 STAR 讲法（约 250 字）："移动云真实踩过。节点间认证时好时坏、日志时间戳乱跳——间歇性问题最磨人。我的直觉先押时间，因为证书认证对时间敏感：逐台 timedatectl 对比，个别节点偏差到秒级，行为模式和偏差漂移吻合；chronyc 一查，问题节点没配 NTP 源。修复后 tracking 偏差毫秒级，认证再未复现。沉淀：'时间同步校验'进初始化基线必查项，也进了避坑清单——总结成一句话'先对时间，再谈认证'。这个案例说明间歇性故障的排查入口是找不一致，多节点横向对比是最快的找法。"

C9 SSH 登录慢 【经典故障】

排查：ssh -v 分段计时——TCP established 很快、卡在密码提示前 = 服务端连接后在做慢事；最常见是 UseDNS 反向解析在内网等超时，叠加 GSSAPI 协商。 根因：sshd 默认 UseDNS 开启，内网无反解记录等超时。 解决：sshd_config 关 UseDNS 和 GSSAPIAuthentication，重启 sshd，time ssh 对比验证——十几秒降到秒回。 预防：两项进系统初始化基线。 STAR 讲法（约 220 字）："我处理过类似的。一批机器 SSH 要等十几秒出密码提示，登上去一切正常——'慢在登录前、正常在登录后'这个形态本身就是线索。ssh -v 打开详细输出分段看：TCP 秒连，卡在密码提示前，说明不是网络，是 sshd 自己在干慢事——最常见就是 DNS 反解在内网干等超时。关掉 UseDNS 和 GSSAPI，time 验证秒回，配置进初始化基线。这个案例讲方法：交互类'慢'先用 verbose 模式分段计时，卡在哪一段一目了然，比瞎猜快十倍。"

C10 网络不通分层排查 【经典故障】（详见第 9 章命令树）

排查：ip a 本机地址 → ip r 路由网关 → ping 网关（网关是分水岭：不通=本机/二层，通=继续往外）→ ping 对端 → telnet 端口（ping 通 telnet 不通=端口/防火墙/监听问题）→ traceroute/mtr 看断在哪跳（假丢包识别）→ curl -v 七层验证 → tcpdump 终极取证。 根因：按层分布——地址配置/路由/ACL 防火墙/服务监听/DNS。 解决：收敛到哪层修哪层；DNS 问题应急三板斧（换公共 DNS/hosts/清缓存）。 STAR 讲法（约 240 字）："网络问题我的标准打法是命令树逐层收敛，每条命令回答一个'是不是'。举例：用户报访问某系统不通——我先 ping 网关通、ping 对端通，说明三层可达；telnet 服务端口不通，问题收敛到四层——三个方向查：服务起没起、监听是不是 0.0.0.0、防火墙安全组放行没放行；一查是发布后安全组没加规则，补上即通。我的习惯是每个结论都有命令输出支撑，给客户的答复是'断在第几层、什么原因'而不是'好像网络有问题'——分层排查的终点是一句可以负责任的话。完整的命令树和工单五步我在第 9 章有系统整理。"

---

C11 存储挂载卡死（上传频繁卡死）【经典故障】

排查：这类"指标正常但业务卡死"的故障先排除本机资源（top/free/iostat 过一遍无实锤）→ 复现时敲 df -h——本地挂载点秒回、网络存储挂载点直接挂住不返回，命令卡死本身就是诊断信息：内核在等那个挂载点的 IO → /var/log/messages 里大量 "NFS: server not responding" 佐证 → 应用日志同步看到上传超时。 根因：存储设备高负载时连接抖动+参数不兼容，NFS 硬挂载让进程进入 D 状态无限等待。 解决：存储方优化网络与超时重传参数，恢复后大量文件上传压测验证。 预防：挂载配置 soft/timeout 兜底、应用加超时降级、挂载点可达性监控。 STAR 讲法（约 260 字）："我处理过类似的。文件上传频繁卡死，但 CPU 内存磁盘指标都正常——这种'指标正常业务卡'要从本机资源转向外部依赖。复现时敲 df -h 抓到关键现象：本地挂载秒回、网络存储挂载点挂住不返回——df 卡死本身就是证据，说明 IO 阻塞在存储链路而不是本机。messages 日志大量 NFS not responding 佐证，和应用日志的上传超时、近期改过的重试参数全对上了。根因是存储高负载抖动加 NFS 硬挂载无限等待，存储团队调参后压测通过。这单的收获：排查命令的异常行为和它的输出一样有价值——命令卡住不返回，本身就是一层证据。"

C12 Keepalived 脑裂（结合银行真实防范经验）【经典故障】

排查：确认一条命令——两台机器分别 ip addr，两边都绑着 VIP 就是脑裂实锤（正常只该在 MASTER 一方）→ 查 VRRP 通告链路：组播/单播报文是否被交换机或防火墙拦截、advert_int 配置是否匹配——脑裂的直接诱因几乎都是"备节点收不到主的通告"。 根因：主备之间 VRRP 报文不可达（网络分区/组播被禁/防火墙拦截），备节点超时自我升级，而主还活着。 解决：临时定一方降级（停一端 keepalived 或摘 VIP）恢复流量唯一性；根治是打通通告链路（放行 VRRP 协议号 112 或改 unicast）。 预防（我在银行项目的真实四招）：① vrrp_script 检测真实服务端口（16443 有没有监听）而不是 keepalived 进程本身；② priority 拉开 100/90；③ 通告走管理平面保证链路质量；④ 上线前主节点关机实测 VIP 秒级漂移。 STAR 讲法（约 270 字）："脑裂这题我既有理论也有防范实践。先讲原理：Keepalived 主备靠 VRRP 通告维持，通告链路被打断就会出现两边都是 MASTER、都绑 VIP 的脑裂，流量时通时断——确认方法两台分别 ip addr，都绑 VIP 就是实锤。再讲我在银行项目的实践：单 master 升三 master 时我配的 Nginx+Keepalived 前置层，防脑裂四招——健康检查脚本盯的是 16443 真实监听而不是 keepalived 进程（keepalived 活着不代表代理链路活着）、priority 拉开 100 比 90 防抢占抖动、通告走独立管理平面、上线前主节点直接关机实测 VIP 秒级漂移加集群正常。'高可用是设计出来的更是演练出来的'这句信条就是从那次实测来的。"

---

14.3 案例使用地图：按岗位类型选案例 【必背】

标准回答： 面试前的 10 分钟选案动作——按 JD 类型从案例库挑 2-3 个"最对味"的，比背完全部更重要的是选对。驻场/客户支持类 JD（金融政企厂商生态）：主打 S1（报障全流程，证明闭环能力）+ S3（原厂协同，证明跨组织能力）+ S2（情绪应对，证明服务软实力）——三连覆盖"技术闭环+协同+服务"；IT 支持/Helpdesk 类 JD：主打 S5（知识库化，证明自助化能力）+ S4（优先级决策，证明多任务能力）+ C3 磁盘满（桌面侧也高频）——第 15 章的 Helpdesk 行为题配套；云平台技术支持类 JD：主打 C5（NotReady 真实项目，证明 K8s 背景）+ C7（证书 SAN，证明深度）+ S1（报障流程，证明支持素养）——技术和服务的双重证明；带知识库/AI 味的 JD：主打 S5（知识库化）+ C8（时间同步，真实+反直觉）+ 第 11 章项目——把差异化打满。通用原则三条：每个 JD 准备"一个真实项目案例 + 一个通用案例 + 一个服务软场景"的组合，真实案例建信任、通用案例显广度、软场景贴岗位；被问"还有什么例子"时永远有下一层——本章 18 个案例够撑两轮深挖；讲完任何案例主动加一句沉淀收尾（检查项/SOP/知识库），这是我的签名动作。

追问链：

• 追问1：面试官问的案例方向你没准备过怎么办？ → 答：用框架兜住，别慌。万能框架（先响应→止损→定位→复盘）适用于任何故障场景题——先按框架给结构，再用"同类经验"迁移：没处理过 Oracle 的故障但处理过 MySQL 的，排查分层思想一致；没做过某行业客户但做过银行客户，服务沟通方法一致。诚实亮边界："这个具体产品我没碰过，但我处理同层级问题的方法是 XX，我可以讲一遍我上手的路径。"——面试官测的是排障思路和学习能力，不是产品百科；坦诚+方法论永远比硬编安全，这也是我兜底话术的一贯原则。

14.4 面试官最爱追问的 10 个问题（支持场景版）

1. "讲一个你印象最深的故障/客户" → 首选 S1 批量登录失败（真实+全流程+有沉淀）；讲客户类首选 S2 情绪应对（服务能力）或 S3 原厂协同（跨组织能力）。
2. "故障时你第一件事做什么？" → 先响应客户：确认收到、四要素、同步预期——支持岗的第一动作是响应不是技术；然后止损：有备切换、能回滚先回滚。
3. "怎么定位根因的？" → 三板斧：监控看故障时刻曲线、日志看报错证据、变更记录问"最近改了什么"（60% 故障和变更相关）；分层收敛，每层拿事实。
4. "这次故障你的责任是什么？" → 主动担责+讲改进（坑变成检查项/SOP/告警），不甩锅不说"不是我干的"。
5. "怎么保证不再发生？" → 复盘四件套：根因改进、监控补盲、流程固化（SOP/检查单）、知识沉淀（FAQ/知识库）——每单闭环后自问"会不会复发"。
6. "客户对处理结果不满意怎么办？" → 先了解不满意的具体点（结果没达预期还是过程体验差）→ 能补救立即补救并给时间点 → 结果之外的体验问题复盘改进 → 用后续服务重建信任（S2 的四步）。
7. "转出去的问题出了纰漏算谁的？" → 转派后我仍是第一责任人——跟踪、验证、客户沟通都是我的；二线方案的技术正确性由二线负责，但"这个方案最终有没有解决客户问题"的闭环责任在我——接口人制度的意义就在这。
8. "这些都是你一个人处理的吗？" → 如实分层：银行项目讲"一线我处理、疑难协同华为原厂、客户侧三方协同"；云项目讲"我主导、开发配合"——把协作结构讲清楚本身就是协作能力的证明。
9. "给你一个没见过的场景题（现场模拟），你怎么处理？" → 先复述场景确认理解（"我确认下：现象是 XX、影响 XX、没有变更信息，对吗？"——这本身就是支持岗的职业动作），然后按万能框架给结构：先响应（安抚+预期）、再止损（可回退动作）、再定位（按层级排查，说出每层用哪条命令排除什么）、后复盘（沉淀）。卡住时诚实说"到这一层我需要查证/求助二线"——面试官模拟的就是真实值班，表现出的"有序+诚实"比知道所有答案更接近满分。
10. "你处理的故障里，哪次对你后来的工作习惯影响最大？" → 讲证书 SAN（C7）——"改集群入口必须先想证书"从单次教训变成了前置设计（移动云初始化直接写进 certSANs）；或讲 S6 夜间磁盘——"日志限额进基线"让同类问题根除。答题落点：故障对我的价值不是惊险故事，是长在工作习惯里的检查项——这句话本身就是答案的高分收尾。

14.5 章末自测清单（快问快答）

1. 支持场景回答第一句话？ → 框架第一句："我的原则是先响应客户、再止损、再定位、后复盘"——第一动作是响应不是技术。
2. 报障四要素？ → 现象、时间、范围、最近变更——"最近改了什么"命中率最高。
3. S1 批量登录失败的根因？ → Vastbase 主备切换后应用连接串未跟随——依赖层日志抓到的证据。
4. 登录排查链六层顺序？ → 用户侧网络→入口 Nginx/证书→后端进程→依赖（DB/Redis）→数据库主备→中间件证书。
5. 情绪激动客户四步？ → 接情绪不对抗→15 分钟一次信息同步→解决给交代→事后复盘修复关系。
6. 原厂证据包七件套？ → 概述、版本配套、原始日志、告警、已做尝试、复现条件、期望约束。
7. S3 破案的关键动作？ → NTP 校准后的时间线对齐+稳定复现规律——时钟偏差导致证书校验间歇失败。
8. 五个报障排序三维？ → 影响面 × 紧迫度 × 处理成本；两条纪律：P1 无条件插队、承诺时间必须兑现。
9. "共因合并"是什么？ → 多个报障同一根因时合并处理——分诊后要看报障之间有没有关联。
10. 知识库化三步递进？ → 统计选题（数据说话）→四段式标准化（可读性自检）→RAG 自助化升级。
11. FAQ 四段式？ → 现象、原因、解决步骤、截图——写完念给非技术同事听。
12. 夜间应急纪律一句话？ → 夜里做止损和保底，不做创新和激进动作；大动作留给白天。
13. S6 夜间磁盘处置为什么用 truncate？ → 原地清空立即释放；rm 后进程持句柄空间不释放。
14. CPU 排查三部曲？ → uptime 对比核数 → top 按 P → top -Hp 看线程；us/sy/wa 分布定方向。
15. OOM 第一证据命令？ → dmesg -T | grep -i "out of memory"；泄漏靠曲线斜率发现。
16. 502 和 504 一句话区别？ → 502 后端连不上/挂了；504 连上了但超时——排查方向完全不同。
17. NotReady 第一排查点？ → CNI Pod 状态，九成是镜像拉取失败。
18. 证书 SAN 案例三步解决？ → 补 certSANs → 移走旧证书重签 → SAN 回写配置；教训"改集群入口先想证书"。
19. 间歇性故障排查入口？ → 找"变化的变量"——多节点横向对比（时间/配置/版本）。
20. 每个案例收尾必须落在？ → 沉淀了什么——检查项、SOP、告警、FAQ、知识库条目；"把坑变成别人的护栏"是支持岗最有辨识度的习惯。

14.6 本章使用红线（面试前再读一遍）

1. 来源口径不混：S1/S3/S6 和 C5/C7/C8 是【真实项目】放开讲细节；S2/S4/S5 是【真实场景】（真实经历改编脱敏，讲时自然叙述不强调"改编"）；C1-C4/C6/C9/C10 是【经典故障】用"我处理过类似的"口径。讲错口径比讲不出更伤。
2. 第一句话永远是响应句：支持岗的素养信号从"先响应客户"开始——技术岗可以上来就 top，支持岗不行。
3. 数字克制：恢复时长、工单量只讲有把握的数——被追一句"怎么统计的"就露馅；"约 40 分钟""几百单/年"这类量级表述最安全。
4. 命令讲"为什么"：每条命令能说出"我用它排除/确认了什么"——只报名词不讲判断依据等于背书。
5. 复盘收尾习惯：每个案例最后一句落在沉淀物上——巡检项、SOP、FAQ、告警、知识库条目；这是我全部经历里最有辨识度的标签，也是支持岗"体系化"的证明。
6. C11 上传卡死的关键证据？ → df -h 里网络存储挂载点卡住不返回——命令卡死本身就是诊断信息。
7. C12 脑裂确认与预防？ → 两台 ip addr 都绑 VIP 实锤；防四招：检测真实端口、priority 拉开、通告链路保障、上线演练。
8. 框架示范的 60 秒结构？ → 原则句→四要素+预期→分层排查→恢复优先→验证同步→根因预防入 FAQ。
9. 案例讲述节奏？ → 框架 10%、情境 15%、行动 55%、结果沉淀 20%——行动里必须有"我"的决策与命令。
10. 讲案例的签名收尾动作？ → 每个案例最后一句落在沉淀物：检查项/SOP/告警/FAQ/知识库条目。
11. 客户沟通微话术三连？ → 开始给预期（"X 点内给第一份进展"）、中间同步进展（已定位层/正在做/预计时间）、结束给根因和预防——节奏感就是专业感。
12. "这个问题归你们管还是归我们？"怎么答？ → 先帮解决再说归属：能指导的先指导，处理完工单里如实记录根因归属，同步时用事实不指责——归属清晰+态度到位两头都不丢。
13. 面试前选案例的动作？ → 按 JD 类型配"一个真实项目+一个通用+一个软场景"三连——真实建信任、通用显广度、软场景贴岗位。
14. 场景题完全没见过怎么办？ → 复述确认+万能框架给结构+同类经验迁移+诚实亮边界——面试官测的是思路和学习力，不是产品百科。
15. 通俗讲 RTO/RPO 的三问？ → 数据丢了会怎样？能接受多长恢复时间？能接受丢多少？——三问定保护层（第 8 章数据保护分层的入口）。
16. 案例速查总表的用法？ → 面试前扫一眼选 1-2 个最熟的展开，现象、第一条命令、根因、来源四列——条件反射来自这张表。