搜文章
推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > 51CTO技术栈 > 兵败DevOps!一个Bug损失4.6亿美金,不得不看的惨痛教训!

兵败DevOps!一个Bug损失4.6亿美金,不得不看的惨痛教训!

51CTO技术栈 2018-07-01

缺乏最佳实践的 DevOps,会给你的企业带来缓慢的发布周期,甚至是灾难性的错误。本文向你介绍一些能够充分使用 DevOps 的小技巧。


本文会分享一些有趣的 DevOps 原则,并通过应用展示它们给高效的项目交付与转化所带来的好处。


这里所提及的概念都源于 John Willis,他有着丰富的 IT 管理经验,同时也是 DevOps 运动的最初倡导者。


当一个组织考虑去实践 DevOps 的时候,他们需要掌握一些相关术语和实用方法。


本文会谈及如下几个方面:

  • 骑士资本的故事

  • DevOps 的术语

  • 价值流(value stream)/交付(lead) 时间/周期时间(CycleTime)

  • 高绩效组织与低绩效组织

  • 对精益模型的学习

  • 持续交付模型

  • DevOps 的实践


骑士资本的故事


在开始讨论 DevOps 的最佳实践之前,让我们先来看看 IT 流程和技术的失败是如何导致企业的各种业务问题与损失的。


为了深入理解这一点,我们会引入一个发生在 2012 年的骑士资本的失败案例。

兵败DevOps!一个Bug损失4.6亿美金,不得不看的惨痛教训!

骑士资本集团曾是一家美国本土的全球金融服务公司,它的业务涉及到开拓市场、电子交易、机构销售和交易。


2012 年 8 月 1 日,骑士资本在系统的生产环境中部署了带有倒退功能、且未经测试的软件。


该事故的发生是由于技术人员忘记将新的零售流动性计划(Retail Liquidity Program,RLP)代码拷贝到八台 SMARS 服务器中的一台之上,而这台服务器正是骑士用于处理股权订单的自动路由系统之一。 


当代码被发布到生产环境中以后,导致了 154 只股票的 4 百万宗交易,在大约 45 分钟内有超过 3.97 亿的换手,造成直接损失 4.4 亿美元。


骑士资本的这一异常交易行为被定性地描述为“技术故障。”这充分地表明了:将带有 Bug 的软件部署到生产环境中所能够造成的严重程度。


反观此事,如果他们当时遵循了 DevOps 的基本原则,该事故是完全可以避免的,而且无用功也会降低许多。


这里的无用功意味着他们完全可以使用自动化的部署,来取代引发人为错误的手动部署。接下来我们看看 DevOps 的各种实践。


DevOps 的术语


Chef 的创始人 Adam Jacob 将 DevOps 定义为一种文化和专业的运动。


通常,影响一个项目的三个因素分别是速度(时间)、可靠性和成本。开发需要有按时交付的速度,而运营需要有可靠性。DevOps 可以保证以低成本的方式实现速度和可靠性。


DevOps 会涉及到各种模式,包括:持续改进、组织文化、学习曲线、持续交付、持续学习、持续协作和自动化。


与 DevOps 相关的术语有:

  • 价值流,它指一个组织针对客户的需求所执行的各项交付活动的顺序。也就是指你如何把一个想法最终变现的过程。

  • 交付时间,它指价值流从开始到结束,全程转化的耗时。一般情况下,交付时间是指呈现到客户眼前所花费的时间。

  • 周期时间,始于按照需求所开展的工作,终于准备好交付项目的时候。

  • 交付时间的掌控能力,意味着我们对 DevOps 的运用水平。

  • 部署交付时间,反映了我们在自动化方面的水平。


由此可见,组织应遵循 DevOps 的模式和实践方式,以减少交付的时间。他们完全可以从中选取诸如:放大反馈或加强持续学习文化等一个或多个适合自身的 DevOps 方法。


高绩效组织与低绩效的区别


在 2016 年的 DevOps 状况报告中,有着关于如何区分出高绩效与低绩效的组织研究。


该研究指出:高绩效的组织更接近于 DevOps 的文化,而低绩效的组织则不太适合。


以下是从那些高绩效组织中所观察到的 DevOps 文化和实践:

  • 更高的员工参与程度。

  • 内部质量方面的建设。

  • 遵从精益产品的管理原则:注重客户反馈意见的收集、传播与实施;分解整体工作成各个小的部分,并使交付流程的工作流可视化。

  • 在计划外的工作和返工上花费的时间最少。


总结起来,他们具有如下的实践和文化:

  • 更高的部署频率

  • 更短的变更交付时间

  • 更短的平均恢复时间(Mean Time To Recover,MTTR)

  • 更少的变更故障率


下面是有关此类高绩效组织的详情:

  • 范例:亚马逊、谷歌、Facebook、Etsy 和 Netflix。

  • 在 2015 年,谷歌已经表示:他们每天会提交 5000 行代码,75 万次用例测试;亚马逊,每天会进行 13.6 万行代码的部署,平均每年 1500 万行;Netflix,每天部署 500 行代码;Etsy 则每天数百行以上。

  • 相对于低绩效的组织来说,他们的部署频率多了 200 倍以上、交付时间快了 2555 倍、恢复时间快 24 倍,而故障率则只有三层以下。

  • 他们往往有更多的合作、培训、风险信息分享、并且更鼓励沟通,同时他们面对各种故障也有着健康的心态。


