IT支持人员应对方案细节了如指掌

申请免费试用、咨询电话：400-8352-114

在与冰山碰撞之后，泰坦尼克外形看起来还不错。没有人受伤，并且从桥楼上看，该船完好无损。白星总管布鲁斯.伊斯梅一心想挽回颜面以及挽回公司的名誉。在晚上11:50，即碰撞发生的10分钟后，伊斯梅下令重新启动轮船并且离开冰山。乘客们并没有意识到任何危险，也对碰撞及潜在的灾难性后果一点也不感到紧张，但事后证实了他们最初的幸免于难只不过是噩梦的开始。

在今天的IT项目中，项目自身及专业化员工（操作人员/技术支持人员）能为IT解决方案制定、准备、计划及测试平均修复时间(MTTR)至关重要。在第二“问题”象限（这四个象限为：检测、判定、方案及修复）所收集的数据必须经得起严格的审核。

在将解决方案或修复方案应用到产品前，小组必须评估继续进行下去的综合风险。执行上的干预也必须象其它投入要素一样能经得起严格的检验，这样才不会使情况更加恶化。重要的是，如果这种干预没有带来任何起色，那么它也会被人质疑。

史密斯船长是否参与了重启泰坦尼克号的决定并不重要，因为伊斯梅按他自己的想法控制了整个形势。史密斯走入无线电室向位于波斯顿的白星公司发送通知。史密斯当时还是很乐观的，毕竟，轮船上设计了73个水密室，这让人颇有信心。史密斯发出了一条无线电报，叙述了泰坦尼克号撞上了冰山，但是几乎没有损伤。船上的每个人都很安全，同时为了预防起见，轮船现在正向哈利法克斯驶进。这条信息本可以使白星公司有足够的时间来安排别的轮船来转移这些乘客前往纽约。但是无线电并没有被加密，它被世界媒体中途阻止了。这就是为何人们就欧洲新闻对此次碰撞的早期报导仍觉乐观的原因所在。

在今天的IT项目里，平均修复时间(MTTR)程序由负责IT解决方案及服务的小组完全控制。小组必须密切留意与意外状态的沟通情况，并且当与一项解决方案的服务接收者进行的沟通属于外部性沟通时，小组要制定出支持决策。错误的信息可能很快使服务提供者的信心大大降低。

第二搜索救援组（包括造船专家托马斯.安德鲁以及木匠约翰.哈奇森）返回时带来了对整个情况的更精确的评估和更详细的数据。第一搜索救援组并没有完全下到甲板上去观察所有的损伤。在几秒钟的碰撞中，海水漫进了煤仓和5号锅炉房中。一个消防员在事后证实他看到在煤仓的地板上有一个2英尺深的洞。抽水泵立即被拿来抽吸海水，看来为了使船保持漂浮，抽水的速度要与海水漫进来的速度一较高下。安德鲁深知如果档案室被淹的话，这艘船将难逃恶运。

今天的IT项目从中所获取的经验是：为了查明错误，支持小组要充分了解整个处于运作中的解决方案，并且具备将这些了解的内容细分到各个逻辑层、并将其分解成一系列的产品和组件的能力。在项目的每一阶段要创建文件，并且要将此文件传达给支持小组留作后用，这两点非常关键。

在重新启动轮船后，6号锅炉房也开始进水了。约20分钟后，很明显最初的判断是非常不精确的，修复并没有使形势得到缓和。档案室被淹没了。史密斯与安德鲁及官员协商后，决定将当时正以8哩/小时速度行驶的轮船慢慢停下来。前进无疑于加速死亡。船已经进了很多水，这使灾难即将来临。船的其它部分，在刚开始还没有损坏，但是在海水的压力下也开始出现了裂变。

今天，如果一个IT解决方案在平均修复时间阶段（MTTR）出了问题，保持对周围数据（迹象）的评估和再评估以及监视环境上的任何变化非常重要。最初的修补通常是暂时的，因为这只是为了让解决方案能快些恢复正常并使服务重新启动。要想得到永久的修补通常要花上好几个小时或好几天。修补解决方案可能必须在不引人注意的地方进行。诸如，代码可能必须重写或者方案中出现了一个新的集成组件。然后这要经过计划及测试，之后才可以使用项目程序在生产中执行，因此我们需要一个强大的变动管理流程和一个测试/演示环境。

安德鲁客观地向史密斯汇报了这艘船约过两小时就会沉没。这无疑是判了死刑，史密斯最终意识到情况已不象刚才发生撞击那样还能修复，现在已彻底令人绝望。

今天的IT项目从中所汲取的教训是：平均修复时间程序在一个有限的时限内是循环的，并且它酌留出了修复尝试的空间。然而，伊斯梅强行控制了轮船，即根本就不考虑MTTR或修复就让轮船继续前进。

结论

今天，由于在解决方案的运作及修复阶段没有遵循事先制定好的方法，许多IT项目在关键情况中遭受了不幸。专业化的平均修复时间程序可以帮助我们从不同的决策中选择出最好的一个，然后将其运用在泰坦尼克号上。因此支持人员应该对解决方案的细节了如指掌。

来源：AMT