黄旭东 张盛男

医院发生了一次杀毒软件无法更新病毒库的故障，医院的运维人员和杀毒软件厂商的技术人员对故障原因进行排查，原因是控制台的数据库文件写满所致。针对这次事件，技术人员结合故障现象和控制台日志对故障过程进行了复盘，并对故障原因追根溯源，在此基础上对运维工作提出了改进措施。

杀毒软件环境简介

某医院部署了一套杀毒软件，已使用10年左右。杀毒软件是C/S结构，即一个服务端（通常称为杀毒软件的控制台，简称控制台）以及安装在PC机和服务器上的杀毒软件客户端（简称客户端）。

病毒库更新的流程，是控制台每周一次自动从杀毒软件的官方网站下载病毒库，客户端每天从控制台更新病毒库。

医院的运维人员每周做2次巡检，内容包括控制台更新病毒库是否成功、客户端更新病毒库成功的比例是否正常等。杀毒软件厂商的技术支持人员每季度到医院做一次深度巡检，内容包括控制台运行状态是否正常、控制台是否有隐患等。

事件经过

1.发现疑点

201X年9月中旬，医院的运维人员某甲进行例行巡检，抽检了50个服务器，其中一项巡检内容是杀毒软件的病毒库是否更新到最新。抽检结果是7个客户端病毒库日期已超过2周，没有更新到本周的日期，即过期比例是14 %，这个比例大大超出了经验值，服务器处于7×24 h开机状态，客户端病毒库都能及时更新，偶尔因为特殊情况才会不成功，过期的比例通常在4 %以内。这个异常的比例引起了某甲的注意，初步判定为杀毒软件更新病毒库异常，立即向领导上报，领导批示继续关注、持续跟踪。

2.初步排查

客户端更新病毒库是自动进行的，也可以在客户端界面上点击“更新”手动进行。某甲在上述7个客户端上尝试手动更新病毒库，反复点击“更新”多次后，有2个客户端的病毒库更新到本周，另5个没有变化。

2个客户端能更新，表明控制台是正常的。某甲查看了5个客户端的磁盘空间，可用空间很充足，排除了磁盘空间不足的可能性。某甲在客户端电脑上ping和telnet控制台，ping是通的、telnet也是通的，排除了网络不通的可能性。经过一系列检测后，某甲排除了其他原因，将范围缩小到杀毒软件自身，因缺乏杀毒软件更新病毒库的工作原理资料，无法进一步排除原因。

某甲联系杀毒软件的技术支持人员某乙，详细描述了现象和排查过程。某乙判断是客户端在长期运行后，部分功能模块或配置文件损坏，导致更新病毒库的模块无法正常工作。某乙提供了一些尝试解决的方法：从更新正常的客户端电脑上拷贝通信文件和策略文件，导入更新异常的客户端；在电脑的控制面板中找到杀毒软件，点“修复”，重启操作系统。除了重启系统，某甲尝试了某乙提供的其他方法，5個客户端的病毒库仍然没有变化。生产服务器不能随时重启，需要与业务的使用方协商日期和时间才能重启。某甲联系业务使用方给出的重启时间，最早是在10月底，在重启操作系统之前，无法进一步排查，只能等待、继续观察。

3.陷入僵局

9月最后一周，某甲例行巡检时，重点关注了上述5个服务器，有2个客户端病毒库更新到最新；同时，在本周抽检的50个服务器（与上周没有重合）中，有3个客户端病毒库日期是上周的、没有更新到最新。

控制台统计数据时，判断客户端病毒库是否过期的标准是超过10天没有更新的都算做“已过期”。某甲巡检看到控制台显示病毒库已过期的比例是27 %，超过了20 %的历史经验值，但临近国庆节长假，实习生等已提前休假，此时无法确定是杀毒软件没有更新病毒库，还是一些PC机没有开机。

连续几周，某甲观察到的现象总结起来，是个别客户端病毒库未能更新，手动更新有可能成功，也可能不成功，完全是随机事件，没有任何规律可循，排查原因一时陷入了困境。

10月第一周，情况和上周相似，病毒库过期比例36 %，适逢国庆节放假期间，这个比例属于正常情况。

10月第二周，情况和上周相同，病毒库过期比例43 %，国庆节后第一周，这个比例稍微有点偏高，但是也可以算做正常情况。

4.真相浮现

10月第三周，某甲通过控制台发现2个测试服务器的杀毒软件病毒库是上周的，经联系使用方确认这2个测试服务器当天中午可以重启，此前发现病毒库过期的客户端都是生产服务器，这是首次出现在测试服务器上，于是转机从此开始。中午，某甲在2个测试服务器上进行了完整的测试操作：卸载客户端- >重启操作系统- >安装客户端- >重启操作系统- >手工多次更新病毒库，在这些试验后，病毒库仍然没有更新。

同时，控制台显示的病毒库过期比例是61 %。10月第三周，医院各科室已恢复正常的工作秩序，过期比例这么高，明显不正常，某甲判断问题出在控制台的可能性非常大，但是没有技术资料，无法进一步分析是哪里出了问题。

某甲电话联系杀毒软件的技术支持人员，讲述了本周观察到的现象，技术人员判断客户端病毒库过期不是个例，是普遍现象，需要到现场进行排查。

次日早上，杀毒软件的技术支持人员某丁到某医院现场。经过一上午的排查，从控制台的日志文件里找到一些报错信息，与数据库空间已满有关。打开数据库的设置界面，看到控制台使用的数据库文件AntiVirus.mdf的大小限制为20 000M（20 G），如下图所示，而这个文件此时的大小是20 00M。

