小团队如何用“自动化巡检表”替代昂贵的监控系统
很多中小团队在业务上线后都会遇到同一个问题：服务突然变慢、接口悄悄报错、数据库连接数悄悄飙升，但等到用户投诉时，故障已经持续了十几分钟甚至更久。买一套商业监控系统动辄每年几万到几十万，对只有三五个后端的小团队来说，这笔预算往往批不下来。过去半年，我们在没有增加任何付费工具的前提下，用一张“自动化巡检表”加几个轻量脚本，把平均故障发现时间从原来的十几分钟压到了90秒以内。下面把具体做法拆开讲。
先想清楚：你到底需要监控什么
绝大多数小团队并不需要全链路追踪、调用拓扑、智能基线告警这些重型能力。你真正需要盯住的，通常只有四类信号：
- 核心接口的可用性（比如登录、下单、支付回调）
- 关键资源的饱和度（CPU、内存、磁盘、数据库连接数）
- 业务层面的异常计数（每分钟订单创建失败数、消息队列积压量）
- 外部依赖的健康状态（第三方支付网关、短信通道、对象存储）
把这四类信号列成一张表，每一行是一个检查项，每一列是检查频率、阈值、通知方式、负责人。这张表就是你的巡检清单，不需要任何监控产品也能先跑起来。
用“定时任务 + 轻量脚本”落地第一版
我们最早的做法极其简单：一台最低配的云服务器上跑 crontab，每30秒执行一批 shell 和 Python 脚本。每个脚本只做一件事——检查一个信号，返回0表示正常，非0表示异常。
举个例子，检查订单创建失败数的脚本核心逻辑只有三行：
bash
count=$(redis-cli get ordercreatefail_1min)
if [ "$count" -gt 10 ]; then
curl -X POST "https://your-webhook/alert" -d "订单创建失败数：$count"
fi
通知渠道直接用企业微信或飞书的群机器人 webhook，不需要额外配置短信或电话。所有脚本的输出统一写到一个按天滚动的日志文件里，方便事后回溯。这套方案第一版只花了半天时间搭建，覆盖了12个最关键的检查项。
把“巡检表”变成可视化面板
脚本跑起来之后，新的问题出现了：每天早上要手动翻日志才能确认夜里有没有异常，效率很低。于是我们加了一个极简的看板——用 SQLite 存每次检查的结果，再用一个单页 HTML 每10秒轮询一次接口，把最近24小时的状态渲染成一张带颜色的小方块图。绿色表示通过，红色表示触发告警，灰色表示脚本本身执行失败。
这个看板没有用任何前端框架，就是一个静态页面加一段十几行的 JavaScript。但它带来的改变很直接：每天早上花10秒扫一眼，就知道过去一夜有没有红色方块。如果某个检查项连续出现灰色，说明脚本自己挂了，需要先修脚本而不是修业务。
两个容易踩的坑
第一个坑是告警风暴。最初我们把阈值设得太敏感，数据库连接数一波动就发通知，结果一天收到上百条消息，所有人开始忽略群里的告警。后来改成“连续三次检查都超阈值才通知”，并且同一个检查项10分钟内只通知一次。消息量立刻降到了每天个位数，每一条都值得点开看。
第二个坑是脚本本身没人维护。巡检脚本和业务代码一样，会因为环境变化而失效——比如 Redis 地址换了、证书过期了、磁盘满了导致日志写不进去。我们的做法是给每个脚本加一个“心跳检查”：如果某个脚本超过预期时间没有写入结果，看板上那一格就变灰，并且单独发一条通知。这样脚本失效本身也会被巡检到。
什么时候该考虑升级
这套自动化巡检表足够支撑日请求量在百万级以下、服务数量不超过20个的小团队。但如果你遇到以下情况，就该认真评估商业监控或开源自建方案了：
- 服务实例超过30个，手动维护检查项已经明显吃力
- 需要跨多个机房或云厂商做统一视图
- 故障排查需要调用链级别的上下文，而不再只是“某个指标超了”
- 团队里没有人愿意长期维护脚本和看板
在那之前，先用一张巡检表把最关键的信号盯住，比等预算、等排期、等采购要实际得多。故障发现时间从十几分钟降到90秒，靠的不是更贵的工具，而是更早开始做这件事。
