适当时间的计划停机其实可以让你免遭损失。除非你绝对少不了，否则别信需要7*24、随时可用的服务这套论调。

　　问一下自己：当你宣布（或请求）停机窗口，以便完成升级或进行维护时，你那些用户会有啥反应？我想情况恐怕不妙。

　　多年前，在除了超大型IT部门外的所有环境，计划停机还是一件很平常的事；而如今，很少有企业轻易让你申请到很长的停机窗口。哪怕在凌晨时分这样的时间段，连明显不需要7*24服务的一些部门（比如三班倒的制造工厂或者设有急诊室的医院）都很难拒绝自己的用户访问数据。

　　其中的原因有多方面，但是说穿了还是日常业务过于依赖IT系统——而服务器虚拟化技术的出现，在很大程度上大大改进了规避灾难的能力。公司企业对数据入了迷、上了瘾；而技术取得了长足进展，以至于我们IT人士轻易就能满足他们这个“瘾”。

　　遗憾的是，这种情况带来了双重影响：它造就了一种氛围，即连针对计划停机再小的请求都常常被拒绝或被推迟；当灾难发生时，用户们毫无准备、束手无策。

　　停机的三个好处

　　首先，停机对于确保系统的稳健性和可靠性大有帮助。如果你得等上数周、乃至数月才能为基础架构打上重要补丁，这无异于自招麻烦。虽然现代化IT基础架构中的系统大多基本上不用停机就可以打上补丁，但是对于另一些系统而言，要打上最新版本，你就得关掉电源，因而给至少几个用户带来不便。

　　就拿你那些普通的交换机和路由器来说吧。它们常常一放就是好多年，顺畅无阻地运行。实际上，我在上一周碰到的一只桌面级汇聚交换机其正常运行时间超过了2000天。这足以那家厂商的产品确实很可靠，但是我可以打赌：这个设备的固件里面存在很大的安全漏洞——大得好几辆小车都能通过，很容易被人钻空子。

　　其次，如果能充分利用计划停机窗口，你就能检验高可用性功能、演练灾难恢复计划。要是你很少检验自己的高可用性或灾难恢复功能，那么当你真正需要这些功能时，它们失灵的可能性就要大得多。我在去年写过一篇博文，当时有位读者的留言可谓是一针见血：“任何功能要是每天使用不到一次，那么每当你使用它时，别指望它每次都行。你使用它的次数越少，当你实际使用时，它失灵的可能性就越大。”凭本人的经验，这句话再对不过了。

　　你知道自己的高可用性系统应该如何工作，但是你确信它们会正常工作吗？你有没有使用冗余交换机的光纤通道存储区域网（SAN）？有没有使用冗余的核心网络交换机或数据库集群？你是否让我可以不用提醒广大用户，就在工作时间段关闭其中一个系统呢？

　　如果你反对，这表明你根本就不够确信。只有在计划停机窗口期间有意关掉基础架构的冗余部分，你才能够确信自己的高可用性系统会按原本的方式正常工作。要不然，你就会搞清楚：要是自己有时间或预算，应该把精力主要投入在哪个环节，以求改进。

　　最后但可能也是最重要的一点是，计划停机让广大用户多多少少体会了万一真的发生灾难，会出现什么样的情况。在我亲眼目睹的几起非常严重的基础架构停运事件中，最糟糕的情况莫过于用户们一片茫然、不知所措。是的，关键业务系统的停运会影响生产力，这是完全可以料到的；但你会惊讶地发现，只要采取异常简单的措施，其实原本可以避免许多最严重的影响。要是你不偶尔关闭系统，看看会发生什么情况，也许永远也不知道那些措施。

　　据理力争

　　虽然给广大用户带来不必要的麻烦看起来像是没事找事，但是如果有充足的理由，关掉基础架构的一部分还是能给企业带来实实在在的好处。严酷的现实是，对计划停机请求坚决说不的企业终究会发现自己遭到非计划停机，由于灾难恢复机制未经考验，结果蒙受的损失要大得多，而广大用户对无法访问数据的日子又毫无准备。尽管据理力争让人不悦，但是下一次你的停机请求遭到反对时，你还是要竭力搬出这个理由。这么做也许不招人待见，但是总比不这么做要强得多。