企业网D1Net 1月2日讯

变更管理是一条复杂的道路，路途中到处坑坑洼洼。学习一些方法和指南有助于帮助您更好地管理数据中心。

虽然系统或网络管理的工作往往就是要维持现状,但是变革管理也是你的工作。为了保证有效地交付服务和资源，必须在老系统过渡到新系统时，应尽可能地保持数据中心正常运行。

变革管理(也称为配置管理)并不总是安全的或容易的。换句话说,在IT方面，如果我们只是一味地追求安全,那么我们现在可能仍然运行着Windows NT 4 SP 6a。新系统和新技术似乎总是更快、更有活力。曾有一些系统在建成后的第二年,为了安装更好的系统而被拆除。从财政角度，我对这其中可能产生的浪费惊骇不已,而在技术层面，部署新事物让我着实高兴。

多年以来,我学会了一些变革管理的方法想与大家分享。一些来自于直接的经验,另外一些来自于他人的知道，而更多的来自于在现实中对朋友或同事公司的糟糕环境的观察。

我所提到的变更管理,是指技术安装、升级、修复及迁移(比如从物理服务器迁移到虚拟机)。请注意,在信息技术基础设施库(ITIL)中有正规的变更管理过程的相关内容，也有如Evolven和McCabe CM等专门的软件包来帮助完成变更管理。而这里则将带来一些得到成功实践的非官方技巧。

冗余永远不嫌少

大多数的IT专业人员并不需要热衷于增加冗余(各种的挑战在于说服财务部门),但是任何一个关键任务都需要有双备份系统。这点适用于服务器、网络硬件,甚至是存储。如果您想正常运行您的业务,请确保有双备份的系统。如果你没有双备份系统,那么你得知道，当主系统不可用时如何能拼凑出替换系统。例如,几年前我设立了一个Windows文件服务器用来在SAN共享数据。我们没有正式集群或网络负载均衡解决方案方面的预算,因此我开发了一个备份服务器故障转移计划:

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

2、我每天晚上从主服务器注册表中导出文件共享配置，并保存在C盘中:以此驱动备份服务器。

3、我每5分钟记录一次主服务器的域名服务器。

4、我在备份服务器注册表禁用严格的名字登陆检查,因此客户可以通过任何我希望的DNS名与其连接(默认Windows服务器操作系统可以防止这一点)。

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

这意味着通过相关DNS记录的更新，备份服务器可以很容易地“成为”主服务器，并且用户可以很快地重新转入（很多用户甚至不会注意到这个中断）。这包括驱动器映射和文件共享访问。完备的记录意味着我同事当中的任何一个都可以遵循以上的步骤。

对于冗余部件,应千方百计地使它们保持一致性——它们应该是相同的制造商/模型,运行相同的操作系统,有相同的驱动和热补丁,以不同的交换机或PDU插入相同的端口等等。

还有一个关于冗余的关键提示…

冗余系统之间应分别进行变更

当应用变更时，冗余系统会为你提供巨大的杠杆作用，你可以让冗余系统中的一半先停止工作来进行转移或升级，然后再对另一半系统进行同样的操作。然而,一定要在两次变更之间留一段的间隔时间来确保第一次的系统变更是成功的。例如,当修补服务器时,一定要腾出几天时间来发现和纠正问题，之后在对第二套系统进行修补，这段期间你将需要依靠功能仍然正常的系统。

使用集中解决方案来部署更新

对于质量变更管理，你应该始终选择复杂度最低的方式,这意味着一个能安装补丁、软件、杀毒软件更新和配置设定的集中内部系统。这将使得你能更好地追踪系统，为变更做准备并报告结果。例如微软的Windows服务器更新服务、微软系统中心配置管理器、微软群组策略(Active Directory的一部分)、赛门铁克端点保护管理器和戴尔管理控制台等，这些产品将给你一个参考,并确保你的客户端和服务器不会只是没有选择地从网上下载更新(或者更糟的是,更新失败且没有通知你)。

绝不要使用系统粉碎机

没有什么比完全摧毁现有系统，以求让一个新系统来代替它来得恐怖。无论是文件服务器、邮件服务器、存储设备，还是别的东西,在迁移到新系统时，你都应该完整地保留旧系统,直到更新全部完成。直到旧系统过时了，你才可以使其退役。

例如,如果要使Windows 2008文件服务器更新到Windows 2012系统，需要将所有数据(与权限)从旧系统拷贝到新系统，并安排用户来测试访问。在更新系统的时候,我发现了新服务器网络驱动程序的一些问题,这迫使我将用户迁移回旧系统。我并不介意这一步,我为还可以使用旧系统而感到庆幸。

采用多点输入的方式来设计变更计划

跟冗余越多越好一样,变更计划的步骤也要越多越好,就像一个好的聚会,参与者越多，效果才越好。

尽可能多得的利用其他的输入信息来识别一切隐藏的陷阱。你的初步计划尽可能的周密,这样不需要其他步骤为你填补空白。比如，你在思科交换机上升级固件,然后就可以直接重新启动吗?你如何能确保升级成功了呢?好吧，你可以发送信息,如果收到回复的话就断定升级完成，但是我认为那只是表面。你应该登录、检查错误日志，并测试所有功能。登录后,确保它没有因内存泄漏而锁定。多次对其进行重新启动。从另一个子网络连接它。也许除了这些检查之外，还有人会建议测试一些运行在与交换机相连的服务器上的核心应用程序。所有的这些都是你应该一步步检查的,最理想的是你在测试系统上提出这个清单,尽管测试环境中的结果在实际生产中并不能保证总是一致的。

