流程可观测性:上线一个月后你应该能看到什么
在我们的商业提案生成器中,系统从一开始就积累了两类统计数据:按客户经理统计的业绩,以及哪些提案类型的需求更高。这是整个服务中最容易实现的部分,也是唯一能让我们用数字而非印象来回答"到底有没有效果"这个问题的部分。
任何流程上线一个月后,管理者都会问同一个问题。如果得到的答案只是"团队反馈不错"和"用起来更顺手了",那么上线的其实不是一个流程,而是一场演示。流程可观测性(process observability,指系统能够通过外部数据还原其内部状态的特性)必须在上线之前就规划好,上线之后几乎不可能再补上。
最小化的可观测性配置只需要三个数字:有多少流程实例走完了全程、其中有多大比例以失败告终,以及从开始到出结果一共用了多长时间。有这三个数字,就足以区分真正的改善和单纯的运气。超出这三项的所有指标,都应该等具体问题出现后再补充,而不是提前堆砌——过多的指标扭曲行为的力度,远大于它们提供的帮助。
流程上线后必须追踪的三个数字
这套指标之所以保持精简,不是出于节省成本的考虑,而是实践得出的教训:每多一个指标,就需要多一个负责人,也会引出更多不指向任何决策的讨论。下面这三个指标各自回答一个不同的问题,彼此之间不能互相替代。
已完成的流程实例数量。不是用户数,也不是登录次数,而是流程从开始真正走到结束的案例数。这是唯一能把"真实的工作"和"表面的活跃"区分开的指标:一个用户完全可能每天登录,却一次都没有走完整个流程。
失败率。失败指的是工作在形式上已经完成,但结果没有继续往下推进的情况:文档没有发出去,工单没有分配,回复没有被记录下来。这个比例在流程被修正后会下降,在负载升高时会上升——它反映的是流程本身是否稳固,还是完全靠员工加班加点硬撑起来的。
从开始到出结果的中位耗时。用中位数而不是平均数:耗时分布几乎总有一条很长的尾巴,平均数在这种分布下无法代表任何一个真实案例。中位数回答的是"通常需要多久"这个问题,长尾则回答"哪里出了问题"。
| 指标 | 回答什么问题 | 常被什么替代 |
|---|---|---|
| 已完成的流程实例 | 工作是否真正在流程中流转 | 活跃用户数 |
| 失败率 | 流程是否稳固 | 客服工单数量 |
| 中位耗时 | 速度是否真的提升了 | 平均耗时或团队的主观感受 |
第三列很关键:替代指标几乎总是看起来合理,而且总会让情况显得比实际更好。活跃用户数会因为单纯的好奇心而上升,客服工单数会在用户不再指望得到帮助时下降,而平均耗时只要剔除掉极端值就能变得好看。
为什么流程模型和实际执行会出现偏差
可观测性还有另一个存在的理由:纸面上描述的流程和实际发生的流程是两回事,而且这个差距是可以测量的。将事件日志与正式模型进行比对的方法——一致性校验(conformance checking)——已经存在了很长时间,而它揭示出的偏差往往大得出人意料。
在将真实事件日志与正式流程模型进行比对时,一个行政流程(35个案例)的吻合度为0.51,一个许可证发放流程(407个案例)的吻合度为0.80。造成偏差的原因是管理人员对记录的手动修改,以及并行分支配置错误。
这项研究已经将近二十年,而且研究对象是荷兰的公共部门——这是它的局限所在。但这套方法至今仍是流程挖掘(process mining)的基础,而且只要有人真正把纸面流程和日志做一次对比,这个结果就能在任何组织中复现。实践层面的结论是:偏差达到一半案例并不是异常,而是一个无人监控其执行情况的流程的常态。
会衡量指标的团队与不会衡量的团队之间的结果差距
衡量能力与实际结果之间的关联,在软件工程实践中记录得最为充分——那里的指标高度标准化,而且已经积累了多年数据。
在变更失败率上,成熟度最高与最低的团队之间差距达到182倍;在故障后的恢复速度上,差距达到2 293倍。而在两个相邻成熟度组之间,变更失败率的差距是5%对20%。
这里的局限我要直说:这份报告并不能证明是可观测性本身导致了这样的结果——它显示的是,成熟度不同的团队,其中一项差异恰恰是统计自身失败的能力。因果关系在这里并未得到证实,我使用这些数字只是为了说明差距的量级,而不是作为因果关系的证据。
AI场景下的可观测性:一个特殊情况
对于基于语言模型的场景,在三个基础数字之外还要加上第四个:人工修正过的结果所占的比例。没有这个数字,任何关于提示词优化或模型更换是否有效的判断都只能停留在信念层面。
在生产环境中部署了AI系统监控的组织比例,从2024年的42%上升到2025年的54%。
这里需要一个转述中常常丢失的精确点:该报告衡量的是是否部署了AI系统监控这件事本身,而不是具体是否监控回答质量。报告中并没有单独给出准确性控制或错误回答比例的数字。而且这是一份由可观测性工具厂商发起的调查——其商业立场是明摆着的。真正有参考价值的是方向:接近一半的企业把AI场景推上了生产环境,却没有对其实际行为建立内置的控制机制。
为什么指标集合必须保持精简
"什么都想测一测"的冲动几乎立刻就会出现,而且几乎总能占上风。对抗这种冲动的论据比任何仪表盘都要古老:一旦某个指标变成了目标,它就不再是一个指标——这就是如今被广泛称为古德哈特定律(Goodhart's law)的机制。
测量和排名机制不会一直保持中立的旁观者角色:它会开始按自己的逻辑运转,并且侵蚀掉它本应记录的那个对象。这项研究正是那句广为人知的"指标一旦成为目标"表述的源头。
需要说明一点:这篇文章的全文是付费内容,我参考的是摘要——那句著名的表述本身并没有出现在公开可读的部分,但它确实被普遍归到这篇研究名下。我在这里把它当作一个概念性的论据使用,而不是直接引用。由此得出的实践结论很直接:任何一个用来评价员工的指标,都会开始反过来塑造他们的行为——这正是为什么三个数字的组合比十五个数字的组合更安全。
如何在上线前就规划好可观测性
第四个决定是唯一一个事后无法弥补的。基线测量只需要半天时间,人工核对上线前最近二十个结果即可完成。跳过这一步的公司,一个月后讨论的往往不是真实的效果,而是对"以前是什么样"的模糊回忆。这篇关于如何把一个效果拆解成各个组成部分的分析也说明了同样的道理:没有基线测量,这种拆解从根本上就无法进行。
前三个决定看起来像是技术问题,但真正拍板的应该是流程的负责人。什么算作失败,这不是一个架构问题,而是公司要划定"已完成的工作"和"未完成的工作"之间边界的问题。
上线前要做的四个步骤
用一句话描述已完成的流程实例
如果这句话需要附加各种条件和但书才能说清楚,说明这个流程的定义还不够精确,无法拿来测量。
定义三种失败类型
不是笼统的"出错",而是具体的事件:没有发出去、没有分配、没有记录下来。开局有三种就够了。
在二十个案例上完成基线测量
半天的工作量。这是上线之后唯一无法补做的事。
确定一个固定的复盘日
具体到星期几,具体到某一个人。没有固定复盘安排的指标,等于不存在。
如果上线一个月后,"到底有没有效果"这个问题的答案是几句话而不是三个数字,那么这个项目本质上就是一场演示——无论验收单上写的是什么。
关于流程可观测性最常被问到的问题
评估一个刚上线的流程需要哪些指标?
三个:已完成的流程实例数量、失败率,以及从开始到出结果的中位耗时。对于AI场景,还要加上第四个——人工修正过的结果比例。上线阶段超过四个指标反而有害:每多一个都需要一个负责人,而且它开始影响员工行为的速度,往往比它带来任何实际价值的速度都要快。
为什么中位耗时比平均耗时更可靠?
执行时间的分布几乎总有一条长尾:大多数案例只需要几分钟,极少数案例需要好几天。这种分布下的平均数无法代表任何一个真实案例,而且一个极端值就能让它明显偏移。中位数回答的是"通常需要多久"这个问题,长尾则被单独拿出来分析,作为了解究竟哪里出了问题的信息来源。
可以在上线之后再补上可观测性吗?
可以部分补上。计数器和时间戳可以后补,只是成本更高。无法补救的是基线测量:没有它,任何对比都会变成一场关于记忆的争论。如果基线测量确实被漏掉了,唯一诚实的做法是根据上线之前留存的文档资料去重建它,并明确说明这是一次重建,而不是一次真实测量。
员工会不会开始想办法粉饰这些数字?
只要这些数字被用来考核个人,就一定会。所以这三个基础指标应该被当作流程指标来看待,而不是个人绩效指标,讨论的重点应该放在"哪里出了问题",而不是"是谁的责任"。一旦失败率成为发奖金的依据,它就不再反映真实情况——这是任何组织里的任何测量都会出现的稳定规律,不是个别现象。
按客户经理和按各类提案需求积累统计数据的机制,来自作者本人公司Alego.Digital旗下商业提案生成器产品的产品说明。这是作者所在公司的内部资料,未经独立第三方核实,这里仅作为说明该机制运作方式的示例使用。三个基础指标的组合以及上线前四个决定的先后顺序,是作者本人从实施实践中总结出的经验,并非借用某套现成方法论——在公司文档中也没有被正式确立过。
- Rozinat A., van der Aalst W. M. P. Conformance checking of processes based on monitoring real behavior. Information Systems, 2008. vdaalst.com
- DORA, Google Cloud. 2024 Accelerate State of DevOps Report, 2024(受访者超过39 000人). dora.dev
- New Relic, Enterprise Technology Research. 2025 Observability Forecast, 2025年9月. newrelic.com
- Strathern M. "Improving ratings": audit in the British university system. European Review, 1997. cambridge.org