数据中心的变更管理可以说是一条各处都散布着坑洼不平的复杂道路。而希望通过对本文中所介绍的一些经验技巧的学习和借鉴，能够适用于您所在的企业组织。

　　在数据中心的系统或网络管理工作中，最为讽刺的是，管理员们要努力的维持现状(或者用我通常所用的口头禅，“在混乱的世界保持秩序”)，但其实，谨慎的实施变更管理也是管理员们的工作。无论是更换技术还是仅仅实施技术的改进，在您企业从旧到新的过渡期间，仍然需要有效的提供服务，并满足业务部门对于各种IT资源的需要，尽可能的保持最佳的正常运行时间。

　　变更管理(也称为配置管理)并不总是安全或容易的。另一方面，如果我们只确保执行安全的IT，那么我们可能至今仍然还运行着Windows NT 4 SP6a。现如今，新的系统和技术频繁的推陈出新，甚至使得旧系统和技术的更新淘汰速率更为激烈。我们已经看到，不少系统才刚刚部署实施了一年，然后就需要被淘汰以便为下一步部署实施更好的东西铺平道路了。有时，对于在企业财务管理方面一向保守的我看来，对这种可能的浪费往往感到震惊;但如若从我自身的技术专家这一角度出发，看到这些新事物在当前的企业组织的广泛部署又感到欢欣鼓舞。

　　多年来，我逐渐总结出了一些关于数据中心实施变更管理的最佳实践方案方面的指南，希望在本文中能够与大家一起分享。其中一些来自我自身的直接经验，另一些来自我的导师，还有一些来自对于企业朋友或同事们在应对最坏情况时的行动方案的观察。

　　当我提到变更管理时，我所指的是技术的安装、升级、打补丁和迁移(例如物理服务器迁移到虚拟机)。注意，有诸如与信息技术基础设施库(ITIL)相关的正式的变更管理过程。还有专门的软件包，如Evolven和McCabe CM，可以帮助完成这些工作。虽然本文中的某些材料可能与其它一些文章有重叠，但我撰写本文的目的是旨在以一种更轻松随意的评论方式，来介绍我所观察到的成功的企业在这方面的良好的实践方案。

　　企业永远不能有太多的冗余

　　大多数IT专业人士并不热衷于这方面(这方面的挑战可能在于企业的财务部门)，但企业的任何关键任务都需要一定的冗余。这适用于服务器、网络硬件、甚至存储。如果您企业需要其来运行您的业务，确保一切都有一定的冗余。如果您企业不能做到这一点，而如果主要的系统又不可用的话，就看看您企业是否可以拼凑出一个替换系统。例如，几年前，我设置了一个Windows文件服务器，所有共享数据都托管在SAN卷上。我们没有官方群集或负载平衡解决方案方面的预算，因此我借助一台备份服务器开发了一个故障转移计划：

　　我分析和测试了在备份服务器上安装服务器SAN卷的方法。

　　我每晚都从主服务器注册表导出文件共享配置，并将其保存在备份服务器的C盘上。

　　我将主服务器DNS记录一个数据包在网络上传输的最大时间( time-to-live ，TTL)设置为5分钟。

　　我禁用了备份服务器注册表中的严格名称检查，以便客户端可以通过我希望的任何DNS名称(默认情况下，Windows服务器操作系统会阻止这一点)连接到它。

　　我记录了整个故障转移过程。

　　这意味着备份服务器可以非常容易地成为主服务器，仅仅只是通过更新相关的DNS记录，而用户可以在很短的时间内被重定向(许多人甚至不会注意到中断)。这包括驱动器映射和文件共享访问。这方面的文档记录意味着我的任何一位同事都可以遵循该步骤。

　　当涉及到冗余组件时，使它们在每一种可能的方式条件下都是完全相同的，以支持他们的可预测性——他们应该是来自相同的制造商/型号，运行相同的操作系统，具有相同的驱动程序和修补程序，在不同的交换机或PDU插入相同的端口，等等。

　　涉及冗余方面，还有另一个关键性的提示…

　　冗余系统间的空间变化

