CIO值得看看：DevOps现象 - ACM权威

DevOps就是转向基于产品的管理。实际上，这意味着项目不再有“结束日期”，而团队则通过提供功能不断提供价值。实现这一目标的一个重要部分是整合价值流中的团队，从开发到运营; 一些组织甚至包括业务利益相关者。在DevOps模型中，软件是作为产品进行维护，跟踪业务持续交付和不断实现价值指标。

一家传统软件公司很少发布其旗舰产品 - 每隔几年就很少发布。每个版本都可以包含数百个新功能和改进。由于版本很少发布，因此用户可能会不耐烦地等待每个新版本，并在最终获得时时感激不尽。

但是，当发现错误并且功能无法按预期工作时，会导致失望。在巨大压力和巨大动荡的情况下，紧急发布并投入生产（常规发布过程匆匆忙忙，通常会跳过测试），产品中还有更多的错误。这样的过程重复进行，导致更多沮丧，压力和失望。更糟糕的是，由于怀疑，不确定性以及IT部门提供价值的能力的不信任，新的商业机会被遗漏或忽视。（banq注：无充分市场竞争的环境会导致甲方效率降低，组织部门被IT扼杀！）

有没有更好的方法？

对于采取DevOps软件开发和交付方法的公司来说，这种做法已成为过去。新版本经常发布：通常是每周或每天。错误很快得到修复。热情和自信地寻求新的商机。通过快速迭代发布，修改和改进新功能。一个案例表明，该公司能够每11秒提供一个新的软件功能。

您更喜欢这些软件团队中的哪一个？哪些公司将在其行业的数字化转型中获胜？

与传统的软件开发方法（通常称为 阶段门 或 瀑布 ）相比，DevOps为组织提供了战略优势，领导力在转型过程中发挥着重要作用。事实上， Gartner预测，到2020年尚未改变其团队能力的CIO将会被取代 。

数字化转型的承诺与挑战

对于希望获得市场份额并更快地交付价值（甚至只是更安全，更安全地交付软件）的组织，DevOps承诺速度和稳定性。4它已成为现代组织中数字化转型的一个突出现象，它使用软件为银行，零售甚至制造业等行业的客户创造价值。DevOps结合了软件开发和交付的活动，以提高向客户提供新软件功能的速度。这可以提高客户满意度和盈利能力，这是组织层面的重要成果。它还可以带来重要的团队级成果，例如不同部门（如开发人员，测试人员和IT运营部门）之间的更好协作以及改善的工作与生活平衡。

执行成功的DevOps转换并非没有挑战。组织和软件产品的成熟度和实施方式各不相同，因此难以跨团队和组织设计和部署转型工作。最重要的是，要让DevOps真正实现价值，它必须包括的不仅仅是 工具 和自动化 - 所以简单地购买和安装解决方案是不够的。如此处所述，DevOps包括文化，流程和技术。事实上，成功案例比比皆是：Kaiser Permanente，Capital One，Target，Starbucks和ING等公司采用了DevOps方法，允许他们在几秒钟内为关键应用程序提供软件。

DevOps增强了从应用程序到基础架构配置的自动化。持续交付支持自动化，通过快速反馈周期加快产品上市速度和敏捷软件开发。由于这种现象在实践中相对较新，从业者报告了与领导力和文化转型，实施持续交付管道以及在团队环境中整合协作文化等问题的斗争。

抛弃传统项目管理

DevOps方法的特点是软件交付的处理方式发生了变化：从一个独立的项目转变为一个持续的产品。传统的软件交付方式（以前称为 阶段门 或 瀑布 ）是在项目管理的帮助下进行的。在这个范式中，项目通常“结束”的标志是：新软件的第一个主要版本或主要增量版本发布。一般而言，项目团队在新版本发布后解散，然后运行系统的责任被“抛到墙上”甩给运维团队。运营团队负责进一步的变更和事件管理。这导致了几个问题：

•开发人员不负责运行他们构建的系统，因此不了解在创建和运行系统时是否出现权衡，尤其是软件的可扩展性和可靠性。这可能导致在未来的软件版本中出现相同的问题，即使操作团队很好地理解它们。

•运营团队负责维护高度可靠和稳定的系统。每个新的软件部署线都会引入变化，从而导致不稳定。

•生产环境（包括开发人员和业务）上游的利益相关者（即开发流程的早期阶段）在第一次完整发布之前无法收到有关性能的任何反馈。并非软件中的所有功能都能提供价值，加快对开发团队和业务的反馈可以加快迭代速度以优化软件。这会导致浪费时间和资源，而这些功能最终无法带来价值。例如，微软的研究表明，只有三分之一的精心设计的功能为客户带来了价值。

相比之下，DevOps要求转向基于产品的管理。实际上，这意味着项目不再有“结束日期”。

DevOps的最新研究与实践

行业中最大的挑战之一是缺乏DevOps的正式定义。许多从业者认为这是故意的，因为它允许团队和组织采用适合他们的定义。此外，他们指出，对敏捷的正式定义（在敏捷宣言中编码）并没有解决定义蔓延的问题，并且当一个组织说它“变得敏捷”时，由此产生的混淆真正意味着什么困扰着整个行业。这种缺乏理解可能具有挑战性，因此我们提供一些共同的定义供参考。

1. •“DevOps是一种软件开发和交付方法，可以提高速度和稳定性，同时为组织提供价值。” 
2. •“DevOps，无论是在运营工程师接受开发任务的情况下还是在开发人员在运营领域工作的情况下，都是努力使这两个学科更加接近。” 
3. •“DevOps，'开发'和'运营'的复合体，是一种专为高速度而设计的软件开发和交付方法。” 

