半夜2点的告急：一次生产故障的抢救现场

凌晨2点，电话响了。Slack 上的 critical alert 红成一片，数据库查询延迟突然飙到 30 秒，用户开始投诉页面卡死。我迷蒙着眼睛爬起来，这是我成为 DevOps 工程师这几年来见过无数次的场景了，但每一次心率还是会瞬间飙升。

我花了 3 分钟登上 V**，打开监控面板。CPU 使用率 92%，内存占用 88%，数据库连接池快要耗尽。根据近 1 小时的指标变化看，问题大概从 1 点 45 分开始恶化。这个时间点很关键——我需要回顾一下这个时间段发生了什么。

一边看日志，一边我就开始在 Slack 的 incident 频道里通知团队。DBA、开发负责人、产品经理，分别该谁该睡觉谁该起床。然后我做的第一件事不是着急去 fix bug，而是稳定现状——因为我学过一次惨痛的教训，越是着急就越容易乱改一通，最后把故障从黄色警戒升级成红色核弹。

我登上 Kubernetes 集群，看了下 Pod 的资源使用情况。发现其中一个微服务的内存使用量从正常的 200MB 急速蹿到 1.5GB，这通常意味着内存泄漏或者某个查询突然开始扫全表。立刻做了第一个决策：扩容这个服务的副本数。从 3 个 Pod 扩到 5 个，负载均衡一下，至少能把症状压住。

kubectl scale deployment api-service --replicas=5 -n production

5 分钟后，仪表盘的红色稍微淡了点。CPU 从 92% 降到了 72%。数据库查询延迟从 30 秒回落到 8 秒。还没完全恢复，但至少用户的投诉电话应该会少一些。

现在可以开始诊断了。我拉出数据库的慢查询日志，果不其然，出现了一条新的查询，没有建立索引，直接在百万级别的数据表上做了 WHERE 条件搜索。这条查询每次执行都要扫表，一次要花 8 秒。而且这条查询被打成了一个非常常见的业务路径，所以瞬间就炸了。

查了一下代码提交历史，这段查询是下午 5 点钟一个同事新加上去的功能。正好我旁边的 DBA 已经上线了，我们俩一个给这个查询加上了合适的索引，一个验证了新索引的效果。

CREATE INDEX idx_user_status_created_at ON users(status, created_at);

索引建好之后，那条查询的执行时间从 8 秒降到了 120 毫秒。就这 120 毫秒的差别，整个系统的表现天翻地覆。数据库连接池里的连接立刻释放出来，查询堆积一扫而空。

凌晨 2 点 45 分，所有的指标都绿了。但故事还没完。

我没有立刻去睡觉，而是做了第二个重要的决策：缩容回去。把那 5 个 Pod 重新缩回 3 个。原因很简单，扩容是应急手段，不能变成常态。如果真的需要 5 个副本，那说明这个服务的性能瓶颈需要优化。用扩容掩盖性能问题，最后只会被更大的故障反咬一口。

然后我整理了一份 incident report。包括什么时间发现问题，什么原因导致的，采取了哪些应急措施，最终怎么根治的，以及为了防止这种事再发生，需要在哪些环节加强。比如：

1. 1. SQL 审查流程加强：新的数据查询必须由 DBA 审核，没有索引的查询要打回
2. 2. 自动化检测：给数据库的慢查询日志接上告警，超过 1 秒的查询自动报警
3. 3. 压力测试：新功能上线前要过一遍压力测试，不能只在本地环境过一遍

这件事最后的结果是，凌晨 3 点 15 分，大家都回到了各自的床上。我看了一眼监控，设置了备用告警，才算真正入睡。

但你知道运维这个工作最扎心的地方在哪吗？这次故障从检测到完全恢复，花了不到 30 分钟。可正是这 30 分钟，有可能让公司损失一笔可观的用户投诉、用户流失、甚至商务罚款。而公司对 DevOps 的预算反而永远是最紧张的。做得再好也没人看见，出了故障所有人都能看见。

这也是为什么现在的我，特别重视预防。不是等到故障发生再抢救，而是在日常的、看似枯燥的工作里，一点一滴地积累。监控、告警、日志、自动化测试、压力测试、code review、基础设施即代码（IaC）。这些东西乍一看很烦，但真的能救你命。

有人问过我怎么能在半夜的紧急情况里保持冷静。我的答案是，那不是冷静，那是重复。每一次故障都是一次演习，每一次演习都教会我一点新的东西。到了某一个时刻，故障处理就变成了一种肌肉记忆。按部就班地做诊断、做隔离、做恢复、做复盘。紧张感还是有的，但手上的动作不会乱。

现在的我特别想对那些刚入行的 DevOps 工程师说：不要怕故障。故障来临时，记住一个原则——先稳定，再诊断，最后才是修复。很多人的第一反应是立刻改代码、改配置，结果越改越糟。停一停，深呼吸，打开监控，看清楚具体发生了什么事，再动手。这个顺序不能乱。

以及，写好复盘报告。一次故障的价值，有 20% 在于当时有没有及时止损，80% 在于事后有没有从中学到什么、改进了什么。那些真正值得记录的，是为什么会发生这个问题，以及怎么确保它不会再发生。这个东西沉淀下来，就变成了团队的资产。

其实这么多年下来，我对 DevOps 最深的体会就是：这个岗位的核心不在于你懂多少工具，而在于你能不能在混乱中保持清醒，在紧急关头做对决策。工具永远在变，但处理问题的思路是不变的。熟能生巧，就是这个道理。