夜间事件：生产环境单体稳定

午夜生产事故：稳住单体应用与团队协作

寻呼机警报“生产环境全红”把我从床上拽起。冲进事件响应室：SRE 标准流程——先稳住、诊断、事后复盘。团队分工明确：协调、沟通、数据库、指标与日志监控。目标：挖掘埋藏在遗留代码层层堆叠下的根因。

利益相关者第一时间收到更新：“服务宕机。团队已介入。15 分钟后下一条更新。” 监控显示所有指标全红，只有一个绿点闪烁。日志被超时错误刷屏，这些错误直击单体应用，我们亲切地称它为“巨龙”。

诊断：从消息队列到数据库瓶颈

消息队列指标呈指数级飙升，消费者因超时崩溃。罪魁祸首：数据库查询拖沓。典型问题如下：

SELECT * FROM users WHERE some_condition ORDER BY created_at LIMIT 1000;
-- some_condition 和 created_at 均无索引，扫描 1000 万+ 行——灾难。

DBA 发现缺失索引和新服务中的 N+1 查询问题。遗留架构师确认：单体应用囤积全局状态，未经重构无法扩展。

紧急提出 Kubernetes 迁移？直接否决。危机中增加复杂度却不解决根本问题。

安全把关与艰难妥协

请求临时权限限流并回滚功能？安全团队卡住不动。威胁模型要求风险签批。最终妥协：一小时访问权限，全程日志记录并生成审计报告。

行动步骤：

• 通过限流节流流量。
• 用功能开关回滚新功能。
• 监控恢复：红 → 粉 → 灰 → 稳定绿。

利益相关者更新：“已稳定。诊断继续。30 分钟后下一条更新。”

根因与关键教训

事故受控：队列堵塞，数据库被新服务低效查询狂轰滥炸。单体应用被拴住并稳定，但它急需系统性改造。

OKR 负责人插话：双倍发布、“重写一切”、到处 Kubernetes。风险：追逐大爆炸项目而忽略渐进式胜利。

关键经验：

• 根因是粗糙查询和队列堵塞，而非单体应用本身。
• 明确事件角色至关重要：协调、沟通、专业深度。
• 安全可灵活处理：限时访问 + 审计。
• 危机中避开仓促迁移；优先稳定。
• 事后复盘将指导路线图：索引、功能开关、渐进重构。

团队用 2 小时完成稳定。下一步：复盘与行动计划。

— Editorial Team