我们为什么要重启服务器

有一个相当经常被提起的问题：服务器是否应当例行重启，比如每周一次，还是应当让它们尽可能长久地运行，以求达到最长的“正常运行时间”。对我而言，答案很简单——除极少数例外情形外，定期重启是对服务器最恰当的选择。

正如任何规则一样，总有一些它并不适用的情形。例如，某些运行关键系统的企业没有任何停机的余量，必须做到 7×24 全天候可用。显然，像这样的系统不能简单地以例行方式重启。然而，如果一个系统关键到永远不能宕机，那么这种情况就应当敲响一记警钟：这个系统是一个故障点，或许应当着手考虑如何应对停机，无论是计划内还是计划外的停机。

另一个例外是，某些 AIX 系统需要相当长的正常运行时间，超过几周，才能获得最高的效率，因为该系统会自我调优，需要时间来获取使用信息并据此进行自我调整。这种情况往往仅限于大型、极少变动的数据库服务器以及类似的使用场景，它们不如其他平台那么常见。

在 IT 领域，我们常常崇拜“正常运行时间”这一概念——即一个系统在无需重启的情况下能够运行多久。但“正常运行时间”并不是一个能为业务带来价值的概念，IT 需要时刻把业务的需求放在心上，而不是聚焦于人为的指标。业务并不关心一台服务器在不重启的情况下设法保持在线了多久——他们只关心服务器在业务处理需要时是否可用、是否就绪。这是两个非常不同的概念。

对于几乎任何一台普通的业务服务器而言，都存在一个服务器需要为业务目的而可用的时段，以及一个并不需要它的时段。这些时段可能是每日的、每周的或每月的，但一台真正全天候、无一例外地处于使用中的服务器实属罕见。

我常常听到有人声称，因为他们运行的是操作系统 X 而非 Y，所以他们不再需要重启，但这根本不是事实。定期重启有两个主要原因：验证服务器成功重启的能力，以及应用那些不重启便无法应用的补丁。

应用补丁是大多数企业进行重启的原因。几乎所有操作系统都会收到需要重启才能生效的定期更新。由于大多数补丁是出于安全和稳定性目的而发布的，尤其是那些需要重启的补丁，应用它们的重要性相当高。仅仅为了维持正常运行时间，而让一台服务器承受本不必要的脆弱性，并不明智。

测试一台服务器成功重启的能力，则是常常被忽视的方面。大多数服务器都会被定期施加变更。变更可能是补丁、新应用程序、配置更改、更新或类似的东西。任何变更都会引入风险。一台服务器在变更刚应用完毕后是健康的，并不意味着这台服务器以及在其上运行的应用程序在重启时会如预期那样启动。

如果这台服务器从不重启，那么我们就永远不知道它能否成功重启。随着时间推移，自上次重启以来所应用的变更数量将不断增加。这非常危险。我们所惧怕的，是已经做出了大量变更，其中可能有许多未经记录，而随后一次重启失败了。到那时，要查明是哪一项变更导致系统失败，可能会是一个难以逾越的过程。没有单独一项变更可供回滚，没有已知的可恢复路径。这就是恐慌降临之时。当然，一台从不被有意重启的机器更有可能在无意中重启——这意味着重启失败这件事，既更有可能发生，也更有可能在它正处于活跃使用之中时发生。

虽然定期重启的本意并不是为了降低重启失败的频率——事实上它们实际上还会增加失败的发生——但其目的在于：从“已知变更”的角度让那些失败变得易于管控，并且更重要的是，掌控这些重启发生的时机，确保它们发生在服务器被指定为可供维护、并被设计为可承受压力的时段，从而使问题在能够在不影响业务的情况下加以缓解的时机被发现。

我听过许多系统管理员声称，他们避免在周末重启，因为他们不想因为服务器在重启后起不来而被困在周日加班。我自己也曾在许多个周日早晨因一次重启失败而被呼叫，但每一次接到那通电话，我都感到一种宽慰。我知道，我们刚刚在一个业务不会蒙受财务影响的时机抓住了一个问题。倘若那台服务器没有在非工作时段被重启过，它“无法启动”这件事或许直到在活跃的营业时段发生故障、并造成收入损失时，才会被发现。

多亏了定期的周末重启，我们能够安全地抓住正在酝酿的灾难；而且，多亏了知道我们只有一周的变更需要排查，我们通常能够以相当少的精力例行地修复这些问题，并且对故障发生之前所做出的变更有着很大的把握。

定期重启，关乎保护业务免受那些本可通过非常简单而可靠的流程加以缓解的中断和停机之苦。