企业微信集成的日常运维清单

「服务活着」不等于「集成活着」

普通 Web 服务的健康检查回答的是两个问题：进程在不在、依赖连不连得上。企业微信集成在这之外还挂着三样不在你进程里的东西 —— 账号的登录态、回调地址的可达性、平台侧还愿不愿意往你这儿投递。这三样任何一样断了，你的 /health 都照样返回 200，错误率也照样是零。

所以日常运维的第一条原则是：用「有没有在发生」当探针，而不是用「有没有报错」当探针。错误率为零可能是最好的消息，也可能是最坏的 —— 因为一条请求都没进来，而这两种情况在监控图上长得一模一样。

• 账号掉线：出向调用开始因登录态失败，但如果这段时间恰好没人调用，它就完全无声，等到早高峰才集中暴露。
• 回调停投递：入向计数归零，错误日志同样是零，两条曲线一起躺平，看图的人只会觉得今天挺安静。
• 消费停顿：事件收下了、ACK 也回了，业务侧却不再产生任何副作用。这类最难被发现，因为链路每一段的自查都是健康的。

三类的共同点是不报错。所以每天的动作不该是「扫一眼有没有红」，而是「确认这条链路今天确实在发生」。指标怎么定义、阈值怎么算，站内另有一篇专门讲；这篇只管人每天该做的那几件事。监控做得再细，也替代不了每天有人花十分钟问一句「这条链路今天还在跑吗」。

每天十分钟：四个动作，不是四张仪表盘

清单只写四条是刻意的。运维清单真正的敌人是长度 —— 二十项的清单第三天就没人看了，而四条能在十分钟内做完，做完还有余力去处理看到的东西。四条分别覆盖入向、链路、出向、积压，每一条后面都必须跟一个明确的「看到什么就做什么」，否则它只是看图。

1. 1对一眼入向事件量和昨天同时段的比值。为什么用比值而不是绝对阈值，指标那篇有展开；这里只管动作：跌破一半就人工确认一次，别等它归零。
2. 2看昨夜合成探针的成功率和时延。这是唯一能把「没人说话」和「链路断了」区分开的信号。时延比平时高一截就记进值班本，先不动，连着两天再查。
3. 3看出向失败的构成，而不是总成功率。参数错误、登录态、频控、超时这四类的处置动作完全不同，混进一个百分比里就失去了指导意义。哪一类涨了，就往哪一段走。
4. 4看队列里最老那条消息的年龄和死信的新增量。年龄为什么比长度可信，指标那篇讲过；这里只要两个动作：年龄超过约定值就去看是哪个分区卡住，死信只要有新增就当天看一眼，它是唯一会沉默累积的债。

有人会问，为什么 CPU、内存、数据库连接数不在里面。因为那些是通用服务指标，你的监控系统本来就在盯，真出问题它会主动叫你。晨检要看的恰恰是那些不会主动叫你的东西 —— 每一条都对应一种「系统不知道自己坏了」的场景。清单和告警的分界线就在这里：告警覆盖你预料到的失效，清单负责捞你没预料到的。

第三条值得多说一句：错误分类得先能统一。用 wecomapi 这类统一网关时错误模型是一套的，按类别分桶直接就能出图；自己对接多套接口形态的，先做一层错误归一再统计，否则不同来源的分桶不可比，趋势图上什么也看不出来。

2026-08-15  值班：张三
入向/昨日同时段    0.93         正常
探针 成功率/P95    100% / 1.2s   <- 平时 0.8s，观察
出向失败构成       频控 61%      <- 批量任务并发已下调
最老消息年龄/死信   4m / +2       <- 重放 1 条，剩 1 条待查
今日变更           无
未闭环             死信 1 条（工单 #4412）

静默失效只能靠自己主动证伪

上面四个动作有一个共同弱点：它们都是被动的。链路彻底断掉时，四个数会一起变成零，而零和「夜里没人说话」在图上无法区分。补这个洞只有一个办法 —— 自己定时给自己发一条消息，让它走完发送、平台、回调、消费整条路，再回到你的断言里。

做法不复杂：准备一个专用的测试会话，每隔几分钟用 wecomapi 的消息接口发一条带唯一标记的文本，消费端等这个标记出现并记录端到端耗时，连续两次没等到就告警。这是整条链路唯一的正向证据，比任何错误率都硬。

# 示意脚本，鉴权方式、精确字段与端点以线上接口文档为准
MARK="canary-$(date +%s)"
curl -X POST https://manager.wecomapi.com/message/sendText \
  -H "Content-Type: application/json" \
  -d "{\"guid\":\"7db8...\",\"toId\":\"78813...\",\"content\":\"$MARK\"}"