而对于低绩效的组织来说:

  • 此类组织只能努力实现一年两次以上的部署,并只有一种瀑布式的部署模型。

  • 他们的执行力缓慢、且不太可靠。在合作方面,他们的水平较低,沟通并不顺畅,对失败常会产生消极和畏难情绪,且不愿意尝试新鲜的事物。


对精益模型的学习


与精益模型有关的术语包括:无用功、资源流和压力。


无用功:通过对精益模式的学习能够消除无用功。这里的无用功是指对于实现交付时间毫无用处的、不必要的步骤。就 DevOps 而言,我们应该多采用一些自动化来完成工作。


资源流:资源流就是在开发成品时所用到的资源的平衡。我们必须保持它们的一致性,而且坚持全局优化会优于局部优化的理念。


压力:在我们减少无用功和平衡资源流时,其实就是在给系统减少压力。这是一种系统的思维:在我们观察资源流的全局性能时,应确保各路资源能尽快地流向最终的产品。


改善(Kaizen):这是一个有关持续改进的日语词汇。我们以丰田生产系统为例,它能够通过优化资源流,来消除无用功,并通过持续改进来减少对系统的压力。


规程(Kata):通过对规程的执行,公司里的各个角色员工能够以系统性的方法开展工作。而且通过可重复的方式,学习者可以用非常自然的、自发的方式,来提高技术和执行能力。


DevOps 中的精益模型影响,旨在消除任何可能出现的无用功,从而实现对资源流的优化与平衡。


此外,通过减少压力,以确保各路资源能够尽快地流向最终的产品。因此我们需要持续改进,并且通过遵循规程,以自然、自发的方式,来提高技术和执行能力。


持续交付模型


DevOps 的一个重要部分就是持续交付模型,也被称为 CI/CD - 持续集成/持续交付。


它们的基本原则就是要内置到质量保障之中,这可用通过在软件上建立全方位的测试来实现。


高绩效的组织一般会做非常严谨的测试,他们会认真地对待各种流程中的功能性代码、集成测试、冒烟测试(smoke test),并且贯穿到他们最终的软件交付阶段。


DevOps 的实践


从较高层次上说,有三种方法可用来实现 DevOps,你可以从中挑选出一到两个最适合本企业的方法进行尝试:

  • 缩短交付周期

  • 放大反馈

  • 持续学习


第一种是从左(始)到右(终)的方式为了能够在较高的层次上实现对交付周期的缩短,我们需要有一个面向客户与交付的、整体交付时间的规划。


该方法的实现方式有:

  • 使工作可见化,如使用看板(译者注:Kanban board 是在看板系统中用塑料或纸制成薄板,将产品名称及数量写于其上,故此得名)。

  • 切分成小批量的处理工作。

  • 自动化可重复的任务。

  • 运用精益软件的原则,消除无用功,减少各种瓶颈。

  • 设置对正在进行中的工作的各种约束。


第二种是从右(终)到左(始)的方式,或称为放大反馈。我们使用多种工具来进行监控。


一般情况下,通过赋能各种获取反馈的能力,我们就能够在流程中更早地发现各种缺陷、或是无用功。


该方法的实现方式有:

  • 遥测法。

  • 故障注入。

  • 同等评审,所有的变更都被同等地进行评审。

  • 监控各种提交日志。


相对于第一种的从左(始)到右(终)、和第二种的从右(终)到左(始)来说,第三种方法是一个闭环我们通过使用上述提到的改善和规程来进行持续的学习。


各个组织对它的具体实现方式有:

  • 持续学习。

  • 沟通反馈。

  • 以目标为导向的反馈。

  • 学习的目标应可信、且能不断改进。

  • 反馈不应针对个人,应当针对的是交付过程中的行为,且必须是可行的。

  • 反馈方法,在低信任度的环境中使用海豚式反馈,在中信任度的环境中使用三明治式反馈,以及在高信任度的环境中使用基层人员式反馈。

  • 无抱怨式的企业文化。


结论


从骑士资本的故事中,我们已经能够看到:严重的软件问题能够引起多么大的灾难。


根据 DevOps 的状况报告,DevOps 的文化和实践不但能够让企业受益,还能够让他们在成本节省和价值上提高投资回报率:

  • 成本节省,包括宕机的成本和过剩的重复劳动上的成本。

  • 价值,包括从更快速的发布中,所收获的潜在收入与更多的客户。


我们希望通过本文的分析和引导,你的组织可以更好地领悟 DevOps 的实施潜力,并能创造出更多的价值。


原文标题:Best Practices of DevOps for Effective Project Delivery

编辑:陶家龙、孙淑娟

投稿:有投稿、寻求报道意向技术人请联络 editor@51cto.com


陈峻(Julian Chen) ,有着十多年的 IT 项目、企业运维和风险管控的从业经验,日常工作深入系统安全各个环节。作为 CISSP 证书持有者,他在各专业杂志上发表了《IT运维的“六脉神剑”》、《律师事务所IT服务管理》 和《股票交易网络系统中的安全设计》等论文。他还持续分享并更新《廉环话》系列博文和各种外文技术翻译,曾被(ISC)2 评为第九届亚太区信息安全领袖成就表彰计划的“信息安全践行者”和 Future-S 中国 IT 治理和管理的 2015 年度践行人物。

精彩文章推荐:




版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《兵败DevOps!一个Bug损失4.6亿美金,不得不看的惨痛教训!》的版权归原作者「51CTO技术栈」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注51CTO技术栈微信公众号

51CTO技术栈微信公众号:blog51cto

51CTO技术栈

手机扫描上方二维码即可关注51CTO技术栈微信公众号

51CTO技术栈最新文章

精品公众号随机推荐