本文算是对最近遇到的软件可靠性问题的一个小结，从非功能层面考虑。市面上好像还没有一本关于软件可靠性方面的权威书籍，所以不知写的是否准确详尽。
1. 冗余
系统中的任何部分都需要有冗余，即不存在单点故障，网络链路、服务器主机，再到软件层面的各功能模块，都应具有冗余，保证在系统中出现一个故障点后，可以马上切换到另一处完成任务。现在互联网的数据量大，并发高，一般都会采用负载均衡集群的策略，要做好系统监控检查，笨点的就是ping，另外可通过应用层面去检查。还有就是双机热备的策略，好像一些商用软件这样会比较省license费用。系统再大一点，或许还要考虑异地容灾。
这些应该都是在系统设计、组网层面的，具体到软件模块，可能也就跟数据库有点关系，不过只要存储系统用个raid之类的，也不用在应用层关心太多。
2. 独立的备份与恢复系统
这算是前面一条的补充吧，备份恢复是在应用层面对业务数据的保护，各数据库产品都有自己的一套备份恢复方案，网上资料也一大把。应用程序需要备份吗？大概保留一个安装程序就差不多了吧，版本别搞错了。
3. 无处不在校验
代码中的函数参数校验不用多说，健壮的代码必须具有的特性。更加要注重模块间、平台间接口的参数校验，以及校验失败时的异常处理。
对于分布式系统，少不了数据的一致性校验，怎么校验就要看系统的实际情况，这与系统的数据同步机制有关系，当然至少还是要保证数据在校验规格上是能通过的。用数据库同步会比较简单，但是会消耗性能，更好的方案是内存中的会话同步。
4. 独立的系统监控、告警与恢复
好像现在是个软件都有提供一个独立的监控系统。监控的内容应该要有个checklist，系统部件的状态那是必须监控的，比如哪个服务器宕机了，那就让它重启下，哪个进程挂了，也得去拉它一把。系统资源参数也是应该监控的，如CPU、内存、IO，还应该有跟系统性能关系紧密的监控项，比如吞吐率、响应时间等。当然，还要监控与业务强相关的内容。监控项的checklist不太可能一蹴而就，以后慢慢加吧。
5. 日志系统
日志的作用是对系统的操作有一个记录，方便找出系统问题所在，要警惕异常情况下的超大日志。
6. 系统流量控制
避免出现过大的访问压力，把系统压垮了，底线就是系统不挂。笨点的办法，系统压力超过一个阈值就直接拒绝服务，用户你就下次再试吧，举个例子，各游戏平台的房间人数上限。当然，已在进行中的会话是不能中断的。其他更好的办法，暂时还不是很了解，大概也还是要跟系统实际架构结合吧。
7. 升级、扩容
尽量让用户感觉不到系统在升级、扩容，当然客户端升级那是没办法了，这也是C/S架构系统的一个劣势。