电脑系统怎么样能保持不坏(如何保持系统的高可用性？)
前言
1979年3月28日美国宾州的三哩岛核电站发生部分队芯熔毁的严重事故，迫使25万周边居民转移。
1986年1月28日美国佛州的挑战者号航天飞机发生升空后爆炸，造成7名宇航员全部遇难。
2011年7月23日北京南开往福州的动车与杭州开往福州南的动车组追尾，40人死亡。
2012年2月28日微软的Azure云服务大面积服务中断，宕机事件超过24小时。
2012年6月15日亚马逊的AWS云服务因停电造成服务中断大约6小时，影响广泛。
2015年5月28日携程官网因操作错误导致故障引起服务中断长达14小时。
2018年6月28日阿里云因为运维操作失误出现了大规模的故障。
…………
无论是宇宙飞船、民航客机、高速铁路、电子邮件、即时通讯、电子商务、电子支付，还是网络游戏、在线直播和金融服务系统，用户都希望需要的服务能呼之即来，来之能用；运维人员都希望自己的系统永远不发生事故。那么现在的互联网技术是否有可能保障系统有金刚不坏之身，保持100%的高可用性呢？
其实，早在1984年耶鲁大学社会学教授查尔斯·佩罗（CharlesPerrow）就发表了一本很有影响的专著《高风险技术与“正常事故”》。佩罗论证说，由于高技术系统的各个组成单元之间存在着高度耦合，而耦合所造成的相互作用迅速升级使人类成功控制系统机会不大。而且，那些设计来保障安全的单元往往自身也会出现故障。例如美国三哩岛核电站事故的起因就是安全阀出了故障，用来在撞车时减震的气囊伤人的事也偶有发生。因此，从某种意义上说，现代互联网的高度耦合系统所固有的复杂性使事故不可避免，这类事故将是“正常事故”。
事后分析过程的三个阶段
那么如何才能减少关键系统事故的概率呢？是否有什么好的方法和最佳实践呢？俗话说“失败是成功之母”，我们强调从错误中学习经验和改进错误的重要性，正视事故而且不断地从中学习并改进现有系统的架构和流程才有可能降低失败的概率。《架构即未来》总结出了一个简单易行的学习和改进过程。对于所经历的任何重大问题，我们相信一个组织应该采用下面描述的事后分析过程，通过截然不同的三个阶段来解决问题：
1
描述问题
聚焦在时间轴上描述引起问题或危机的事件。在这个阶段，除了时间轴以外，什么都不要讨论。一旦参加会议的每个人都同意再也没有更多的事件要添加到时间轴上时，该阶段就宣告结束。通常会发现，即使已经通过了时间轴阶段，人们仍然还会在事后分析的下一个阶段继续想起或发现值得在时间轴上标注的事件。
2
发现问题
协调团队成员在时间轴上共同回顾并发现问题。如果监控在早上8点第一次发现客户失败，但是直到中午才有人出来响应，这么做是否适当？为什么数据库的自动故障转移没有按照预期的设计发生？为什么相信删除表会使应用程序恢复运行？从时间轴上发现每个问题，但不纠正或采取行动直到团队完成问题识别。尽管团队成员总是提出具体的行动建议，但是过程的协调者有责任让团队聚焦在识别和发现问题上。
3
明确行动
确定每个问题至少应该有一个相应的措施。对于列表中的每个问题，确保措施、负责人、预期结果以及完成时间。应用SMART原则，每个措施都应该是具体、可度量、可实现、现实且有时间性。即使该行动可能需要一个小组才能完成，也应该明确唯一的具体负责人。
高可靠组织的五种行为习惯
1996年当加州大学伯克利分校的研究者托德·拉波特（ToddLaPorte）在研究如何确保复杂系统运维的可靠性时，分析了美国核动力航空母舰，联邦航空交通管制署和核发电站的运维实践，提出了高可靠性组织理论（HRO）。所谓高可靠性组织是指通过内部有效的管理与安全预警机制，应用人类行为学理论来计划、组织、调配、领导和控制人类行为，从而提高系统的安全性和可靠性的组织。高可靠性组织是从组织本身的角度来思考企业事故发生率及安全管理问题。密西根大学组织心理学教授魏克指出，高可靠性组织具备一项共同的基本特质：即对于不断袭面而来的意外改变，能及早警觉，并迅速采取有效的应对措施。高可靠性组织有以下五种行为习惯：
1
谨慎关注失败
绝对不要被过去的成功冲昏了头脑，要一直对失败保持高度的敏感。例如定期通报各种事故，让所有参与关键系统运维的人员时时警钟长鸣。
2
拒绝简化解释
人们倾向于把微小的变化解释为常态，而这很可能是对即将发生的失败最重要的早期示警，绝对不放过任何可能导致重大事故的蛛丝马迹。
3
操作的敏感性
认真查看分钟级别的详细日志和监控数据。包括使用实时数据并坚持持续评估和不断更新，对任何一个运维操作都要有实施方案、回滚预案和实施监控。
4
保持人员冗余
通过轮岗和新技能培训，形成过剩的运维能力。确保运维团队有足够的资源监控、调查、处理问题，在运维人员上节省资源可能是CTO最后悔的事情。
5
尊重专业经验
在危机处理过程中，不是让最大的行政官员，而是让拥有最好专业知识的人来主导协调和处理危机，通过不断的演练培养出核心运维指挥官。
总结
总之，系统运维是一个系统性和专业性的工作，也是CTO的心腹大患。要打造一个高可靠性组织，必须采用合适的方法，遵循高可靠性组织的行为准则。