# 消费端命中 $MARK 时记录端到端耗时
# 晨检只看一件事：昨夜这条曲线有没有断点、时延有没有整体抬升

探针用哪个账号发，本身也是个决定。用生产账号才测得到真实链路，但它会在客户看不见的角落里持续产生记录；用专门的测试账号更干净，可它证明不了生产账号的登录态还在。折中做法是两条都跑：测试账号高频跑完整链路，生产账号低频跑、早晚各一次，只验登录态。

探针的价值还不止于发现故障，它给你一条基线时延。平时 800ms、某天变成 4s，你会在用户投诉之前就知道链路有变化。两个细节别忘：探针会话要从业务统计、自动回复规则和标签逻辑里排除掉，否则它会触发自己；探针进程本身挂掉也要有告警，一个静悄悄死掉的探针比没有探针更危险，因为它让你以为有人在看。

每周和每月，管的都是会过期的东西

日常四条管的是当下。剩下的风险几乎都属于同一类：某个有有效期的东西悄悄走到了终点。这类事故没有征兆、一次性全面失败、在监控曲线上完全看不出来，只能靠日历去管。

• 每周：凭证与登录态的剩余有效期、频控命中率的斜率、死信的新增量与最老条目、上周告警的复盘 —— 复盘的产出应该是删规则，而不是加规则。
• 每月：回调域名的证书到期日、出口 IP 与域名的变更计划、账号数与消息量的容量水位、下游系统（工单、CRM、数仓）的超时预算是否还成立。

到期表本身也要有主人，否则它很快会变成一张没人更新的旧表。做法是把每一项到期时间写成带提醒的日历事件，提前两周通知，责任人写到具体的人而不是组 —— 写到组等于没人负责，这一条在证书上尤其灵验，而证书过期是全量、瞬时的故障，没有灰度可言。

频控命中率单独说一句。它上涨往往不是因为你调得更多，而是因为业务量涨了、批量任务的打散策略没跟上。这个数从 0.1% 爬到 2% 会花好几周，每天看都觉得正常，只有按周对比才看得出斜率 —— 而等它触发阈值告警时，通常已经在影响转化了。

每月还要留一件事：演练。掉线之后自愈是不是真能拉起来、密钥轮换的并存期是不是真的存在、死信重放脚本是不是还能跑通 —— 这三件没演练过的预案，等于没有预案。演练挑工作日上午做、故意做、事后记录耗时，凌晨被叫醒时你能依赖的只有肌肉记忆。

值班与交接：清单只有落在人身上才成立

清单失效通常不是因为写得不好，而是因为它没有主人。上线两周后热情消退，四个动作变成两个，再过两周变成打开面板扫一眼颜色。要挡住这个衰减，只能把它变成一件有交付物的事。

1. 1值班本：每天一行，记今天的异常、做过的变更、以及没闭环的项。它的作用不是留档，是让第二天的人知道昨天发生过什么 —— 大部分「查了两小时才发现是昨天改了配置」的时间都花在这上面。
2. 2交接三问：昨天有没有变更、有没有未闭环的告警、探针基线有没有变化。这三个问题回答不了就别接班。
3. 3告警的格式比分级更重要：一条告警必须带上账号维度、请求标识和一条明确的首个动作。「出向成功率下降」是没用的告警；「账号 A 出向成功率 62%、失败集中在频控，先降批量任务并发」才是。
4. 4每周至少删一条规则。噪声不会自己消失，只会把有用的告警一起淹掉。一条一个月内没有导向任何动作的告警，就该降级或删掉。

还有一件小事收益很大：让机器把四个数填好，每天早上自动发进值班群，人只负责判断和回一句话。要求人去打开三个面板抄数字，这个流程活不过一个月 —— 清单的存活率和它需要的手工步骤数成反比。

变更日历：事故的时间戳几乎都紧跟一次变更

跑上一段时间你会发现，这类集成的线上问题极少是自己坏的，绝大多数是被改坏的 —— 而且改的常常不是你这边。所以日常运维里最划算的一件事，是维护一张所有人都看得到的变更日历。

• 你侧变更：发版、配置调整、密钥轮换、回调域名与证书、出口 IP 变更。这些都该有窗口，且窗口之后要守 30 分钟。
• 对侧变更：企业管理员在后台改了成员、权限或可见范围；下游系统升级改了超时预算；网络出口换了供应商。这些不会有人通知你，只能靠日历上的定期确认和探针基线的变化去发现。

守 30 分钟的意思是：发版之后不要立刻散会，盯着四个数和探针时延各看一遍。这半小时是整个运维流程里投入产出比最高的一段 —— 大部分由变更引发的故障都在这个窗口里露头，而这个时候回滚只需要一个动作。