【.com原稿】DevOps缺乏最佳实践会给你的业务带来缓慢的发布周期,甚至是灾难性的错误。本文向您介绍一些技巧,以充分利用DevOps。本文将分享一些有趣的DevOps原则,并展示它们在通过应用程序进行高效项目交付和转型方面的优势。这里提到的概念都来源于JohnWillis,他拥有丰富的IT管理经验,也是DevOps运动的最初倡导者。当组织考虑实践DevOps时,他们需要掌握一些相关术语和实践方法。本文将从以下几个方面来谈:KnightCapital的故事DevOps的术语价值流(valuestream)/交付(lead)时间/周期时间(CycleTime)高绩效组织和低绩效组织了解精益模型持续交付模型DevOps骑士资本的实践故事在开始讨论DevOps的最佳实践之前,我们先来看看IT流程和技术的失败是如何导致各种业务问题和企业损失的。为了深入理解这一点,我们将介绍一个发生在2012年的KnightCapital的失败案例。KnightCapital集团曾是一家总部位于美国的全球金融服务公司,业务涉及市场开发、电子交易、机构销售和交易。2012年8月1日,骑士资本在系统生产环境部署了未经测试的具有回归功能的软件。事件发生时,技术人员忘记将新的零售流动性计划(RLP)代码复制到Knights用来处理股票订单的八台SMARS服务器之一。自动路由系统之一。当代码发布到生产环境时,它导致154只股票进行了400万笔交易,在大约45分钟内有超过3.97亿笔易手,直接造成4.4亿美元的损失。骑士资本的这种异常交易行为被定性地描述为“技术故障”。这充分说明了将有缺陷的软件部署到生产环境中可能造成的严重性。回过头来看这件事情??,如果他们当时遵循DevOps的基本原则,完全可以避免事故的发生,无用功也会减少很多。这里无用的努力意味着他们可以使用自动化部署,而不是导致人为错误的手动部署。接下来我们看看DevOps的各种实践。DevOps术语Chef创始人AdamJacob将DevOps定义为一种文化和专业运动。通常,影响项目的三个因素是速度(时间)、可靠性和成本。开发需要速度以按时交付,运营需要可靠性。DevOps可以以低成本保证速度和可靠性。DevOps涉及各种模式,包括:持续改进、组织文化、学习曲线、持续交付、持续学习、持续协作和自动化。与DevOps相关的术语有:价值流,指的是组织为响应客户需求而执行的一系列交付活动。也就是说,你最终如何实现一个想法的过程。交付时间,指的是价值流从开始到结束的耗时转换。通常,交货时间是指商品出现在客户面前所需的时间。周期时间,从按要求执行工作到最终准备好交付项目时开始。能够控制交付时间,意味着我们对DevOps的应用程度。部署提前期反映了我们的自动化水平。可以看出,组织应该遵循DevOps模式和实践来减少交付时间。他们可以选择一种或多种适合自己的DevOps方法,例如放大反馈或增强持续学习文化。高绩效组织和低绩效组织之间的区别在2016年DevOps状态报告中,有关于如何区分高绩效组织和低绩效组织的研究。该研究表明,高绩效组织更接近DevOps文化,而低绩效组织则不然。以下是在高绩效组织中观察到的一些DevOps文化和实践:更高的员工敬业度。内部质量方面的建设。遵循精益产品的管理原则:注重客户反馈的收集、传播和执行;将整体工作分解成小部分,可视化交付过程的工作流程。花在计划外工作和返工上的时间最少。总结起来,他们有以下实践和文化:更高的部署频率更短的变更交付时间更短的平均恢复时间(MeanTimeToRecover,MTTR)更少的变更失败率以下是关于此类高绩效组织的详细信息:示例:亚马逊、谷歌、Facebook、Etsy和Netflix。2015年,Google表示他们每天提交5,000行代码和750,000个用例测试;亚马逊每天部署136,000行代码,平均每年1500万行;Netflix每天部署500行代码;Etsy每天超过数百行。与低绩效组织相比,他们的部署频率高出200多倍,交付速度快2555倍,恢复速度快24倍,所有故障率都在三层以下。他们往往有更多的合作、培训、风险信息共享和更鼓励的沟通,他们也对各种失败抱有健康的态度。而对于低绩效的组织:这些组织一年只能争取实现2次以上的部署,只有瀑布式部署模型。他们的执行缓慢且不可靠。在合作方面,他们层次低,沟通不顺畅,常有消极情绪,害怕失败,不愿尝试新事物。了解精益模型与精益模型相关的术语包括:无用功、资源流和压力。无用的工作:通过学习精益模型可以消除无用的工作。这里的死工作指的是对达到交货时间没有用的不必要的步骤。就DevOps而言,我们应该使用更多的自动化来完成工作。资源流:资源流是用于开发成品的资源平衡。我们必须使它们保持一致,并坚持全局优化优于局部优化的理念。压力:当我们减少无用功,平衡资源流时,实际上是在减轻系统的压力。这是一种系统思维:我们在观察资源流的整体表现时,应该保证所有的资源能够尽快流向最终的产品。Kaizen:这是持续改进的日语词。让我们以丰田生产方式为例。它可以通过优化资源流动来消除无用的工作,并通过持续改进来减轻系统的压力。程序(Kata):通过程序的执行,公司各个角色的员工都可以有系统地工作。通过可重复性,学习者可以非常自然和自发地提高技术和执行技能。DevOps中的精益模型影响旨在消除任何可能出现的浪费,从而实现资源流的优化和平衡。此外,通过降低压力来确保所有资源能够尽快流向最终产品。因此,我们需要按照程序自然自发地不断提高和提高技术和执行能力。持续交付模型DevOps的一个重要部分是持续交付模型,也称为CI/CD-持续集成/持续交付。他们的基本原则是建立质量保证,这可以通过对软件进行全面测试来实现。高性能组织通常会进行非常严格的测试。他们会认真对待各个流程中的功能代码、集成测试、冒烟测试(smoketesting),并贯穿到他们最终的软件交付阶段。DevOps的实践在高层次上,DevOps有三种方法,您可以从中选择一种或两种最适合您的企业尝试的方法:缩短交付周期放大反馈持续学习最后一种是左起(开始)到正确的(结束)方式。为了能够在更高层次上缩短交货周期,我们需要有一个以客户为导向,以交货为导向,整体的交货时间计划。这可以通过以下方式完成:使工作可见,例如使用看板。将处理作业分成小批次。自动执行可重复的任务。使用精益软件的原则来消除无用的工作并减少各种瓶颈。对正在进行的工作设置各种限制。第二种是从右(结束)到左(开始)的方式,或者放大反馈。我们使用各种工具进行监控。一般来说,通过赋能各种能力获取反馈,我们可以在流程的早期发现各种缺陷或无用的工作。此方法通过以下方式实现:遥测。故障注入。同行评审,所有的变化都被平等地审查。监控各种提交日志。与第一种方法从左(开始)到右(结束)、第二种方法从右(结束)到左(开始)相比,第三种方法是一个闭环。我们通过使用上述改进和程序继续学习。各组织的具体实施方式如下:持续学习。沟通反馈。以目标为导向的反馈。学习目标应该是可信的,并允许持续改进。反馈不应该是个人的,它应该是交付过程中的行为并且必须是可操作的。反馈方式,在低信任环境下使用海豚式反馈,在中等信任环境下使用三明治反馈,在高信任环境下使用基层反馈。无投诉的企业文化。结论从KnightCapital的故事中,我们已经能够看到一个严重的软件问题是多么具有灾难性。根据StateofDevOps报告,DevOps文化和实践不仅可以让企业受益,还可以让他们在成本节约和价值方面提高ROI:成本节约,包括停机成本和重复劳动的成本。价值,包括潜在收入和更快发布带来的更多客户。我们希望通过本文的分析和指导,您的组织可以更好地了解DevOps的实施潜力并创造更多价值。JulianChen在IT项目、企业运维、风险管控等领域拥有十余年经验,日常工作深入系统安全的各个环节。作为CISSP证书持有者,他在各种专业期刊上发表了《IT运维的“六脉神剑”》、《律师事务所IT服务管理》和?的论文。他也持续分享和更新《廉环话》系列博文和各种外文技术翻译。曾被评为“信息安全实践者”、Future-S2015中国IT治理与管理实践者。【原创稿件,合作网站转载请注明原作者和出处为.com】