某丁与更资深的同事确认之后，确定是数据库文件写满导致客户端更新病毒库失败的概率很大。解决方法是把“最大文件大小”修改为“无限制”。修改设置之后，当天16点查看控制台数据时，病毒库过期比例降低到45 %。

10月最后一周，病毒库过期比例降低到17 %，回落到历史经验数据20 %以内，这个数据表明问题已彻底解决、客户端更新病毒库的功能已恢复正常。

事件分析

1.事件复盘

结合巡检观察到的现象和控制台的日志，技术人员对此次故障的全过程进行了复盘，内容如下。

9月初到9月中，控制台的数据库文件大小接近20 G上限，个别客户端更新病毒库时需要写入数据库的内容较多，超出了可用空间，更新失败。

9月中旬，更新病毒库失败的客户端数量持续增多，巡检时抽测的过期比例是14 %。

9月最后一周，控制台释放了一些数据库文件的空间，所以有些上周不成功的客户端本周更新病毒库成功了；同时，不断有客户端尝试更新病毒库，向数据库中写入数据，使数据库文件大小一直保持在很接近20 G的位置。客户端的现象是哪个客户端能更新成功，完全是随机的、没有规律。

10月第一周，国庆长假，很多电脑没开机，大量客户端病毒库过期，在统计数据中湮没了有异常的客户端。

10月第二周，信息中心没有各科室回归工作的统计表，也就没有电脑开机的数据。虽然控制台显示的过期比例是43 %，但是无法判断客户端病毒库过期是电脑没开机，还是更新病毒库失败。

10月第三周，数据库文件在本周或之前已经写满20 G，控制台能释放非常有限的数据库空间，只有少量幸运的客户端能成功更新病毒库。巡检看到的现象是过期比例已经达到61 %。

11月第一周，修改数据库设置之后，有了充足的数据库文件空间，客户端都能成功更新病毒库。于是过期比例下降到17 %。

2.故障探源

故障原因找到了，处理起来也很快，但是这个风险点为什么一直没有被发现呢？还要溯源查清楚，因此技术人员进行深入分析。

某医院安装部署这个控制台是在10年前，是杀毒软件厂商的技术人员实施的。控制台是傻瓜化的安装程序，双击运行之后填写数据库用户名、密码等参数后，安装过程自动进行。安装程序自动创建了控制台使用的数据库实例、设置实例的参数如文件大小限制等，同时创建表机构、创建控制台访问数据库的用户等。技术人员按照操作手册进行操作，操作手册里面没有更改数据库设置的内容，即使是最新版的手册里也没有。

控制台的功能，设计了一些机制来删除数据库记录，确保数据库文件有充足的空间可以使用。所以按照厂商的设計，20 G的大小是足够的，厂商的巡检列表检查项里没有设计相应的检查项。

某医院的情况是在非常偶然的情况下出现的，在国内的用户中很罕见。

控制台从官网更新病毒库时，写入数据库的内容很小，优先级很高，在数据库文件几乎写满的情况下，控制台仍然能成功更新病毒库。

工作建议

从故障出现苗头，到最终解决，经历了近2个月的时间，我们总结出一些建议，可以更好地指导未来的工作。

1.建议杀毒软件厂商完善巡检细则

该杀毒软件的技术支持人员每季度会给某医院的控制台做巡检，但是多年来一直没有发现这个隐患，原因是巡检列表中没有数据库设置这个检查项。此次事件后，某医院已建议该厂商增加数据库文件使用率等检查项。

2.建议其他厂商完善巡检项

除了杀毒软件，某医院还部署其他公司的软件系统，有一些软件系统和杀毒软件类似，是成品软件，因各种原因提供给医院的技术资料非常少，医院的运维人员能做的巡检和运维工作非常有限，深度巡检非常依赖厂商。医院不清楚厂商的巡检列表中是否有数据库文件使用率、表空间使用率等检查项，因此建议厂商在巡检列表中增加相应的内容，保障系统的稳定性和可用性。

3.不放过工作中的任何疑点

很多故障，一开始都是苗头或征兆的，因为忽略或没有及时排查，随着时间的积累发展成了故障，进而引起业务中断等，因此碰到疑点要彻查。此次故障，某甲在巡检中发现情况异于经验值，每周和杀软厂商的技术支持人员沟通，从疑似有问题到一步一步确认问题，并且通过一系列测试把故障点缩小到控制台，为技术支持人员排查故障和解决问题创造了有利条件。

4.及时获取领导的支持

这次事件中，某甲上报领导后，领导给予某甲充分的时间跟进此事，某甲得以连续数周投入大量时间跟踪现象、进行各种测试。这个故障，能及时发现且比较顺利地解决，离不开领导的大力支持。

5.相信专家，但不迷信专家

专家在大多数时候都是对的，所以要相信专家。但是智者千虑偶有一失，也不能完全迷信专家，不能认为专家每次都是对的。较好的做法是收集更多的信息，给专家提供丰富的资料，协助专家做出正确判断。

6.及时寻求技术支持

在国庆、春节等节假日之前发现的疑点，要本着宁可虚惊一场也不放过一个的精神，及时进行排查，需要厂商协助的，不能怕麻烦别人，也不能担心占用厂商服务时长，一定要请厂商的技术人员来现场排查，避免因节假日而让软件系统长期带病运行，从一个小隐患发展成大问题。