[设计] audit机制的风险

继前一篇：[程序员] 技术支持里的大宝藏。在这个问题的处理过程中，发现软件路由audit机制的处理，存在一个小问题，引发的一个小的个人思考！

在程序的设计里，也有一种防御机制是需要通过audit机制来提供一种自愈的方式。比如在C语言里，有很多函数要做入参的判断，看输入是否在合理的范围；还有对指针的判断，是否初始化等等；如果指针未作有效性校验，可能导致代码非法内存地址访问从而导致程序异常退出。如果加了校验，也就意味着，所有用到指针的函数，都需要这种校验，代码量就上来了，导致性能下降，出错概率增加，维护成本增高等等后续的问题。

还有一种是复杂的数据一致性的audit恢复机制；例如有一个软件需要自己维护三层路由表，以及恢复机制；具体是，一开始启动，软件会将需要的路由表配置到系统里；这样就有两套路由的信息，一个在软件内存，一个在内核系统。如果操作系统里的路由表里的记录和软件内存中记录不一致，需要做增删的操作，以确保应用于操作系统在路由数据和内存一致。这里产生不一致的情况，大体有两种：一个是人为误操作；一个是内核有问题。

但是就这两种情况，发生频率非常低。因为，现场操作的时候也是战战兢兢如履薄冰。而内核我们选用的都是比较稳定，已经在整个软件业，soak了很长时间，而且路由模块在内核里非常的稳定。如果要做这个audit，就需要软件自己实现一套netlink操作增删改查校验的机制（如果使用ip命令，效率是个问题；如果使用相应的库，需要熟悉这个库的使用方式）。增加了原有代码的代码量，随之而来的就是bug风险增加，增加效率的消耗。

上面这个例子就严重依赖内核netlink的行为，如果内核发生变化，也要做相应的调整，其实这一块的代码量不小。不巧，本人就遇到几例，这种审计代码带来的bug，导致现场的网络出现问题。这就相当于路由的原始删减没有问题，内核没有问题，人为操作上也没碰到过误操作，但是审计代码出了好几次问题。这就比较尴尬！

这种审计的代码做的一定要仔细，要有更为高的测试/回归测试/边界值测试的覆盖率！以免尴尬的出现！