【.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】
