再扼要回顾一下把当时的情况：泰坦尼克号的指挥官们拼命想躲过一场撞击（见第8部分）。但是，“S型转向”这个正确的决策仍未能使船足够减速。数以百计的旅客在事后说，泰坦尼克的船体几乎平白无故地来了个停顿，颤动着、响起数秒钟咕噜噜的滚动和摩擦声音，如同船体正从大量的石头弹子上翻侧过去似的。
并没出现所谓“骤然急停”、灾祸、或者哪怕是轻微的受伤什么的。也没出现猛烈的侧向摇晃，或沿船体侧线的重复冲撞。这些情况，本会在船体要费力避开从侧面撞来的冰山的时候出现的。放在饭厅的早餐餐具几乎没颤动，头等吸烟室和休闲厅内的饮料也一点没洒漏。
一切迹象说明，船底刚好给搁在位于水下冰山基部的某一处冰架上了。默多克大副成功地规避了一场本可能让头前四个船厢粉身碎骨、并将杀伤数百名旅客的“迎头一击”。
同样地，一个IT解决方案在生产营运阶段出现不稳定时，根据项目本身预先准备、计划、和测试过的规程，会采取一系列行动（见第4部分）。
这种规程应以所谓MTTR （平均恢复时间）为基准，其主旨是使得该IT解决方案能从故障中尽快恢复上线，以满足所谓的“服务水准协议”SLAs。继而在后台通过某种临时、或者长远的修补来得到完善。
诚然，正式上线前，方案的完整性首先要得到确立，以防故障再次出现。
以时间为基准，运营团队将走完前述流程和故障的四个区间，即“故障探测”、“故障确定”、“故障解决”和“从中恢复”。 “平均恢复时间”MTTR一旦开始计时，意味着“服务中断”（一种损失，见第二部分）的开始，应按“用户损失分钟数”来采集评测指标，该“用户损失分钟数”可衡量出多少用户得不到服务以及持续了多久。
这种方法，远比常用的所谓“服务可用性百分比”，如99。999%的评测方式来得更精确。那末，泰坦尼克（“平均恢复时间”MTTR中）的“故障探测”期间，就是瞭望观察哨给出警报的那37秒。但在IT解决方案中如此（长的“故障探测”期）并不常见，通常的情况倒是会在大问题出现前，就为处理故障给出了较好的提示警报。
这给了自动化的、或者是人力的营运者以时间来首先防止问题的发作。（见第八部分）。
接下来，泰坦尼克号的船长、主管和指挥人员们在舰桥部集积确定行动步骤。作为“确定故障”的一部分，两组人员分别被派往船的头部、中部调查受损程度。第一组在10分钟内就带回了积极的报告：无大损伤，无漏水。
在主管布鲁斯-埃斯梅的头脑中，故障的“探测”和“确定”期就此结束了。至于以发出遇险或者求救信号的方式来完成随后的“故障解决”环节，对他来说却真是个大问题了，因为那会给泰坦尼克招来大量流言蜚语，将有损白星公司的市场位置，并且那种吸引了满世界富豪精英都来乘坐这有史以来最安全航班的辉煌市场效应，也将毁于一旦。
其实，此时更好的“故障解决”方案，应该是把船开回加拿大哈里发克斯港，避开纽约这一世界新闻中心。这样，他也可编出一个更好的新故事，把此次事故边沿化成一桩小事而已。他还能让乘客们都弃舟而改上火车，把船体修补一下后就开回贝尔法斯特作大修。事实上，他甚至可以大谈装备了最新式应急系统的泰坦尼克、本身就是一艘怎样的救生船，是如何从一场巨大灾难的边沿中成功自救的，还能把白星公司航线的安全性更进一步地加以宣传推广。
现今的IT解决方案中，“故障的确定”要评估其给用户带来的影响。“确定”本身，必须有“证据”可支持，在确定问题是否恶化升级了、引发源头是什么上面，重新调查反馈机制和日志是至关重要的。
在一个大型复杂的IT解决方案中，常现所谓“多米诺联动效应”，即一个小的故障点比如某个子系统，会波及其相关邻接者，从而引发大量的后续问题。
如果不准确地理清这些故障事件之间的关联顺序，将导致误判乃至做出错误修补，以及问题的再次发生。只有当对问题根因的估计得到测定和证实后，故障的“确定”期间才算正式完成。
对一个IT解决方案，重要的是保证掌握了“证据”，并提出下列问题：该方案是否预知自己将出现故障？如果是，那末是否有任何（自动的）防范行为发挥作用了？这些防范行为是否通知了人、或自动化操作者？反馈机制是否本身有问题、或反馈了不可信的数据？“故障的探测”
是否正确完成了？
泰坦尼克已处于紧要关头，但还未陷灾难。
埃斯梅为保全面子所累，而他对白星公司好名声的渴求所造成的环境氛围，使得任何问题都容易发生。泰坦尼克蹲在水下的冰架上，似乎完全没事；如果报安全为上、以防万一的态度收船回航，也可能发现不过是小问题而已；埃斯梅仓促之间作出决策。而此时第二组带了结构师和木工的损伤调查组尚未有评估报告返回。
今天的IT项目可吸取的教训在于：“故障的解决”中，重要的是在对可供选择的行动方案一一考察时，要在所有的“证据”基础上、考虑相关风险。唯此后，才可开始这最后“从故障中恢复”的环节，即营运团队根据“服务水准协议”SLAs让IT方案重新上线恢复服务。
在泰坦尼克上，作为故障解决的一环，并未对所有的可选行动方案进行充分考虑。埃斯梅做出了错误的决策，让船继续前进，并电告引擎室“以最低速度前进”来完成“从故障中恢复”的环节。工程师时候证实，船以伴有碾摩杂音的3节速度继续前进。
结论
今天，许多IT项目在营运阶段大打折扣，是因为项目计划的某种不充分：即没有以MTTR时间为基础来计划“故障解决流程”。
这样（计划充分的）流程，在帮助营运团队迅速恢复服务并保持一定的服务水准方面都至关重要。这种（计划充分的）流程，也应通过系列检查来实施各部门之间的相互制衡，以将在压力状态下犯错的可能性降到最低。这种（计划充分的）流程，还要析构出“角色与职责”结构，以保证让正确的职员作正确的决策。
下面将着眼于灾难状况中的泰坦尼克指挥人员是如何作反应的。
回顾当时泰坦尼克号的情形：与冰山相撞后船体仍显无恙，没人受伤。在船桥指挥部看来，船的完整性保持如初。白星公司主管布鲁斯-埃斯梅死守自己面子和公司的声誉。当晚11点45分，在撞击发生的10分钟后，埃斯梅催促启航，泰坦尼克号踉踉跄跄驶离冰架。
对危险一无所知的乘客们在开船之中松了口气，对撞击及其潜在的损害、后果都少有担忧。
如今的IT项目中至关重要的一点是，确保IT解决方案的平均故障恢复（MTTR）规程（见第9部分）已经在项目本身（见第4部分）之中被建立，准备，计划和测试过了，并被配以专人（运行团队/技术支持）“制度化”了。
在故障的第2区间（4个区间分别为故障的探测，确定，解决，和从中恢复）内，数据的采集应经过严格的检验。
在修复有问题的产品前，团队需要对修复本身的总体风险进行评估。对待上级的干预，应同对待其他方面来的意见一样，经过仔细的检验，以免造成问题的恶化。
重要的是，这些意见一旦可疑，就应立即予以挑战。
史密斯船长是否也是重起航程的决定者之一，已不重要了。因为埃斯梅已按照自己的意愿左右了大局。史密斯到无线电报室向波士顿公司总部汇报情况时仍显乐观，毕竟这艘有73个水密舱的大船在设计上具有很大的信心。
他发出的无线讯息中称，船撞冰了但受损很小，大家都很安全，为预防起见正驶向加拿大海尔法克斯。这条讯息应该给了白星公司足够的时间去安排火车和马车，把乘客们转往纽约。该无线讯息没有加密所以为各地媒体所悉。这也是欧洲新闻中对撞击的早期报道都普遍乐观的原因。
如今的IT项目中，平均故障恢复（MTTR）规程应完全取决于对it方案服务负责的团队。与故障有关的沟通、消息发布都需先经他们的密切配合，只有在与方案的服务对象做了外部沟通后，才能作后续支援的决定。不准确的信息将迅速瓦解服务提供者的信誉。
第2组调查人员，包括结构师托马斯-安德鲁斯和木匠约翰-哈金森,带回了更准确地事故评估和更好的数据。
而第1组调查人员则尚未检视完足够的地方来获悉更大范围的损伤。实际上撞击后数秒内，煤料燃烧房和第5锅炉房已经渗水。一名消防员事后证实，在煤料燃烧房地板上见到2英尺深的裂口。抽水机立刻开始工作，似乎能应付渗水、维持船体的上浮。托马斯-安德鲁斯深知一旦邮件室淹水，船也就完蛋了。
如今的IT项目可从中吸取的教训是，为了查明事故，支援团队必须对集成的可行方案知之甚祥，必须能将之逻辑分层，分解成一系列产品和部件。要诀在于，项目各个阶段工作文档化的重要性，和把文档作为知识下传后续运行阶段的支援团队。
重新起航后，第6锅炉房也开始渗水。
仅仅20分钟后，当初的决策有多不准确就已经很显见了。补救措施已无济于事，邮件室终被水淹。史密斯与托马斯-安德鲁斯及指挥员们开会决定让8节航速的船慢慢停下来。续航的行动终尝恶果，灾难性上涨的海水让船吃水更多，其他本未受撞击影响的部分也在水压下开始漏水了。
而今IT方案在不稳定时，在一个MTTR状态下，重要的是不断评估、再评估运行环境的数据（证据），并监视环境的变化。第1个修补通常是临时性的（见第9部分）、只为让方案重新开始服务。替代的永久性修补，可能需要数小时、数天才能到位，方案本身可能需要在后台打补丁。
如，代码可能需要重作，或者一个新的部件需要集成进方案的整体中。这样的话，在按照规程使之产品化之前，必须经过一个严格的计划、测试（见第4，5部分）。因此要求一个强有力的变更管理流程和测试/演示环境。
安德鲁斯向史密斯准确预测了船距离沉没还有2小时，这是死刑判决。
而史密斯终于也认识到情况已经无可挽救，不像撞击刚发生时那样尚有所可为了。
如今的IT项目可从中吸取的教训在于，MTTR规程是可循环的，顾及了在有限时间内的多次尝试。但是，埃斯梅迫使情况发展到超出了MTTR规程或者说是可恢复的限度。
结论
如今许多IT项目在紧急情况下大打折扣，因为不按照预定的运行和方案恢复规程行事。
制度化的MTTR规程，本来应有助于弱化如泰坦尼克号执行的那种亡命决策，并防止紧急状况恶化成大灾祸。因此，支援团队人员都应对方案的细节知之甚祥。下一部分将着眼于IT项目的灾难性恢复阶段。
回顾一下泰坦尼克号当时的情形：撞击发生后（见第8部分）船体摇晃驶离冰架，重新启航，开向海尔法客斯。
一切都似乎无碍，但8节航速下20分钟后，当初的决策有多不准确就已经很显见了。续航的行动终尝恶果，船进了更多的水。其他本未受撞击影响的部分也在水压下开始漏水了。上涨的海水正演变成一场大浩劫。
如今，第一要务是边确定永久性的修复方案，边通过临时性的补救措施来使服务迅速恢复上线。
但是，此时根本之处在于，应密切监视服务环境，观察补救措施是否见效。
包括结构师托马斯-安得鲁斯和木匠约翰-哈金斯的第二调查组，报告说有5个船部的主体被淹了，并认为这大违泰坦尼克号的设计初衷。沿船底的摩擦已严重撕裂了外壳并损坏了双层船体。6个主要船部进水速度的不同，也说明顶部船体已损。
事态竟然会糟糕到如此境地，这超出了设计者的预想。
在如今的IT项目中，至关重要的是项目团队要对这样一类任何补救措施都无济于事、事态发展将超出MTTR规程的不测，预作计划。对最终用户和客户，服务中断了且难于修复。针对这样的情形，在项目之内就应建立、准备、计划、测试灾难恢复规程，并且配以专人（运行团队/技术支持）使之制度化。
结构师意识到，泰坦尼克号状况已超一般的事故恢复范围，已演变成一场大浩劫。他说，船离沉没还有2个半小时到3个小时。并准确认定已无力回天。太多的船部破裂，水淹至抽水机都不及挽救。各船部之间的防水隔墙，没做到水密水平横断线的高度，所以当船鼻下沉时，水从一个船部渗进另一个，就像水浸过制冰格盘一样。
舞厅实际上成为让水向各部分派发的大通道。
此时我们已可发现，项目建设阶段在非功能性需求上的那种妥协，在这场浩劫中是如何引发巨大恶果的。
只有船长和部分指挥官确知损坏程度，而眼下只能眼睁睁看着船的下沉。没有发出过“弃船”或其它正式的灾难公告。
只在撞击后的65分钟时，船长命指挥官们打开救生艇的遮布，并让乘客和船员们都到甲板上。泰坦尼克号上没有正式的灾难恢复计划。
如果发生在今天，接下来应启动灾难恢复计划，并向所有人沟通该计划。每个灾难恢复计划都应有考虑周全的沟通计划，需向不同的听众清楚无疑地进行沟通。
泰坦尼克号的船长在碰撞后很快就明白了问题的严重性，但是，他没有通过其船员与乘客们完成沟通。这船上人们的困惑加剧了，尤其是船员们。比如，引擎室向甲板派出了工程师，可指挥部却让他们返回去。对船上这样糟糕的沟通问题，可能的解释有：
●船上装备的沟通系统有限，没有公告系统。
重要信息只能通过船员们到各个舱位敲门后口传给乘客。考虑到舱位数以百计，这太费时了。
●船员们本身就对实情不清楚，所以乘客们所能知晓的就莫衷一是。这个老船长对船体的安全系统太有信心，也许难于相信结构师的判断，因此开始的时候一切似乎都还正常。船长的表现几乎就相当于好像一切正常。
●船长深知救生艇数量不敷所需，大约只够带走全船2223人中的一半。所以，也许最好还是不制造恐慌，而在适当时候让救生艇在一片平和中有秩序地载走乘客。船体水平状的结构，和舱位等级的界别，意味着头等舱的乘客们可更优先得到救生艇位。
●船长担心恐慌的扩散。
他同下属都知道14年前法国客轮La Bourgogne下沉的故事。当时也只有一半乘客有救生艇位，引发一片恐慌。史密斯船长知道，他可以通过让那些足够幸运者都上到救生艇上，来挽救尽量多的人。所以，他没告诉所有乘客，尤其是3等舱的那些人。
如今，沟通计划可能与灾难恢复计划一样重要。
原因如下：
●与雇员的内部沟通极有助于控制灾难的影响度。同时，沟通的速度也很重要，比如可首先让面向客户的那些雇员获悉讯息，因而他们能转达客户。
●与客户的外部沟通也很重要。沟通计划需要根据问题或灾难的大小范围，以不同渠道来向顾客各个层级传达。
●根据服务中断的严重程度，和公众媒体的沟通也许是必要的。这需要确定什么是关键信息，如何沟通发布，通过什么渠道。许多公司不再设防，流动通信员带着一些陷阱问题访问不知情的雇员们。
结论
如今，许多IT项目由于没有对最坏情况准备对策，而在运行中大打折扣。
光有MTTR规程还不够。除了灾难恢复计划，一个考虑周全的沟通计划也必须到位。下一部分将着眼于灾难恢复的启动。
回顾泰坦尼克号当时的情形：当船重新起航后，渗水演变成一场大灾难。当晚12时45分左右，即在船体搁在冰架上65分钟后，船长令指挥员们打开救生艇并把所有乘客和船员召集到甲板上。
船员们因不清晰的沟通而处于困惑之中，行动迟疑，不相信一切已经不对头了。毕竟，其时大灾难的迹象尚未显见。
在今天，灾难恢复的概念是把在线运行转移到另一个替代性的服务环境。但是形式却是多种多样的，从数天内完成单个应用的数据/文件的简单恢复，到数分钟小时内就得完成整个业务运行的相对复杂的恢复。
灾难可能呈现三种态势，即：完全状态（绝对而立即），急迫而逼近，缓慢而无毒害。当灾难被确认后，应急计划就启动了，灾难也将被公诸于众。
在泰坦尼克号上，灾难属于缓慢而无毒害型的。虽然全面的恢复计划不再可行，船长与指挥官们仍可展开局部的恢复。而在缺乏正式的撤离或灾难恢复计划的情况下，他们能做的也只能是在灾难迹象明显之前，发令阻止恐慌和混乱的蔓延。
在设计时对灾难恢复的场景假想，是用救生艇把乘客们转移到另一艘船上并带回港岸，就是说，救生艇会往返运载乘客，因此对其数量的要求就很小。但这一假想的前提是基于泰坦尼克号是不会沉没的，至少能自己漂浮在海上待援。
而今我们开发一个灾难恢复计划时，必须考虑全IT方案中可能引发灾难的所有形式的故障。
例如：
●技术上的物理故障或有形缺陷
●设计错误，含系统/应用程序软件设计的失败和代码问题
●由运行操作人员因事故，不熟练，培训不足，不按规程甚至蓄意恶意造成的运行失败
环境（如动力系统，冷却系统，连同网络）的故障，可以和自然灾害、恐怖行动一样，对运行中心造成同等的破坏。
在过去400年中，绝大部分与横渡大西洋有关的环境因素，都已经被发现，植入图表和载入文档了。内容包罗万象，从全年的自然情况（如海流的变化），天气情形（如风暴和飓风），到自然危害（如海上浓雾，冰原，冰山带和危险的海岸线，礁石等等）。然而，在泰坦尼克号项目中弥漫的一种信念就是，这艘不会沉的巨大铁船能应对一切自然问题。
在设计一个灾难恢复计划时，还需考虑灾难的级别。比如，当较小的风暴，火灾或者水淹来袭时，你的顾客希望得到某种相对迅速的应急服务。现在，你就需要对所有这些都准备应急措施，以至对更大的灾难也一样。
灾难恢复的相关费用，会因耗时，引发原理，恢复程度的不同而相异。
这些费用，应作为计划的一部分，针对每个特定的IT方案对象，仔细确定。
对泰坦尼克号而言，按海运惯例本应有一个考虑到了上述一切情况的灾难恢复计划，来将所有人带到救生甲板，把他们转移到座位宽绰有余的救生艇上，安全放下并让训练有素的船员带走他们。
在金斯顿的救生艇训练中，应该已经测试过计划中的这后一部分。
在生产环境下大量的严重问题都开始于无毒无害的状态，即在问题刚开始时，你的组织也许甚至都不会留意到它及其影响后果。如，IT方案中一个不紧要的部分停下来了，未被注意，但是因为各个部件和应用之间的内在关联，出现一种连锁效应并很快使得该方案的其他部分受到影响，这将在极短时间内引发大的灾祸。
在泰坦尼克号上，救生艇的释放明显晚了，说明方式犹豫到最后才不得不发放的。指挥员的缓慢反应，可能因为总觉得该船不可能沉没，事态也不明显，当时一切都尚显正常。还有，900船员中，真正意义上的水手只有83个（见第5部分），只有这些人掌握了把30英尺长的救生艇（可乘65人）怎样放到60英尺下海面上的复杂操作。
这样的救生艇一共16艘，此外另有4艘较小的可拆装式的称作Englehardts的救生艇（可乘45人）。
结论
如今，不少IT项目完全忽视灾难恢复，其理由是不在项目范畴内，和另有年度计划流程来覆盖。IT项目本身除了确立商务理由，针对IT方案进行设计外，其实也包括了对所需恢复展开深入的了解。
对影响IT方案的灾难后果所作的严肃思考，需在项目早期尽早完成，以便对整体的灾难恢复计划进行调整。下一部分我们仍将着眼于灾难恢复。
全部
