审计和追溯

 

审计和追溯

 

陈能技

2007-10-16

 

原文：Audit Trails, Traceability - Because Sometimes Things Go Wrong (And no, they are not to place blame! （Alan S. Koch）

 

每一次我们对产品作出改动，都存在出错的风险。风险是一个事实。彻底消除风险的唯一方法是永远不要修改。（但是，这是不现实的。）因此，我们只有采取行动降低风险。配置管理（CM）就是用来降低风险的。

 

我们在配置管理中做的所有东西都是为了减少出错的可能性而设计的，或者是为了真正出错时降低影响的程度。配置管理帮助我们避免很多错误，并且对于不可避免的错误出现时能尽快地恢复。

 

那么审计和追溯如何适应这些情况呢？

 

追溯不是防止错误，而且审计不会帮助我们从错误中恢复。那么是否意味着它们不是有价值的配置管理工具呢？

 

相反，审计和追溯是在配置管理工作中学习如果降低风险的两个最重要的工具。

 

回答六大问题

审计和追溯是为了回答6个问题而设计的机制：何人，何物，何时，何地，为何，如何。例如：

-          谁做出的更改？谁允许的？谁知道这些更改？

-          做出了什么更改？什么没有更改？

-          什么时候做出了更改（尤其是与某些活动相关联的）？

-          更改出现在什么地方（例如：什么平台、什么库、什么位置）？

-          为什么做出更改？什么触发了这个更改或者这个更改的动机是什么？

-          这个更改是如何进行的？做了什么，没做什么？更改的信息是如何记录和沟通的？

 

虽然用这6个问题来指责人是很诱人的一件事情，但是如果这样做则会产生反作用！最好是通过这些信息来学习如何处理变更，并且如何在今后让这些事情更顺利地进行。

 

从“何人”学习

“何人”做出的更改主要围绕有效性相关的信息。是否是“正确”的人来做出的修改？做出修改的这个人是否拥有足够的信息来做出修改方法的选择?同样的问题可以问同意做出更改的人。

 

并且由于任何的修改都会影响到其它的活动，因此类似的问题可以问：更改所涉及到的其他人是否知道他们需要清楚的相关信息？

 

从“何物”学习

更改了“何物”给我们指出完整性的问题。更改是否是对所有应该更改的东西进行的？什么东西遗漏了吗？为什么遗漏了？

 

相反的是，改掉了不应该改的东西。更改的人是否过于热情？他是否悄悄加入了一些未被审核的更改？

 

从“何时”学习

“何时”更改关系到同步问题。在更改进行之前是否应该先完成什么活动？或者在更改之前是否有些活动不应该进行？这些更改是否影响到了其它更改？

 

“何时”更改还可能关系到被更改系统的业务使用。是否有些业务活动不应该被中断而去做这些更改？或者是否应该推迟更改知道某个特殊事件发生后（例如月结后）？

 

从“何地”学习

“何地”做出了更改帮助我们区分问题。是否更改发生在它应该进行的区域？更改后是否分发给所有应该接收到它的人？是否及时在每个地方安装起来？

 

相反的，是否有地方不应该更改的却被更改了？是否超越了它的预期目标？偏离了多远？

 

从“为何”学习

“为何”更改可能是最重要的问题。更改背后的理由是什么，不同的意见是什么？是否考虑到了相关的事实？问题得到了正确的回答吗？决定做出更改的人明白其中的风险了吗？

 

从“如何”学习

最后，人们都会犯错。错误是否只是人的原因？这个人是否跳过了某个步骤，是否不正确地做事情，或者抄近路走捷径了？这个人是否有必须的技巧和培训让他能够做对事情？他们是否明白更改程序存在并且清楚遵循步骤的价值？他们是否有足够的工具或方法帮助他们协调和有效地进行自己的那部分工作？

 

从六大问题学习

如果我们不使用这些信息去指责别人，那么我们用它来干嘛？学习啊！

 

我们一方面努力不去犯错误，另一方面我们要时刻把错误当成是改进的机会。最少这六个问题中的一个可以为我们指出我们的配置管理流程的缺点。也许有些过程需要更具体些。也许有些应该包括进来的人被忽略了。可能需要培训。也许某些核实和权衡需要进行。

 

我们对目前问题的信息拥有得越多，我们越容易从它们学习到东西，我们的过程改进也就能更好地进行。因此，又把我们带回到审计和追溯。这是我们挖掘宝贵信息的主要渠道。缺乏信息，只会留给人们回忆和想象来识别问题的根源。面对“硬”数据，一个清晰的过程改进路径才可能出现。

 

因此，审计和追溯是真正降低风险的机制。虽然它不能直接帮助我们避免风险，但是它们确实把我们放到一个从每个错误和失败学习的位置，并且避免在将来重复！