09 · 运维与发布 · 业务信号
机器还活着，回写队列已经堵了一上午
SRE（可靠性）用业务能感知的信号告警，例如收货失败和回写积压。机器还活着不算可用；第一动作不是重启全部服务。
SRE 把告警定义成业务已经受伤
运维工程师保证机器和备份可恢复。SRE 的特点是选择少量真正代表业务失败的指标：收货错误率、待回写堆积、登录失败、磁盘将满。指标要有阈值和负责人。机器 CPU 偶尔高，如果收货正常，就不该把人叫醒。人被无关告警叫醒几次之后，真的队列堵住时不会有人看。
每个告警写明第一动作。待回写堆积先看是网络、对方关账还是程序错误，而不是先重启全部服务。重启会把处理中的请求变成未知。SRE 和集成工程师一起写这个动作。没有第一动作的告警，只是一条消息。
错误预算用在发布上
如果一周内收货失败已经超过约定，SRE 可以要求暂停非紧急发布。这不是权限争夺。连续发布会让人无法判断是哪一版引入的。他用发布号把指标分成段，方便对照。用户侧的报障时间要能和告警时间对齐。对不齐，说明告警并不是用户真正感知到的那件事，需要改指标。
队列堵了一上午
金蝶维护导致回写全部超时。应用服务器健康检查仍是绿的，仓管只看到单据停在待回写。SRE 把积压条数和最老一条的年龄做成告警，超过十五分钟通知集成和财务。那天告警在维护开始后不久触发，支持按预案告诉仓库：可以继续收货，凭证会延迟，不要重复点回写。维护结束队列消化完，没有双草稿。如果只看首页健康检查，这一个上午会在对账时才发现。
预案写进值班说明，和运维的恢复演练放在一起。SRE 每个季度删掉没有触发过行动的告警。删之前问一句：如果它今晚响了，谁要做什么。答不出，就删。留下的告警必须能在值班说明里找到第一动作，并且第一动作不是先重启所有服务。误报要记原因。误报不处理，阈值只会越调越高，真正的积压也被吞掉。
他把告警和构建号叠在一起看：业务指标没变、错误率却上升，先查统计口径，不把夜班叫起来重启。用户报障最多的那一步如果没有对应指标，要么补一个指标，要么承认这一步没人监控。报障聚类指出的是采集盲区，不是客服态度。告警恢复后写清是哪一条动作起了作用。写不清，下次仍会从头试到第三轮。备份能不能解开，是运维的演练；本岗管的是业务已经受伤时谁做什么。值班表上的第一人必须能说清先给谁打电话。双草稿会不会出现，仍由集成用幂等号证明。积压年龄和积压条数要分开告警。条数少但最老一条已经四个小时，对账窗口可能已经过了。值班说明里写清：先打电话给集成，还是先通知财务关账时间。两个电话的顺序写错，仓库会继续点回写。对方系统的维护窗口要提前写进日历。维护当天积压告警会响，预案必须写「预期中，不要重启」。没有这行字，值班会按故障处理把队列冲乱。