持续学习DevOps与实验的技术实践
我们一起讨论DevOps在价值流里建立快速工作流所需的技术实践。我们的目标是从工作系统里尽可能多的领域中建立尽可能多的反馈，并且更及时、更迅速、更廉价。会展示一些能尽量快速、频繁、经济地创造更多学习机会实践。这包括从事故和故障中学习，因为当我们在复杂的系统中工作时，故障死不可避免的；还包括组织和设计工作系统，使我们能不断地尝试和学习，让系统更加安全。期望达到的成果包括获得更高的弹性，以及系统实际工作机制的日益丰富的集体知识，从而能让我们更好地实现目标。
在复杂的系统中工作时,我们不可能预测到所有可能的结果。即使使用了静态预防性工具如核对表和标准化操作手册等,可还是会有意外发生,有时候甚至是灾难性的事故。这些工具只是记录了我们当前对系统的理解。
为了在复杂系统中安全地工作,组织一定要能够进行更好的自我诊断和自我改进,而且必须熟练地发现和解决问题,并通过在整个组织中传播解决方案来扩大效果。这种方式会创造出一个动态的学习系统,让我们理解错误,并将理解转化为防止这些错误复发的行动。
这就像 Steven Spear博士所说的“可恢复型组织”,能够“熟练地发现问题,解决问题,并通过在整个组织中提供解决方案来扩大经验的效果”。这些组织具有自我愈合的能力。“对于这样的组织,应对危机并不是什么特殊的工作,而是每时每刻都在做的事情。这种响应能力是可靠性的源泉。”
2011年4月21日,当亚马逊AWS整个美国东部( US East)可用性区域宕机时,我们看到了这些原则和实践产生了难以置信的恢复力。在这个区域中,几乎所有依赖AWS的用户都受到了影响,包括Reddit和 Quora。然而, Netflix却是一个惊人的例外,似乎并没有受到这次AwS大规模服务中断的影响。
在这次事件之后,有很多关于Neflix如何维持服务可用性的猜测。一个流行的说法是,因Neflix是AWS的顶级用户,所以得到了某些保证服务的特殊待遇。然而,一个名为“ Neflix工程”的博客发文解释说,正是他们在2009年的架构设计决策,为这种超常的恢复力奠定了基础。
早在2008年,Neflix的在线视频交付服务还运行在一个单体的J2EE应用程序上,这个应用程序托管在一个数据中心。然而,从2009年起,他们就开始了系统的重构,结果就是所谓的云原生( cloud native)—系统完全运行在亚马逊AWS公有云中,而且具备足够的可恢复性,能够幸免于难。
他们有一个特别的设计目标,那就即使AWS的整个可用区城都发生了故障,就像这次美
东部区的事故,也要确保 Netflix的服务能够持续运行。要达到这一点就需要系统架构是松稠,N每个功能和组件都设计为具有完全降级的能力,例组,当流量剧增造成了CPU使用率暴涨的时候,就不向用户显示个性化的电影推荐列表,而是只显示已经缓存的静态内容,从而减少计算资源的需求。
此外,这篇博客文章还解释,除了实施这些架构模式构建并运行了一个令人吃惊的大胆服务,称为“捣乱猴”( Chaos Monkey)它会不断地随机删除生产服务器,来模拟AWS环境故障。他们这样做是希望所有的“工程团队习惯于在常规的故障水平上工作”,使得服务能够
在没有任何人工干预的情况下,自动恢复正常”。
换句话说,Nenx团队通过运行“捣乱猴”不断地将故障注入到预生产和生产环境中,从面实现了运维上的恢复性目标。
可以想见,当他们在生产环境中首次运行“捣乱猴”的时候,服务发生的故障超出了想象。
通过在正常工作时间里不断地探测和解决这些问题, Netflix的工程师们很快反复打磨出这项弹性十足的服务,同时创造出了组织学习成果(在正常工作时间里!),从而能够开发出超越所有竞争对手的系统。
“捣乱猴”只是将学习融入日常工作中的一个例子。这个故事还展示了学习型组织是如何思考故障、事故和错误的—将其视为学习的机遇,而不是惩罚的机会。本章探讨如何创建学习系统,如何建立公正文化,以及如何通过定期演练和人为模拟故障的方式加速学习。
建立公正和学习的文化
学习型文化的先决条件之一是,当发生事故时(这是毫无疑问的).对待它的反应要“公正
Sidney Dekker博士整理了一些有关安全文化方面的关键要素,并且使用了公正文化这个术语。他写道:“如果对待事件和事故的反应被认为是不公正的,就可能阻碍安全调查,从而在从事安全关键性工作的人员中引发恐惧而非正念,使组织更加官僚面不是更加小心谨镇,并且诱发职业性保密、逃避和自我保护。”
在整个20世纪里,这种惩罚的观念一直出现在很多经理人采用的运营方式中,或微妙、或明显。这种思想是,为了实现组织的目标,领导者必须通过命令、控制和建立流程的方式来消除错误,并且强制遵守这些流程。
Sidney Dekker博土将这种通过消除肇事者而消除错误的观念叫作坏苹果理论。他断言这是的,因为“人为错误并不是问题的原因;恰恰相反,人为错误是我们提供的工具存在设计间造成的后果”。
如果事故并不是“坏苹果”引起的，而是由于我们所建立的复杂系统中存在着不可避免的设计问题而导致的，那么久不应该对造成故障的人进行“点名、责备和羞辱”。我们的目标应该总是最大限度地抓住组织学习的机会，持续强调我们重视广泛地揭示和交流日常工作中的问题。这样才能提高我们所在系统的质量和安全性,并强化系统内所有人之间的关系。
通过将信息转化为知识,并将学习到的结果构建到系统中,我们就开始实现公正文化的目标了,同时平衡了安全和问责的需求。正如Etsy首席技术官 John Allspaw所说:“我们在Etsy的目标是从学习的角度看待错误、报错、失误、过失等。”
当工程师犯错误时,如果可以有安全感地给出详细信息,那么他们不仅愿意对事情负责,而且会热情地帮助其他人避免同样的错误发生。这就创造了组织学习。与之相反,如果惩罚那个工程师,每个人都没有了提供必要细节的积极性,想了解故障的机制、原理和操作就无从谈起了那么这个故障肯定还会再次发生。
有两个有效的实践有助于创造公正的学习型文化:一是不指责的事后分析;二是在生产环境中引入受控的人为故障,用于创造机会针对复杂系统中不可避免的问题进行练习。下面首先看看不指责的事后分析,并探索为什么失败可以是一件好事。
DevOps咨询热线
深圳青蓝咨询服务有限公司
电 话：0755-86950769
官 网：www.shzhchina.com
邮 箱：peixun@shzhchina. com
地 址： 深圳市南山区高新南一道06号TCL大厦B座3楼309室
深圳地铁1号线高新园站C出口