继前一篇:[程序员] 技术支持里的大宝藏。在这个问题的处理过程中,发现软件路由audit机制的处理,存在一个小问题,引发的一个小的个人思考!
在程序的设计里,也有一种防御机制是需要通过audit机制来提供一种自愈的方式。比如在C语言里,有很多函数要做入参的判断,看输入是否在合理的范围;还有对指针的判断,是否初始化等等;如果指针未作有效性校验,可能导致代码非法内存地址访问从而导致程序异常退出。如果加了校验,也就意味着,所有用到指针的函数,都需要这种校验,代码量就上来了,导致性能下降,出错概率增加,维护成本增高等等后续的问题。
还有一种是复杂的数据一致性的audit恢复机制;例如有一个软件需要自己维护三层路由表,以及恢复机制;具体是,一开始启动,软件会将需要的路由表配置到系统里;这样就有两套路由的信息,一个在软件内存,一个在内核系统。如果操作系统里的路由表里的记录和软件内存中记录不一致,需要做增删的操作,以确保应用于操作系统在路由数据和内存一致。这里产生不一致的情况,大体有两种:一个是人为误操作;一个是内核有问题。
但是就这两种情况,发生频率非常低。因为,现场操作的时候也是战战兢兢如履薄冰。而内核我们选用的都是比较稳定,已经在整个软件业,soak了很长时间,而且路由模块在内核里非常的稳定。如果要做这个audit,就需要软件自己实现一套netlink操作增删改查校验的机制(如果使用ip命令,效率是个问题;如果使用相应的库,需要熟悉这个库的使用方式)。增加了原有代码的代码量,随之而来的就是bug风险增加,增加效率的消耗。
上面这个例子就严重依赖内核netlink的行为,如果内核发生变化,也要做相应的调整,其实这一块的代码量不小。不巧,本人就遇到几例,这种审计代码带来的bug,导致现场的网络出现问题。这就相当于路由的原始删减没有问题,内核没有问题,人为操作上也没碰到过误操作,但是审计代码出了好几次问题。这就比较尴尬!
这种审计的代码做的一定要仔细,要有更为高的测试/回归测试/边界值测试的覆盖率!以免尴尬的出现!