　　当涉及到更改的应用时，您的冗余将为您企业带来巨大的杠杆作用，因为您可以将一半的冗余对向下迁移或升级，然后将另一半的冗余对执行相同的操作。但是，请永远不要在两者之间没有留出时间间隙，以确保第一次更改是成功的情况下这样做。例如，当修补服务器时，不要为第二组系统打补丁，直到几天过去之后能够给您足够的时间来发现和纠正任何问题，在此期间您将需要依赖于仍然运行的系统。

　　使用集中式的解决方案以部署更新

　　对于质量变更管理而言，您企业应始终选择复杂性最小的，这意味着采用集中式的内部部署系统，以推进补丁、软件、防病毒的更新和配置设置。这将使您企业有最好的机会跟踪您的系统，规划您的更改，以及报告结果。这方面的示例包括微软的Windows Server更新服务、微软的系统中心配置管理器，微软组策略(Active Directory的一部分)、赛门铁克端点保护管理器和戴尔管理控制台。这些产品将给您一个单一的参考点，并确保您的客户端和服务器不只是从互联网下载更新(或更糟糕的是，未能这样做而且也不通知您)。
　　
　　我想，没有比撕裂企业现有的某款系统，并用一款新的系统来替代该系统更为恐怖的事情了。无论是文件服务器、电子邮件服务器、存储设备还是其他设备，都应该始终迁移到新的系统，保留传统遗留的旧系统，直到您完成了整个更改。不要停止任何系统的运行，直到其完全过时。

　　例如，如果要将Windows 2008文件服务器更新为Windows 2012系统，则需要将所有数据(具有权限!)从旧框复制到新框，并让用户测试访问权限。有一次，在这一过程中，我在新的服务器上发现了一些网络驱动程序的问题，迫使我把用户切换回旧系统。我不介意这一步，因为我很庆幸有旧系统仍然是可用的!

　　制定具有多重输入的变更计划

　　就像您企业永远不会有足够的冗余一样，您企业的变更计划永远不会有足够的步骤。

　　尽可能多的从别人那里获得信息，以助于您企业可以发现任何隐藏潜在的陷阱。但是，我请务必使您的初始计划尽可能的全面，这样其他人不必为您来填补空白。这样，当您正在升级您企业的思科交换机的固件时，然后就对其执行重新启动吗?您如何确保该升级是成功的呢?好吧，您可以执行Ping命令，然后如果其回复了，您就可以宣布升级完成……但我认为这只是表面的问题。您将需要登录，查看错误日志，并测试所有的功能。稍后登录，并确保其没有由于内存泄漏而锁定。重启，再次重启。从另一个子网连接到它。也许在审查过程中，会有别的人建议在服务器上运行的一些核心应用程序来测试，通过该交换机连接，从而避免“Gotcha!”时刻。所有这些都应该是在您的分步检查清单上的内容的示例——而在理想的情况下，您会通过测试系统来获得这个清单，尽管会出现警告：您的测试环境中的结果并不总是保证能够在生产过程中复制。

　　不要假设因为您可以执行某件事情，那么其就必须奏效。让别的同事登录并尝试，以进一步确认。我曾看到过很多类似的问题：具备管理员权限的人可以完美执行一项功能，但只有普通用户权限的员工就无法按预期工作，至少直到被调整之前无法执行。

　　最后一点：在不同的系统上多次检查您的清单将是一个乏味和沉闷的过程，您可能会试图跳过某种的某些步骤或偷工减料，“是啊，前两次已经奏效了，为什么还要自找麻烦呢?” 但请务必要抵制墨菲定律。

　　利用多层审批的方法

　　如果您能从他人那里获得关于应该将哪些内容添加到您的变更计划中的反馈，将是极好的。然而，明智的企业组织会制定一个批准方法计划，从其它部门或其他适当的当事方获得批准鼓励。这可能包括您企业的高层老板，相关部门的主管或您的客户群的副总裁。此审批流程将确保每个人都确切的清楚了解，同意并支持所提议的更改。让各个当事方共同面对：如果我知道会把我的名字列入到一个计划的执行中，这可能会影响我所在企业的盈利，故而我需要确保该计划的执行过程是健全的。

　　如果该变更计划出现任何问题，这一多层审批的安全方法不仅覆盖了您，同时还会在出现失败的情况下通报各当事方，进而可以帮助一起找到解决方案。

　　制定还原方案

