服务器前线手记 10:重启后用户打不开软件?被忽视的服务依赖

前两篇文章，我们处理的是单用户故障。

某一位医生的软件崩溃、设置丢失。

排错思路是不断缩小嫌疑圈，从“服务器有问题”缩到“这个人的配置文件有问题”。

今天，我们要面对的是一类完全相反的故障。

它不挑人，不挑账户，全员中招。

而且它有一个非常规律的触发条件：服务器重启。

周一早晨，医生们陆续登录，双击手术计划软件。

启动画面出来了，进度条转了两圈，停了。弹出一个对话框：

你远程登录服务器，检查了一圈：网络通，远程桌面服务运行正常，五位医生都能正常登录，服务器也没死机。只是软件打不开。

问题出在一个你巡检时可能从来没有注意过的地方：后台服务，特别是它的启动类型。

今天这篇文章，就解决这一个问题。

读完你会发现，根治它的操作，只需要改一个下拉菜单。

但如果你不知道这个下拉菜单的存在，它会反复发作，每一次服务器重启，都是一次全科停摆。

一、手术计划软件不是一个人在战斗

我们平时双击桌面上的软件图标，看到的是一个窗口弹出来。

这让我们很容易产生一个错觉：软件就是那一个窗口，关了窗口软件就没了。

但手术计划软件，以及绝大多数需要在服务器上为多用户提供服务的企业级软件，通常由两部分组成：

医生双击桌面图标，启动的是用户界面程序。

用户界面程序在启动时，做的第一件事是尝试连接后台服务。

后台服务才是真正负责存取数据、执行计算的那个角色。

如果后台服务没有运行，用户界面就卡在启动画面，然后弹出“无法连接”的错误。

这个后台服务，就出现在我们第1天学过的服务控制台里。

只不过当时我们只检查了 Remote Desktop Services 一个服务。

今天，我们要找到并保护手术计划软件自己的服务。

二、怎么找到手术计划软件依赖的服务？

如果你不知道手术计划软件的后台服务叫什么名字，没关系。

这里有三种方法，从最简单到最可靠。

方法一：打电话摇人。

打开手机，找到手术计划软件厂商的技术支持电话或微信。

发一条消息：“我们用的是服务器版，后台数据库服务的Windows服务名称是什么？”

有经验的厂商支持人员十秒内就能告诉你。

方法二：观察。

在医生正常使用软件的时候，你以管理员登录服务器，打开任务管理器，切换到“服务”标签。注意，不是“进程”。

在这个列表里，按“描述”列排序，寻找带有手术计划软件名称或数据库名称的服务。比如你看到这样一个条目：

这些就是你要找的目标。

方法三：追查可执行文件路径。

在服务列表里，右键一个可疑的服务，属性。

在“常规”标签里，有一行“可执行文件的路径”。

如果这个路径指向手术计划软件的安装目录，比如

C:\Program Files\SurgPlan\bin\SurgPlanDB.exe

那就确认了它的身份。

下面这张图，帮你建立服务属性窗口的心理地图：

三、启动类型：一个下拉菜单，决定生死的设置

打开某个服务的属性窗口，“启动类型”的下拉菜单里，有四个选项。

它们之间的区别，直接决定了服务器重启后这个服务能不能自己站起来。

现在，你应该能推理出周一早晨故障的完整链条了：

手术计划软件的后台数据库服务，启动类型被设成了“手动”。
周五下班前，服务器一切正常。因为数据库服务已经在运行中，医生们能用。
周六凌晨，Windows Update自动安装安全补丁，完成后自动重启服务器。
重启后，所有启动类型为“自动”的服务——比如Remote Desktop Services——自己站起来了。但“手动”的数据库服务，安静地停留在“已停止”状态。
周一早晨，医生登录，双击软件。软件试图连接数据库服务，找不到。报错。

整个链条里，没有任何人犯错。只是那个下拉菜单，从来没有被设对过。

四、根治：改为“自动”，并测试

现在，动手修复。操作本身不需要一分钟：

在服务列表里，找到手术计划软件的后台服务。

右键 → 属性。

在“常规”标签，点击“启动类型”下拉菜单，选择“自动”。

如果服务当前状态是“已停止”，点击“启动”按钮让它现在就跑起来。

点击“确定”，关闭属性窗口。

做完之后，在同一个属性窗口里，还有一个标签值得你花一分钟看一下：依存关系。

五、给服务加上自愈能力

在同一个属性窗口，还有一个“恢复”标签，值得你一并配置。它的作用是：当服务意外崩溃时，系统自动尝试恢复，而不是干等着你来手动启动。

推荐配置如下：

对于手术计划服务器的关键服务，建议第一次失败和第二次失败都选“重新启动服务”。

“后续失败”是否选择“重新启动计算机”，取决于科室的容忍度。

保守做法是前两次重启服务，第三次留给你人工介入，选“不操作”也可以。

这个配置的意义在于：如果服务在半夜因为某种瞬时原因崩溃了，系统会自己拉起来，第二天早上医生们无感知。

你唯一要注意的是，如果服务真的反复崩溃了，它会在事件查看器里留下连续的“错误”记录。

这也就是为什么我们第3篇强调每天巡检要扫一眼事件日志——自动化恢复在救你，但你应该知道它发生过。

六、一个真实模式的完整推演

让我们用今天学的全部内容，走一遍完整的故障-排查-根治流程。

周六凌晨3:00。Windows Update自动安装月度安全补丁。安装完成后，系统自动重启。

重启过程中，所有启动类型为“自动”的服务依次启动：Remote Desktop Services起来了，Windows Time起来了。但手术计划数据库服务 SurgPlanDB 的启动类型是“手动”，系统没有启动它。它安静地停在“已停止”。

周六到周日，没有人登录服务器。一切静悄悄。

周一早晨8:05。李医生第一个到科室，登录服务器，双击手术计划软件。启动画面转了两圈，弹出“无法连接到数据库引擎”。李医生试了两次，一样。打电话给你。

你远程登录服务器。

先用第3篇学的巡检三步快速扫描：

任务管理器→CPU内存磁盘正常；用户标签→只有李医生和你；

服务控制台→Remote Desktop Services运行中。

然后你往下翻服务列表，找到 SurgPlanDB。

状态栏空无一物。你右键点击，选择“启动”。

绿色的进度条一闪，状态变成“正在运行”。

你打电话给李医生：再试试。李医生双击，软件正常启动。问题解决。

但是，这只是临时解决。

你需要永久修复。你右键 SurgPlanDB → 属性 → 启动类型 → 改为“自动”。然后切到“恢复”标签，第一次失败选“重新启动服务”，第二次失败选“重新启动服务”。确定。

然后你在另外两台服务器上，做了完全相同的检查。果然，另外两台也是“手动”。一并改为“自动”。

最后，你在运维日志上记录：

七、你今天必须带走的三个操作

第一，打开服务控制台。

找到所有与你手术计划软件相关的服务。如果不会找，问厂商技术支持一句话。

第二，把这些服务的启动类型全部改为“自动”。

如果有多个服务，问厂商它们的依赖顺序。通常数据库服务应该最先启动，应用服务可以设为“自动（延迟启动）”。

第三，为每个关键服务配置恢复选项。

第一次失败和第二次失败都选“重新启动服务”。

这三个操作，花费时间加起来不超过五分钟。但每做一次，你就永久消灭了一个“周一早晨全科停摆”的隐患。

下一篇我们将学习Windows Server Backup，建立一套能在灾难性故障后把手术数据救回来的备份策略。

我们下篇见。