RELATEED CONSULTING
相关咨询
选择下列产品马上在线沟通
服务时间:9:30-18:00
你可能遇到了下面的问题
关闭右侧工具栏

技术支持

讨论失败并从中吸取教训
  • 作者:技术小林
  • 发表时间:2018-07-21 15:30
  • 来源:未知

  利用每一次失败来学习,吸取重要的教训。采用事后分析方法,在故障较少的环境中推测故障。应用理由:我们从失败中才能获得最深刻的教训,而不是从成功中。不要让任何失败浪费掉。从每次失败中学习,发现需要改正的技术、人员和流程上的问题。

  在聚会中,每当谈到世界大事时,我们中的许多人都可能会说“我们好像从未吸取历史上的教训”。但又有几个人能真正在工作中对我们自己、我们创造的东西和我们的团队执行这个标准呢?在这个具有高可用性和高可扩展性的技术平台上,存在一个有趣的悖论,即最初构建的系统最好,不常发生故障,因此让团队学习的机会不多。这个悖论的内在含义就是,流程、系统或人员定负载的条件下测试脚本,确保在应用程序使用数据库时,它仍然能够执行。

  口数据的语义修改。在发布版本中,开发团队不能修改数据的定义。举个例子。票务表中的一列用于存放状态信号,其中有三个值assigned、fixed和closed。在应用的新版本中,如果没有发布处理新状态的代码,就不能添加第四个状态。

  口WireOn/ireOff』。应该让应用结构化,使其能根据外部配置,让有些用户能够访问某个代码路径和功能,而有的用户则不能访问。这种设置可以存放在配置文件中,也可以存放在数据库表中既能够根据角色赋予访问权限,也能够根据随机百分比分配权限。有了这种结构,就能够让有限的用户对新功能进行beta测试,而且能够迅速地删除主要bug的代码路径,从而不必回退整个代码。我们得到的教训虽然惨痛,但是很有价值,有了这次教训,我们再也不会发布不能回退的代码了。即使以后和其他团队一起工作,我们也会这样要求自己的。可见,这些原则并不复杂,而是相当简单,仟何团队都能够应用它们,都能具备回退的能力。方面的每一次失败都给我们提供了执行事后分析的机会,从而让我们能够有所长进并修改系统。若不能把握好这些宝贵的机会来提高自身水平、改进流程并改善技术,我们就不能像今天这样正常运转下去,从而导致又一次失败。如果这种情况发生在超高速友虔而要积被进付抄的冏业现,那一足公惨遭经當失败。当我们在快速发展时,会发生太多事情,两年甚至一年前设计的解决方案是无法支持相当于构建系统时10倍的业务量的。

  核电时代我们可以更深入地了解为什么要从失败中吸取教训。1979年,三里岛核电站第2组反应堆的部分熔毁,成为美国历史上最重大的核电事故。这一事故为多本书和至少一部电影提供了素材,还产生了两个重要理论,涉及的是在很少发生事故但一旦发生代价很高的环境中学习的必要性。

  CharlesPerrow提出了正常事故理论。该理论推断,现代耦合的系统的内在复杂性使得事故不可避免。这些系统的内在耦合性会使交互急剧升级,致使人或控制系统根本没有机会进行成功的交互。回想一下,你是不是经常遇到这种情况,正在监控的解决方案突然从“绿色”全部变成了“红色”,而在此之前,你甚至来不及对第一个警告信息作出反应ToddLaporte提出了高可靠性组织的理论。他相信,即使没有发生能够让一个组织学习的事故,也会有一些组织策略能够实现高可靠性。2)虽然这些理论的作者没有就这些理论是否能共存达成共识,他们还是有一些共同点的。首先,失败过的组织有更多的机会学习,通常比没有失败过的组织发展得更快,当然,这里假设他们会利用这些机会从中学习其次,和前者相似,很少出故障的系统提供的学习机会少,如果没有其他的方法,那么相关的团队和系统就难以发展和提高。

  讨论完从失败中吸取教训从而获得提高这个主题后,我们简单介绍一个轻量级的流程,通过这个流程我们可以学习和提高。对于经历过的每个重大问题,我们认为相关组织都应该对这些问题进行事后分析,可用如下三个阶段来解决问题。

  口阶段2,发现问题。该流程的主持者会与相关的团队一起工作,按照时间轴逐一检查,发现其中的问题。第一个监控器在早晨8点发现了客户故障,但是直到中午都没有人对其进行响应,这样可以接受吗?为什么数据库没有进行自动故障恢复?为什么我们认为删除用户授权表会使应用重新开始运行?从时间轴中发现每一个问题,但是在问题识别阶段结束之前,不能执行任何修改或其他操作。当然,团队成员要提出建议执行的操作,但让团队在阶段2专注于问题识别是该流程的主持者的责任