自动化运行可观测，怎么在出问题时五分钟内定位
流程跑挂了却没人知道，等到第二天早上才发现昨天的报表没出来，这大概是自动化最常见的一种故障。这篇讲怎么让故障自己浮出来，日志该记什么才够重放，状态机为什么要留上次成功时间，告警怎么分级才不让人被吵麻木，还有一套五分钟定位流程。末尾写了三种情况下这套东西不值得上，以及故障复盘该问自己哪几个问题。
报表没来，人先慌了
早上八点五十，销售在群里问，昨天那份日报怎么还没有。
这套报表已经跑了小半年，每天下午六点出，从没断过。运维翻了一圈，机器活着，流程在平台里显示已发布，定时器也开着。最后是在翻执行记录的时候才发现，昨天下午的 run 压根没启动。
流程失败会弹窗，流程没跑什么都不会弹。这是最容易被忽略的一类故障，因为系统安静得很。自动化运行状态监控要解决的第一件事，就是让「没动」和「动了」这两件事，在监控页上长得不一样。
下面这六块是我自己排障时反复用到的，按顺序搭，搭建成本一次比一次低。
出问题的三种样子，别搞混
自动化出故障，往多了说能列几十种，排着排着会发现反复在三类里打转。分清这三类，后面的排查路径完全不同。
第一种，没动。流程到了点该跑，没跑起来。定时器没触发、前置依赖没起来、机器被重启了、调度服务挂了。特点是没有任何错误日志，因为压根没执行。这类的排查入口是状态，不是日志。
第二种，动了，结果不对。流程跑完了，状态显示成功，可结果没法用。少了一批单、金额对不上、同一条记录推了两遍。这是最阴的一类，因为它会骗过所有只关心成功失败的监控。真正的判据是数据本身对不对，状态字段在这儿没有任何参考价值。
第三种，动了，慢了。流程还在跑，或者跑完了但比平时晚很多。任务堆积、接口变慢、某一步卡在等待上。这类故障通常不会永久存在，但它是前两类的先兆。留好每次的耗时记录，趋势比单次数值有用。
三种里面，第一种和第三种靠监控能发现，第二种只能靠对账或者抽查。指望一套日志同时解决三种，是不现实的。
日志该记什么，标准就一条
很多团队的日志写了十几行，排查时依然两眼一抹黑。原因是记的是给人看的描述，比如「正在处理数据」。
判断日志够不够用，只看一条标准。拿着这段日志，能不能把这次运行重放一遍。做不到就是不够。
重放需要三段。
开头记这次是谁在什么时候触发的，触发方式是什么，参数里带了哪些关键字段。中间的每一步，记步骤名、进参数、出的结果摘要、耗时、出错时的原始报文。结尾记结果和总量，比如处理了多少条、成功多少条、跳过多少条。
参数一定要记原始值。记「用户 1024 号订单」不如把订单号原样记下来。中间结果记摘要，不贴全文，全文动辄几万行，日志会被撑爆，排查时也翻不动。
运行审计日志最容易被砍掉的是最后一段的总量统计。那一段看着没用，实际是判断「结果不对」的第一道关口。前一次跑处理了八百条，这次跑只处理了十二条，状态还是绿的，你能立刻知道中间发生了什么。
还有一条经验，日志里别打敏感信息。账号、身份证、手机号、金额明细，这些真要记的话做脱敏，脱敏之后保留长度和前后几位。排查时你要的是「有没有、是不是同一个」，很少需要完整值。
状态机，别只有绿和红
运行状态至少要有这么几个值。
待运行、运行中、成功、失败、超时、主动跳过。加上这六个之后，监控页上才能回答三个问题。这个流程现在处于什么状态。上一次成功是什么时候。是不是卡住了。
「上一次成功时间」这一个字段，值钱的程度超过前面所有字段的总和。它是自动化运行状态监控里最省事也最有效的一条规则。任何一条流程，如果上次成功时间超过预期周期，直接标黄。这条规则不区分故障类型，延迟、跳过、环境异常，全都能兜住。
超时状态要单独设，别混进失败里。超时说明流程还占着资源，你得决定要不要杀掉它。混进失败的话，人看到红色就以为已经结束了，实际上后台还在跑，下一次调度就撞上了。
状态机的设计有个副作用，提前想清楚就不吃亏。状态一旦推给业务方看，它就成了对外承诺。「运行中」意味着别重复提交，「失败」意味着会重试还是不会重试，这些约定不说清楚，业务方的预期和系统行为就会错位。
告警要分级，不然一周就没人看了
RPA 失败告警最容易走两个极端。不发，业务方发现不了。发，值班的人一晚上收二十条，第二天全部标成已读，接着连开都不开了。
分三级会好很多。
致命级，核心流程停摆，需要有人立刻处理。定时任务没触发、账务相关的流程失败、订单没往下游推。这类要打电话，不能只发消息。
影响级，有失败但有兜底。自动重试成功了，异常数据被跳过并记了台账，业务还能走，但数据要补。这时候发条消息就够了，让人第二天看一眼。
观察级，留个记录，不用打断任何人。耗时比平时高，偶发的外部接口超时，重试三次之后才成功的。
定级的依据是后果，不是错误有多吓人。连接超时听着吓人，如果它在重试里必然成功，那它属于观察级。
告警内容有固定的六项，少一项人就得再点一次页面，那一分钟就白费了。哪条流程、哪次运行、卡在哪一步、原始错误是什么、已经重试几次、建议动作是什么。建议动作这栏最有用，一句「检查 ERP 网关是否可连」比十行堆栈有用得多。
五分钟怎么花
告警来了之后，我一般按这个顺序走。
第一步，先判断是不是普遍性的。同一时间点多条流程一起失败，八成是环境问题，比如网络、服务重启、账号过期。这时候别去翻单条流程的日志，先去看机器和依赖服务。这一步花三十秒，能省掉后面四分半的弯路。
第二步，看状态定方向。待运行卡着没动，是调度和依赖的问题。运行中超时没结束，去看它停在哪一步。失败，直接进日志。成功但没结果，去查数据量。
第三步，看上次成功时间，往前找变更。上一次成功是什么时候，到故障之间有没有发过版、改过配置、换过 IP、动过证书。手工排障里这一招命中率很高，因为很多故障的根因就是一次没注意的改动。改动记录如果没留在系统里，就手动去问一句。
第四步，缩小到一步。日志翻到失败那一步，看它的入参和上一轮同一步的入参差在哪。多数故障到这一步就露底了。
第五步，先止损再定位。如果这条流程今天还要出结果，手动补一次或者临时切回老流程，让业务先走。定位可以下午接着做，卡着业务等结论是最亏的。
三种情况下，别上这套东西
可观测是要花人力的，不是装个插件就完事。下面三种情况我觉得不值得做。
流程就两三条，跑一次几分钟，出错当场就有人在旁边看着。这时候屏幕开着就够了，别急着搭监控体系。
流程没有重跑机制。一条挂了只能手工从头再来的流程，监控做得再全也没用，它只能告诉你出事了，救不了你。先解决重跑和幂等，再回来做监控。
团队里没人会看日志。告警发了没人理，日志存了没人查，这套东西三个月后就成了摆设。先把值班和复盘的规矩定下来，再上工具。
还有一种情况得单独说。有些团队喜欢一上来就把所有流程的日志全留着，全量采集。这个成本很容易失控，日志存储、检索、权限都是麻烦。更实际的做法是从最关键的两三条流程开始，跑顺了再往外扩。剩下的靠调度器的状态和总量统计兜底，够用了。
每次故障之后问自己三个问题
故障处理完，真正能沉淀下来的就三句话。
这次是靠什么信号发现的。主动告警，还是业务方来问，还是第二天翻报表才发现。三者的含义完全不同，业务方来问说明告警漏了，第二天才发现说明缺的是超时未完成这类检查。
定位花了多久，卡在哪一步。第一步没做环境判断就直接翻日志，通常会多花三分钟。第三步没找变更记录，通常要多花五分钟。这两个数字记下来，下次排障顺序要不要调，一目了然。
缺的是日志、是状态，还是告警。三种缺口对应三种改法，日志补字段，状态加枚举，告警调分级。判断错了就会改错地方，改完问题照旧。
三个问题答完，这篇说的六块里也就知道下一块该补哪儿了。
延伸阅读