在聚会中，每当谈到世界大事时，我们中的许多人都可能会说“我们好像从未吸取历史上的教训”。但又有几个人能真正在工作中对我们自己、我们创造的东西和我们的团队执行这个标准呢?在这个具有高可用性和高可扩展性的技术平台上，存在一个有趣的悖论，即最初构建的系统最好，不常发生故障，因此让团队学习的机会不多。这个悖论的内在含义就是，流程、系统或人员定负载的条件下测试脚本，确保在应用程序使用数据库时，它仍然能够执行。
口对应用中的SQL查询进行约束。开发团队需要消除所有SQL语句中的歧义，删除所有 SELECT*查询，并且给 UPDATE语句加上要更新的列的名字。
口数据的语义修改。在发布版本中，开发团队不能修改数据的定义。举个例子。票务表中的一列用于存放状态信号，其中有三个值assigned、 fixed和closed。在应用的新版本中，如果没有发布处理新状态的代码，就不能添加第四个状态。
口Wire On/ire Off』。应该让应用结构化，使其能根据外部配置，让有些用户能够访问某个代码路径和功能，而有的用户则不能访问。这种设置可以存放在配置文件中，也可以存放在数据库表中既能够根据角色赋予访问权限，也能够根据随机百分比分配权限。有了这种结构，就能够让有限的用户对新功能进行beta测试，而且能够迅速地删除主要bug的代码路径，从而不必回退整个代码。我们得到的教训虽然惨痛，但是很有价值，有了这次教训，我们再也不会发布不能回退的代码了。即使以后和其他团队一起工作，我们也会这样要求自己的。可见，这些原则并不复杂，而是相当简单，仟何团队都能够应用它们，都能具备回退的能力。方面的每一次失败都给我们提供了执行事后分析的机会，从而让我们能够有所长进并修改系统。若不能把握好这些宝贵的机会来提高自身水平、改进流程并改善技术，我们就不能像今天这样正常运转下去，从而导致又一次失败。如果这种情况发生在超高速友虔而要积被进付抄的冏业现，那一足公惨遭经當失败。当我们在快速发展时，会发生太多事情，两年甚至一年前设计的解决方案是无法支持相当于构建系统时10倍的业务量的。
核电时代我们可以更深入地了解为什么要从失败中吸取教训。1979年，三里岛核电站第2组反应堆的部分熔毁，成为美国历史上最重大的核电事故。这一事故为多本书和至少一部电影提供了素材，还产生了两个重要理论，涉及的是在很少发生事故但一旦发生代价很高的环境中学习的必要性。
Charles Perrow提出了正常事故理论。该理论推断，现代耦合的系统的内在复杂性使得事故不可避免。这些系统的内在耦合性会使交互急剧升级，致使人或控制系统根本没有机会进行成功的交互。回想一下，你是不是经常遇到这种情况，正在监控的解决方案突然从“绿色”全部变成了“红色”，而在此之前，你甚至来不及对第一个警告信息作出反应Todd Laporte提出了高可靠性组织的理论。他相信，即使没有发生能够让一个组织学习的事故，也会有一些组织策略能够实现高可靠性。2)虽然这些理论的作者没有就这些理论是否能共存达成共识，他们还是有一些共同点的。首先，失败过的组织有更多的机会学习，通常比没有失败过的组织发展得更快，当然，这里假设他们会利用这些机会从中学习其次，和前者相似，很少出故障的系统提供的学习机会少，如果没有其他的方法，那么相关的团队和系统就难以发展和提高。
讨论完从失败中吸取教训从而获得提高这个主题后，我们简单介绍一个轻量级的流程，通过这个流程我们可以学习和提高。对于经历过的每个重大问题，我们认为相关组织都应该对这些问题进行事后分析，可用如下三个阶段来解决问题。
口阶段1，时间轴。为造成问题或危机的事件生成一个时间轴。这阶段只讨论时间轴。我们经常发现，即使已经完成了时间轴，在下一个阶段，人们还是会想起或者发现值得标注到时间轴上的事件。
口阶段2，发现问题。该流程的主持者会与相关的团队一起工作，按照时间轴逐一检查，发现其中的问题。第一个监控器在早晨8点发现了客户故障，但是直到中午都没有人对其进行响应，这样可以接受吗?为什么数据库没有进行自动故障恢复?为什么我们认为删除用户授权表会使应用重新开始运行?从时间轴中发现每一个问题，但是在问题识别阶段结束之前，不能执行任何修改或其他操作。当然，团队成员要提出建议执行的操作，但让团队在阶段2专注于问题识别是该流程的主持者的责任
口阶段3，说明操作。对于发现的每一个问题，至少要有一个与之关联的操作。该流程的主持者会与相关的团队一起遍历问题清单，标识出要执行的操作、这个问题的负责人以及预期的结果和应该完成操作的时间。根据 SMART法则，每个操作应该是具体的、可衡量的、可实现的、现实的且及时的。即使一个操作需要一组人来完成，也需要标识出一个负责人。
直到造成故障的人员、流程和技术方面的问题都解决了，一次事后分析才算完成。我们]经常发现，客户会把“服务器死机”作为一个偶然事件的根本原因。任何一个偶然事件的根本原因，都不能归咎于单一的失败，无论是硬件故障，还是人员和流程的失误。任何扩展性和可用性方面的失败，真正的问题都是“为什么整个系统不能运行得更好呢”。如果数据库失败是由于负载问题，那么为什么相关组织不能早点儿发现负载需求呢?应该采用什么样的流程或监控措施，才能帮助组织发现问题呢?为什么需要花费这么长时间从故障中恢复呢?为什么没有划分数据库，让故障对客户或服务的影响小小一些呢?为什么没有一个数据库的读副本迅速地被提升为写人副本呢?根据我们的经验，至少要回答五个覆盖不同方向的“为什么”的甚
既然已经讨论过了应该做什么，那么下面来看看没多少出故障机会的例子。有些组织幸运地拥有能够有效扩展且很少出故障的平台，Weick和 Sutcliffe为这样的组织提供了一个解决方案。我们根据需求对他们的方案稍加修改，改后的方案如下所示。
口关注故障。这个实践就是监控产品和系统，实时地报告发生的错误。他们认为，成功会麻痹感觉，滋生自负心理。要与这种自满情绪作斗争，组织需要保持系统故障和失败彻底透明。监控报告要广泛地分发下去，并且要在每日例会这样的环境中频繁讨论平台的运维。
口拒绝简化解释。对一切都不要掉以轻心，寻求多种弓引人问题的可能。不用认为故障是正常的，是系统固有的。人们习惯把小小的波动解释为“正常的”，其实它们可能是即将发生的故障的最早指示信号。
口关注运维。査看分钟级别的详细数据，包括实时数据的使用，不断进行评估，并持续更新这些数据。
口培训多技能员工。让员工在不同的岗位上轮换，给他们培训新技能，可以让他们具备额外的能力。eBay以前的运维人员能够证明这一点，它的DBA、SA和和网络工程师都曾经在运维中心做过运维工作。此外，一旦给系统打了补丁，相关组织就应该迅速为下一次出现状况做好准备。
口尊重专家。在危机事件中，要把领导权交给处理该问题最专业的人。可以考虑在运维中心的危机管理机制中创建一个新职位，如“技术责任人”。
绝对不要浪费从网站制作失误中学习的机会，因为这是对系统或平台进行正确修改的最佳机会。把一种流程(例如事后分析的流程)落实到位，确A所有大中字的机公。如果你的条统设计得很好，即便超负荷作，也不常出故障，那么可以实践一下预警能力，仔细观察数据，以便发现将来可能出现的故障。在这种情况下，人们很容易自满，你可以组织头脑风暴或者推理活动，发现可能发生的各种故障事件。
本文地址：//cosda.cn//article/3493.html
