如何正确认识IT系统可靠性-- ZDNet软件频道

我们在服务器可靠性方面经历得太多了。我们总是在努力保障服务器、路由器和switch的正常运转，而用户却总在抱怨系统的可靠性太差。一旦系统出现故障，用户们就会把帮助席位的电话打爆了。而且每一次系统出现故障，他们都会责备系统维护人员。等到高级管理人员最终来到的时候，由于他们也同样经受了系统故障带来的痛苦，他们会站在用户一边。当这些问题如潮水一样涌来，问题出现了：究竟什么是可靠性？谁来测量它？当我为一个客户提供支持流程改进服务的时候，我学到了很多东西。

我的客户是一家中型（大约有3000或者左右的节点）公司，它在20个州和4个国家有办事机构。它邀请我作在的公司帮助他们解决反复出现、困扰着他们的“可靠性”问题。他们期望我们能到他们的环境中去，并为他们的问题提供特别的技术和服务方案。我们公司派了一个比较小的团队进行这一个项目，我是其中的一个低级别成员。

经过两个星期的评估，我们发现了一些非常显见的问题。服务器维护人员把MS Exchange和MS SQL Server安装在卫星办公室的同一个磁盘阵列。网络小组在对路由器做规划的时候非常奇怪地忽略了国外的办公室。有三个用户总是飞来飞去，他们总是处在安全域之外；他们帐户故障的频率比其他用户高出两个量级。我们建议采用磁盘阵列来解决由双任务服务器所引起的磁盘连接问题，避免在欧洲办公室的工作时间安排关机，培训那些问题多的用户。客户非常感激我们，并安排了六个月的试用来验证这样做的效果。

我们满怀期望，希望可靠性的问题解决了。从技术角度说，确实如此。可是用户的IT部门的人员却不太情愿采用我们的建议方案。设备正常运行的时间显示我们的方法还是达到了预期的效果。服务器不再按照一定的周期出故障。通往欧洲的连接始终状态良好。帐号故障率下降了80%

不幸的是，用户仍然周期性地抱怨网络稳定性。从技术角度稳定性的提高并没有转换成用户满意度的提高，为什么？

测量可靠性：我们在测量什么？
IT人员还在自鸣得意的时候，我们就开始尝试去找出这个问题的答案。一位工程师被指派负责这一工作，他是我最初几年工作的导师，他发现了一些不同寻常的事。我们打了很多电话，有时候还装扮成潜在用户来观察系统是如何跟踪数据流的。

经过两个星期的工作，我们有如下发现：

用户觉得只有他们不能完成工作时，他们的问题才受到重视。因此，当他们希望能够立刻得到重视，他们就会宣称当时遇到的问题妨碍他们完成工作。所有被标志着“妨碍工作”的问题都会被当作是可靠性的问题。

IT小组的成员则认为任何没有造成系统重启的错误都不能够算做一个失败，因为他们的奖金是按照是否能够建设一个零故障的环境来计算的。一台不需要重启以重新提供服务的服务器永远“没有故障”，虽然它不能为客户提供服务。

用户通常分不清楚什么是网络故障，服务器故障，服务故障或者是安全防范措施。他们把任何问题都看作是系统故障。这就让终端用户不能够很好地进行系统稳定性跟踪，尽管高级管理层们可能相信他们能够担负这一任务。

执行者认为经过这些基础分析，我们完成了我们的工作。可是我的导师不这样认为。他准备了一份报告，上面论述了该公司因为测试如下三种完全不同的事情，并试图把它们放在一起对照比较，所以自己造成了无穷无尽的问题：

用户感觉可靠性，这包括服务访问能力、培训、可用性、企业文化、不同项目产生的行政辐射，本地和集中支持产生的人的冲突。

对于设备正常运行时间的技术考核没有考虑到它的可用性。考核系统正常运行时间是很好的第一步，但并不是考核可靠性的首要而全部的指标。

管理信息系统认为所有的报告者都对于基本信息有同等的了解。这就造成了模糊的数据。这些数据会引导管理人员做出错误的决定，比如采用技术的方案来解决流程或沟通的问题。

为了解决这些问题，避免重复的电话，我们的小组建议IT人员和管理人员在他们最初的数据分析上采取更多积极的行动。为了摆脱对通用报告的依赖，我们设计了四种基本的调查工具，这样客户就可以对用户进行调查，对遇见的问题按照实际种类进行分类。