一张现场调试记录,最后可能只剩下四行:
调整线束固定方式。
放宽通信超时阈值。
临时屏蔽一个输入判断。
重新启动后,机器人恢复运行。
这四行每一句都是真的,却回答不了一个关键问题:
到底是哪一步改变了结果?
如果每次改动之后都没有单独观察,最后只能知道“几个动作做完以后,机器能跑了”,却无法判断哪一个因素和原问题有关。
这不是简单的记录缺失。
真正丢掉的,是临时改动与故障现象之间的因果证据。
三次改动只有一个结果,为什么说明不了原因?
把现场过程连起来,常常是这样:
原始状态 → 改动 A → 改动 B → 改动 C → 机器人恢复
最终结果挂在整条动作链后面,却没有对应到其中任何一步。
可能是改动 A 已经让现象减少,只是现场没有观察;可能是改动 B 暂时掩盖了报警;也可能三个动作都没有解决问题,只是重新启动以后,原触发条件暂时没有再次出现。
如果这时直接写“问题由 A 引起”或者“采用 C 后问题解决”,结论就超过了证据能够支持的范围。
多个动作可以共同帮助恢复现场,但多个动作加一个最终结果,不能直接形成清楚的诊断结论。
临时改动,不只是变更动作
在故障排查过程中,临时改动不只是为了恢复运行。团队主动改变一个条件、观察系统响应,本身就是一次诊断动作,也可以理解为一次“诊断干预”。
例如,调整线束固定方式,是想观察问题是否和机器人运动时的受力有关;放宽通信超时条件,是想确认现象是否和通信响应裕量有关;临时隔离某个输入,是想缩小可能的触发范围。
一次有效的诊断干预,至少要能够对应四件事:
- 为什么要改,也就是这次准备验证什么假设;
- 这一步只改变了什么;
- 改动以后,预期看到什么;
- 实际现象发生了什么变化。
如果缺少这些对应关系,临时改动就只是一串现场动作,不能成为一组可以继续判断的依据。
临时动作之间,至少要留下观察点
现场不一定有时间写长报告,但可以用一份最小干预记录,把动作、假设和观察结果对应起来。
| 顺序 | 验证假设 | 本次变化 | 变化后现象 | 恢复原状态后的结果 |
|---|---|---|---|---|
| 1 | 这次想排查什么因素 | 只写本次实际改动 | 消失、减少、转移或无变化 | 现象是否重新出现 |
| 2 | 上一步结果支持继续查什么 | 写清新增变化 | 与上一步相比有什么差异 | 是否能够回到原对照状态 |
| 3 | 为什么还需要继续干预 | 写清是否叠加其他动作 | 新增了什么发现 | 哪些结论仍不确定 |
这份记录最重要的不是格式,而是让每一次动作都有前后对应。
顺序不能合并
“调整线束、修改参数并重新启动”不能只写成一条。
如果三个动作之间没有观察点,后面就无法区分各自动作的作用。
假设必须有方向
不要只写“试一下”或者“现场优化”。
要写清这次动作准备排查哪个因素,以及什么结果会支持或削弱这个判断。
变化要尽量单一
条件允许时,一次只改变一个关键因素。
如果为了恢复运行必须连续处理,也要保留动作顺序和每一步之后能观察到的结果,不能等所有动作做完以后才统一写“恢复正常”。
结果不能只写“好了”
现象是完全消失、出现频率下降、触发位置变化,还是报警被隐藏,支持的结论并不一样。
“能跑了”描述的是运行结果,不足以替代诊断结果。
“改完好了”,最多能支持哪一步结论?
临时改动以后现象发生变化,结论需要分层写。
第一层:现象发生了变化
这是最直接的观察结果。
例如,报警减少、触发步骤变化、问题暂时没有出现。此时只能确认改动前后存在差异。
第二层:某个因素可能与问题有关
如果相同干预多次带来相似变化,可以提高这个因素与问题相关的可信度。
但“可能有关”仍然不等于根因已经确认。
第三层:原因范围得到缩小
如果改变该因素时现象稳定变化,恢复原状态后现象又出现,并且其他关键条件保持可比,团队才有更强依据把排查范围收窄。
第四层:永久方案得到验证
只有确认原因、影响范围、相关边界和异常条件,并验证正式方案不会引入新的问题,临时处理才可能进入长期方案。
这四层不能跳级。
一次“改完以后好了”,通常只够支持第一层;观察结果支持到哪一步,工程结论才能写到哪一步。
什么时候应该先停下来,不要继续改?
现场越着急,越容易连续加动作。
但出现下面几种情况时,继续改往往只会让因果关系更乱:
- 已经说不清当前状态和最初状态有什么差异;
- 上一步改动还没有观察结果;
- 多个条件同时变化,无法确定各自作用;
- 当前状态已经无法回到原来的对照条件;
- 日志、报警或触发方式已经被前面的改动改变。
这时候更有价值的动作,不是继续增加一个新调整,而是先冻结当前状态,把动作顺序和已有结果补齐,再决定下一步动作。
诊断结束以后,再处理变更去向
现场排查结束以后,临时动作仍然需要回到正常的工程管理中。
无效的动作回退,依据不足的调整限定范围继续观察,确认采用的方案再进入设计、参数、装配和验证要求。
但这属于诊断之后的下一步。
本文真正要解决的是,在现场还没有找到原因之前,不要让一连串临时动作先把判断链条打散。
临时改动不是越少越好,而是每一次都要留下独立结果。
否则改动越多,关于“机器已经恢复”的记录越多,能够解释“问题为什么发生”的依据反而越少。
现场恢复运行,只说明结果发生了变化。能够解释哪一步改变了结果,排查才有继续往下走的基础。

474

被折叠的 条评论
为什么被折叠?



