接头失败并从中汲取经验

行使每回次失败来进修，汲取首要的经验。采用过后阐明要领，在故障较少的环境中猜测故障。应用理由:咱们从失败中才气获得最深入的经验，而不是从胜利中。不要让任何失败挥霍掉。从每次失败中进修，发现需求改过的手艺、职员和流程上的问题。
在聚首中，每当谈到世界大事时，咱们中的许多人均能够会说“咱们如同从未汲取汗青上的经验”。但又有几个人能真正在事情中对咱们本身、咱们缔造的东咱们的团队执行这个标准呢?在这个具有高可用性和高可扩展性的手艺平台上，存在一个乏味的悖论，即最初构建的零碎最好，不常发生故障，因而让团队进修的时机未几。这个悖论的内涵寄义就是，流程、零碎某职员定负载的前提下测试剧本，确保在应用程序运用数据库时，它依然能够执行。
口对应用中的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一切大中字的机公。若是你的条统设计得很好，即使超负荷作，也不常出故障，那末可以实践一下预警威力，细心察看数据，以便发现未来能够泛起的故障。在这类情况下，人们很容易自满，你可以组织脑筋风暴或者推理勾当，发现能够发生的各类故障事宜。