将其结为CALMS：文化，自动化，精益，测量和共享，以下是每个组件的简要定义：

• 文化。融合相互信任，学习和持续改进的意愿，不断的信息流，对开发人员和运营之间的变革和实验的开放态度。
• 自动化。实现具有高度自动化的部署管道（最值得注意的是持续集成/持续交付）和全面的测试自动化。
• 精益。应用精益原则，例如最小化正在进行的工作，以及缩短和放大反馈回路，以识别和最小化价值流中断，从而提高效率。
• 测量。监控关键系统指标，例如业务或交易指标和其他关键绩效指标。
• 分享。在组织和跨组织边界共享知识。团队成员应该相互学习经验并积极沟通。

CALMS的解释

本文使用CALMS的五个核心元素作为框架。

1.文化

作为DevOps团队的一员，需要   在跨职能团队环境中建立协作文化。在理想状态下，DevOps使用所谓的跨职能团队，这意味着由开发人员，测试人员，质量保证专业人员和IT运营工程师组成的团队共同合作开发和交付软件。通过这种方式，他们熟悉彼此的工作和挑战（描述这一点的常用词语是“有同理心”），这有助于他们创建和维护更好的软件。例如，因为他们看到了维护运营专业人员遇到的可扩展和可靠基础架构所面临的挑战，开发人员与运营人员合作编写了更具可扩展性和可靠性的代

2.自动化

接下来的原则，   自动化 ， 需要一整套的DevOps工具。以下是可用的自动化工具的几个例子：

构建

•构建。用于软件开发和服务生命周期的工具，包括编译代码，管理依赖关系，创建文档，进行测试以及在不同阶段部署应用程序。

• 持续集成。不断测试新的软件组件。

发布

•发布自动化。将软件组件从所有环境中的开发打包并部署到生产中。

•版本控制。管理对程序的更改并收集其他信息。版本控制是配置管理的一个组件。

•测试自动化。使用软件执行测试和重复活动。

部署

• 配置管理。借助在开发阶段复制生产系统，减少生产配置和配置维护。

•持续交付。旨在实现不间断部署的原则，实践和模式的组合。

运维

•记录。跟踪对于应用程序管理至关重要; 一切都必须记录下来。

•监测。在客户注意到之前识别基础设施问题。监控存储，网络流量，内存消耗等

持续集成和交付降低了发布软件的成本和风险。他们通过将自动化和良好实践相结合，以一致，可靠和可重复的方式执行工作（例如测试和构建），从而在软件交付过程中实现快速反馈并建立质量。这有助于团队更快，更可靠地交付功能，从而为组织实现更快的价值交付。性能最高的团队能够比低绩效团队更频繁地部署46倍，交付时间缩短2,555倍。故障率降低了7倍，并且能够比性能较低的同行快恢复2,604倍。

精益

“构建质量” 是DevOps的一个关键原则，也是 精益中的 一个原则。应用于DevOps，这意味着团队寻找机会去除浪费，利用反馈循环并优化自动化。

我们来看一个例子。DevOps团队的规模和产品责任各不相同。在某些模型中，单个团队执行所有软件开发和交付活动，包括开发，测试，交付和维护。他们最终负责软件产品的完整软件交付生命周期（并且可能负责多个产品），为业务带来价值。精益流程允许在整个开发和交付过程中快速迭代和反馈，以提高质量并构建更快，更可靠的系统。示例包括小批量工作以实现快速流过开发流程，限制正在进行的工作，修复发现时与最后发生的错误，并在安全输入上“向左移动”。

这些做法听起来很熟悉; 类似的做法推动了制造业的质量和价值。（有关精益制造一个伟大的故事，看看这个美国生活的插曲561 11，其中讨论了NUMMI（新联合汽车制造股份有限公司），在Fremont，CA丰田和通用的合资公司）

测量

测量是DevOps的另一个核心方面。监控和观察系统的能力很重要，因为软件开发和交付基本上处理的是无形的库存，这些库存以无法观察到的复杂方式进行交互。（这与NUMMI案例中描述的传统物理制造系统（如汽车装配线）形成鲜明对比。）

通过有效的监控，团队能够在整个软件交付生命周期中跟踪，观察，测量和调试他们的系统。应该注意的是，度量标准也是质量保证的工具，应该利用来自多个来源的测量。

分享

知识和信息的共享使DevOps团队成功，并有助于扩大他们的成功。通过在团队内，整个组织内以及整个行业内共享实践 - 包括成功和失败 - ，团队从其他人的学习中受益，并更快地提高。虽然其他人已经指出可以在任何领域和任何方法中进行共享，但DevOps已将此作为一种文化规范，并且许多业内人士报告说，该领域比以前的技术工作更具协作性。

内部协作可能包括工作阴影或工作交换：开发人员参与操作和维护活动（例如，开发人员甚至可能“接收寻呼机”）， 运维工程师轮流进入开发和测试角色，学习设计和测试的基本组件工作 。在许多情况下，所有跨职能团队成员都参加同一会议，这为他们提供了共享的背景。跨行业共享经常在会议上进行，数十个DevOpsDays和其他社区组织的活动在世界各地蓬勃发展。

这些原则的应用可以带来更好的结果：对于个人（在减少职业倦怠和更高的工作满意度方面），对于团队（在更好的软件交付结果和更好的团队文化中看到）和组织（从改善绩效等方面看到的组织）盈利能力，生产力，客户满意度和效率.