你好！进入 Day 3：SRE 专项：监控、告警与故障演练，这部分是决定你是否具备“资深感”的关键。字节跳动的 SRE 面试官非常看重你处理不确定性故障的逻辑，以及对监控底层的理解。
以下是针对今日重点及你简历亮点的深度拆解：
一、 Prometheus 存储原理（TSDB）深度解析
字节面试常问：“为什么 Prometheus 能处理每秒百万级的数据指标？”
- 数据模型：时间序列（Time Series）由
Metric Name + Labels确定。 - 存储结构（Block）：
- 内存（Head Block）：新产生的数据先存入内存，并写入 WAL（预写日志） 保证宕机不丢数据。
- 磁盘（Persistent Block）：每 2 小时将内存数据压缩成一个 Block 存入磁盘。
- 核心优化技术：
- 倒排索引（Inverted Index）：通过 Label 快速定位 Series ID。
- 数据压缩（Gorilla 算法）：通过 Delta-of-delta（差值再差值）算法，将 16 字节的时间戳压缩到平均 1.37 比特，极大地节省了存储空间。
二、 故障排查方法论（字节高频必考）
当面试官问“服务器 Load 高怎么排查”时，千万不要只说一个 top。要展现你的体系化思维。
1. CPU Load 高（平均负载高）
-
第一步：使用
uptime看 Load 趋势，使用top或htop看进程。 -
第二步：区分 Load 类型。
-
CPU 密集型：
top看到us（用户态）高，说明是计算逻辑问题。 -
IO 密集型：
top看到wa（等待 IO）高，说明磁盘/网络慢了。 -
中断高：看
/proc/interrupts，可能是网卡多队列没调优。 -
第三步：定位。
perf top看哪个内核函数调用高，或者strace -p [pid]看系统调用。
2. IO 忙（Disk IO 瓶颈）
- 工具：
iostat -x 1观察%util和await。 - 深度排查：使用
iotop定位具体的进程。使用lsof -p [pid]查看该进程打开了哪些大文件。 - 场景：如果磁盘空间满了但
du -sh看不到大文件？说明文件被删除但进程未释放句柄，用lsof | grep deleted找回并重启进程。
3. 内存泄漏（Memory Leak）
-
现象：监控曲线稳步上升，且
free命令显示的available持续下降。 -
排查：
-
看
/proc/meminfo确认是用户态还是内核态（如 Slab）泄漏。 -
使用
valgrind或gperftools（针对 C/C++）或jmap（针对 Java）做 Heap Dump 分析。
三、 简历深挖：动态基线与 AI 自愈（挑战题）
面试官会针对你的项目进行“压力面试”：
1. “3倍标准差”算法在实际中有什么坑？
- 你的回答：3-Sigma 假设数据符合正态分布。但在互联网场景下，流量通常是“长尾分布”或有“阶梯性”突发。
- 改进方案：我会引入加权移动平均（EWMA），给最近的数据更高的权重，从而让基线更敏感地适应业务架构的正常调整。
2. 字节高频：如果 AI 自愈误判了怎么办？（必杀技）
这是面试官考察你风险意识的核心题。建议从以下四个维度回答：
- 设置“熔断机制”：
- 频率熔断：同一个节点 10 分钟内只允许执行 1 次自愈操作。
- 规模熔断：如果集群内超过 5% 的机器同时触发自愈，立即停止所有自动操作，转人工处理（防止由于全局配置错误导致的连锁重启）。
- 操作分级（白名单）：
- 无损操作（如清理日志、重启非核心组件）：AI 直接执行。
- 有损操作（如重启数据库、扩容）：AI 给出建议，必须由运维在飞书机器人点击“Confirm”后才执行（Human-in-the-loop）。
- 前置校验与后置检查：
- 执行前检查：目标 IP 是否在核心服务列表？
- 执行后验证：执行完
systemctl restart后，必须检查端口是否监听、健康检查接口是否返回 200，若失败立即回滚。
- 影子模式（Shadow Mode）：
- 在新功能上线初期，AI 只输出“建议操作”但不实际执行，通过比对人工处理结果来优化模型准确率。
今日互动测试
场景模拟：
你收到一个 Prometheus 告警，显示某 K8s 节点的内存使用率达到 95%。你登录机器发现 top 显示内存确实很高，但你通过 ps 把所有进程内存加起来却只占了 40%。
请问：剩下的 55% 内存去哪了？你会查看哪个系统文件来确认？
（提示：这个知识点在你的简历“内核调优”部分有涉及）