北京
一个工作流每天跑27次，每次都显示"已完成"。但其中27个分支从未真正执行过——条件永远无法匹配，步骤被跳过，运行却照常标记为成功。这个状态持续了数周，系统一直在诚实地报告"成功"，而实际上什么都没做。
问题出在一个从未被使用的枚举值上。StepExecutionStatus.SKIPPED从项目一开始就存在于代码中，但整个代码库里它的出现次数是零。被跳过的步骤根本不会创建数据库记录，循环只是把一个字典追加到内存列表中然后继续。跳过的唯一痕迹，藏在一个JSON blob里。
这不是"有bug"那么简单——有bug是常态。真正值得思考的是：系统每天27次报告成功，而实际上什么都没处理。你是在什么时候发现这个问题的？
修复只花了一个下午
修复方案很直接：被跳过的步骤现在会写入一条真实记录，包含跳过原因。运行报告会显示处理了多少、跳过了多少、失败了多少，这些数字直接从记录行推导，不会和步骤视图产生偏差。
然后我加了一个徽章：当一次完成的运行什么都没处理时，明确标注出来。
但审核者在不到一小时内就否决了它，而且他是对的。
零可能是合法的
安静的一天，没有东西要发送，COMPLETED且处理数为0，这是正确的。一个定时工作流在无事可做的日子里，本来就会处理零个任务。我的徽章会在所有这类运行上触发，一周内就会被静音，然后在真正重要的那天反而不起作用了。
这比什么都不显示更糟——因为它看起来像是有覆盖。
徽章被移除了。计数保留下来，作为朴素的事实。判断权跟着徽章一起走了。
两天后的另一个发现
两天后，我写了一个部署脚本：在本地运行测试，有红就拒绝部署，最后验证部署是否成功。
它打印了五行绿色：
- ✓ 已部署
- ✓ 服务器在 c15b730
- ✓ 所有容器运行中
- ✓ agent-mesh.org/health 健康
每一行都是真的。但我刚部署的功能是死的。容器在我添加它需要的环境变量之前就启动了，所以代码发布了，却什么都没做。
我是通过curl端点并读取值才发现问题的——脚本没有做这一步。
部署验证≠功能验证
一个验证"已部署"的脚本，不等于验证"功能正常"。健康检查是通用的，效果检查才是具体的。
这两个案例指向同一个教训：自动化系统倾向于验证自己知道如何验证的东西，而不是验证真正重要的东西。枚举值存在但从未被写入，部署脚本验证了部署但没验证功能——都是系统在"正确地"做错误的事。
真正的检查，往往需要跳出系统自身的视角，问一个它不会问的问题：这次运行到底处理了什么？这个部署到底做了什么？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
