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

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

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

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

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

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

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

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

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

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

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

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

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