IT运维（IT Ops）人员在组织中扮演着三个关键性角色。他们可以是建筑师、建设者以及出现问题时为你们挽救大局的英雄。他们设想和帮助规划数字环境，建立这些环境运行的基础设施，并在问题变为危机之前（和之后）解决这些问题。
正如他们在Geico广告中所说的那样，这就是他们所做的。
今天，我想把重点放在IT运维工作的突破性/固性上，特别是预防IT网络危机并在发生危机时应对它们的一些琐碎的事情。基于过去15年处理IT运维变更的经验，个人觉得IT专业人员需要注意以下重要事项，以避免网络危机，或是在危机已经到来时解决危机。
什么发生了变化？—— 很多的（甚至是大部分的）危机是由于环境的变化而产生的。在诊断问题时，了解一下最近发生的其他环境变化也许会对你有所帮助。如果你不能找到很明显的直接原因，请花点时间来询问： 最近发生的可能导致该问题的原因是什么？这在解决远程问题时特别有用，因为你不可能看到发生的所有事情。
例如，如果服务器停止响应，首先要检查服务器，确保服务器没有挂起或宕机，硬盘空间足够并已连接到网络等。如果你无法在服务器本身找到原因，那么是时候扩大搜索范围并查看其他在近期发生的变化了。
在故障期间，网络连接往往会揭露自身问题。检查你的项目管理系统或更改日志，以查看网络上最近发生了哪些变化。可能是由于配置在错误的路由器、交换机或防火墙后面，导致你无法访问服务器。也可能是有人意外地删除了服务器的DNS记录或更改了路由路径。问题可能发生在其他地方，你看到的只是症状，而不是导致问题发生的根源。
有计划地避免附带损害—— 当你在一个地方进行变更时，却在另一个地方发生了意想不到的问题，没有比这更令人沮丧的了。一个附带损害的例子可能是置换出一台服务器，结果却发现它敲出了一个夜间传输，因为传输的安全性和机器的硬件认证相关联，改变硬件就改变了硬件键。避免附带损害的关键是在作出变更之前做好功课并尽可能多地确定相关功能。深入了解并识别任一相关功能，并对你的计划作出必要调整。
列一个变更清单—— Atul Gawande在他的著作《清单宣言（Checklist Manifesto）》中谈到如何运用清单来提高我们正确、安全和可靠地传递信息的能力。 IT 运维人员经常会使用记忆、培训和直觉来进行关键性的工作。当他们不按顺序执行或是跳过某些步骤执行时往往会出现问题。我非常支持在进行网络变更时使用清单，以确保成功并能避免危机。一个好的清单可以帮助你在变更过程中计划并正确实施这些步骤。
预备步骤 - 在作出更改之前需要做些什么？哪些服务器或设备需要被down或调整？需要通知谁？
进程中的步骤 - 在更改过程中必须执行哪些步骤？需要修改哪些配置？
验证变更是否奏效 - 您如何确定变更是否奏效。你应该检查哪些项目？应使用哪些数据来进行验证？
应急程序 - 如果形势转坏，应该使用什么策略来缓解？你的应急策略是什么？
恢复步骤 -如何才能撤销为实施更改所做的预备步骤？（这一步必须得到重视，因为它往往可以避免引发另一个危机。）
清单不一定要很长，但是要深入、准确和适用。个人觉得，使用清单是网络变更成功的关键。如果你对此有兴趣，可以查看我之前写的文章《IT项目实施时使用清单的8个理由》。
“一次只做好一件事”原则——我个人的原则是：一次只做一项主要的网络更改。如果只做一处变更，那么即便出现问题，你也只面临一个危机。如果两个或两个以上的变更同时出问题，那就是另外一回事了，就造成了多重危机。一次执行数个更改，却只有一部分网络down掉，这听起来很诱人，但是请不要这么做。这种冒险行为并不值得。
要清楚你所处的位置——位置感知（position awareness） - 当IT人员误以为自己是在测试系统上工作，然后抹去了一个生产系统，这绝对是最可怕的自我伤害。一个最好的例子就是IT经理在刷新QA数据库的时候，意外地清空了生产数据库，因为他在错误的机器上。通常在使用远程桌面程序时会出现这些错误，因为你可能在无意中连接到了错误的机器。在工作开始之前，一定要确保你在正确的机器上，即便只是执行一个hostname命令那么简单。在它首次制止你连接到错误的机器上的时候，你会感激你自己。
上述都是一些在变更管理指南中并未提及或仅是简单提及的实用性步骤。这些步骤很简单，但是可以帮助你应对意外的IT运维危机或是防止产生危机。