没有运维，服务告警可以这么搭
2025 年 9 月我上线第一款小游戏，种子计划每天进 180 人。那时我从没想过没有运维怎么知道服务挂了，以为接下来只要看数据就行。
实际情况是服务挂了我不知道，广告位失效了我也不知道，等我发现的时候流量已经过去了。那款游戏最后的数据是次日留存 5 人、当天广告收入不到 ¥6。
一、没有运维怎么知道服务挂了：目标不是监控一切，是别让我当人肉探针
我现在对告警的定义很简单：在我还来得及的时候，主动告诉我出事了。
大公司那套指标面板、链路追踪，对我一个人维护的项目来说大多数用不上。我要的只有一件事——服务不正常的时候有人(或某个东西)叫我。
把这个目标写清楚，后面的取舍就都顺了。没有运维怎么知道服务挂了，答案就藏在这一句里。
反过来说，凡是不能让我「及时知道」的监控，做得再漂亮也只是装饰。
二、第一条：先把「服务还活着吗」这件事自动化
最基础也最值钱的一条，是服务存活检测。
判断标准极为简单：从外部访问一个固定地址，能通就算活着。不要放在服务内部自己判断自己，那等于让病人给自己开诊断书。
具体动作：找一个服务之外的定时任务，按固定间隔请求一次你的健康检查地址。
间隔不用太密。密到每秒一次除了让你更焦虑，不会让恢复更快。
三、第二条：只对「用户能感知到的坏」报警
我早期想给所有异常都加告警，结果是被自己吵到麻木。
后来我把范围收窄：只报用户能感知的问题——页面打不开、接口大面积失败、关键流程走不通。内部的偶发异常记日志就够了。
报警太多等于没有报警，因为你会开始无视它。
具体动作：列出你认为「用户一定会发现」的三个场景，只给这三个加告警。
四、第三条：告警必须能落到手机上
以前我把告警发到自己的服务里，服务一挂，告警也一起挂。
这是新手最容易犯的错：告警通道不能和被测系统共用同一条命。它必须依赖一个跟你服务器无关的通道。
具体动作：用一个你不会关掉的通知渠道接收，比如手机上的即时消息或邮件，然后测试一次——手动把服务停掉，看你能不能收到。
没测过的告警，等于没配。这一步我建议配完立刻做，别等真出事才发现通道是哑的。
五、第四条：给告警分级，别用同一个响度
不是所有事都值得半夜爬起来。
我会分两档：一档是「立刻要看」，服务不可用属于这档；另一档是「明天再看」，比如磁盘余量、证书到期、响应变慢。
分级的价值在于你会长期保持对最高档告警的敏感。
具体动作：把你现有的告警项挨个标一个档，标不出来的是你还没想清楚它重不重要。
六、第五条：先做减法，再谈加监控
一个人维护的项目，告警系统的复杂度上限，就是你能维护它的精力上限。
我的判断是：能靠一条外部探测解决的事，不要引入一整套监控组件。等你确实被某个盲区坑过一次，再针对性补上。
优先级：先做哪一条
按投入产出排，我的顺序是：外部存活探测 → 手机能收到 → 只报用户可感知的坏 → 分级 → 再谈其他。
前两条做完，你就已经比「什么都不知道」的状态好了一大截。到这一步，没有运维怎么知道服务挂了，对你来说就不再是难题了。
常见问题
Q：没有运维，服务挂了怎么第一时间知道？
A：用一个独立于服务器的定时任务去探测你的健康检查地址，把结果推到你手机上的通知渠道。关键是探测方和通知方都不能依赖你被监控的那台机器。
Q：个人项目有必要上专业监控系统吗？
A：大多数没必要。先用最轻的方式覆盖「服务是否可用」，等真的被某个盲区坑过，再针对那一个盲区补，比一次上一整套划算。
Q：告警太频繁看不过来怎么办？
A：把范围收到只报用户能感知的问题，剩下的进日志。报警太多会让人麻木，麻木之后最重要的那条也会被漏掉。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」