监控工具的一些思考：从裸辞到重新出发的代码人生
去年十月，我坐在广州老西关一间不足30平米的出租屋里，窗外是熟悉的骑楼和偶尔飘来的肠粉香味。屋内，三台显示器同时亮着，其中一台跑着 Grafana 的仪表盘，另一台则疯狂输出着 kubectl logs 的滚动日志。而我的 MacBook Pro 散热风扇正发出像拖拉机一样的轰鸣声——这已经是本周第三次线上服务雪崩了。
我当时还在某大厂做后端开发，职级P6，月薪22k，听起来不错吧？但每天凌晨三点被 PagerDuty 报警吵醒、半夜爬起来修 Kafka 积压、周末陪老婆逛商场还得随时回公司救火……那段时间，我感觉自己不是在写代码，而是在给系统“擦屁股”。
“你再这样下去，身体迟早垮掉。” 老婆把一碗刚煮好的云吞面推到我面前，语气里没有责备，只有心疼。那天是2023年10月18号，周三。我盯着碗里浮着葱花的汤，突然意识到：我拥有的资源很多——高薪、大厂履历、技术栈全面；但我人生的资源却在快速枯竭——睡眠、健康、陪伴家人的时光。
一周后，我递交了辞职信。HR 一脸震惊：“你确定？年终奖还有两个月就发了，而且明年有机会升P7。”
我说：“我知道，但我得先救自己一命。”
Gap 半年：从“救火队员”到“冷静观察者”
裸辞后的前三个月，说实话，焦虑得要命。
房租3500，房贷5800，加上老婆的产检费用（她当时刚怀上二胎），每个月固定支出近一万。存款还能撑八九个月，但心里没底。我一度天天刷BOSS直聘，看到“急招SRE”“监控平台重构”之类的职位就点进去，生怕错过机会。
但很快我发现一个问题：我在大厂干了五年，写过无数行监控告警规则，却从来没真正“理解”过监控本身。
以前在公司，我们用的是内部自研的监控系统，名字叫“天眼”。它强大、集成度高、报警精准——但黑盒。我们只知道往里喂指标，它就吐出告警。没人问“为什么这个阈值是80%而不是75%？”“这个告警真的需要半夜call人吗？”
Gap期间，我决定沉下心来，把自己当成一个“外部用户”，重新审视监控这件事。
我搭了一套自己的 Home Lab：用 Raspberry Pi 做边缘节点，Prometheus 抓取指标，Alertmanager 发微信通知，Grafana 画图。我还特意部署了一个模拟电商后端（用 Go 写的简单服务），故意让它内存泄漏、CPU 打满、数据库慢查询……
这一次，我不是为了上线交付，而是为了“看懂”系统。
监控不是越多越好，而是越准越好
很多人以为监控就是“堆指标”——CPU、内存、磁盘、网络、QPS、错误率……恨不得把 /proc 里的每个文件都采一遍。
但我在 Home Lab 实验中发现一个残酷事实：无效告警比没有告警更可怕。
有天晚上，我故意让服务返回 500 错误。Prometheus 检测到 HTTP 5xx 突增，立刻触发告警。Alertmanager 给我微信发了一条消息。我秒回：“收到，正在排查。”
结果呢？这只是我手动触发的测试。但那一刻，我心跳加速、手心出汗——这就是“告警疲劳”的根源。
在大厂时，我们团队每周平均收到127条告警，其中真正需要人工介入的不到5条。剩下的要么是临时抖动，要么是已知问题。久而久之，大家看到告警就直接“acknowledge”然后划掉，直到有一天——真正的 P0 事故来了，没人当回事。
所以，我总结出第一条最佳实践：
告警必须具备“可行动性”（Actionable）。如果你收到告警后不知道该做什么，那这条告警就不该存在。
怎么做到？我给自己定了三个标准：
- 明确责任人：谁收到这条告警，就应该能处理它；
- 有明确恢复路径：比如“重启服务”“扩容实例”；
- 避免重复轰炸：用 Alertmanager 的 grouping 和 inhibit 规则抑制连锁告警。
资源有限，监控更要“精打细算”
Gap期间，我深刻体会到“资源”的珍贵——不仅是服务器资源，更是人的注意力资源。
在大厂，我们有成千上万台机器，监控数据量以 TB 计，背后有几十人的 SRE 团队支撑。但回到现实世界，很多中小公司甚至 solo 开发者，可能只有一两台服务器，预算有限，人力更有限。
这时候，盲目照搬大厂那一套，只会把自己累死。
比如，我朋友阿强，自己创业做 SaaS 工具，就一台 4C8G 的云服务器。他之前学我们大厂，给每个微服务都加了十几个指标，结果 Prometheus 占了 3GB 内存，业务服务反而 OOM 了。
我帮他重构监控体系，只保留三类核心指标：
- RED 方法（Rate, Errors, Duration）：针对每个对外 API；
- USE 方法（Utilization, Saturation, Errors）：针对主机资源；
- 业务关键链路：比如“用户注册→支付成功”的转化漏斗。
其他花里胡哨的指标，全砍掉。告警也只设两个级别：
- P0：影响核心业务，必须 5 分钟内响应；
- P1：性能下降或非核心功能异常，上班时间处理即可。
三个月后，他说：“现在半夜终于能睡整觉了。”
这让我想起一句老话：“监控不是炫技，而是兜底。” 你的资源有限，就要把子弹打在最要害的地方。
代码人生：监控教会我的事
很多人觉得监控是运维的事，跟写代码的没关系。但经历了这场 Gap 期的反思，我越来越觉得：监控思维，应该融入每一个程序员的“代码人生”。
什么意思？
写代码时，我们总想着“功能实现”，却很少考虑“如何观测”。比如一个接口，返回成功就万事大吉？但如果它慢了 10 倍呢？如果它悄悄开始返回脏数据呢？
现在我写代码，一定会做三件事：
- 埋点关键路径：用 OpenTelemetry 或简单日志，记录耗时、参数、结果；
- 定义 SLO（Service Level Objective）：比如“99% 的请求应在 200ms 内完成”；
- 预设故障场景：如果 DB 挂了，服务会不会雪崩？有没有降级方案？
这些不是额外负担，而是对代码负责的表现。就像你养孩子，不能只管生，不管养。
更重要的是，监控教会我“敬畏不确定性”。
系统永远会出问题，区别在于你是被动挨打，还是主动掌控。好的监控体系，不是为了杜绝故障——那是不可能的——而是为了缩短 MTTR（Mean Time To Recovery）。
这不正是我们人生的隐喻吗？
生活总有意外，失业、生病、关系破裂……但如果你有“人生监控系统”——比如应急存款、健康习惯、亲密关系——你就能更快恢复，而不是一蹶不振。
重新出发：带着思考回到职场
今年四月，我重新开始找工作。面试时，我不再只谈“我用过 Kubernetes、Prometheus、ELK”，而是讲清楚：“我为什么用它？解决了什么问题？代价是什么？”
上周五晚上，我接到一家广州本地科技公司的 offer，月薪 24k，比裸辞前还高。HR 问我：“你 Gap 半年，会不会跟不上技术？”
我笑了笑：“这半年，我重新学会了怎么写代码。”
新公司规模不大，但技术氛围很好。他们正在搭建统一监控平台，我主动请缨牵头。这次，我不再追求“大而全”，而是从三个核心业务线切入，先跑通 RED + USE 模型，再逐步扩展。
老婆听说我又要搞监控，开玩笑说：“这次别半夜爬起来修报警了啊。”
我说：“放心，这次我把‘人生告警阈值’调低了——超过晚上十点，一律静音。”
最后一点真心话
写这篇文章的时候，窗外又飘来了肠粉的香味。我已经重新习惯了老城区的节奏：早上七点去茶楼喝早茶，下午在家 coding，晚上陪老婆散步。
裸辞不是逃避，而是一次“系统重启”。在这半年里，我重新校准了自己的“资源分配”——不再把所有 CPU 时间都给工作，而是留一部分给健康、家庭和思考。
监控工具如此，代码人生亦如此。
我们无法控制所有变量，但可以设计好自己的“可观测性”。
当你能看清自己系统的瓶颈，也能看清人生的卡点。
愿你我的代码，不仅跑得稳，更能活得明白。
—— 一个从西关骑楼下重新出发的老广程序员
2024年6月于广州
评论 0