　　每一项变更都应该有一套与之相关的还原计划。一旦变更发生失败，您将要如何让所有的东西还原回他们原本的状态?例如在虚拟环境中，您是否会使用快照?您是否会重新导入关键注册表项或使用备份组策略以便返回Windows服务器配置到其以前的状态? 您需要为这一计划制定文档，使其尽可能的具备可行性。在更改/升级出现失败期间，您的创造力可能会削弱，而在这样的紧张时刻，研究选项可能会是您想做的最后一件事。您企业的备份计划，很可能是一个保险策略，您可能不会用到，但提前准备一份，有助于您企业的变更计划得以安心的执行。

　　如果您必须还原某项更改，请确保您执行尽可能多的记录，包括截图或其他支持证据，以便您可以找出哪里出了什么问题，并在下次纠正。 “执行第二次尝试，希望其能够有效”的策略显然是不令人愉快的。

　　请仔细选择您的变更计划

　　毫无疑问，数据中心中的大多数(如果不是全部的话)变更计划应安排在非关键时段期间或之后。如果决定对您企业数据中心的辅助服务器在星期一上午10点开始执行变更，那么即使升级冗余系统也会造成风险。故而，请务必仔细规划您的变更时间表。

　　您企业应该在星期日晚上11点执行数据库切换。但是如果某些事情导致延迟，如果用户在七个小时后会到达办公室，切换仍然在运行该怎么办呢?

　　也许在星期五下午5点开始执行变更是一个更好的主意。只要小心您不会在周末被家庭生活琐事搞得忘了检查升级结果，直到您星期一早上上班才突然想起。

　　也许您企业会有一个用于灾难恢复(DR)的辅助站点，并且已将其作为主站点来测试故障转移功能?那么，在计划反转过程的12个小时之前，不要急于在原始主站点中升级系统。

　　正如我上面所说，您的变更计划安排应该是涉及到支持和管理这些系统产品(如适用)的各个利益相关方和团体。

　　在可能的情况下，始终在您的企业环境中使用审核(即使您必须在更改项目期间将其临时打开，然后关闭，以保留资源)。这将有助于跟踪在这些系统上运行的命令以及由此产生的影响。

　　类似的注意事项包括，如果可能的话，尽量避免使用共享或通用帐户，如“管理员”帐户;这些命令应链接到个人帐户(最好是仅用于执行此类工作的特权帐户;通常在可能的情况下使用有限权限的帐户)。诚然，这在Active Directory环境中并不总是那么容易，在许多情况下，即使有类似权限的用户(似乎)被授予一个名为“个人”的帐户，仍有许多任务仍然顽固地要求使用域“管理员”帐户。但是，尽可能奉行这项政策。

　　如果某项变更需要回滚(rolled back)或识别找到了问题，您就需要哪个账户曾执行过何种任务的具体信息。

　　始终在监控系统中安排停机时间

　　假设您企业有一套全面的环境监测设置，以检查关键系统的正常运行状况，并在出现任何问题时通知您。 当您打算让任何这些系统离线，以执行变更管理时，您应该对您企业的监控系统安排合理的停工期，其会保持静默(不再发送警报通知)。采取这一步骤可能会是相当痛苦的，特别是对于多系统而言，但忽略关键警报的策略太危险而不能追求执行。

　　如果您正在升级的过程中，除了手头的正在执行的工作，您不会真正知道发生了什么，您可能会发现自己被环境愚弄了。 举例来说，如果您收到一个页面，告诉您您的思科IronPort没有响应，您可能会想：“是的，我知道这会没有响应，因为我升级了!”但如果您以后发现页面指的是其他理应处于良好的工作状态的IronPort，但却已经停止响应三十分钟了呢?

　　把所有的整合在一起

　　企业数据中心的IT人员们通常面临过度的压力(外部或内部)：他们往往是匆忙完成了一个任务，又立马赶到下一个任务，以便他们可以继续向企业组织展示自身的价值。 然而，这种压力与IT本身的概念是对立的：保持以最小的停机时间和中断运行。

　　许多好的变革管理方法归结为常识、保守和安全。希望这些指南将有助于使您企业数据中心的环境的变化尽可能有预见性和可控性，所以您可以积极的应对各种的可能性，而不是害怕他们。