第2章：SRE核心技能栈与面试考察点
SRE 面试围绕六大核心技能领域展开：网络、系统、容器、监控、自动化、故障排查。面试官通过场景题评估你对这些领域的理解深度和实操能力。下面给出通用回答框架和3个典型面试问答。
面试问答卡片
📌 面试问题
请描述一次你通过排查网络问题解决服务异常的案例。
🎯 面试官考察点
- 是否掌握基础网络排查工具（ping、traceroute、tcpdump、netstat）
- 能否区分网络层、传输层、应用层故障
- 是否具备系统化排查思路（从现象到根因）
📋 回答框架
- 背景：某前端页面加载超时，用户报障。
- 排查步骤：先 curl 确认服务端口可达 → 发现延迟高 → tcpdump 抓包发现 TCP 重传 → 检查网络链路（ping 网关正常，但跨AZ延迟突增）→ 定位到交换机端口丢包。
- 恢复：切换流量至另一可用区，通知网络团队换端口。
- 复盘：增加跨AZ链路监控告警。
💬 简短示例回答
“用户反馈页面加载超时，我先curl确认服务端口未响应。通过tcpdump抓包发现TCP重传率20%，再用mtr检测到跨可用区链路延迟突增至500ms。联系网络团队发现交换机端口故障，立即切换流量至备用AZ，服务恢复。后续增加链路质量自动告警。”
❓ 可能追问
- “如果tcpdump显示大量SYN收到但未建立连接，是什么问题？”
- “如何快速判断是网络带宽瓶颈还是应用本身慢？”
- “你会在生产环境直接抓包吗？有什么注意事项？”
⚠️ 避坑提醒：
① 不要一上来就说“重启服务”，优先用工具排查；
② 禁止在生产环境直接抓包未脱敏流量的全包，建议用 tcpdump -c 限制包数 + -w 落盘；
③ 回答时体现“影响范围评估”和“回滚方案”更显专业。
① 不要一上来就说“重启服务”，优先用工具排查；
② 禁止在生产环境直接抓包未脱敏流量的全包，建议用 tcpdump -c 限制包数 + -w 落盘；
③ 回答时体现“影响范围评估”和“回滚方案”更显专业。
📌 面试问题
如何通过系统指标和容器日志定位一个Pod频繁OOMKilled的问题？
🎯 面试官考察点
- 对容器资源限制（limits/requests）的理解
- 系统层面 OOM Killer 机制与日志查看方法
- 是否具备分析内存泄漏的常规手段
📋 回答框架
- 检查Pod状态：kubectl describe pod 查看 last state 为 OOMKilled
- 查看资源限制：确认 limits.memory 是否过小
- 检查应用日志：kubectl logs --previous 查看重启前日志，找OutOfMemoryError或堆内存溢出
- 系统层面：dmesg | grep -i oom 查看内核OOM记录
- 监控分析：用 Prometheus 查 Container Memory Working Set 时间序列，看是否有持续增长趋势
💬 简短示例回答
“Pod反复OOM，先kubectl describe发现limits.memory=256Mi过小。查看前一次日志，Java进程抛出OutOfMemoryError。增加memory limits至512Mi后仍OOM，通过Prometheus内存曲线发现持续增长，判断是内存泄漏。配合Heap Dump分析定位到未关闭的HTTP连接池。”
❓ 可能追问
- “为什么OOM后Pod会重启？哪个控制器负责？”
- “limits和requests的区别是什么？设置不合理会有什么问题？”
- “你如何在Kubernetes中配置内存Limit的自动扩缩？”
💡 加分点：回答时提及“先用top/ps查看主机资源是否充足，排除节点级别OOM”，体现全局视角。
⚠️ 避坑提醒：不要只查容器级指标，忽略宿主机的内核日志。另外，务必区分“OOMKilled”和“CrashLoopBackOff”的不同原因。
📌 面试问题
请你设计一个自动化故障恢复流程，当某微服务连续3次健康检查失败时自动执行什么操作？
🎯 面试官考察点
- 对自动化运维的认知深度（自愈 vs 人工介入边界）
- 能否设计安全可靠的容错流程（防抖、熔断、回滚）
- 是否熟悉常见自动化工具（K8s自愈、Ansible、混沌工程）
📋 回答框架
- 触发条件：健康检查连续失败3次 → 触发自动流程
- 第一步：隔离：从负载均衡池摘除该Pod/实例
- 第二步：尝试自愈：K8s会自动重启Pod；若为传统部署，执行预定义脚本（如重启服务、清理临时文件）
- 第三步：健康验证：等待30秒后再次健康检查，若恢复则重新加入LB池
- 第四步：升级警报：如果第2次尝试仍失败，发送告警给on-call工程师，并保留现场日志
💬 简短示例回答
“我会设计一个三级自愈流程：1）失败3次后摘除实例并重启容器；2）重启后重新health check，成功则加回LB；3）若重启两次仍失败，则保留现场并创建工单，同时将流量转移至其他可用实例。整个流程用K8s的liveness探针+自定义Operator实现，避免无限重启。”
❓ 可能追问
- “如果所有实例同时失败，你的自动化流程会怎样？”
- “如何防止自动恢复导致的‘雪崩效应’？”
- “你会将自动恢复能力与告警系统如何联动？”
⚠️ 避坑提醒：不要设计“无限自动重试”逻辑，必须有最大重试次数和人工介入阈值；回答时强调“容错与熔断”，展示对分布式系统稳定性的理解。
项目案例：电商平台微服务Kubernetes迁移故障演练
| 项目名称 | 电商核心链路K8s迁移与自愈机制建设 |
|---|---|
| 业务背景 | 原有虚拟机部署的订单、支付服务，因大促扩容慢、故障恢复需人工干预，决定迁移至Kubernetes集群，并构建自动化故障恢复能力。 |
| 规模指标 |
|
| 技术栈 | Kubernetes 1.24、Docker、Prometheus+Grafana、ELK、Consul、Nginx Ingress、自研Operator（基于Go） |
| 核心难点 |
|
| 面试高频追问 |
|
| 可迁移回答话术 | “在迁移类似大型系统时，我会优先设计灰度切流+可观测性双保险。比如先用20%流量验证K8s集群稳定性，同时强化Prometheus告警和日志中心。对于自愈机制，设置熔断阈值和人工审核窗口，避免自动化误操作。这个思路同样适用于云原生环境下的其他迁移项目。” |
📚 本章小结
- SRE 面试的核心是对 网络、系统、容器、监控、自动化、故障排查 六项技能的综合运用能力。
- 回答故障排查类问题时，遵循 收集→假设→隔离→恢复→复盘 的通用框架，展示系统化思维。
- 项目案例中要突出 规模指标、核心难点、你的针对性方案，并准备可迁移话术。