学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放

当你以“救火队员”身份解决突发事件并以此为傲时，用户会袖手旁观，毫不领情，甚至还会埋怨：因为你所救下的并不是他们辛劳之后唯一拥有的个人财富，而且罪魁祸首正是你所代表的组织所提供的产品和服务——你做得再好也只是为决策的不幸而承担责任。当你以“游击队员”身份服务于各个用户并以此为荣时，用户会在等待中消耗配合的热情，形成对你所在组织的坏印象，甚至直接抄起电话就投诉：因为用户看不到你那些光荣业绩，只看到他\她的资源因为等你而在被浪费——你做得再好也只是为执行的不力而承担责任。当你以“系统专家”身份处理疑难杂症并以此为尊时，用户会在窃笑系统尽然如此脆弱和愚笨，只是在输入的时候不小心输错了一个字符、按错了一个按钮，就给弹出些莫名其妙的东西：因为用户总是认为系统应该能够理解并处理好所输入的东西，并没有想到只是自己的一个什么纰漏导致了这个问题的发生——你做得再好也只是为设计的不良而承担责任。希望说的这一切没有都在你一个人身上发生。但如果是的话，那是时候换到用户的角度来看待IT运维了：不要只是正确地IT运维，而要正确的IT运维。

正确的IT运维包括以下三个部分：对于组件级别的正确的替换；对于应用级别的正确的应急；对于系统级别的正确的灾备。对于一台不能正常工作的桌面打印机，用户需要的是另一台能正常工作的桌面打印机联上就能用：这就是替换；要做的是确保这个替换是经济的、快捷的、平稳的；只有这样才会为搞定这台不能正常工作的桌面打印机提供足够的资源，找到并解决真正的问题，从而使其投入到可替换的行列中。这就是“对于组件级别的正确的替换”最典型的例子。但是事情往往会比这复杂：用户往往需要某一特定应用来完成其工作；如果某一特定应用不能正常工作时，应该让该特定应用的用户想到是否还有其他办法能够同样完成其工作：这就是应急的起点；要做的是如何让用户知道不正常的发生、如何让用户知道存在应急方案并能正确执行、如何让用户在恢复正常后将采取的应急措施的影响消化掉；只有这样才会为恢复正常应用以及所制定的应急措施的有效性提供足够的资源。这里会涉及到与不同应用的不同用户不断互动的事情，却是“对于应用级别的正确的应急”最常见的例子。当然，事情还有更复杂的：很多工作往往需要多个用户通过系统来协同工作才能将其完成；如果某一系统不能正常工作时，应该通知所有相关用户，保留好工作现场，并配合灾备的有序开展：这就是灾备的过程；要做的是如何让灾备方案起到系统级替换的效果；只有这样才会为灾备的完善、有效和快捷提供足够的资源。这是“对于系统级别的正确的灾备”最经典的例子。

那么，怎么才能正确地把这个正确的IT运维给做起来呢？先做系统级别的灾备，再做应用级别的应急，最后做组件级别的替换。对于用户来说，系统级别上的工作往往会被认为是高级别的：因为在一个系统中，不及时处理自己工作的用户往往会成为整个工作顺利完成的瓶颈；同时，对于应用和组件上的工作则会是在低等级的优先级上。而对于IT运维来说，这样不仅能够建立起大局观，同时也便于针对不同的情况逐级推进具体工作；只有这样，用户和IT运维组织也才能同心同德一起搞好工作——明知道大家都在灾备，就不会对低一等级的优先级的事务上而抱怨，投诉，甚至是幸灾乐祸。同时，这样推进整个IT运维也是从可行性上、经济性上、管理体系成长性上提供了良好的方向指导：毕竟整个IT运维的水平的提高是一个持续不断的过程，受到很多因素的影响，能做的，就是保持方向的正确性。其实也只有这个方向的正确性，才可以不会再被“正确的IT运维，还是正确地IT运维”所困扰，坚持做好IT运维就可以了，也就是正确地IT运维。

这说的有点综合了几个观点：

1、正确做事还是做正确的事？

2、优先做重要的事还是做紧急的事？

alex 点评极佳！:lol

往往知易行难

就是这样了

“一切真理一旦被发现就变得通俗易懂，关键在于发现的过程。——伽利略”

推论出

“一些道理一旦知道就变得有了参考的依据和目标，关键在于实现的过程”;P