不要以为你会做的事就一定会成功，一定必须亲自注册并尝试过。我见过很多的问题,以管理员权限可以执行很好的功能，但普通用户权限却不能按期工作,至少需要调整之后才行。

最后一点:在不同的系统上多次执行你的检查列表会是冗长无味的，然后你可能会忍不住跳过某些步骤或者偷工减料,你会想:“对呀,已经检查过两次了为什么还要如此的繁琐呢？”墨菲定律告诉我们，要抵制这样的邪念。

多重验收

如果能从别人那得到应该在完善什么的反馈那就再好不过了。聪明的公司懂得分散风险:制定计划应获得员工或其他相应当事人的批准。这也许包括你的老板、相关部门主任，或者是客户基础副总裁。审批过程应确保所有人都知道和同意,并支持拟议的变更。让我们面对现实:如果我知道我将负责一个失败了将影响企业盈亏的计划,我会努力确保过程是合理的。

这样的安全措施不仅可以在出现差错时保护你，而且将让人们了解该事故,并能帮助团队共同努力来找到解决方案。

制定撤销计划

每一个变更都应该有相应的撤销方案。如果失败了，你打算怎样把事物归回原位?你会在虚拟环境中使用快照？你会重新导入重要的注册表，或是应用备份组策略使Windows服务器配置回归到之前的状态?你需要制定这个计划,并使其尽可能的明了细致。一次失败的变更或升级可能会大大地损伤你的创造力，在紧张时刻，查找可行的选择会是你想做的最后一件事。撤销方案很可能是一个你不曾用到的保险单,但能为我们带来平和的心态。

如果你确实需要撤销变更,确保你尽可能多地记笔记、截图或保留其他的证据,以便下一次你可以找出错误并进行纠正。摆脱不愉快的开端的秘诀便是“第二次尝试并希望它成功”。

仔细选择你的变更计划

毫无疑问,数据中心的大多数变更都应该在下班后或非关键时期。如果你的备用服务器在周一上午10点罢工的话，即使是升级冗余系统也可能会构成风险。无论如何,要仔细地计划你的时间表。

你可以在周日晚上11点执行数据库转换。但如果某些原因造成延迟，而且7个小时过后当用户到达办公室时，转换仍在进行，那该怎么办呢?

也许选择在周五下午5点会是一个更好的主意。呃,好吧,只是要注意你不要沉醉于家庭生活,直到周一早上上班，才想起来检查升级结果。

也许你有备用站点可以用于灾难恢复(DR)，并且你已经让它成为主站点来测试故障转移功能。在你计划反转的12小时前，不要急于升级原来的主站点系统。

正如我上面所说的,你的计划应该是使用、支持和管理这些系统的利益相关者和团体的产物。

使用审计和个人账户

如果可能的话，在您的环境中总是使用审计账户(即使你不得不在变更项目期间暂时的打开，之后为了保护资源又将其关闭)。这将有助于追踪系统命令及产生的效果。

类似的,如果你可以避免的话，不要使用如“管理员”这类的共享或通用账户。这些命令应该与个人账户相连(最好是只用来执行这类工作的特定账户,尽可能使用有限制的帐户)。在动态目录环境中，这并不是那么容易,许多时候都需要使用“管理员”帐户。无论如何,要尽可能地遵循这一原则。

这令人联想起 “如果屋里有东西坏了,你只有一个孩子,你当然知道是谁干的!”然而,这不是指责,而是记录发生了什么,由哪个账户产生的。如果需要撤销变更或是确认问题所在，你将需要这些信息。

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

假设您设立了一个健全的监控环境来检查关键系统的健康和正常运行时间,并在出现任何问题时通知你。当你打算使这些系统脱机来进行变革管理时，你应该在你的监控系统中事先安排合理的停机时间，因此它才会保持沉默。采取这一步是挺痛苦的,尤其是对于多重系统来说,但是忽视重要警示的做法实在是太危险了，以至于必须先不去追踪它。

因为当你处于升级中时，你无法确切地知道发生了什么，除了手头的紧迫任务,你可能会发现自己被环境愚弄了。例如,你收到一个告知你思科邮件网关反应迟钝的信息,你可能会想:“是的,我知道它反应迟钝，因为我在升级它!”如果你之后发现该信息是由其他工作良好的邮件网关产生的，而它停机了三十分钟，该怎么办呢?

总结

IT人员常常承受着大量(外部或内部)的压力，完成一个任务之后又急着开始下一个任务,这样他们才可以继续体现对组织的价值。然而,这种压力与IT本身的概念正相反:以最少的停机时间和中断来运行设备。

许多优秀的数据中心变更管理技术可以归结为常识、保守和谨慎行事。希望这些方法将有助于你的环境变革变得可预测和可控制,从而你可以接受一切可能性而无所畏惧。

(作者Scott Matteson是一位高级系统管理员，同时也为中小企业提供咨询服务)