实践研究
PDFDevOps 现象
高管速成课程
Anna Wiedemann, Nicole Forsgren, Manuel Wiesche, Heiko Gewald 和 Helmut Krcmar
一家传统的软件公司不经常发布其旗舰产品——最少可能几年一次。每次发布可能包含数百个新功能和改进。由于发布不频繁，用户可能会不耐烦地等待每次新发布，并在最终发布时心怀感激。
然而，当发现错误并且功能未按预期工作时，失望感便会油然而生。在巨大的压力和动荡下，会紧急发布一个版本并投入生产（匆忙完成常规发布流程，通常通过跳过测试来实现），但这仍然存在更多错误，并且该过程会随着更多的紧急发布而重复，从而导致更多的挫败感、压力和失望。更糟糕的是，由于对 IT 部门交付价值的能力的怀疑、不确定性和不信任，新的商业机会被错过或忽视。
难道没有更好的方法吗？
对于采用 DevOps 软件开发和交付方法的公司来说，这种做法已经成为过去。新版本发布频繁：通常每周或每天。错误得到快速修复。新的商业机会以极大的热情和信心去寻求。新功能通过快速迭代进行发布、修订和改进。在一个案例研究中，一家公司能够每 11 秒提供一项新的软件功能。17
您更愿意成为哪支软件团队？在行业的数字化转型过程中，哪家公司会胜出？
与传统的软件开发方法（通常称为阶段关口或瀑布）相比，DevOps 为组织带来了战略优势。7 领导力在该转型过程中起着重要作用。事实上，Gartner 预测，到 2020 年，尚未转变团队能力的 CIO 将被取代。9
数字化转型的承诺与挑战
对于希望抢占市场份额并更快地交付价值（甚至只是更安全可靠地交付软件）的组织而言，DevOps 承诺速度和稳定性兼得。4 它已发展成为现代组织中数字化转型的一个突出现象，这些组织使用软件向包括银行、零售甚至制造业在内的行业的客户交付价值。DevOps 结合了软件开发和交付活动，以提高将新软件功能交付给客户的速度。这带来了更高的客户满意度和盈利能力，这些都是组织层面的重要成果。它还带来了重要的团队层面成果，例如不同部门（如开发人员、测试人员和 IT 运营部门）之间更好的协作以及改进的工作与生活平衡。
成功执行 DevOps 转型并非没有挑战。组织和软件产品的成熟度和实施情况各不相同，使得跨团队和组织设计和部署转型工作变得困难。最重要的是，为了使 DevOps 真正交付价值，它必须包含的不仅仅是工具和自动化——因此仅仅购买和安装解决方案是不够的。正如本文所述，DevOps 包括文化、流程和技术。事实上，成功案例比比皆是：Kaiser Permanente、Capital One、Target、Starbucks 和 ING 等公司都采用了 DevOps 方法，使他们能够在短短几秒钟内为关键应用程序交付软件。
DevOps 增强了从应用程序到基础设施配置的自动化。持续交付支持自动化，并通过快速反馈循环实现更快的上市时间和敏捷软件开发。由于这种现象在实践中相对较新，从业者报告在领导力和文化转型、实施持续交付管道以及在团队环境中整合协作文化等方面存在困难。8 这些领域中的每一个都将受益于正式研究的检查和指导，以测试和增强行业从业人员的宝贵经验。
摆脱传统的项目管理
DevOps 方法论的标志是软件交付处理方式的转变：从离散的项目转变为持续的产品。传统的软件交付方式（之前称为阶段关口或瀑布）是在项目管理的帮助下进行的。在这种模式中，项目通常在新软件的首次重大发布或在一系列重大增量发布中交付的一组新功能后“结束”。通常，项目团队在新版本发布后解散，运行系统的责任随后“甩锅”给运营部门。运营团队接管后续变更和事件管理的责任。这导致了几个问题
• 开发人员不对他们构建的系统的运行负责，因此不了解在创建和运行系统时是否会出现权衡，尤其是在软件的可扩展性和可靠性方面。即使运营团队很好地理解了这些问题，也可能导致相同的问题在未来的软件版本中永久存在。
• 运营团队负责维护高度可靠和稳定的系统。每个新的软件部署行都会引入变更，因此会导致不稳定。这导致了激励机制的不匹配，即接受来自开发人员的新软件会引入风险（不稳定）和不确定性（因为对开发过程的可见性较少或没有，使他们对他们继承的软件知之甚少）。即使新组件质量很高，所有新代码都会增加系统的复杂性和风险，即软件的开发可能没有考虑到可扩展性和可靠性——运营部门必须在新软件以及现有软件中解决和支持的关键因素。
• 来自生产环境的上游（即开发过程的早期阶段）的利益相关者，包括开发人员和业务部门，在第一个完整版本发布之前无法收到有关性能的任何反馈。这通常发生在项目批准后几个月。此外，并非所有软件中的功能都能交付价值，加速向开发团队和业务部门的反馈可以更快地迭代以改进软件。这导致时间和资源浪费在最终无法交付价值的功能上。例如，来自微软的研究表明，只有三分之一精心设计的功能为客户交付了价值。14
相比之下，DevOps 提倡转向基于产品的管理。实际上，这意味着项目不再有“结束日期”，团队而是持续交付功能——以及由此产生的价值。实现这一目标的一个重要部分是整合价值流中的团队，从开发到运营；一些组织甚至包括业务利益相关者。在这种模式下，软件是一种作为产品维护的产品，业务部门持续跟踪交付和价值指标。
关于 DevOps 的最先进的研究和实践
行业中最大的挑战（和抱怨！）之一是缺乏 DevOps 的正式定义。许多从业者认为这是故意的，因为它允许团队和组织采用适合他们的定义。此外，他们指出，拥有敏捷的正式定义（在敏捷宣言中编码）并没有解决定义蔓延的问题，以及围绕组织声称其“正在走向敏捷”时真正意味着什么的由此产生的困惑仍然困扰着该行业。这种缺乏理解可能具有挑战性，因此我们在此处提供一些常见的定义以供参考。
• “DevOps 是一种软件开发和交付方法，它提供...在为组织交付价值的同时提高速度和稳定性。”4
• “DevOps，无论是在运营工程师承担开发任务的情况下，还是在开发人员在运营领域工作的情况下，都是一种努力使这两个学科更接近的方式。”16
• “DevOps，是‘开发’和‘运营’的复合词，是一种为高速率而设计的软件开发和交付方法。”17
然而，这些定义侧重于结果（通过速度和稳定性实现的价值，来自 Forsgren4）或学科的基础（将开发和运营结合在一起，来自 Roche16 或 Sebastian 等人17）。如果想了解 DevOps 方法的组成部分，也许最常见的呈现方式是 CALMS 的总结：文化、自动化、精益、度量和共享。6,12 以下是每个组件的简要定义
• 文化。相互信任、学习意愿和持续改进、持续的信息流、对开发人员和运营人员之间的变化和实验的开放心态的整合。
• 自动化。实施具有高自动化水平的部署管道（最值得注意的是持续集成/持续交付）和全面的测试自动化。
• 精益。应用精益原则，例如最大限度地减少在制品，以及缩短和放大反馈循环，以识别和最大限度地减少价值流中断，从而提高效率。
• 度量。监控关键系统指标，例如业务或交易指标以及其他关键绩效指标。
• 共享。在组织内部和跨组织边界共享知识。团队成员应相互学习经验并主动沟通。
对 CALMS 的解读
本文使用 CALMS 的五个核心要素作为框架。
文化
作为 DevOps 团队的一员工作需要跨职能团队环境中的文化协作。在其理想状态下，DevOps 使用所谓的跨职能团队，这意味着由开发人员、测试人员、质量保证专业人员和 IT 运营工程师组成的小组共同工作以开发和交付软件。通过这种方式，他们熟悉彼此的工作和挑战（描述这种情况的常用短语是“具有同理心”），这有助于他们创建和维护更好的软件。例如，由于他们看到了运营专业人员在维护可扩展和可靠的基础架构时遇到的挑战，因此开发人员与运营人员协作编写更具可扩展性和可靠性的代码。
自动化
下一个原则，自动化，需要一套 DevOps 工具。2,13 以下是一些可用自动化工具的示例
构建
• 构建。用于软件开发和服务生命周期的工具，包括编译代码、管理依赖项、创建文档、执行测试以及在不同阶段部署应用程序。
• 持续集成。持续测试新的软件组件。
发布
• 发布自动化。打包和部署软件组件，从开发环境跨所有环境到生产环境。
• 版本控制。管理程序的更改并收集其他信息。版本控制是配置管理的组成部分。
• 测试自动化。使用软件执行测试并重复活动。
部署
• 配置管理。借助在开发阶段重现生产系统，减少生产配置和配置维护。
• 持续交付。旨在实现不间断部署的原则、实践和模式的组合。
运营
• 日志记录。跟踪对于应用程序管理至关重要；一切都必须记录。
• 监控。在客户注意到基础设施问题之前识别它们。监控存储、网络流量、内存消耗等。
持续集成和交付降低了发布软件的成本和风险。它们通过结合自动化和良好实践来一致、可靠且可重复地执行工作（例如测试和构建），从而实现快速反馈并在软件交付过程中构建质量。这有助于团队更快、更可靠地交付功能，进而为组织实现更快的价值交付。与低绩效团队相比，绩效最高的团队能够以高出 46 倍的频率进行部署，提前期缩短 2,555 倍。故障率降低七倍，恢复速度比绩效较低的同行快 2,604 倍。8
精益
“内置质量”——前一段中提到的——是 DevOps 的关键原则，也是精益中发现的原则。应用于 DevOps，这意味着团队寻找机会消除浪费、利用反馈循环和优化自动化。
让我们看一个例子。DevOps 团队的规模和产品责任各不相同。在某些模型中，单个团队执行所有软件开发和交付活动，包括开发、测试、交付和维护。他们最终负责软件产品的完整软件交付生命周期（并且可能负责多个产品），为企业交付价值。精益流程允许在整个开发和交付过程中进行快速迭代和反馈，以提高质量并构建更快、更可靠的系统。示例包括小批量工作以实现通过开发管道的快速流动、限制在制品、在发现错误时立即修复错误而不是在最后修复，以及“左移”安全输入。
这些实践听起来可能很熟悉；类似的实践推动了制造业的质量和价值。（有关精益制造的精彩故事，请查看 This American Life 的第 561 集11，其中讨论了 NUMMI（New United Motor Manufacturing Incorporated），丰田和通用汽车在加利福尼亚州弗里蒙特市的合资企业。）
度量
度量是 DevOps 的另一个核心方面。监控和观察系统的能力非常重要，因为软件开发和交付本质上是在处理以复杂方式交互且无法观察到的无形库存。（这与传统的物理制造系统（例如 NUMMI 案例中描述的汽车装配线）形成对比。）
通过有效的监控，团队能够在整个软件交付生命周期中跟踪、观察、度量和调试他们的系统。应该注意的是，指标也是质量保证的工具，应该利用来自多个来源的度量。9
共享
知识和信息的共享使 DevOps 团队取得成功，并有助于扩大他们的成功。通过在团队内部、跨组织和跨行业共享实践（包括成功和失败），团队可以从他人的学习中受益并更快地改进。虽然其他人指出共享在任何领域和任何方法论中都是可能的，但 DevOps 已将其作为一种文化规范来采用，并且行业中的许多人报告说，与他们以前在技术领域的工作相比，该领域更具协作性。
内部协作可能包括工作见习或岗位轮换：开发人员参与运营和维护活动（例如，开发人员甚至可能“接听寻呼机”），运营工程师轮换到开发和测试角色，学习设计和测试工作的基本组成部分。在许多情况下，所有跨职能团队成员都参加相同的会议，这使他们拥有共同的背景。跨行业的共享通常发生在会议上，世界各地涌现出数十个 DevOpsDays 和其他社区组织的活动。
这些原则的应用带来了更好的结果：对于个人（表现在倦怠感降低和工作满意度更高），对于团队（表现在更好的软件交付成果和更好的团队文化），以及对于组织（表现在盈利能力、生产力、客户满意度和效率等指标的改进。7,21
尽管 DevOps 在行业中已经是一项重要的运动十多年了，但直到最近才受到学术界的太多关注。虽然 CALMS 原则并不总是使用这些术语来指代，但它们确实出现在现有研究中（例如，Fitzgerald 和 Stol3）。
研究总结
以下是一些先前 DevOps 相关研究的核心见解
期刊文章
• Fitzgerald 和 Stol (2017)。系统与软件杂志3
介绍了持续软件工程管道以及针对不同持续过程（包括 DevOps 和 BizDev（业务战略和开发））的研究议程。
• Forsgren、Sabherwal 和 Durcikova (2018)。欧洲信息系统杂志10
强调了在系统管理环境中共享和采购知识时采用的角色，并确定了优化结果的策略。
• Forsgren、Durcikova、Clay 和 Wang (2016)。AIS 通讯5
确定了维护系统的用户工具的最重要的系统和信息特征。
• Dennis、Samuel 和 McNamara (2014)。信息技术杂志1
强调在设计阶段应考虑维护工作，并称之为 DFM（面向维护的设计）。作者提出了关于文档之间的链接应如何影响维护工作和使用的见解。
• Sharma 和 Rai (2015)。欧洲信息系统杂志19
调查了组织采用计算机辅助软件工程的决策如何受到 IS 领导者的个人因素和技术因素的影响。
• Shaft 和 Vessey (2006)。管理信息系统杂志18
旨在检验软件维护作为互连的理解和修改；这两个因素之间的关系受到认知契合度的调节。
会议
• Trigg 和 Bødker (1994)。 计算机支持的协同工作会议20
考察了人们如何定制他们的共享 PC 环境，并提出了对软件开发定制如何有助于设计更符合需求的系统的理解。
• Lwakatare 等人。(2016)。夏威夷系统科学国际会议15
调查了嵌入式系统领域采用 DevOps 的关键挑战。
• Wiedemann 和 Wiesche (2018)。欧洲信息系统会议22
介绍了 DevOps 团队成员应采用的管理软件交付生命周期的理想技能组合。
实践挑战与机遇
实施 DevOps 存在若干挑战。首先，技术——以及由此产生的组织转型——是困难的，但强有力的领导可以提供帮助。正如许多从业者所指出的，管理和推动组织内部的文化变革可能比实施技术变革更困难和更重要。良好的领导力至关重要。在包括 DevOps 在内的多种环境中研究的一种方法是变革型领导；这种风格使用五个维度（愿景、智力激励、鼓舞人心的沟通、支持型领导和个人认可）来激励和指导团队。
其次，DevOps 需要针对每个组织定制解决方案。每个环境都是独一无二的，采用规范性的 DevOps 实施和采用方法不太可能成功。团队和组织构成了一系列独特的挑战和文化规范。每个组织都应采用和调整自己的方法以实现 DevOps 的成功。DevOps 的调整应包括不仅要发展技术实践，还要发展文化、流程和度量实践。创建独特且看似临时的技术转型之旅的工作是困难的，并且可能令人望而生畏，因此许多组织都在寻找逐步指南。然而，这些指南不太可能提供解决方案（除了诸如“自动化您的工具链”之类的基本建议），并且通常由试图向您推销某些东西的人提供。
第三，每个 DevOps 解决方案都应包含一个整体视图，包括自动化（包括工具和架构）、流程和文化。在许多传统方法中，利用一个领域（例如，开发）的专业知识来完成任务，然后再将其传递给另一个团队。在 DevOps 中，有必要从这种高度专业化转向包含对更多领域的广泛理解。（有些人称之为T 型知识，其中“T”的顶部代表广泛的知识，而 T 的茎代表对某个专业领域的深入理解。）
这使人们能够了解他们的工作将如何影响技术堆栈的更多领域并与之交互；这通常需要在向 DevOps 过渡的过程中进行大量的额外学习和承担责任。组织应提供培训和教育，而不仅仅期望技术人员独立增强他们的学习能力。请注意，虽然一些技术人员认为这种职责和知识的扩展令人兴奋，但另一些人可能会抵制，尤其是那些离退休只有几年并且对自己的工作角色感到舒适的人，或者那些认为分享有关其角色的信息会危及工作保障的人。组织将需要特别考虑这些培训和文化挑战，并做出相应的回应。（正如已经指出的，DevOps 不仅仅是技术！）
结论
DevOps 旨在为新软件功能的更快上市时间和实现更高水平的稳定性提供指导。实施跨职能的、以产品为导向的团队有助于弥合软件开发和运营之间的差距。通过确保他们的转型包括 CALMS 中概述的所有原则（文化、自动化、精益、度量和共享），团队可以实现卓越的绩效并为其组织交付价值。DevOps 通常具有挑战性，但来自整个行业的故事表明，许多组织已经克服了早期的障碍，并计划继续他们的进步，理由是 DevOps 对他们的组织有价值，并且对他们的工程师有益。
参考文献
1. Dennis, A.R., Samuel, B.M., McNamara, K. 2014. 面向维护的设计：KMS 文档链接决策如何影响维护工作和使用。信息技术杂志 29(4), 312-326.
2. Ebert, C., Gallardo, G., Hernantes, J., Serrano, N. 2016. DevOps. IEEE 软件 33(3), 94-100; https://ieeexplore.ieee.org/document/7458761.
3. Fitzgerald, B., Stol, K.-J. 2017. 持续软件工程：路线图和议程。系统与软件杂志 123, 176-189.
4. Forsgren, N. 2018. DevOps 交付。 通讯 61(4), 32-33; https://dl.acm.org/citation.cfm?id=3174799.
5. Forsgren, N., Durcikova, A., Clay, P. F., Wang, X. 2016. 集成用户满意度模型：评估信息质量和系统质量作为系统管理中的二阶结构。信息系统协会通讯 38, 803-839.
6. Forsgren, N., Humble, J. 2015. 持续交付在 IT 和组织绩效中的作用。在西部决策科学研究所会议记录中。
7. Forsgren, N., Humble, J., Kim, G. 2018. 加速：精益软件和 DevOps 科学：构建和扩展高性能技术组织。俄勒冈州波特兰市：IT Revolution Press。
8. Forsgren, N., Humble, J., Kim, G. 2018. 加速：DevOps 状态报告：新经济战略。DORA（DevOps 研究和评估）和 Google Cloud； https://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State%20of%20DevOps.pdf.
9. Forsgren, N., Kersten, M. 2018. DevOps 指标。 通讯 61(4), 44-48; https://dl.acm.org/citation.cfm?id=3200906.3159169.
10. Forsgren, N., Sabherwal, R., Durcikova, A. 2018. 知识交流角色和 EKR 绩效影响：扩展知识重用理论。欧洲信息系统杂志 27(1), 3-21.
11. Glass, I. 第 561 集，“NUMMI 2015”。This American Life; https://www.thisamericanlife.org/561/nummi-2015
12. Humble, J., Molesky, J. 2011. 企业为何必须采用 DevOps 以实现持续交付。Cutter IT Journal 24(8), 6-12; https://www.cutter.com/sites/default/files/itjournal/fulltext/2011/08/itj1108.pdf.
13. Humble, J. 2018. 持续交付听起来不错，但它在这里适用吗？ 通讯 61(4), 34-39; https://dl.acm.org/citation.cfm?id=3173553.
14. Kohavi, R., Crook, T., Longbotham, R., Frasca, B., Henne, R., Ferres, J. L., Melamed, T. 2009. 微软的在线实验，数据挖掘案例研究 11。
15. Lwakatare, L.E., Karvonen, T., Sauvola, T., Kuvaja, P., Olsson, H.H., Bosch, J., Oivo, M. 2016. 嵌入式系统领域 DevOps 展望：为何如此困难？在夏威夷系统科学国际会议记录中。
16. Roche, J. 2013. 在质量保证中采用 DevOps 实践。 通讯 56(11), 38-43; https://dl.acm.org/citation.cfm?id=2524721.
17. Sebastian, I. M., Ross, J. W., Beath, C., Mocker, M., Moloney, K. G., Fonstad, N. O. 2017. 大型老牌公司如何驾驭数字化转型。MIS Quarterly Executive 16(3), 197-213.
18. Shaft, T.M., Vessey, I. 2006. 认知契合度在软件理解和修改之间关系中的作用。MIS Quarterly 30(1), 29-55.
19. Sharma, S., Rai, A. 2015. 组织中 IS 流程创新的采用：IS 领导者的个人因素和技术认知在决策中的作用。欧洲信息系统杂志 24(1), 23-37.
20. Trigg, R.H., Bødker, S. 1994. 从实施到设计：定制和系统化的出现。在 CSCW '94： 计算机支持的协同工作会议论文集, 45-54; https://dl.acm.org/citation.cfm?id=192869.
21. Wiedemann, A. 2017. IT 团队中一种新的协作形式——探索 DevOps 现象。在太平洋亚洲信息系统会议论文集中, 1-12.
22. Wiedemann, A., Wiesche, M. 2018. 您准备好迎接 DevOps 了吗？DevOps 团队所需的技能组合。在欧洲信息系统会议论文集中。
致谢
作者要感谢匿名审稿人，他们的指导和周到的反馈帮助我们塑造和完善了本文。
Anna Wiedemann 是新乌尔姆应用科学大学的研究助理，也是慕尼黑工业大学的博士候选人。她的研究兴趣包括 DevOps、项目管理和业务-IT 对齐领域的主题。她的作品曾在众多会议上发表，并在国际 IT/业务对齐和治理杂志上发表。
Nicole Forsgren 在 Google Cloud 从事研究和战略工作。她是加速：精益软件和 DevOps 科学的合著者，并且最著名的是迄今为止规模最大的 DevOps 研究的首席研究员。她曾是一位成功的企业家（已退出 Google）、教授、性能工程师和系统管理员。她的作品已在多家同行评审期刊上发表。
Manuel Wiesche 是慕尼黑工业大学 (TUM) 信息学系信息系统主席的博士后研究员。他目前的研究经验和兴趣包括项目管理、平台生态系统和 IT 服务。他的研究已在许多参考文献会议论文集、MIS Quarterly 和其他众多同行评审期刊上发表
Heiko Gewald 是新乌尔姆应用科学大学的信息管理研究教授，也是服务科学研究中心的主任。他的研究重点是 IT 管理、健康 IT 以及老龄化一代对数字资源的使用。他是这些问题会议的常客，他的作品已在众多同行评审期刊上发表。
Helmut Krcmar 是慕尼黑工业大学信息学系信息系统全职教授，也是巴伐利亚自由州软件和系统研究机构 fortiss GmbH 董事会发言人。他的研究兴趣包括数字化转型、信息和知识管理以及基于平台的 IT 服务系统生态系统管理。他的作品已在同行评审期刊上广泛发表。他是信息系统协会会士。
版权所有 © 2019，所有者/作者所有。出版权已许可给 。
最初发表于 Queue vol. 17, no. 2—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但它们的设计方式似乎存在差距。加密哈希存在许多标准，这些标准受各种安全要求的驱动，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者直观地接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议计划和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中新的工具、技术和技巧不断发展以服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚潮流的影响，并且可能会忘记或忽略针对它面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，后来得到普及，是这些成熟的解决方案之一。
© 保留所有权利。