第2章：高频面试问题与回答框架
本章定位：掌握容器平台稳定性面试的常见问题类型、答题逻辑与公司偏好。通过结构化回答框架，将技术经验转化为面试官可量化的能力信号。
核心知识结构：大厂稳定性面试考察重点对比
| 公司类型 | 考察重点 | 常见问题方向 |
|---|---|---|
| 字节跳动 | 快速定位+应急响应流程 | 线上故障排查、SLO/SLI设计、告警降噪 |
| 阿里巴巴 | 体系化稳定性 + 容灾架构 | 多可用区部署、流量调度、容量规划 |
| 腾讯 | 海量规模下的亚健康管理 | 容器频繁重启、节点异常、内核问题 |
| 百度 | 故障自愈 + 变更风控 | 滚动更新策略、回滚机制、P0/P1流程 |
| 美团 / 快手 | 成本与稳定性的平衡 | 混部策略、资源超卖、QoS优先级 |
通用回答框架：四步结构化表达
加分提示：回答时主动给出故障背景（影响多少 Pod/用户），用数据说明分析过程（如通过 Grafana 发现 CPU 毛刺，定位到某个 Goroutine 泄漏）。
面试问答卡片
Q1：线上 K8s 集群节点 NotReady，如何排查？
考察点：故障排查流程、对 kubelet / 网络 / 系统组件的理解、报告能力。
回答框架：定义问题 → 检查节点状态与事件 → 分层次定位 → 临时恢复 → 根因修复。
示例回答：首先查看节点事件，确认是否由 OOM 或磁盘压力触发。若 kubelet 未响应，SSH 登录查看 kubelet 日志与磁盘使用率。常见原因为 docker 日志撑满 /var，清理后恢复。后续配置 logrotate 并设置节点预留。
可能追问：如果 SSH 也连不上怎么办？如何自动化检测此类故障？
避坑提醒：不要只说“重启 kubelet”，要体现分层排查（资源→系统→网络→控制面）；避免跳过临时止血措施（如 cordon + drain）。
Q2：设计一个容器平台的 SLO，你会怎么定？
考察点：稳定性指标选取、用户视角、错误预算意识、量化能力。
回答框架：明确服务类型（计算/网络/存储）→ 定义 SLI（可用性/延迟/错误率）→ 设定目标（如 99.9%）→ 计算错误预算 → 告警阈值。
示例回答：以 Pod 调度延迟为例，SLI 定义为从创建到 Running 的 P99 延迟，目标 99.9% ≤ 5s。每月错误预算约 43 分钟，超预算时停止非关键发布。同时配合 Prometheus 计算并告警。
可能追问：多租户场景下如何区分 SLO？错误预算耗尽后具体流程？
避坑提醒：避免空泛的“保证稳定”，须给出具体数值和计算方式；不要遗漏“服务商 vs 租户”的责任边界。
Q3：容器频繁被 OOMKilled，如何定位与优化？
考察点：内存泄漏排查、cgroup 理解、JVM/Go 内存模型、性能调优。
回答框架：确认 OOM 触发类型（Limit vs Node）→ 分析内存增长曲线（RSS/WorkingSet）→ 应用侧 dump heap 或 pprof → 优化代码或调整 Limit → 设置垂直弹性。
示例回答：通过 Prometheus 观察到 WorkingSet 随时间线性增长，判定为内存泄漏。对 Java 应用采用 jmap dump 分析，定位到未关闭的 HttpClient 连接池。修复后内存稳定，同时设置 requests 为 80% limit，触发 HPA。
可能追问：Go 和 Java 的内存排查工具差异？如果无法 dump 怎么办？
避坑提醒：不要只提“加内存 limit”；必须给出具体分析工具链（如 pprof、jmap、gcore）；注意区分容器级别 OOM 和进程级别 OOM。
公司偏好提示：字节看重快速响应与标准化流程；阿里关注架构级容灾；腾讯侧重大规模下的异常行为。提前了解目标公司的稳定性文化，针对性准备案例。