《火星救援》是最近一部受到广泛关注的片子，讲述在一次人类登陆火星的任务中，宇航员马克·沃特尼经历了一场恶劣的风暴后，与他的机组成员失联，所有人都认为他在这次任务中丧生。然而，马克却幸运地活了下来，然而他发现自己孤单地置身于异星球。面对贫乏的生命补给，马克必须用他的聪明才智和顽强的精神存活下来，并如何寻求求救的故事。

   大部分互联网系统也面临各种临时突发的故障，技术负责人及相关工程师需要及时响应故障，采取合适的手段来解决问题。因此火星救援中体现的很多原则，做法和高可用系统故障恢复是同理。

1、故障信息的透明性原则

   在火星救援中，当NASA发现马克还生存时候，NASA第一时间再次举行了新闻发布会，向媒体及公众进行了交代，包括后续大部分事件如文本聊天，也是通过媒体现场直播，这是信息透明的原则。但是里面只有一点，NASA将相关信息给宇宙飞船的成员隐瞒了很长一段时间，这个是信息不透明带来后果的案例，后面面对公众时也出现了尴尬、被动包括可能需要承担职责的局面。

   互联网系统在故障发生时候，技术人员第一时间发现了故障，如果不能马上排除，则需要考虑是否将问题上报、以及将信息公示给所有用户。

   给公司上级上报故障在某种程度会对技术团队留下负面印象，给外界用户公示故障会给产品带来负面的印象及不信任。因此保证信息透明需要有一定勇气。但反过来思考，故障已经成为事实，也已经对用户使用系统造成影响，隐瞒问题会带来更多及更大的问题。技术负责人主动承认问题发生，及时通报问题以便各部门采取合适的应对及支援手段，以便能合理利用更多的资源来更早的解决问题。及时公示问题给用户(比如通过官方微博及官方网站)，以便争取用户的理解及支持。

   从长远来看，所有故障都不是某个人及所在小组的责任，管理层很少会出现迁怒于人的可能，而更多的是去改进体系上及管理上的问题。因此公开故障可以帮助公司及团队更好的、更透明的去认识问题，帮助技术团队做出改进，以便将来从体系上规避类似问题。

2、故障突发性对应的解决时限性原则

   火星救援中几个时间点都非常急迫。马克在火星的食品非常有限，并且可能会随时遇到不可预料的情况。尤其是当栖息舱爆炸后，全部种植的马铃薯死亡，且无法再次种植。瓦特尼只能倚靠之前收成的马铃薯生存下去，当时能让他再多活200个火星日。但是发射宇宙飞船登陆火星是一件非常庞大的系统工程，需要做好长时间的准备及周密的测试，并且存在欲速不达的可能。因此火星项目负责人需要在有限的时间内做出最佳可行的方案选择。

   故障选择也大多处于类似被动的局面，当故障发生时候，用户访问系统受到影响，需要在尽可能短的时间内恢复服务。但由于时间紧迫，负责人可能没有足够的时间来分析故障的根本原因，只能根据现象及已有经验迅速做出判断。而且根据故障问题的不同，一些恢复手段如数据重建可能需要较长的时间，一些方案可能会超过用户容忍的极限，因此需要技术负责人在短时间内做出快速解决故障的选择。

3、故障中解决方案的技术决定性原则

   火星救援中，有几个场景体现了技术的决定作用。一个是中国的太阳神助推器，将宇宙飞船赫耳墨斯号推向火星，一个是航天动力学家里奇·布内尔的航行方案，可以看到，临时的技术方法在救援中起了决定作用。

   故障恢复时候也有这样的情况，大家围着主要负责人旁边一筹莫展时候，突然角落里不起眼的程序员说找出了解决方法，然后非常及时的解决了问题。故障时候仅能看到现象，很多时候还没来得及分析出根本的原因，因此技术负责人也很难当机立断提出非常确认的方案来解决问题。熟悉体系的程序员这时候可以发挥自身的能动性，小范围的去推测、尝试及验证，有有很大的机会更快的解决问题。一些故障拖很长时间，有一定程度是团队成员没有有效手段，另外一个原因也许是团队成员群体思维，全部按照主流的思想或者负责人的思路去应对及处理，如果主流方法不是合适解法，有可能会将故障时间拉长。

   还有一些公司将线上系统当成黑盒，工程师只需要将自己模块合并进去，无需关注线上运行状况。这种情况一旦出了可用性问题，大部分工程师是一筹莫展的，只能依靠少数几个精英来解决问题，通常不利于问题的迅速解决。

4、充分利用系统预留扩展能力的原则

   马克与地球取得联系，是依靠1996年发射的火星探路者号(Pathfinder)，并且依靠其预留的通讯接口，让实时文本聊天成为可能。火星救援最后的决定作用是预留的MAV，通过下次任务战神四号预留的MAV上升载具起飞到太空轨道，然后对接上宇宙飞船赫耳墨斯号返回地球。这让马克在食品用完之前返回地球成为了可能。

   我们在开发高可用系统时，大部分服务模块的代码都留了一个开关，可以在适当时候开启或者关闭一段代码。虽然在99.9%的场景下这个开关不起作用，但在灾难事故发生时候，可能一个小小的开关犹如发生故障时玻璃窗旁边的救生锤，可以决定整个事故的走向。

5、简单粗暴处理原则

   火星救援最后的MAV起飞时候，由于上升高度不能到达赫耳墨斯号对接，因此简单粗暴的将所有没用的东西去除。看起来可能在电影里面才会出现，但如果真的碰到类似情况，可能也没有更好的处理方法。

   在处理故障过程当中，很多时候也需要打破常规，用一些简单粗暴的方法，这些方法可能临时会造成一些用户访问的问题，甚至会引起部分数据的不一致，但是如果能让整体迅速恢复，这些简单粗暴的方法是值得鼓励和尝试的。关键技术负责人需要知道有合适的善后技术方案来恢复这些用户的数据。

   马克·瓦特尼回到地球，许多天后的一天清晨，坐在公园长椅喝咖啡，原来我们写代码普通一天也是火星人羡慕的幸福生活。

   本文中文翻译参考《火星救援》译林出版社中文版。

建议继续学习：

1. 基于MySQL的高可用可扩展架构探讨    (阅读：3777)
2. 利用MySQL Cluster 7.0 + LVS 搭建高可用环境    (阅读：3455)
3. 寻找适合你的MySQL高可用解决方案    (阅读：2979)
4. Twitter“鲸鱼”故障技术剖析    (阅读：2779)
5. ORACLE Fusion-io最佳实践    (阅读：2639)
6. Oracle+Fusionio+Dataguard的高可用方案    (阅读：2581)
7. 分布式系统设计系列 -- 基本原理及高可用策略    (阅读：2543)
8. 构建高可用系统之故障篇    (阅读：2382)
9. Oracle高可用架构    (阅读：2329)
10. 构建高可用和弹性伸缩的KV存储系统    (阅读：2304)