程序匠

星期二, 八月 29, 2006

编写可靠软件-面对不可避免的错误

学习一种新语言的目的是什么?

最重要的是能够从新的语言中吸收到新的营养,从不同的角度去理解我们所碰到的问题,以及新的解决问题方式。至少不至于坐井观天。

或许你认为理想上经过严格测试的软件是不应该有Bug的,而当Bug作恶的时候你会产生罪恶感,你觉得总有那么一条道路可以通向完美的零缺陷之路,你自责、困扰。但你是否曾经反过来想想,这种理想是永远达不到的,但是如果我们承认系统、软件是包含错误的,我们是不是无能为力了?

这两年来我做的一些程序和以往的软件相比有一点很大的不同,那就是经常需要和硬件打交道。我们经常碰到的一个问题是在很多情况下,譬如温度过高、或者运行时间过长、或者磁盘读写、删除次数太多的情况下,DSP会暂时停止运行,或者磁盘会损坏。这个时候,你能干什么?假装这些事情不会发生?

有些时候也并不完全是硬件的问题,在如今高度紧张的竞争环境下,我们的客户需求变更完成时间通常以天或者周为单位,如此的速度去响应你的客户,你能保证你的代码没有任何问题?

没有人能够保证,但是这个时候,你还必须做到这样的系统是能够可靠运行的,就拿我们的其中一个软件来说,虽然本身价值不高,但是它可能牵涉到大量的金钱、甚至是人的生命。

为了解决这些问题,在某些关键的位置,工程人员必须在机器上插入硬件狗,在机器停止响应的时候自动重新启动机器。但是某些时候机器本身是没有问题的,而是系统或者软件的问题,例如DSP因长时间运行停止运作,或者程序本身产生错误,所以我们需要软件狗,一个守护进程,监视系统的运行状态,并在出现异常的情况下重启系统。

然而,这样还是不够的,某些时候,整个系统的运行是正常的,只不过某些模块会出现问题,因此,我们进一步把整个系统划分为几个重要的模块,单独的进程运行这些模块,一个比较完备的守护进程管理这些模块之间的依赖关系、它们的启动、状态监视以及出现异常的情况下按照某种顺序重新启动。

这样的需求和实现出现在我们一个小小的产品中,但很快发展到我们所有的软件中。例如,视频编解码通常需要大量的CPU,而在CPU非常紧张的情况下或者某些时候编码器网络传输的流数据不正常,解码器通常会出现异常的情况,轻则停止解码,重则退出系统。而在监控大量视频图像的情况下,工作人员或许根本无法注意到哪一路图像出现异常。所以,客户的要求是不管因为网络、编解码软件或者其他什么原因,必须保证24小时永不停止的图像显示(如果能够自动恢复的话),在我们流媒体、集中存储系统中也存在着同样的需求。

因此,我们必须假设系统、程序是包含错误的,在这样的情况下我们如何编写可靠的软件?

我们用自己的守护系统来应对这个问题,但是并不是那么系统、完备和彻底。

而这也是Erlang要解决的问题,通过编程语言、通过库、通过良好的系统原则来构造可靠的强壮的系统,如果我能够早一年看到,或许就会少走许多弯路,能走得更好。

0 Comments:

发表评论

Links to this post:

创建链接

<< Home