Appearance
第7章 监控告警响应与值班交接
对应简历：技能第 7 条「具备 Prometheus + Grafana 监控告警的日常使用经验，能根据告警与日志快速定位问题层级」/ 工作职责实-3「负责平台日常巡检、监控告警响应与版本升级配合，保障试点业务稳定运行」/ 项目一 P1-3「负责日常巡检与 Prometheus 监控告警响应，配合版本升级与割接保障」/ 项目三 P3-2「部署监控告警体系与 Kuboard 可视化平台，日常通过告警与平台快速定位处理异常」。 支持版定位：以运维版 07 为底稿改造——告警响应流程（收到→分级→响应→升级）、值班与交接、大盘使用是主梁；Prometheus 架构压缩为 1 节（原理够用即可），告警分级与响应动作全量展开。告警只是起点，"响应得专业"才是支持岗的价值所在。
术语约定：Kubernetes（以下简称 K8s，仅正文简写）。
7.1 Prometheus 架构一节版 【必背】
标准回答： Prometheus 是 CNCF 开源监控系统，我按数据流一条线讲它的六大组件，这条线也是判断"告警响没响"的排查地图：Exporter 是采集端，把系统状态转成指标暴露出来——node_exporter 采主机（我们全节点部署、9100 端口）、kube-state-metrics 采 K8s 对象状态；Prometheus Server 是核心，按 scrape_configs 周期抓取各目标的 /metrics 接口存进内置时序数据库 TSDB，并周期评估规则文件；Rules 规则文件定义告警条件，条件满足且持续了 for 设定的时间就推给 Alertmanager；Alertmanager 负责降噪和分发——分组（同类告警合并成一条）、抑制（高级别压掉同根因的低级别）、静默（维护窗口临时屏蔽），然后路由到邮件、企业微信等通知渠道；Web UI 和 Grafana 负责查询和可视化。数据流一句话：Exporter 暴露指标 → Server 拉取存储 → 规则评估 → Alertmanager 降噪 → 渠道通知。我的两个项目两种形态：银行项目是 BCS 平台配套的 Prometheus 2.33.5 + Node Exporter 1.3.1 基础监控（部署在 monitor 命名空间，ARM 镜像离线导入）；移动云项目是我自己设计的混合部署——独立监控节点二进制部署 Prometheus + Grafana（不占集群资源、故障隔离，"观察者不能和被观察者一起死"），集群内跑 kube-state-metrics，全节点 apt 装 node-exporter。从配套部署到自选型设计，这条演进线我常讲。
追问链：
- 追问1：为什么用 pull 拉取模型？ → 答：pull 把控制权放在采集端，三个实际好处：目标列表集中管理、抓取频率统一可控；目标挂了 Server 天然感知——up 指标变 0 就是现成的存活告警，不用额外心跳；避免大量 Agent 向 Server 打流量的回压问题。我们的规模（7 节点）用 static_configs 静态配置目标列表最直观可控，节点规模上去或上了自动扩缩容再换 kubernetes_sd 动态发现——"什么时候该换、为什么现在不换"我能讲清楚，这比背概念重要。
- 追问2：Prometheus 自己挂了谁监控它？ → 答：分层答。我们小规模环境是单节点部署加 systemd Restart=always 自动拉起，配 up 指标兜底（Server 挂了它采不了别人，但云监控还看着这台监控节点）；我的架构设计里"谁监控监控者"的答案是分层互看：Prometheus 看集群、云平台基础监控看监控节点、告警通道（云监控短信）独立于 Prometheus 体系——监控告警的通道不能和被监控体系同生共死，这是我在设计移动云监控时特意留的一条命脉。
- 追问3：告警规则里的 for 是干什么的？ → 答：for 定义"条件持续满足"的确认期：表达式为真后先进入 pending 状态，持续满 for 时长才 firing 并真正通知。作用是防抖——CPU 尖峰 10 秒就过去、网络抖一下 up 瞬间为 0，这类毛刺不该半夜叫醒人。窗口 [5m] 平滑曲线、for 2-5 分钟确认持续性，两层过滤后还报警的基本是真问题。我们所有告警规则上线前都做过全链路演练——故意停一个 node-exporter 验证告警真能送达手机和群里，"没演练过的告警等于没配"这条我一直在强调。
7.2 告警分级体系与响应要求 【必背】
标准回答： 告警分级是响应流程的地基，我的分级按"影响面 × 紧迫度"定四级，每级都有明确的响应时限和动作要求。P1 紧急：业务中断或安全事件——节点失联、核心服务不可用、磁盘将满、安全告警；要求 5 分钟内响应、立即开始定位、处理不收敛 30 分钟内升级（第 6 章 6.11 的升级机制），处置过程每半小时向客户同步一次。P2 重要：核心功能受损但有影响、性能明显劣化——副本不满、CPU 持续高位、接口错误率上升；30 分钟内响应、2 小时内给阶段结论。P3 一般：单点异常暂不影响业务——单个非核心 Pod 重启、低危资源水位；4 小时内响应、当日内闭环或转工单排期。P4 提示：记录性信息——证书剩余 30 天、容量趋势提醒；纳入巡检跟踪即可，不打扰值班精力。分级的落点在通知渠道：P1 电话+短信直达值班人，P2 群消息+提醒，P3/P4 进面板和日报。分级之外我坚持一条纪律：每条告警必须有人认领——没人认领的告警要么删要么降级，"发给所有人就是发给没有人"，告警体系最怕的就是响多了没人当真。这套分级我在银行驻场和移动云集群都在用，区别只是收件人名单和渠道配置。
追问链：
- 追问1：分级标准怎么定才不是拍脑袋？ → 答：三个依据。一看影响面：影响全部用户/核心业务的最高级，影响单用户单功能的中级，纯记录性最低级——判断时问"客户业务此刻受损到什么程度"；二看恢复难度：有自动自愈机制的（K8s 重启、CLB 摘除）可以降半级观察，需要人工干预且无预案的升级；三看时间敏感度：磁盘这类"满了就晚了"的刚性资源敏感，容量趋势类不敏感。我定级时的习惯动作是先打开大盘看一眼实际影响——告警说的和业务真实的受损程度有时不一致（阈值敏感型告警可能虚高），"先看一眼再定级"能避免两级误判。分级本身也要定期复盘校准：每月看告警统计，误报多的降级、漏报的补规则——分级是活的，不是定完就不管。
- 追问2：同时收到 P1 和 P2 告警，先处理哪个？ → 答：先 P1，但要做得专业而不是简单切换。我的动作：P2 告警先"认领挂起"——在群里回一句"P2 的 XX 告警我看到了，先处理 P1 的业务中断，P2 预计 X 点后跟进"，让团队和客户都知道这单有人管、有预期；然后全力处理 P1；P1 稳定后立即回头处理 P2 并补上时间线。如果 P1 需要等待（比如升级原厂等待响应），期间就切回 P2——排序原则是"影响面优先、可等待的让路"，但认领挂起的动作不能省，否则 P2 在等待期变成没人管的黑洞。多告警并行的排序能力是值班的硬功夫，我在银行夜间值班时练过很多次，第 13 章"同时来五个报障怎么排"的行为题用的就是这套逻辑。
7.3 告警响应流程七步 【必背】
标准回答： 从告警响起到闭环，我的固定流程七步，每步都有明确动作和时间预算。① 确认收到（0-2 分钟）：看告警内容、级别、对象——P1 级在群里回"收到，正在看"，响应的第一价值是让监控值和客户知道"有人动了"；② 定级与影响面（2-5 分钟）：打开大盘确认告警真实性（排除误报、已知维护、静默遗漏）和实际影响范围——单节点还是全局、哪个业务，这一步防止被误报带偏；③ 快速定位（5-20 分钟）：按告警名查对应的处置手册第一步（7.4 的初判地图），把"哪里坏"收敛到一层——网络、节点、Pod、应用、数据库；④ 决策处置：有预案执行预案（重启、切换、扩容——按 SOP 不即兴），能自愈的等待自愈并盯结果，不能立即修的先降级保业务（摘流量、切备用）；⑤ 通报协同：影响业务的按模板通报（现象、影响、当前动作、预计恢复），需要二线/原厂的立即转判（第 6 章）；⑥ 恢复验证：指标回归 + 业务功能验证（不只看监控绿，要让客户实际用）才算恢复；⑦ 闭环复盘：补工单时间线、写复盘记录（时间线/根因/响应是否及时/预案是否有效）、沉淀改进（加告警、补 SOP、改预案）。七步走完，一次告警才算真正处理完——只做了前三步的叫"看了"，不叫"响应了"。
追问链：
- 追问1：半夜收到告警但看不出来是什么问题，怎么办？ → 答：按"保底动作"走，这是我驻场两年最重要的应急纪律。第一，确认告警真实性——是不是监控自身故障、是不是已知维护窗口，假告警静默并记录；第二，真实的、一时定位不了的，按影响面决策——影响业务的先做保守动作：把可疑节点摘流量、切备用路径，宁可保守不可炫技；第三，按升级路径叫人——二线、原厂值班、云厂商工单（银行项目有明确的"一线我、二线华为"分工），半夜升级不是添麻烦，是把风险控制在最小半径；第四，全过程记录时间线和动作，天亮交接时信息完整。半夜的原则我总结成一句话："夜里做的是止损和保底，不是创造和创新"——大动作留给白天和人多的时刻。这个纪律救过我：一次凌晨的存储告警，我没做任何激进操作、只做了摘流和通报，天亮后二线定位是误报相关的联动告警，如果我半夜重启了什么，反而会制造真故障。
- 追问2：怎么保证告警响应流程在团队里真的被执行？ → 答：三个抓手。第一，处置手册到告警：每条 critical/warning 告警对应一页手册——"什么含义、第一步看什么、常见原因清单、升级给谁"，值班同学拿到告警按单操作不靠猜（7.16 给了模板）；第二，演练验证：上线前停一个 exporter 做全链路演练（告警触发→通知送达→响应动作→恢复通知），流程跑通才算交付；第三，复盘闭环：每次 P1/P2 处理后复盘"响应是否及时、手册是否好用、要不要补规则"，把流程里的卡点修掉。我的观点：流程被执行的前提是流程好用且被验证过——一份没人演练过的响应流程，和没有流程一样。这三条也是我组织培训时反复讲的：支持体系的可靠性不在文档多厚，在"值班的人拿到告警后 5 分钟内知道做什么"。
7.4 告警初判地图：从告警名到问题层级 【必背】
标准回答： 值班的核心能力是"告警响了我 30 秒内知道往哪看"，我把高频告警整理成初判地图，每条按"告警名→含义→第一动作→常见根因"背。节点失联（up==0）：该节点所有采集中断——第一动作看云控制台实例状态（区分云层故障和 OS 层故障），常见根因：实例停机、网络断、node-exporter 进程死；磁盘使用率高：先 df -h 定位分区，容器环境优先查容器日志和镜像层（第 5 章 5.14），根因：日志无上限、镜像堆积、数据增长；CPU 持续高位：top 按 P 找进程，us 高查应用、wa 高查磁盘 IO，根因：业务高峰、死循环、异常进程；Pod 重启次数上涨 / CrashLoop：kubectl logs --previous 拿崩溃遗言，退出码分诊（137 OOM / 1 应用错），根因：内存限额不足、配置错误、探针过严；副本不满：describe 新 Pod 看起不来的原因（资源不足、镜像失败、探针不过），根因：扩容失败或发布异常；证书到期：按清单续期——这是"慢故障"，到期才处理就是事故；网络不可达类：第 9 章命令树接管。地图背后是同一个模式：每条告警都对应"监控指标 → 系统层级 → 第一条命令"的映射，我把它做成了值班手册的目录页，新同事拿着它也能正确响应——告警响应的知识不该只在我脑子里，这是知识库化的一部分（第 11 章）。
追问链：
- 追问1：磁盘使用率告警响了，完整处理流程？ → 答：这是我最熟悉的告警，流程五步。第一，看级别和分区：df -h 找到告警的挂载点，85% 预警级先排期、90%+ 立即处理；第二，定位大头：du -sh 逐层下钻 + docker system df 看容器侧占比，通常 5 分钟有结论——日志、镜像层、数据目录三大嫌疑；第三，分级处置：安全项先清（容器日志 truncate、悬空镜像 prune，不碰业务数据），业务数据盘紧张的走归档或扩容流程并给客户增长预期（按当前速率算"还能撑几天"）；第四，验证与防复发：处理完盯水位回落，查"为什么涨"——日志没限额？清理策略缺失？告警太晚？把根因补进基线；第五，留痕：工单记录处置过程和数据，容量类问题列入月度巡检重点观察项。整套流程我在真实工单里走过多次，从告警到释放通常 20 分钟内完成——熟练来自"两个只涨不缩的目录"这个先验认知（容器日志和镜像层），不用从零排查。
- 追问2：告警说 CPU 高，但打开大盘看是正常的，怎么办？ → 答：这种"告警和大盘对不上"是值班常见情形，按三层排查。第一层，时间差：告警触发在 10 分钟前，for 防抖期过后已经回落——这其实是告警体系的正常工作（毛刺被抓到了），处置是记录观察，连续多天同规律出现就查定时任务（备份、报表）这类周期性负载；第二层，口径差：告警的指标和大盘面板的指标可能不是同一个——告警按节点级、大盘看的可能是均值或不同窗口，核对告警规则里的 PromQL 和面板查询是否一致（第 7 章运维版的指标口径细节）；第三层，告警自身故障：规则写错（标签过滤漏了、单位错了）、评估异常——查 Prometheus 的 Alerts 页看规则状态和最近评估记录。处理完的通用动作：把这次的解释记进告警台账，下次同类疑问直接查。这题考的其实是"对监控体系自身的理解"——支持岗不仅要会用告警，还要能解释告警为什么会"骗人"。
7.5 大盘使用：值班看什么 【必背】
标准回答： 值班期间的大盘使用我按"三个时间点 + 三个层次"讲。三个时间点：接班时——按 7.7 的交接清单过一遍关键面板（节点健康、Pod 异常、告警列表），确认"接的是健康盘还是带病盘"；告警响应时——按告警对象下钻对应面板，看趋势和关联指标（磁盘告警同时看 IO 和增长速率，判断是尖峰还是持续）；交班前——再扫一遍全局面板，把异常项写进交接记录。三个层次：总览层——集群健康度一屏（节点 Ready 状态、Pod 异常计数、P1/P2 告警数），我搭的 Grafana 首屏就是按"30 秒内回答三个问题：有没有事、什么事、要不要升级"设计的；细节层——单节点资源、单服务指标、事件流，下钻入口从总览层点进去；对比层——同比昨天/上周同时段，突变比绝对值更有信息量。工具组合上我的分工：Grafana 看指标和趋势（Prometheus 数据源，Node Exporter 和 K8s 两套大盘）、Kuboard 看资源对象和操作（工作负载、日志终端、事件）、云监控看云层（ECS/CLB/云数据库的平台级告警）——三层监控互补，一次故障从"基础设施还是集群"的定位靠两层对照几秒完成。大盘的纪律：值班只看不改，大盘变更走评审——改坏了大盘等于把值班人员的眼睛蒙上。
追问链：
- 追问1：你怎么评价一块大盘做得好不好？ → 答：我的检验标准是场景化的两条。第一条，半夜测试：告警响了，值班同学打开大盘能否在 30 秒内回答三个问题——什么东西坏了、影响多大、要不要升级；达不到就是信息架构有问题（关键指标没在首屏、缺少上下文标注）。第二条，新人测试：没参与建设的人独立用大盘定位一次模拟故障，能走通说明结构自解释。我搭移动云大盘时按这两条迭代过：第一版堆了二十多个面板，实际值班时没人看得过来；重构成"总览一屏 + 按对象下钻"后，值班效率明显提升——大盘是给别人用的不是给自己看的，这句话是我做监控可视化最大的心得。支持岗面试讲大盘，能讲到"为使用者的场景设计"这个层面，就超出了"会用工具"的水平。
- 追问2：Kuboard 在你日常支持里扮演什么角色？ → 答：Kuboard 是我的操作台，和 Grafana 的分工很清晰：Grafana 管"看"（指标、趋势、告警上下文），Kuboard 管"做"（工作负载编排、扩缩容、日志终端、进容器终端）和权限审计。日常 80% 的操作我在 Kuboard 页面完成——发布回滚、看实时日志、进容器排查，页面对非 kubectl 用户友好，团队里开发同事也能安全自助地查自己的服务日志；权限上按命名空间做多级 RBAC，谁做了什么有审计记录。这个组合的意义在支持场景：客户报障进来，我开 Kuboard 定位 Pod 层问题、开 Grafana 看资源层曲线、开云监控对照云层——三个窗口就是我的三色指挥灯。部署细节（固定 master 调度、hostPath 持久化、RBAC）我有完整实操经历，被深挖可以展开（第 12 章 P3-2 单元）。
7.6 告警风暴与降噪 【理解】
标准回答： 告警风暴是值班质量的头号敌人——一次大故障触发几十条告警，真正的关键信号被淹没。我的应对分事前、事中、事后三段。事前预防三条：规则层 for 防抖（7.1 追问 3）+ 分组聚合（Alertmanager 按标签把同类告警合并——机房断网发一条而不是两百条）+ 抑制规则（节点宕机这个 critical 触发时，自动压掉该节点上所有服务不可达的 warning——它们是同一根因的衍生现象）；事中止血两条：维护窗口提前静默（计划内变更前 silence 相关告警 30 分钟，避免刷屏淹没真告警），风暴已发生时在 Alertmanager 上按标签临时静默一类，保住 P1 通道的注意力；事后治理：复盘风暴根因——多数风暴是"一个根因 × 一批对象 × 每对象一条规则"的乘法效应，解法是把规则改成聚合维度（按集群发而不是按节点发）。还有一条治理纪律贯穿三段：告警质量月度复盘——统计告警量和误报率，删掉半年没"真响过"的规则，每条规则都有存在理由。我的经验数据：治理前一个故障晚高峰能响几十条通知，治理后收敛到个位数——降噪不是少配告警，是让每条响的都值得看。
追问链：
- 追问1：静默会不会把真告警也屏蔽了？ → 答：会，所以静默必须管起来，我的三条纪律：一是范围最小：静默条件精确到告警名+实例标签，不放大范围——静默"某节点的磁盘告警"，不静默"所有磁盘告警"；二是时间有限：设置到期自动恢复（Alertmanager 的 silence 支持时长），禁止无限期静默；三是留痕可审计：谁在什么时间因为什么静默了什么，记录进变更日志——静默本质是一次"有计划的告警变更"，按变更管理对待。我在维护窗口的操作惯例：变更前 10 分钟设静默、变更完成验证后立即解除、解除后观察一轮确认无漏报。这套纪律让静默成为工具而不是隐患——用它的人多、管好它的人少，区别就在这三条。
- 追问2：你们怎么处理"告警太吵大家都不看了"的疲劳问题？ → 答：告警疲劳的本质是"信噪比崩塌"，我的治理按源头做：第一，砍：月度复盘删掉误报率和无动作率高的规则——响过 20 次、20 次都不需要动作的规则就是噪音；第二，降：需要知道但不需要行动的降成 P4 进日报——比如容量趋势；第三，拆：P1 通道保持纯粹——只有"必须立即行动"的才进电话短信，值班人对 P1 的敏感度是这个体系的命根子，P1 一疲劳就是事故温床；第四，兜：用轮值和双人复核机制保证 P1 永远有人响应（接警确认机制：告警后 5 分钟无响应自动升级到下一位）。我的验收标准：值班同学听到告警铃声的第一反应应该是"有事要处理"而不是"又来了"——保持这个条件反射，就是告警治理成功的标志。
7.7 值班制度与交接班 【必背】
标准回答： 值班交接是把"7×24 稳定运行"落到人的关键机制，我的交接标准三件套。第一件，书面交接单：固定模板五栏——在处理的问题（P1/P2 的现状、当前动作、下一步、联系人）、未闭环的告警（哪条、为什么还没消、计划怎么处理）、变更窗口（今天/明天有哪些计划内变更、谁负责）、巡检结果（当日巡检异常项）、待办事项（客户提的需求、等原厂回复的单）。口头交接必须对着这五栏走，说完签字确认——"我说了你听了"不算交接，"单子上都有、双方确认"才算。第二件，状态确认：接班人主动核验——大盘过一遍全局健康、抽查在处理的问题工单、确认告警通道（值班手机能收到测试告警）——接班 10 分钟内对"现在系统什么状态、我该盯什么"心里有数。第三件，责任划界：以交接完成时间为界，之前的单子原值班人负责到底（除非正式移交），之后的归接班人——责任不清是交接最大的坑。我的交接习惯还有一条增值动作：在岗日记——值班期间的每个动作随手记时间线，交接时它就是现成的交接素材，复盘时就是完整记录。银行驻场时我参与过上百次值班交接，"单子+核验+划界"这三件套是稳定运转的底座，后来我在移动云和内部 IT 值班都复用了这套。
追问链：
- 追问1：接了一个"带病盘"（有未处理的 P1/P2），你怎么接管？ → 答：四步接管法。第一，还原上下文：读交接单和工单时间线，向交班人问清三个问题——现在做到哪一步、下一步是什么、有什么风险点，不许凭工单字面自己脑补；第二，核实现状：亲自看一眼告警和监控——确认交班人说的状态属实（偶尔交接时状态又变化了）；第三，接管动作：把工单责任人和状态正式变更到自己名下，通知相关方（客户对接人、二线）"此单现在由我跟进"——接口人变更必须广播，不然客户还在联系旧人；第四，定计划：立即给出我接手后的动作清单和时间点，必要时向客户同步一次进展。我接过最复杂的一次是凌晨的存储告警单，前一班已做摘流处理，我接管后按原计划等二线定位并完成客户同步——平稳接手的诀窍就是"还原上下文+广播变更"这两步，跳过任何一步都可能造成信息断层。
- 追问2：值班安排上你有什么经验或建议？ → 答：我经历过的值班形态有三种：驻场银行的 7×24 值守（人随客户窗口走）、移动云的轮值、公司内部 IT 的兼职值班，三种形态给我的经验是：第一，排班要轮换且留备份——单人长期值班会疲劳也会形成单点，轮换让大家保持状态，AB 角备份保证请假不断档；第二，值班要有工具兜底——处置手册、告警分级、大盘三件套到位后，值班对"资深程度"的依赖下降，新人也能值基础班，资深的人处理升级单；第三，值班要有补偿机制——夜班调休、值班补贴这些要明确，这在谈 offer 时我也会主动了解（第 13 章）；第四，值班的产出要沉淀——每次值班的问题和处置都进知识库，值班不只是熬时间，是问题库的采集期。我的态度一句话：值班是运维和支持岗位的属性，我完全接受（银行两年已经习惯），同时我会用分级、手册、自动化把无效值班降到最低——让值班回归"应急兜底"的本义。
7.8 给客户的告警通报话术 【必背】
标准回答： 告警通报是支持岗的"对外接口"，我固定用一个四段模板，银行驻场两年验证过。模板四段：①现象与影响——"X 点 X 分监控发现 XX 告警，当前影响是 XX（哪些功能、哪些用户）"；②当前动作——"我们已完成的动作是 XX，正在进行的是 XX"；③初步判断——"初步定位在 XX 层面，正在进一步确认根因"（拿不准就说正在定位，不说死）；④预计恢复与下次同步——"预计 XX 前恢复/给出阶段结论，我会每 30 分钟同步一次进展"。三条话术纪律：第一，没把握的不说死——"初步判断"和"确认根因"分开表述，避免二次打脸；第二，影响面如实但不吓人——用"影响 XX 功能的 XX 操作"这种具体描述，不用"系统瘫痪"这种模糊吓人的词；第三，恢复通知必须有——处理完的恢复通报和首报同样重要，客户经常只记得"出过事"，恢复通报才建立"闭环了"的认知。示例（磁盘告警实报）："10:05 监控发现应用服务器磁盘使用率 92%，影响：若持续增长可能影响服务写入；已动作：已定位为应用日志堆积，正在清理归档，业务当前正常；预计 30 分钟内释放至 75% 以下，11 点前给您处理结果。"——四要素齐、有时间点、影响表述克制，这就是银行客户认可的通报水准。
追问链：
- 追问1：故障刚发生时信息还不全，客户马上问"什么原因"，怎么答？ → 答：用"已知/未知/下一步"三段式，绝不编造原因。我的话术结构："目前确认的情况是 XX（已知：什么现象、影响什么）；根因还在定位中，初步方向是 XX（未知但给方向）；我们正在做 XX，预计 X 点前给您根因结论或阶段进展（下一步+时间承诺）。"这样答的三个理由：一是诚实——错误的原因判断一旦说出去，后续纠正的成本很高，客户信任掉了就捡不回来；二是专业——"不知道但在有序排查"和"不知道"是两种表达，前者是掌控感；三是节奏管理——给出了下次同步的时间点，把"客户反复追问"变成"我主动同步"。我在银行遇到客户领导直接电话来问的情况，用的就是这套——对方要的不是你马上变出答案，是确认"这事有人管、有章法"。
- 追问2：故障恢复后的复盘报告怎么写给客户？ → 答：我的复盘报告五段结构：①事件概述——时间线（发现、响应、恢复三个时间点）和影响范围；②根因分析——直接原因和深层原因分层写，用"根因是 X，暴露出 Y 环节的薄弱"的结构；③处理过程——关键动作按时间排列，展示专业性和响应速度；④改进措施——这是重点，分"技术改进"（加告警、补预案、修配置）和"流程改进"（SOP 更新、检查项新增），每条带责任人和完成时间；⑤预防承诺——同类问题的预警机制说明。写复盘的原则：不甩锅、不回避、有闭环——银行客户看复盘报告看的就是改进诚意和落地性，一份有具体改进项和时间表的报告，能把一次故障变成信任加分项。我写过的故障复盘里，改进项是会被跟踪销项的——承诺了就要兑现，这个习惯让客户对我的报告高度信任。
7.9 巡检与告警的配合、月度小结 【理解】
标准回答： 巡检和告警是"主动找"和"被动响"的互补关系，我把两者串成一个体系。分工：告警覆盖"有阈值可判"的问题（资源水位、进程存活、错误率），巡检覆盖"没阈值但重要"的问题（事件流里的 Warning 苗头、刚出现的 Pending Pod、证书剩余天数趋势、容量增长斜率）——巡检的价值就是打告警的盲区。节奏：告警 7×24 实时，巡检每日一次固定动作（第 6 章 6.5 的五分钟清单）加每周一次深度项（etcd 健康、证书有效期、容量趋势）。闭环：巡检发现的异常不直接改，按工单流程记录—处理—闭环，和告警响应同一条主线；月度汇总两类数据出一份小结给客户——本月告警量与分布、巡检发现与处置、容量趋势与建议。这份月度小结是我在银行驻场的固定交付物，它有三个作用：客户能看到"平台一直在被认真管着"（服务可见性）、异常趋势能提前进入客户决策（容量预算）、我自己的工作有留痕有沉淀（价值证明）。支持岗做监控，不能只当"告警接收器"，要当"平台健康的经营分析者"——这是我比普通值班人员多走的一步。
追问链：
- 追问1：巡检和告警重复了怎么办，怎么划边界？ → 答：划边界的原则是"按发现方式分，不按对象分"。同一对象（比如节点磁盘）既有告警（超 85% 实时响）也有巡检项（每日记录水位画趋势）——这不是重复，是两个维度：告警管"超线了要行动"，巡检管"离线还有多远、涨多快"。真正要消灭的重复是"同一动作做两遍"：比如巡检脚本去重启服务、告警也触发重启——这种冲突要清理，原则是"自动化动作只归一个系统管"。我整理移动云巡检清单时做过一次去重：把"巡检能看到的"全列出来，逐项标注"告警已覆盖/仅巡检/建议新增告警"——结果是清掉了两项重复动作，还把三个巡检高频项转成了正式告警规则（比如 etcd 磁盘水位）。这个"巡检项向告警规则迁移"的演进方向本身就是体系成熟的标志：人工看的东西逐步自动化，人去做机器做不了的事。
- 追问2：如果让你接手一个没有监控的存量环境，第一步做什么？ → 答：不是装工具，是"摸底定优先级"三步。第一步盘点家底：什么在跑（节点、服务、依赖关系）、哪些是核心链路、历史上哪里出过事（问客户、翻工单）——据此排出监控对象的优先级；第二步先保命：第一批告警永远配给"挂了最疼"的对象——主机存活（up==0）、磁盘水位、核心服务端口探活，三天内上线；第三步再铺面：节点资源、K8s 对象状态、数据库中间件逐层补齐，大盘按总览加细节搭建。切忌一上来铺全家桶：没有优先级的全面监控等于没有监控，第一批告警必须"挂了最疼的先响"。我接手公司内部 IT 环境时就是这么做的：先给核心业务服务器和打印机服务器配了探活和磁盘告警，两周内补齐了完整体系——"先保命、再治病、后健身"的顺序，这个方法论我在第 14 章的案例里也会用到。
7.10 常见告警速答 TOP8 【必背】
标准回答： 值班速答卡八张，每张"告警→第一动作→去向"，这是响应速度的来源。① NodeDown（up==0）：云控制台看实例状态——停机走云层流程、活着 SSH 上去查 node-exporter；查不通转二线。② 磁盘使用率高：df -h 定位、容器环境查日志和镜像层、truncate/prune 先释放、根因补基线（7.4 追问 1 的五步）。③ CPU/内存持续高位：top/ps 找进程——应用问题转开发带证据，异常进程（挖矿特征）按安全流程上报处理。④ Pod CrashLoop：logs --previous + 退出码分诊，OOM 调限额、配置错修配置、代码错转开发。⑤ 节点 NotReady：第 6 章 6.4 五步，九成查 CNI 镜像。⑥ 副本不满：describe 新 Pod 看起不来的原因，发布类回滚优先。⑦ 证书到期：按清单续期——提前 30 天预警的慢故障，续期后验证业务。⑧ 数据库/Redis 连接数高：先看是谁占的（按来源 IP 统计），应用连接泄漏转开发，业务增长给扩容建议。八张卡背后的通用模式：告警 → 第一条命令 → 三种去向（我处理/转二线/转开发）。我把这些做成了值班手册的速查页，也放进了公司知识库——新值班同事照卡操作，响应动作就不会变形。速答卡不是我的记忆负担，是我服务体系的产物。
追问链：
- 追问1：这些告警里哪个你最怕在半夜响？为什么？怎么防？ → 答：最怕磁盘将满（90%+ 且增速快）——因为它有连锁性：满了会连带数据库写入失败、容器驱逐、日志丢失，恢复后还可能丢数据，是少数"拖不得且后果不可逆"的告警。我的三层防御：事前——磁盘告警三级配置（80% 预警/85% 处理/95% 紧急），预警级就有足够时间从容处理；容量趋势纳入每周巡检（增长斜率异常提前发现）；事中——处置手册把"安全清理项"写死（哪些日志能 truncate、哪些镜像能 prune），半夜也能按单操作不犹豫；事后——每次磁盘事件都把根因补进基线（日志限额、清理 crontab）。防御做足之后，磁盘告警从"最怕"变成"最熟练"——怕，说明体系没做好；熟练，才是支持岗该有的状态。这个问题我在面试里主动讲过，它同时展示了风险意识和体系思维。
- 追问2：告警之外，你怎么发现"监控还没覆盖的问题"？ → 答：三个来源。第一，复盘反推：每次故障复盘必答一题"监控为什么没更早发现"——答不出来的就是盲区，当场补规则（我的 9 项避坑清单里有几条就是这么来的）；第二，用户报障反推：客户报的障如果监控当时是绿的，说明这块是盲区——比如某次客户反馈接口慢，但 CPU/内存/磁盘全正常，后来补了接口响应时间的拨测告警（blackbox 思路：从外部模拟用户探测）；第三，巡检直觉：巡检时"看着不对劲"的（日志增长突然加速、某服务重启次数缓慢爬升）都会记录跟踪——量变到质变前的苗头，往往先被人眼看到。监控体系不是一次建成的，是靠"故障、报障、直觉"三个输入持续补盲的——这个演进视角比"我会配 Prometheus"更能体现监控工作的价值。
标准回答：
7.11 客户侧告警 FAQ 速答 【必背】
告警引发的客户疑问有固定几类，我备好了速答，让每次解释既准确又不引发恐慌。"告警响了是不是系统要崩了？" → 答："告警是提前预警不是故障宣布——比如磁盘 80% 告警是提醒我们'还有空间但增长需要关注'，我们会在它影响业务之前处理掉；真正故障反而可能没有告警预案覆盖，所以我们既做告警也做巡检。""为什么半夜才处理，白天不能弄吗？" → 答："P1 级（即将影响业务）必须即时处理——磁盘写满不等人；P3 级我们会排到工作时间，这是分级响应的设计，把深夜打扰降到最少。""告警这么多，是不是系统很不稳定？" → 答："告警多分两种：一种是体系敏感（我们把阈值设得偏早，宁可多看一眼不漏一个），一种是规则需要优化——我们每月复盘告警质量，删掉无效规则，趋势是越来越准的。""这个告警和你们上次说的那个是一回事吗？" → 答：调工单对照，"上次是 XX 根因已修复并加了预防项，这次是 XX 新现象，分别处理"——关联历史工单回答，客户能看到连贯性。速答的原则：先定性（正常/异常/预警）、再给动作、后给时间点——三句话内让客户从"慌"到"定"。
追问链：
- 追问1：客户质疑"你们上次也说没问题，这次又出告警"，怎么接？ → 答：不辩解、用事实分层。"两次是不同的对象和不同的原因——上次是应用日志堆积，已配了轮转限额根治；这次是数据盘的业务性增长，属于容量规划问题，走的是扩容流程。"然后补一层信任建设："告警变多或换地方响，恰恰说明监控在正常工作——我们把以前'看不见的问题'变成'看得见的预警'了。我理解反复告警让您烦，我的承诺是每条都处理到根因，您可以看到月报里告警量的下降趋势。"——把"告警又响了"重新定义为"体系在生效"，同时用治理趋势给信心。这类质疑的本质是客户对"重复问题"的零容忍，回应的关键是展示每单都在收敛。
- 追问2：客户要求"把告警关掉，太吵了"，怎么办？ → 答：不能一刀切，也不能硬顶。先了解他的真实诉求——通常不是"不要告警"而是"不要无效打扰"，那方案就是降噪而不是关闭：把扰他的那几条做分级调整（降级到日报）、修阈值、加 for 防抖；然后给替代可见性："关掉的告警我会放到日报里跟踪，出趋势照样能看到。"最后书面确认调整范围——告警策略变更也是变更，要有记录。我的立场表达要稳："告警是给您和我们的保险丝，全拆了出事就是事故；我建议我们做的是让保险丝只在该断的时候断。"这个场景处理好的标志：客户接受降噪方案且关系反而更近。
标准回答：
7.12 升级路径速查表（实操模板） 【必背】
升级路径是值班时"该叫谁"的唯一依据，必须白纸黑字、全员一致、随身可查。我把它做成一页速查表贴在值班位，四个维度定死：按问题类型——平台组件类找二线组长、产品缺陷类找原厂接口人（华为项目有专属通道）、网络类找网络组、云资源类走云工单；按时间因素——工作时间先群后私、夜间 P1 直接电话（夜里不发群消息等回复，P1 就该吵醒人）；按升级条件——响应超时（P1 十五分钟无响应升二线主管）、处理超时（P1 一小时无阶段进展升项目经理）、客户升级（客户点名要负责人时立即对应，不打折扣）；按信息要求——每次升级带上"现象一句话+已做什么+需要对方做什么"三件套，升级不是甩锅是请求增援。这张表在银行项目多方环境里救过场：凌晨存储类告警直接按表找到原厂值班接口人，没有一分钟浪费在"该找谁"上。我的观点：升级慢的代价是故障扩大，升级"错"的代价只是打扰一个人多一分钟——两害相权，宁可打扰。
实操模板（升级路径速查表骨架，可背）：
text
P1 平台组件异常 → 二线组长（电话）→ 无响应15min → 项目经理
P1 产品疑似缺陷 → 原厂接口人（专属通道）→ 同步二线
网络/链路类 → 网络组（工单+电话双通道）
云资源/云层异常 → 云厂商工单（P1 走紧急通道）+ 通报客户对接人
夜间 P1 → 直接电话，不发群等回复；同步记工单
升级三件套 → 现象一句话 + 已做动作 + 需要对方做什么标准回答：
7.13 割接/变更窗口的告警保障 【理解】
计划内变更和割接是告警体系最容易"误伤"的时刻——变更动作本身会触发一堆"正常变更类告警"，把真故障淹没；所以变更窗口的告警保障是专门功课，我的流程四步。变更前：梳理本次变更会触发哪些告警（重启类服务会报 down、配置类会报异常），对相关告警设置定时静默（范围精确到变更对象、时长覆盖窗口加缓冲、留痕记录谁在什么时间静默了什么）；同时检查真故障通道畅通——静默绝不覆盖"未变更对象"的告警和 P1 全局规则；变更中：值守盯大盘，静默期内异常靠人工观察兜底（变更期是"人肉监控"接管期）；变更后验证：逐项确认变更效果（业务验证清单），然后第一时间解除静默——解除后观察一轮，确认无漏报；变更后复盘：本次变更触发的告警哪些是预期内、哪些暴露了规则盲区——把"变更引发的告警特征"沉淀下来，下次窗口的静默清单更精准。这套流程的本质是把"告警体系"和"变更管理"两个体系接口对齐——它们各自都成熟，接口没对齐就会互相打架。
追问链：
- 追问1：静默期间真的出了故障怎么办？ → 答：这是静默设计的核心风险，我的对策三层。第一层范围控制：静默只覆盖"本次变更会正常触发"的对象和规则，其他告警照常响——变更窗口的故障大概率在变更对象之外（比如隔壁机器磁盘满），照样能报出来；第二层人工兜底：变更值守人员盯大盘关键指标（服务探活、业务响应），静默不等于失明；第三层快速解静默机制：值班手册写明紧急解静默的命令和路径，真出事 30 秒内恢复告警视野。我在变更窗口的口诀："静默的是预期噪音，不静默的是全世界"——范围收得越窄，这个机制越安全。
- 追问2：变更后告警一直没恢复（该恢复的没恢复），怎么判断是变更问题还是告警问题？ → 答：用"双源验证"切分：看告警对应指标的真实数据（Prometheus 查询/登录目标机器实测）——指标真异常是变更问题，按变更回退或修复流程走；指标正常但告警还响，是告警侧问题——常见三种：for 防抖期未过（等一个周期）、规则评估异常（看 Prometheus 的 Rules 页）、静默解除不完全（检查 silence 列表）。处理完把这次的判别路径记进值班手册——"告警不恢复"是变更窗口后的高频困惑，先查事实再查告警侧，顺序别反。我的经验：变更后一小时内是告警侧问题的密集期，值守时安排专人盯恢复态，能把客户的二次报障消灭在萌芽里。
标准回答：
7.14 值班工具与接警确认机制 【理解】
值班的质量一半靠人一半靠工具链，我的值班工具配置四件。第一件告警通道分级：P1 走电话/短信直达值班手机（不能依赖群消息——群里会被淹没），P2 走值班群强提醒，P3/P4 进面板和日报——通道本身就是分级的一部分；第二件接警确认机制：P1 告警发出后 5 分钟无人确认，系统自动升级通知下一位值班（AB 角互备）——"确认收到"必须是一个系统动作而不是自觉，这是防漏报的兜底；第三件值班手册与速答卡随身：每条告警的处置手册（7.16 模板）、告警初判地图、升级联系人名单，纸质打印放值班位加电子版收藏——半夜人不清醒的时候，手册比记忆可靠；第四件在岗日记：值班期间的每个动作随手记时间线（几点几分收到什么、做了什么、结果如何），它就是交接单的底稿和复盘的原始材料。我的值班状态管理还有一条个人纪律：值班当晚不安排深度工作，保持"随时能进入排查状态"的余量——值班的意义在于可用性，排满了活就等于没值。
追问链：
- 追问1：告警发出来了但值班人没看到（手机静音/在洗手间），体系怎么兜底？ → 答：靠"确认+升级"的双保险机制。确认层：告警系统要求值班人点确认（或回复指定关键字），未确认的告警在面板上持续高亮；升级层：P1 超时 5 分钟未确认自动升级到 AB 角第二人，10 分钟再升到主管——升级是自动的不靠人自觉。我们演练过这个链路：故意不确认一条测试告警，验证升级短信确实送达第二人。值班体系的可靠性设计原则和 K8s 自愈一样：不假设人永远在线，假设人会失联，给系统设计接住失联的网——这个设计思想我能讲清楚，因为它和我在高可用架构上的思路同源。
- 追问2：多人同时值班怎么分工才不打架？ → 答：三条分工规则。第一，主值副值制：主值接警处理，副值兜底升级，同一时刻只有一个"第一响应人"——避免两人同时动同一台机器；第二，动作认领制：接手某条告警先在群里声明"XX 告警我来处理"，处理期间该对象的动作归他——和工单认领一个道理，一个对象一个操作者；第三，交接互查制：交接时按 7.7 三件套核对，接手的人主动核验而不是被动接收。我在银行经历过多方值守（客户运维、我、原厂值班），最怕的就是"以为对方在处理"的真空态——所以认领声明和状态同步是我的条件反射，宁可多说一句"这个我在处理"，不能留一个没人管的告警。
标准回答：
7.15 月度告警报告与复盘机制 【理解】
告警体系要"月月复盘"才不退化，我的月度报告固定六块内容，也是给客户和管理层的价值交付物。①总量与趋势：本月告警总数、按级别分布（P1/P2/P3/P4）、环比上月——总量异常上涨通常是新变更引入或阈值漂移的信号；②TOP 告警：按告警名排序的前十名及次数——TOP 1 的告警就是本月最值得治理的对象（加告警、修根因或降级）；③P1/P2 明细复盘：每条 P1/P2 的简要时间线（发现→响应→恢复时长）和根因——这部分是给管理层的核心内容；④误报与治理：本月误报数、已删除或降级的规则、降噪效果——展示告警体系在自我清洁；⑤容量趋势：磁盘/内存/连接数的增长斜率和预计触顶时间——把"未来两个月要注意什么"提前说；⑥改进项跟踪：上月改进项的销项情况+本月新增改进项（责任人+时间点）。这份报告我按月出给客户（银行驻场时期的固定交付物），它同时完成三件事：让客户看见支持工作的价值（服务可见性）、让告警体系持续进化（数据驱动治理）、让容量风险提前进入客户预算（前置决策）。支持岗做监控，最高级的形态就是从"响应告警"进化到"经营告警数据"。
追问链：
- 追问1：报告里 P1 复盘写什么才不是流水账？ → 答：我固定四问结构，每条 P1 回答四个问题：发现了什么（告警内容、发现渠道——告警发现还是用户报障，后者要追问监控为什么没先发现）；多快响应与恢复（首响时长、恢复时长——和 SLA 对比达标没有）；根因是什么（直接原因+暴露的薄弱环节分层写）；改进了什么（具体到"加了哪条告警、改了哪份 SOP、补了哪个检查项"+责任人+完成时间）。四问答完，一条 P1 的复盘就是完整的闭环叙事而不是流水账。我的经验：管理层看报告最关注"暴露了什么薄弱环节、补上了没有"——改进项的销项跟踪是报告里最有分量的部分，承诺不兑现一次，报告的公信力就折损一次。
- 追问2：连续两个月告警量上涨，你怎么分析？ → 答：按"新增源 vs 阈值漂移 vs 真实劣化"三方向拆。第一查新增源：两个月内有没有新上线服务、新加采集对象、新规则——新源带来的告警属于"体系扩容"，正常但要确认规则质量；第二查阈值漂移：数据量增长让某些指标自然逼近阈值（磁盘随业务涨）——这类属于"需要扩容或调阈值的真实信号"；第三查真实劣化：排除前两者后还在涨的，看是不是系统真出了问题（内存缓慢泄漏、连接数爬升）——这是最需要警惕的。分析完把结论写进月报：哪部分是扩容正常、哪部分要扩容、哪部分要修——让数字上涨有解释，而不是让客户看着告警量自己猜。这套分析方法本质是把告警数据当"系统健康的时间序列"来读，是支持岗数据能力的体现。
标准回答：
7.16 告警响应手册模板（实操模板，可直接背） 【必背】
这是我给每条 critical/warning 告警配的一页手册的固定结构，五栏，用"节点失联 NodeDown"做示范。第一栏告警定义与含义：up==0 持续 1 分钟——该节点所有指标采集中断，可能是宕机/网络断/进程亡；第二栏第一步动作：云控制台看实例状态——区分云层故障和 OS 层故障（跑着就是 agent 问题，停机就是实例问题）；第三栏常见原因清单：实例停机、安全组误改、节点宕机、Prometheus 到节点网络断、node-exporter 进程死；第四栏升级路径：10 分钟未定位 → 云厂商工单 + 二线；影响业务的同步客户（用 7.8 通报模板）；第五栏关联预案：节点维护 SOP、该节点上 Pod 的驱逐影响评估（哪些业务会受影响）。手册的使用纪律：值班同学拿到告警先翻手册再动手，动作超出手册范围的升级处理——手册既是效率工具也是风险护栏。我把这套手册在两个项目里各维护了一版，共覆盖 12 条高频告警——它是"告警体系可交接"的标志：人可以休假，手册不休假。
实操模板（手册骨架）：
text
告警名：NodeDown
定义：up == 0 持续 1m（critical）
含义：该节点全部指标采集中断
第一步：云控制台查实例状态 →（停机→云层流程 / 运行中→SSH 查 agent）
常见原因：实例停机 / 安全组变更 / 节点宕机 / 网络不通 / exporter 进程死
升级路径：10 分钟未定位 → 云工单 + 二线；影响业务 → 按 7.8 模板通报
关联预案：节点维护 SOP / Pod 驱逐影响评估标准回答：
7.17 值班交接单模板（实操模板，可直接背） 【必背】
这是 7.7 交接三件套里"书面交接单"的完整模板，五栏固定——它是我值班交接二十年+次的结晶，也复制给了移动云团队。模板的使用纪律：交班人下班前填完、口头对着五栏走一遍、接班人签字确认，三方动作缺一不可；在岗日记是它的底稿——值班时随手记时间线，交接时整理成单只要十分钟。这个模板的价值在两个极端时刻最明显：一是"带病盘"交接（在处理的问题不丢上下文），二是事后追溯（"那晚谁值班、交接了什么"永远有据可查）——值班可以换人，责任和上下文不能断档。
实操模板（值班交接单，可背）：
text
【值班时段】X月X日 XX:00 - XX:00 交班人___ 接班人___
① 在处理的问题：工单号/级别/现状一句话/当前动作/下一步/联系人
② 未闭环告警：告警名/为什么还没消/计划怎么处理/预计时间
③ 变更窗口：今天/明天的计划变更、负责人、是否需要静默配合
④ 巡检结果：当日巡检异常项及处置状态（闭环/跟踪中）
⑤ 待办与提醒：客户承诺的时间点、等原厂回复的单、注意事项
签名确认：接班人核验大盘与告警通道后签字标准回答：
7.18 从 0 到 1 搭监控的十步精简清单（实操模板） 【理解】
把我移动云监控建设的全过程压成十步清单——接手新环境（新公司、新项目）照单执行，这是"方法论可复制"的证明。十步的顺序有讲究：前四步是"保命"（存活与磁盘——挂了最疼的先响），中间四步是"看清"（覆盖与可视化），最后两步是"可持续"（制度与复盘）。面试被问"接手没有监控的环境怎么办"，这份清单就是答案骨架——每步我都能带出当时的真实细节（比如第五步的静态配置取舍、部署期的镜像供给坑）。
实操模板（监控落地十步，可背）：
text
① 摸底定级：盘点对象/核心链路/历史故障 → 排监控优先级
② 部署底座：Prometheus+Grafana（独立节点故障隔离）+ Targets 全 UP 验证
③ 主机层接入：node-exporter 全节点（容器/二进制按环境定）
④ 第一条告警：up == 0 —— 保住"监控自己活着"
⑤ 平台层接入：kube-state-metrics + apiserver（走统一入口）
⑥ 资源告警：磁盘三级（80/85/95）+ CPU/内存分级——磁盘最优先
⑦ 大盘搭建：总览一屏 + 按对象下钻 + 阈值参考线
⑧ 渠道与演练：Alertmanager 分级路由 + 停 exporter 全链路验证
⑨ 制度落地：告警认领、响应手册（每条一页）、值班交接单
⑩ 复盘机制：月度告警报告 + 误报治理 + 容量趋势标准回答：
7.19 支持岗必背的四条 PromQL 与大盘自检五问 【理解】
支持岗不需要 PromQL 专家级，但四条核心查询必须能看懂、能改阈值、能口头解释——这是"看懂大盘"的语言基础。① 存活探测：up == 0——任何抓取目标失联即告警，我们告警规则的第一条，"监控自己先兜底"；② CPU 使用率：100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)——逐层拆解：rate 求每秒 idle 增长占比，avg by instance 把多核平均（自动归一核数），1 减出使用率；③ 内存使用率：(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100——用 MemAvailable 不用 MemFree（available 含可回收缓存才是真实可用），Gauge 直接相除不能 rate；④ 磁盘使用率：100 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100——必须 mountpoint 过滤，否则 overlay 一堆无意义曲线。配套一个"值班看盘自检五问"：有没有节点失联（up）？有没有磁盘将满？有没有 Pod 反复重启？核心服务端口活着吗（探活面板）？昨天的告警今天消了吗？——五问一分钟能过完，全绿才算"接过一个健康的班"。这四条表达式在告警规则和大盘面板里反复出现，面试官若追问 [5m] 窗口的意义我也能答：窗口至少含两个采样点、越长越平滑但响应越慢，15 秒采集配 5 分钟窗口是常规搭配。
追问链：
- 追问1：为什么内存要用 MemAvailable 而不是 MemFree？ → 答：Linux 会把空闲内存拿去做页缓存（buff/cache），这些缓存在应用需要时内核会自动回收——所以"应用真实可用量"= free + 可回收缓存 = MemAvailable；MemFree 只看"完全没用过的"，数字虚低会造成误告警。这个细节和 free -h 命令里看 available 列是同一个道理——我的监控指标选择和命令行习惯是一致的，这种一致性讲出来能体现"指标口径"意识。同类口径问题还有 CPU 的 mode 过滤（不滤 idle 算不出使用率）、磁盘的 mountpoint 过滤——每个指标都有它的"正确用法"，用错口径的大盘比没有大盘更误导。
- 追问2：告警阈值是怎么定出来的（85% 这种数字哪来的）？ → 答：三步推导不是拍脑袋。第一步看增长速率：磁盘按月增速算"从 85% 到 95% 有几天缓冲"——足够走完发现-申请-扩容流程就是合适的预警线；第二步看历史分布：取近 90 天该指标的 P95 做基线，阈值设在"正常波动打不到、真异常必触发"的位置；第三步看响应能力：告警后人工处理需要多久，反推提前量。阈值上线后还要校准——每月看误报率和漏报，动态调整。我的观点：阈值是"资源增速 × 处理流程时长"算出来的运营参数，不是一个通用魔法数字——能讲出这个推导，就超出了"照抄模板配告警"的水平。
7.20 本章案例
- 【真实项目·移动云监控体系混合部署（STAR 精简版）】背景：生产 K8s 集群上线必须有监控配套，内网环境软件源受限。任务：我负责监控方案选型与部署。行动：独立监控节点二进制部署 Prometheus+Grafana（不占集群资源、故障隔离），集群内部署 kube-state-metrics（NodePort 暴露、复用内置 view 只读角色），全节点 apt 装 node-exporter（内网仓库无镜像的二进制等价替代）；配三个抓取 job、两套大盘、告警规则并做全链路演练。结果：节点、控制平面、集群对象三层指标全覆盖，部署过程三个坑（Grafana GPG 404、promtool 无独立包、node-exporter 无镜像）全部解决并进 9 项避坑清单——监控从选型到踩坑闭环都是我独立完成的。
- 【真实值班·夜间磁盘告警响应（完整 STAR 见第 14 章 S6）】凌晨磁盘 92% 告警：按手册五步处置——确认影响、定位容器日志堆积、truncate 释放、补日志限额、记录与交接——20 分钟闭环，业务零中断；此单验证了"处置手册+保守纪律"在夜间场景的价值。
- 【真实场景·告警风暴治理】背景：某次节点故障触发几十条衍生告警，值班群被刷屏，真正的 P1 信号被淹没。行动：事中在 Alertmanager 按标签静默衍生告警保 P1 通道；事后复盘把"按节点发"的规则改成聚合维度，并配了节点宕机抑制规则。结果：同类风暴从几十条收敛到一两条，月度告警量下降明显，值班体验和响应速度双提升——这是"治理告警体系"而不只是"处理单条告警"的实证。
- 【真实交付·告警响应手册】把银行驻场时期的处置经验整理成"每条告警一页手册"（含义/第一步/原因清单/升级路径），移动云团队沿用后新同事值班第二天就能正确响应 P2 告警——支持体系的可复制性比个人能力更值钱，这个产出是我面试讲"体系化支持"的主证据之一。
7.21 章末自测清单（快问快答）
- Prometheus 六大组件与数据流？ → Exporter 暴露指标 → Server 拉取存 TSDB → 规则评估 → Alertmanager 降噪 → 渠道通知（+Web UI/Grafana）。
- Alertmanager 三大降噪机制？ → 分组（合并同类）、抑制（高级别压低级别）、静默（维护窗口屏蔽）。
- for 参数的作用？ → 条件持续满足才触发，防毛刺误报。
- 告警四级怎么分？ → P1 业务中断/安全、P2 核心受损、P3 一般异常、P4 记录提示——按影响面×紧迫度。
- P1 的响应要求？ → 5 分钟内响应、30 分钟不收敛升级、每半小时同步客户。
- 告警响应七步？ → 确认收到→定级影响面→快速定位→决策处置→通报协同→恢复验证→闭环复盘。
- 半夜应急原则一句话？ → 夜里做止损和保底，不做创新和激进动作。
- 磁盘告警处理五步？ → 看级别分区→定位大头→分级处置（先安全项）→验证防复发→留痕。
- 值班交接三件套？ → 书面交接单（五栏）、状态确认（接班核验）、责任划界（以交接时间为界）。
- 告警通报四段模板？ → 现象影响→当前动作→初步判断→预计恢复与下次同步时间。
- 客户马上问根因怎么答？ → 已知/未知/下一步三段式，不编造、给时间承诺。
- 复盘报告五段？ → 概述、根因、处理过程、改进措施（重点）、预防承诺——不甩锅、有闭环。
- 告警疲劳怎么治？ → 砍（删无效规则）、降（P4 化）、拆（P1 通道保持纯粹）、兜（接警确认+升级）。
- 静默三条纪律？ → 范围最小、时间有限、留痕可审计。
- 大盘好不好的检验标准？ → 半夜 30 秒三问测试 + 新人独立定位测试。
- Grafana/Kuboard/云监控分工？ → Grafana 看指标趋势、Kuboard 看对象操作、云监控看云层——三层互补对照定位。
- 巡检和告警的分工？ → 告警管"超线行动"，巡检管"苗头与趋势"，巡检项成熟后迁移成告警规则。
- 接手无监控环境第一步？ → 摸底定优先级，先给"挂了最疼"的对象配告警（保命三件：存活/磁盘/核心探活）。
- NodeDown 第一步动作？ → 云控制台查实例状态，区分云层故障和 OS 层故障。
- 每条告警必须有？ → 明确认领人——发给所有人等于发给没有人。
- P1 无人确认怎么办？ → 5 分钟自动升级 AB 角、10 分钟升主管——不假设人永远在线。
- 多人值班防打架三规则？ → 主值副值制、动作认领制、交接互查制——一个对象一个操作者。
- 月度告警报告六块？ → 总量趋势、TOP 告警、P1/P2 复盘四问、误报治理、容量趋势、改进项销项。
- P1 复盘四问？ → 发现了什么、多快响应恢复、根因与薄弱环节、改进了什么（销项跟踪）。
- 客户质疑"告警又响了"怎么接？ → 分层讲事实（不同对象不同根因）+ 重新定义为"体系在生效" + 月报趋势给信心。
- 客户要求关告警怎么办？ → 降噪不关闭：降级/修阈值/加防抖 + 日报兜底 + 书面确认——告警策略变更也是变更。
- 升级路径四维度？ → 按问题类型找谁、按时间怎么找、按条件何时升、按信息带什么（三件套）。
- 变更窗口静默口诀？ → 静默的是预期噪音，不静默的是全世界——范围最小、人工兜底、快速解除。
- 变更后告警不恢复先查什么？ → 先查指标真实数据（双源验证），真异常是变更问题，正常则是告警侧问题。
- 值班交接单五栏？ → 在处理问题、未闭环告警、变更窗口、巡检结果、待办提醒——交班填写、口头走一遍、接班签字。
- 交接单的底稿是什么？ → 在岗日记——值班时随手记时间线，交接时十分钟成单，复盘时是原始材料。
- 客户 FAQ"告警响了要崩了吗"怎么答？ → 告警是预警不是故障宣布——分级响应把深夜打扰降到最少，月报里看趋势。
- 四条必背 PromQL？ → up==0、CPU（1-idle rate）、内存（1-Available/Total）、磁盘（1-avail/total 带 mountpoint）。
- 内存为什么用 MemAvailable？ → 含可回收缓存才是应用真实可用量——与 free -h 看 available 列同一道理。
- 值班看盘自检五问？ → 节点失联？磁盘将满？Pod 反复重启？核心端口活着？昨日告警消了吗——一分钟过完全绿才算接过健康班。
- 阈值怎么定？ → 增长速率反推缓冲天数 + 历史分布 P95 基线 + 响应流程时长——是运营参数不是魔法数字。
- 监控十步的前四步为什么是"保命"？ → 存活探测（up）和磁盘三级是"挂了最疼"的先响——没有优先级的全面监控等于没有监控。
- 十步清单证明了什么？ → 方法论可复制——接手任何新环境照单执行，每步有真实项目细节背书。