1、引言

DevOps，对某些人来说是一种成功的范式，对另一些人来说是一种神秘而深奥的实践。互联网社区将 DevOps 的定义概括为一组结合软件开发 (Dev) 和信息技术 (IT) 运营 (Ops) 的实践，旨在缩短系统开发生命周期 (SDLC) 并提供持续集成和持续部署高质量软件（DevOps，2020 年）。本文通过描述 DevOps 的基础哲学和科学以及这些领域如何指导其成功，提出了对 DevOps 的简明理解。

就本文的范围而言，术语 DevOps 包括行业术语 DevSecOps ([Development + [Sec]urity + [Op]eration)。安全性对于 DevOps 范式和实践来说应该是隐含的和无所不在的。DevOps 中的安全性与质量保证息息相关，通过 SDLC 等方法提供高效、有质量保证的解决方案（Laskowski，2011）。

通过 SDLC 确保安全是每个人的责任，并且在技术行业中得到了支持（Vogels，2017）。DevOps 起源于软件开发和IT技术社区，是在更大的实践中执行的实践集合；然而，DevOps 的范式和原则对于一般技术解决方案工程和其他领域是可重用的（Sajjad，2020）。以下部分提供了对 DevOps 哲学和科学的简明理解，这些哲学和科学协同定义了 DevOps 的本质。

2、分类

以下建议的 DevOps 分类法从根本上涵盖了哲学和科学领域。图1说明了针对哲学和科学提出的 DevOps 分类法以及它们各自的分支、子域和实例。在哲学领域下，认识论和本体论的分支将通过信念、知识和真理的附加分类来检查。将通过以下概念和实践进一步检查这些子域的适应实例：敏捷开发、质量保证和精益生产。在科学领域，社会和应用的子域将通过社会学、心理学、经济学和工程学的额外分解来检查。这些子域的适应实例将通过文化转型、更快的上市时间和自动化等概念和实践来进一步检查。

3、哲学


在这篇文章中使用“哲学”，将在词汇上归因于剑桥词典的定义，“一种特定的信念、价值观和原则体系”（哲学，nd）。这里提出的 DevOps 哲学是通过行业公认的方法和实践持续改进和交付高效、有质量保证的解决方案工程。以下部分并非详尽无遗；而是通过检查相关分支：认识论和本体论对 DevOps 哲学和核心哲学原则的学术认可。

3.1 认识论

根据牛津大学出版社的说法，认识论的定义是“知识理论，特别是关于它的方法、有效性和范围”；该定义进一步指出，“认识论是对区分合理信念和观点的学术研究”（认识论，n. d.）。以下小节探索了 DevOps 汲取知识的学术和行业来源，如：概念、框架、方法和实践。通过支持子领域：信念和知识，进一步探索了对 DevOps 的认识论理解。

3.1.1 信念

剑桥词典将信念定义为“确信某事存在或真实的感觉”（信念^n. d.）。虽然 DevOps 可能意味着多种信念，但这里探讨的 DevOps 的基本信念是敏捷。DevOps 的核心理念是，应该减少从开发到运营的时间（速度/敏捷性），以获得一个有质量保证的解决方案（输出）。它努力减少和缩短构思、开发、生产和输出中的反馈循环。因此，采用快速、高效响应方法的信念对于 DevOps 至关重要，因此与敏捷方法具有共同的亲和力。

敏捷方法，或敏捷，是项目管理社区对基于快速迭代开发和协作周期（称为sprint）的计划、执行、开发和产生输出的有效性所持有的一种信念。企业、联邦和学术机构以及专业机构开发并采用了各种方法来管理产出（例如产品和服务）；从传统瀑布到敏捷的进化的自适应方法（Satzinger 等，2009）。敏捷起源于一群希望改进软件开发过程的软件专业人员。集体软件专业人士起草了著名的敏捷宣言，其基础源于12条原则，这些原则共同建立了敏捷（Beck等人.，2001）以及后来的 DevOps 的信念结构。

企业和联邦机构都要求对时间敏感和关键任务的工作进行加速解决方案工程。关键任务工作的解决方案工程对速度的需求是如此迫切，有一种格式重新设计了敏捷的杰出冲刺（Sprint）过程，成为一种互补的格式，称为设计冲刺（Design Sprint）。设计冲刺的目的是将关键任务需求的问题解决提炼为五天：第一天制定目标；第二天构思解决方案；第三天选择解决方案；第四天——开发原型；第五天测试原型并获取经验教训，以决定下一步如何开展（Knapp et al.，2016）。敏捷哲学渗透到 DevOps 中，并在实践中建立敏捷性。DevOps 的概念和实践依靠速度来快速设计高效、有质量保证的解决方案，并通过集成和开发来持续改进和交付所需的解决方案。

DevOps 应用敏捷信念的一种方法是通过 CI/CD，这是一个与持续集成和持续交付相关的技术行业术语。然而，这种理解应该扩大到包括：CI 是持续改进，CD 是持续开发。CI/CD 的这种扩大符合从持续集成中持续开发的需要。此外，持续集成的目的是改进之前的迭代，并尽快持续交付所提到的改进。因此，增强的 CI/CD 模型是一个持续不断的CI/CD（持续改进和持续交付）循环，包含单个和/或多个 CI/CD（持续集成和持续开发）流水线的聚合子循环。CI/CD 的实现在战术上是通过软件工程流水线执行的，可以从简单的（一条流水线）到复杂的（多条流水线）。实现的流水线可以相互连接或相互排斥；CI/CD 流水线的架构是根据需要定制的。

CI/CD 模型应用于软件开发和技术运营，以加速交付解决方案输出。任何集成都应该是对输出的渐进式改进。因此，任何开发都应该由集成决定的改进进行驱动，这些改进是由持续改进的反馈循环驱动的，以便提供持续交付改进后的输出。在 DevOps 中通过 CI/CD 应用的敏捷信念允许产出快速失败，快速学习/改进，并缩短关于知识的反馈循环周期。

3.1.2 知识

根据牛津英语词典，知识是“你通过教育或经验获得的信息、理解和技能”（知识，nd）。广泛的技术理解和技能组合对于高效实践和执行 DevOps 至关重要。实践DevOps 的知识输入是大量和多方面的，正如领先技术行业当前的招聘说明所示。术语“T型人才”描述了需要广泛的技术知识和深厚的专业技术知识的 DevOps 专业人员（DevOps Institute，2019年）。

除了 DevOps 从业者需要的知识之外，围绕 DevOps 过程的知识还包括一系列抽象和具体的信息，涵盖多个技术和非技术学科和领域。然而，关于所需知识的各个学科和领域有一个基本的融合——通过高效的、有质量保证的方法持续改进产出。

关于知识获取、表达、评估和保留集成在反馈循环中的重要性的认识已经通过正式的概念得到了解释，例如：质量控制一规范、生产、检查的谢沃夫循环（谢沃特，1939年）；戴明对质量控制和改进的演绎一计划-执行-研究-处理（PDSA）（戴明，2018年）；戴明的工作在日本被翻译成计划-执行-检查-处理（PDCA）（今井，1986）。例如，当一个企业制定了一个策略（计划）来创建一个新的小部件时，小部件向市场的发布（执行）允许企业收集关于小部件的市场信息进行分析（研究/检查）。使用DevOps，分析的知识可以在下一个开发周期中快速集成（处理），以改进小部件及其交付。因此，在 DevOps 中，获取知识的时间缩短了，并持续集成到开发中，以持续改进交付的产出。

像谢尔沃夫循环、PDSA和PDCA这样的正式概念为 DevOps 中的问题解决/决策提供了结构和方法。更快解决问题或做出决策的能力成为使用DevOps的企业或机构的竞争优势。知识成为持续改进的必需品，获取、保留、共享或消费知识的能力决定了重大的业务决策、战略和未来结果。DevOps 通过遵循基于谢尔沃夫循环、PDSA和PDCA的分阶段方法，确保知识得到适当的循环，以提供高效、有质量保证的解决方案。

为了对通过谢沃夫循环、PDSA和PDCA等过程获得的关于质量改进的知识进行基准测试，通过六西格玛应用了一种数据驱动的方法。六西格玛由摩托罗拉创立，旨在通过统计过程控制和全面质量管理的结合来解决质量问题和降低错误率（Tennant，2001）。六西格码方法为 DevOps 提供了对当前质量状态进行基准测试的知识，以便努力实现有保证的产出的必要增量改进。

定义、测量、分析、改进和控制这一过程被称为DMAIC（发音为Duh-MAY-ick）是六西格玛改进的五个阶段（George et al.，2005）。六西格玛改进的五个阶段指导 DevOps提供如下质量有保证的解决方案：1）为期望的产出设置初始质量级别（定义）；2）将初始产出具体化（测量）；3）从质量和错误级别审查知识（分析）；4）集成和开发对新产出的已知问题的修正（改进）；最后，5）确保后续交付周期只包括改进的产出（控制）。这个数据驱动的改进周期通过知识获取和反馈循环为 DevOps 不断重复。

从 DevOps 中使用六西格玛收集的知识提供了必要的过程，以持续提高质量水平，并在下一个高效、有质量保证的解决方案的持续交付周期中减少/消除已知错误。为了不断减少错误或其他导致限制的问题，DevOps 不断寻找关于现有增值和非增值活动的真相，以持续改进和持续交付高效且有质量保证的解决方案。

3.2 本体论


韦氏词典定义中本体论的词汇表示如下，“形而上学的一个分支，与存在的本质和关系有关”（本体论，n. d.）。多亏了 Patrick Debois （梅扎克，2018年），DevOps 自2009年以来就已存在。然而，DevOps 的概念/实践有着显著的熟悉性，因为它是从经过审查的方法、实践、框架和概念的和谐集合中演变而来的。下一节通过子域：真理，来探索DevOps 的本体性质。

3.2.1 真理

前面关于认识论及其子成分——信念和知识——的章节为德沃普斯的本体论真理奠定了基础。下面对真理的讨论并不意味着德沃普斯中所有真理的详尽列表，而是对在最高级别上体现德沃普斯真理的讨论。根据韦氏词典（真理，n. d.），真理是“真实事物、事件和事实的主体：现实”。

关于 DevOps 的真正真理是——精益。DevOps 中的“精益”类似于由 John Krafcik 创造的用于反映丰田汽车公司（Toyota）的丰田生产系统（TPS）的“精益生产”方法；与它的前身大规模生产相比，它有意寻求不断减少或消除生产结构中的无关项目和低效率（沃马克等人，2007）。


TPS从福特生产系统和美国超市的工作流程中获得灵感。福特生产系统是亨利·福特倡导的大规模生产模式。从那时起，TPS在丰田大野耐一（大野，1988年）的领导下成为一个持续改进的、准时制、看板拉动系统。TPS的额外改进来自新乡重夫的快速换模，也被称为SMD（新野，1985年）。

通过丰田的成功和在不同业务领域普遍采用TPS，精益生产已经被检验和验证为真理。精益生产思维方式成为一种思维方式——精益思想。精益思想就是真理：一项活动要么是精益的，要么仍然包含非必要的浪费（在日语中被称为m^uda）抑制了要实现的真正价值（沃马克&琼斯，1996）。使某样东西“精益”的概念可以被认为是使它精确地由有效优化所需的确切项目组成；任何额外的组件都被认为是多余的、非增值的，并导致价值减少或变得次优。

采用 DevOps 产生的输出从精益思想开始，通过最小可行产品(MVP)概念实现节约特性标准化(Ries, 2011)。节俭不应该与粗制滥造联系在一起，而是应该在资源和期望方面明智、谨慎和经济的背景下理解。DevOps中的MVP不应该牺牲质量。相反，应该在 CI/CD（通过持续集成和开发的持续改进和持续交付）的生命周期中分阶段交付高效、有质量保证的 MVP 功能。此外，DevOps 通过持续的知识获取和将所述知识再投入到下一个 MVP 开发周期来逐步改进初始 MVP。DevOps 重复改进循环，将“完美”或“接近完美”作为最终目标。但是请注意，完美的构成将取决于业务/机构的需求。


效率是 DevOps 及其成功的重要咒语，源于对实践各个方面的精益思考。在使用DevOps的同时，精益思考并使解决方案精益，这与爱因斯坦（2019年）熟悉的格言“事情应该尽可能的简单，而不是更简单。”（第475页）非常一致。从精益编程到精益CI/CD 流水线，DevOps 的生态系统应该只包含确切需要的东西，仅此而已。额外的浪费将使DevOps实践膨胀和过载，导致繁琐的维护和操作，这是不理想的。DevOps 的精益思想是一个真理，涵盖实践的许多特性，如软件工程和计算，都采用精益思想。


精益思维对软件工程和计算来说是很自然的，因为两者都来自数学领域。在数学中，算法应该简化（简化）到最简单的形式（Boyer&Merzbach，1991）。任何与算法所需功能无关的附加项目都不在范围内，也不需要存在。软件工程精益代码可以从开发干净代码的愿望中识别出来——简单、直接的代码（Martin，2008）；此外，引用Hoare（1969）的话，“计算机编程是一门精确的科学”（p.576）。精益计算环境是可取的，正如Unix的集体哲学所承认的那样，通过消除或不增加不必要的混乱和复杂性来使每个程序做好一件事（McIlroy et al.，1978）。其他精益计算环境包括极简主义的操作系统，这些操作系统只包含对所需功能至关重要的特定元素，并且能够在需要时及时修改元素（Geer，2009）。


精益是 DevOps 的真理，使实践能够通过减少浪费不断寻求改进和优化，精益思想对DevOps 的效率和成功至关重要。DevOps 从根本上认为一个高效、有质量保证的解决方案应该是精益的，以便减少/缩短构思、开发、生产和输出中的反馈循环。将精益、敏捷和质量保证相结合，提供了指导 DevOps 理念的原则的简明视图，以实现高效、有质量保证的解决方案。

4、科学


根据牛津大学出版社的说法，科学的词汇定义是，“包括通过观察和实验对物理和自然世界的结构和行为进行系统研究的智力和实践活动^（科学，nd）。以下部分是通过对科学领域内的关联分支：社会科学和应用科学的检查，对DevOps固有的科学本质的简要学术描述。

4.1 社会科学


根据牛津大学的说法，社会科学是“对人类社会和社会关系的科学研究”。以下部分传达了社会科学的三个重要学科，它们有助于 DevOps 的科学性：社会学、心理学和经济学。

4.1.1 社会学与心理学

根据吉丁斯（1923）的说法，“社会学是试图通过物理、生命和物理原因的运作来解释社会的起源、成长、结构和活动，并在进化过程中共同作用”（p.8）；根据阿姆尔特（1976），“心理学是对行为的研究；也就是说，研究人类和其他动物的可观察行为”（p.7）。虽然社会学和心理学是独特的领域，但它们将被一起检查，以更好地理解一个组织对 DevOps 的采用。以下部分探讨了 DevOps 文化和变革，特别是适用于采用这种做法的商业组织。然而，所分析的许多要点适用于其他类型的组织，如联邦和学术机构。

企业是社会系统的系统组织，努力有效地激励自主、自由意志的人来实现共同的行为和组织目标（Hersey&Blanchard，1977）。要让企业中的不同系统接受 DevOps，领导者和员工需要做出重大的承诺和努力。个体和集体都需要在文化上采用持续改进等 DevOps 原则，这会强制形成持续学习的环境。

DevOps 的采用将企业文化转变为在社会学和心理学新范式中的思维和行为。


当一个企业拥抱一个新的范式时，新的能力就会出现，需要评估当前能力的持续性。以前的业务范式下的能力可能与 DevOps 不一致，因此可能需要消除或转化为新的能力，以防止它们变得僵化（Leonard，1992）。


企业应该致力于根据需要进行调整或重塑，以满足向 DevOps 成功转型的需要。高管领导应该以透明的方式就DevOps转型进展向员工提供一致、积极主动的沟通，以消除障碍并确保成功。重塑经营理念、学习新的能力和消除转型障碍，可以采用 DevOps 原则和实践。领导层必须坚定不移地做出企业转型的承诺，并被员工有效执行，否则就会失败（戴明，2000）。

当过渡到 DevOps 时，新的能力无疑需要新的技能。企业必须致力于培养具备 DevOps 必要技能的员工队伍，如T型人才，为个体提供重要的心理价值，为劳动力提供社会学价值。为个体提供价值的能力加强了个人和企业之间的组织承诺（Margelyte-Pleskiene&Veinhardt，2018），这反过来又加强了向 DevOps 的成功文化转型。如果新技能得不到培养，个人可能会变得无归属感并寻求替代企业继续职业发展。

使用技术的企业必须认识到采用 DevOps 的必要性，否则就会出现组织退化（Le Mens et al.，2015）和组织犬儒主义（wanous et al.，1994）。此外，企业必须防范因傲慢的领导（Sadler-Smith et al.，2016）、集体傲慢（Sullivan&Hollway，2014）和成功综合症（Tushman&O’Reilly，1996）而对 DevOps 的抵制，所有这些都可能扼杀或阻碍向 DevOps 的采用和转变。

企业的转型并非易事。如果企业能够一开始就明确并向员工传达转型的价值，转型的障碍就更容易消除。从丰田的“丰田之道”中可以找到成功的文化转型的参考模型。通过采用 TPS 并积极拥抱员工以培养社会学和心理学价值，丰田的文化转变为“丰田之道”（Liker & Franz，2011）。丰田将“丰田之道”描述为植根于制造精神（日语为 ^monoz-ukuri）（Toyota Motor Corporation，nd）以及两个原则：持续改进（日语为kaizen）和尊重人（Liker，2004 年） ）。“丰田之道”的原则将丰田的文化转变为积极的学习环境，这加强了员工的组织承诺（Allen&Meyer，1990），并为行业的长期成功做出了重大贡献（Sobek II&Smalley，2008）。

DevOps 文化类似于关于积极、有影响力的业务和文化价值的“丰田之道”。DevOps提供了一种独特的组织文化，通过基于科学的持续改进方法，实践持续交付高效、有质量保证的解决方案。DevOps鼓励集体和个人建立一个基于可重复信息的科学环境来组织、研究、开发和评估解决方案（Wallace，1971）。

4.1.2 经济学

根据马歇尔（1890）的说法，“经济学一方面是对财富的研究，另一方面是对人的研究的分支”（p. l）。经济学有两个主要分支：宏观经济学和微观经济学。宏观经济学研究全球经济，而微观经济学研究个人和企业的经济。为了本文的范围和简洁考虑，本节描述了DevOps如何通过减少高效、有质量保证的产出（如产品/服务）进入市场所需的时间这一重要特征来增加个体企业的财富。虽然本节侧重于企业的DevOps，但如果不承认更快的上市时间对大学和联邦实验室等研究机构的价值，那就太过分了，尽管如此应用，该短语需要稍微修改为更合适的“Faster-Time-to-Science”（NASA，2013）。

DevOps 的应用为业务运营加快了提供向市场投放有质量保证的产品。通过DevOps带来的生产的加速可以被视为更快的投产时间，从而实现更快的上市时间。更快的上市时间的概念源于“上市时间”，与产品到达消费者市场的前置时间缩短相关（Charney，1991）。

DevOps 通过其对敏捷、精益、质量保证、文化转型和自动化等关键概念的普遍应用，为企业提供了重大影响。上述概念的整合为管理和改进业务流程提供了附加值，最终目的是降低成本，同时保持甚至提高客户满意度。企业DevOps的整合通过降低成本和差异化来改善价值链，这可以在竞争激烈的行业中提供竞争优势（波特，1985）。此外，DevOps 增强了组织以更快的频率为市场提供有质量保证的产品的能力（更快的上市时间），从而增加了满足客户的机会。一家公司比竞争对手更快、更频繁地提供客户满意度的能力是竞争优势和对抗其行业内竞争力量的堡垒 (Porter, 1997)。

由于消费者支出和消费者保留带来的现金流，提高客户对交付产出的满意度是任何业务的关键成功因素。因此，企业可能会花费大量资源通过一致性质量来获得客户满意度和留存率，一致性质量侧重于在市场发布前识别和消除缺陷，以确保产品达到或超过预期的设计规范（Garrison et al.，2017）。DevOps 通过其高效、有质量保证的持续改进和交付方法，增强了企业获得一致性质量的能力。有质量保证的产出越早在竞争对手之前进入消费市场，就越早有机会从消费者支出中进行销售（即流入现金流）。如果企业知道流入的现金流量，那么由于潜在的不确定性和失败的不足之处，该货币资源当前的价值将高于未来：内部人员、流程和技术；或者外部与宏观经济和地缘政治不确定性有关（国际清算银行，2011年）。此外，时间就是金钱；货币的时间价值原则认为今天的一单位货币比未来的同一单位货币更有价值（Kimmel et al.，2018）。因此，更及时的流入现金流的实现和购买力允许企业更快地做出货币决策；这是在竞争激烈的市场中的一种关键能力。如果一家企业获得了相对于竞争对手的竞争优势和比较优势，这些优势对企业来说将变得非常宝贵，并被用来引领行业。


虽然宏观经济和地缘政治风险超出了企业的控制范围，但运营风险并非如此。运营风险包括技术系统和技术风险，两者对 DevOps 的实践和持续都具有重要意义。由于技术的购买和使用可能不会提供增值，因此企业会精心制定战略和成本管理：技术如何通过规模经济或范围经济形式的提供运营效率提从而提供增值（Saunders&Cornett，2017）。DevOps通过提高产出速度（更快上市时间）来提供增值，以获得规模经济，并进一步提高满足产出需求的能力，实现范围经济。DevOps希望帮助企业提供一种更快上市的方法（更快上市时间），这反过来又为设计和实施DevOps所需的技术提供了一个有效的投资回报。因此，通过全面质量管理和运营风险管理的协同作用，DevOps 可以补充并进一步增强已经理解的业务成功范式（Luburic，2012 年）。DevOps 提供持续改进和持续交付解决方案（输出），同时对当前质量状态进行基准测试，以努力实现高效、有质量保证的解决方案的增量改进。

4.2 应用科学


根据史密斯（1967）的说法，“应用科学可以被视为一组实验方法、实验确定的常数和理论”…“这可能对工程师和其他必须解决社会问题的人有帮助 通过使用任何可用的方法和概念，而不管其内在的智力兴趣或或缺乏这种兴趣”（第57页）。以下部分传达了有助于 DevOps 科学性质的应用科学的重要学科：工程。
4.2.1 工程学


根据《工程世界》（1919年），工程是“通过组织、设计和建造，安全和经济地应用支配自然力量和材料的科学定律的实践，以造福人类”（第 34 页） ）。

正如本文前面提到的，DevOps起源于软件工程，同样，贯穿实践的重要术语源于各自的工程领域。软件工程包括以下领域的知识：计算机编程、架构（例如数据、软件、系统）、解决方案工程；以及各种学科，如：计算机科学、数学、质量管理、系统工程（Bourque et al.，2014）。

DevOps 工程方法通过坚持合理的数学和工程原则，极大地提高了效率和成功，这些原则包括：抽象（Russell，1903），模块化（Gausier&Pont，1970），多态性（Cardelli&Wegner，1985），可移植性（Newey et al.，1972），封装（Pamas，1972），可重用性（Rich&Waters，1983）。

工程自动化是 DevOps 的一个重要方面，也是其成功的关键组成部分。此外，自动化对现代和未来的计算技术至关重要。2001年，IBM宣布自主计算是必要的，并通过四个概念提供了自我管理能力的原则：自我配置、自我优化、自我修复和自我保护（Kephart&Chess，2003）。然后在2005年，IBM为自主计算提供了一个架构蓝图（IBM，2005）。约翰·冯·诺依曼（John von Neumann）在自主计算领域开创了先河，他就自动计算机器与人类神经系统进行了详细的比较（冯·诺依曼（von Neumann），1951年），后来又提出了自复制自动机的概念（冯·诺依曼（von Neumann），1966年）。DevOps 成功的一个重要贡献在于工程 CI/CD 流水线的实践，以自动化配置、优化、修复和保护高效、质量有保证的工程解决方案。

DevOps CI/CD 流水线的实施利用复杂的技术来增强和促进不同系统的自动化，这需要非平凡的、定制的互操作性，然而开发的软件已经简化了实现（Klein等人，2020）。软件和系统运维团队，或全栈工程团队协调接口以开发、管理和运维用于建立所需流水线的系统。尽管如此，DevOps CI/CD流水线的集成需要进行工程设计以实现表达自动化，从而工程自动化以实现自动化工程（即构建构建机器的机器）。

DevOps 中的工程自动化，例如但不限于 CI/CD 流水线，由协同、可重用、多态的构建块组成：图像、脚本、应用程序编程接口（API）（Klein&Miner，2018）。DevOps中的工程构建块类似于计算机科学中的抽象数据类型和数学中的函数（高阶函数）。在设计通用的、可重用的架构模式和解决方案时，构建块以最抽象的形式被无类型化，然后在实例化时被类型化，以开发高效的、有质量保证的解决方案。


DevOps 中工程构建块的组合为架构师和工程师设计各种可重用模式和解决方案提供了更高的表现力，从琐碎到复杂。由于工程构建块可以被软件定义，因此已经进行了自动化和计算的高级开发。整个系统和SoS（系统的系统）已经演变为与软件定义的解决方案进行集成（Juve&Deelman，2011）。完全软件定义的系统和SoS已经部署到各种物理和数字环境中，用于各种生产工作目的（Gannon et al.，2017）。即使物理调制解调器系统和SoS成为软件定义的非典型命题（Miner&Klein，2018）也已经初始化（Miner et al.，2018）。


由于工程构件之间的表现性相互作用，DevOps 中存在先进的高效、质量有保证的计算解决方案。这些工程构件增强了完全开发的软件定义系统和/或SoS解决方案的使用，这些解决方案提供了一系列有利的战术架构模式以快速使用，如：保存点、短暂性、不可变性和幂等性。与视频游戏或数据库的保存点概念相似，软件定义的解决方案可以表现地保存整个生态系统（如图像、脚本、API）。一旦生态系统被保存，CI/CD 流水线可以重新部署解决方案，以恢复或回滚到所需的状态；和/或继续存在于不同的生态系统中以求生存或合规（Hadgu et al.，2016）


临时解决方案只在它们特别需要的那一刻有效，然后关闭直到再次需要或通过 CI/CD 流水线终止。短暂的，通过计算，短暂的、软件定义的计算环境的使用有所增加（Cotta 等人，2016 年）。不可变的解决方案被设计为具有不变和持久的状态。但是，如果在解决方案中发生不期望的改变，那么改变的解决方案被破坏，并通过 CI/CD 流水线重新实例化到最初预期的期望状态。将不可变性实现到整个解决方案中的这种实现包括不可变基础设施（Mikkelsen et al.，2019）。无论通过 CI/CD 流水线部署或应用的次数如何，幂等解决方案都旨在始终如一地提供不变、持久的存在和行为。这种幂等的软件定义计算解决方案包括分布式云环境 (Ramalingam & Vaswani, 2013)。


DevOps 自动化在现代技术、解决方案架构和高级计算领域的工程中普遍存在，例如云计算、高性能计算、大数据、机器学习/人工智能、物联网、机器人和扩展现实。当基于软件的解决方案的开发和部署的自动化相结合时，实现了更高的表达能力和DevOps自动化的成功。通过DevOps CI/CD流水线和工程构建块的结合，通过工程自动化开发高效、质量有保证的解决方案的能力变得可实现和可维护。

5、结论

DevOps 是一个多方面的、折衷的概念和实践，起源于学术界和行业公认的方法和实践。DevOps 背后的哲学和科学是其被快速采用和成功的原因。本文通过认识论和本体论的分支，在信念、知识和真理的分类下，涵盖了哲学领域的 DevOps。此外，讨论根据科学领域解释了 DevOps，因为社会科学和应用科学的子领域通过社会学、心理学、经济学和工程学等领域进行了研究。通过关键的DevOps概念和实践进一步审查了哲学和科学子域的兼容实例，并将其应用于业务框架。（转自 Brandon T. Klein）

1、引言

DevOps，对某些人来说是一种成功的范式，对另一些人来说是一种神秘而深奥的实践。互联网社区将 DevOps 的定义概括为一组结合软件开发 (Dev) 和信息技术 (IT) 运营 (Ops) 的实践，旨在缩短系统开发生命周期 (SDLC) 并提供持续集成和持续部署高质量软件（DevOps，2020 年）。本文通过描述 DevOps 的基础哲学和科学以及这些领域如何指导其成功，提出了对 DevOps 的简明理解。

就本文的范围而言，术语 DevOps 包括行业术语 DevSecOps ([Development + [Sec]urity + [Op]eration)。安全性对于 DevOps 范式和实践来说应该是隐含的和无所不在的。DevOps 中的安全性与质量保证息息相关，通过 SDLC 等方法提供高效、有质量保证的解决方案（Laskowski，2011）。

通过 SDLC 确保安全是每个人的责任，并且在技术行业中得到了支持（Vogels，2017）。DevOps 起源于软件开发和IT技术社区，是在更大的实践中执行的实践集合；然而，DevOps 的范式和原则对于一般技术解决方案工程和其他领域是可重用的（Sajjad，2020）。以下部分提供了对 DevOps 哲学和科学的简明理解，这些哲学和科学协同定义了 DevOps 的本质。

2、分类

以下建议的 DevOps 分类法从根本上涵盖了哲学和科学领域。图1说明了针对哲学和科学提出的 DevOps 分类法以及它们各自的分支、子域和实例。在哲学领域下，认识论和本体论的分支将通过信念、知识和真理的附加分类来检查。将通过以下概念和实践进一步检查这些子域的适应实例：敏捷开发、质量保证和精益生产。在科学领域，社会和应用的子域将通过社会学、心理学、经济学和工程学的额外分解来检查。这些子域的适应实例将通过文化转型、更快的上市时间和自动化等概念和实践来进一步检查。

3、哲学


在这篇文章中使用“哲学”，将在词汇上归因于剑桥词典的定义，“一种特定的信念、价值观和原则体系”（哲学，nd）。这里提出的 DevOps 哲学是通过行业公认的方法和实践持续改进和交付高效、有质量保证的解决方案工程。以下部分并非详尽无遗；而是通过检查相关分支：认识论和本体论对 DevOps 哲学和核心哲学原则的学术认可。

3.1 认识论

根据牛津大学出版社的说法，认识论的定义是“知识理论，特别是关于它的方法、有效性和范围”；该定义进一步指出，“认识论是对区分合理信念和观点的学术研究”（认识论，n. d.）。以下小节探索了 DevOps 汲取知识的学术和行业来源，如：概念、框架、方法和实践。通过支持子领域：信念和知识，进一步探索了对 DevOps 的认识论理解。

3.1.1 信念

剑桥词典将信念定义为“确信某事存在或真实的感觉”（信念^n. d.）。虽然 DevOps 可能意味着多种信念，但这里探讨的 DevOps 的基本信念是敏捷。DevOps 的核心理念是，应该减少从开发到运营的时间（速度/敏捷性），以获得一个有质量保证的解决方案（输出）。它努力减少和缩短构思、开发、生产和输出中的反馈循环。因此，采用快速、高效响应方法的信念对于 DevOps 至关重要，因此与敏捷方法具有共同的亲和力。

敏捷方法，或敏捷，是项目管理社区对基于快速迭代开发和协作周期（称为sprint）的计划、执行、开发和产生输出的有效性所持有的一种信念。企业、联邦和学术机构以及专业机构开发并采用了各种方法来管理产出（例如产品和服务）；从传统瀑布到敏捷的进化的自适应方法（Satzinger 等，2009）。敏捷起源于一群希望改进软件开发过程的软件专业人员。集体软件专业人士起草了著名的敏捷宣言，其基础源于12条原则，这些原则共同建立了敏捷（Beck等人.，2001）以及后来的 DevOps 的信念结构。

企业和联邦机构都要求对时间敏感和关键任务的工作进行加速解决方案工程。关键任务工作的解决方案工程对速度的需求是如此迫切，有一种格式重新设计了敏捷的杰出冲刺（Sprint）过程，成为一种互补的格式，称为设计冲刺（Design Sprint）。设计冲刺的目的是将关键任务需求的问题解决提炼为五天：第一天制定目标；第二天构思解决方案；第三天选择解决方案；第四天——开发原型；第五天测试原型并获取经验教训，以决定下一步如何开展（Knapp et al.，2016）。敏捷哲学渗透到 DevOps 中，并在实践中建立敏捷性。DevOps 的概念和实践依靠速度来快速设计高效、有质量保证的解决方案，并通过集成和开发来持续改进和交付所需的解决方案。

DevOps 应用敏捷信念的一种方法是通过 CI/CD，这是一个与持续集成和持续交付相关的技术行业术语。然而，这种理解应该扩大到包括：CI 是持续改进，CD 是持续开发。CI/CD 的这种扩大符合从持续集成中持续开发的需要。此外，持续集成的目的是改进之前的迭代，并尽快持续交付所提到的改进。因此，增强的 CI/CD 模型是一个持续不断的CI/CD（持续改进和持续交付）循环，包含单个和/或多个 CI/CD（持续集成和持续开发）流水线的聚合子循环。CI/CD 的实现在战术上是通过软件工程流水线执行的，可以从简单的（一条流水线）到复杂的（多条流水线）。实现的流水线可以相互连接或相互排斥；CI/CD 流水线的架构是根据需要定制的。

CI/CD 模型应用于软件开发和技术运营，以加速交付解决方案输出。任何集成都应该是对输出的渐进式改进。因此，任何开发都应该由集成决定的改进进行驱动，这些改进是由持续改进的反馈循环驱动的，以便提供持续交付改进后的输出。在 DevOps 中通过 CI/CD 应用的敏捷信念允许产出快速失败，快速学习/改进，并缩短关于知识的反馈循环周期。

3.1.2 知识

根据牛津英语词典，知识是“你通过教育或经验获得的信息、理解和技能”（知识，nd）。广泛的技术理解和技能组合对于高效实践和执行 DevOps 至关重要。实践DevOps 的知识输入是大量和多方面的，正如领先技术行业当前的招聘说明所示。术语“T型人才”描述了需要广泛的技术知识和深厚的专业技术知识的 DevOps 专业人员（DevOps Institute，2019年）。

除了 DevOps 从业者需要的知识之外，围绕 DevOps 过程的知识还包括一系列抽象和具体的信息，涵盖多个技术和非技术学科和领域。然而，关于所需知识的各个学科和领域有一个基本的融合——通过高效的、有质量保证的方法持续改进产出。

关于知识获取、表达、评估和保留集成在反馈循环中的重要性的认识已经通过正式的概念得到了解释，例如：质量控制一规范、生产、检查的谢沃夫循环（谢沃特，1939年）；戴明对质量控制和改进的演绎一计划-执行-研究-处理（PDSA）（戴明，2018年）；戴明的工作在日本被翻译成计划-执行-检查-处理（PDCA）（今井，1986）。例如，当一个企业制定了一个策略（计划）来创建一个新的小部件时，小部件向市场的发布（执行）允许企业收集关于小部件的市场信息进行分析（研究/检查）。使用DevOps，分析的知识可以在下一个开发周期中快速集成（处理），以改进小部件及其交付。因此，在 DevOps 中，获取知识的时间缩短了，并持续集成到开发中，以持续改进交付的产出。

像谢尔沃夫循环、PDSA和PDCA这样的正式概念为 DevOps 中的问题解决/决策提供了结构和方法。更快解决问题或做出决策的能力成为使用DevOps的企业或机构的竞争优势。知识成为持续改进的必需品，获取、保留、共享或消费知识的能力决定了重大的业务决策、战略和未来结果。DevOps 通过遵循基于谢尔沃夫循环、PDSA和PDCA的分阶段方法，确保知识得到适当的循环，以提供高效、有质量保证的解决方案。

为了对通过谢沃夫循环、PDSA和PDCA等过程获得的关于质量改进的知识进行基准测试，通过六西格玛应用了一种数据驱动的方法。六西格玛由摩托罗拉创立，旨在通过统计过程控制和全面质量管理的结合来解决质量问题和降低错误率（Tennant，2001）。六西格码方法为 DevOps 提供了对当前质量状态进行基准测试的知识，以便努力实现有保证的产出的必要增量改进。

定义、测量、分析、改进和控制这一过程被称为DMAIC（发音为Duh-MAY-ick）是六西格玛改进的五个阶段（George et al.，2005）。六西格玛改进的五个阶段指导 DevOps提供如下质量有保证的解决方案：1）为期望的产出设置初始质量级别（定义）；2）将初始产出具体化（测量）；3）从质量和错误级别审查知识（分析）；4）集成和开发对新产出的已知问题的修正（改进）；最后，5）确保后续交付周期只包括改进的产出（控制）。这个数据驱动的改进周期通过知识获取和反馈循环为 DevOps 不断重复。

从 DevOps 中使用六西格玛收集的知识提供了必要的过程，以持续提高质量水平，并在下一个高效、有质量保证的解决方案的持续交付周期中减少/消除已知错误。为了不断减少错误或其他导致限制的问题，DevOps 不断寻找关于现有增值和非增值活动的真相，以持续改进和持续交付高效且有质量保证的解决方案。

3.2 本体论


韦氏词典定义中本体论的词汇表示如下，“形而上学的一个分支，与存在的本质和关系有关”（本体论，n. d.）。多亏了 Patrick Debois （梅扎克，2018年），DevOps 自2009年以来就已存在。然而，DevOps 的概念/实践有着显著的熟悉性，因为它是从经过审查的方法、实践、框架和概念的和谐集合中演变而来的。下一节通过子域：真理，来探索DevOps 的本体性质。

3.2.1 真理

前面关于认识论及其子成分——信念和知识——的章节为德沃普斯的本体论真理奠定了基础。下面对真理的讨论并不意味着德沃普斯中所有真理的详尽列表，而是对在最高级别上体现德沃普斯真理的讨论。根据韦氏词典（真理，n. d.），真理是“真实事物、事件和事实的主体：现实”。

关于 DevOps 的真正真理是——精益。DevOps 中的“精益”类似于由 John Krafcik 创造的用于反映丰田汽车公司（Toyota）的丰田生产系统（TPS）的“精益生产”方法；与它的前身大规模生产相比，它有意寻求不断减少或消除生产结构中的无关项目和低效率（沃马克等人，2007）。


TPS从福特生产系统和美国超市的工作流程中获得灵感。福特生产系统是亨利·福特倡导的大规模生产模式。从那时起，TPS在丰田大野耐一（大野，1988年）的领导下成为一个持续改进的、准时制、看板拉动系统。TPS的额外改进来自新乡重夫的快速换模，也被称为SMD（新野，1985年）。

通过丰田的成功和在不同业务领域普遍采用TPS，精益生产已经被检验和验证为真理。精益生产思维方式成为一种思维方式——精益思想。精益思想就是真理：一项活动要么是精益的，要么仍然包含非必要的浪费（在日语中被称为m^uda）抑制了要实现的真正价值（沃马克&琼斯，1996）。使某样东西“精益”的概念可以被认为是使它精确地由有效优化所需的确切项目组成；任何额外的组件都被认为是多余的、非增值的，并导致价值减少或变得次优。

采用 DevOps 产生的输出从精益思想开始，通过最小可行产品(MVP)概念实现节约特性标准化(Ries, 2011)。节俭不应该与粗制滥造联系在一起，而是应该在资源和期望方面明智、谨慎和经济的背景下理解。DevOps中的MVP不应该牺牲质量。相反，应该在 CI/CD（通过持续集成和开发的持续改进和持续交付）的生命周期中分阶段交付高效、有质量保证的 MVP 功能。此外，DevOps 通过持续的知识获取和将所述知识再投入到下一个 MVP 开发周期来逐步改进初始 MVP。DevOps 重复改进循环，将“完美”或“接近完美”作为最终目标。但是请注意，完美的构成将取决于业务/机构的需求。


效率是 DevOps 及其成功的重要咒语，源于对实践各个方面的精益思考。在使用DevOps的同时，精益思考并使解决方案精益，这与爱因斯坦（2019年）熟悉的格言“事情应该尽可能的简单，而不是更简单。”（第475页）非常一致。从精益编程到精益CI/CD 流水线，DevOps 的生态系统应该只包含确切需要的东西，仅此而已。额外的浪费将使DevOps实践膨胀和过载，导致繁琐的维护和操作，这是不理想的。DevOps 的精益思想是一个真理，涵盖实践的许多特性，如软件工程和计算，都采用精益思想。


精益思维对软件工程和计算来说是很自然的，因为两者都来自数学领域。在数学中，算法应该简化（简化）到最简单的形式（Boyer&Merzbach，1991）。任何与算法所需功能无关的附加项目都不在范围内，也不需要存在。软件工程精益代码可以从开发干净代码的愿望中识别出来——简单、直接的代码（Martin，2008）；此外，引用Hoare（1969）的话，“计算机编程是一门精确的科学”（p.576）。精益计算环境是可取的，正如Unix的集体哲学所承认的那样，通过消除或不增加不必要的混乱和复杂性来使每个程序做好一件事（McIlroy et al.，1978）。其他精益计算环境包括极简主义的操作系统，这些操作系统只包含对所需功能至关重要的特定元素，并且能够在需要时及时修改元素（Geer，2009）。


精益是 DevOps 的真理，使实践能够通过减少浪费不断寻求改进和优化，精益思想对DevOps 的效率和成功至关重要。DevOps 从根本上认为一个高效、有质量保证的解决方案应该是精益的，以便减少/缩短构思、开发、生产和输出中的反馈循环。将精益、敏捷和质量保证相结合，提供了指导 DevOps 理念的原则的简明视图，以实现高效、有质量保证的解决方案。

4、科学


根据牛津大学出版社的说法，科学的词汇定义是，“包括通过观察和实验对物理和自然世界的结构和行为进行系统研究的智力和实践活动^（科学，nd）。以下部分是通过对科学领域内的关联分支：社会科学和应用科学的检查，对DevOps固有的科学本质的简要学术描述。

4.1 社会科学


根据牛津大学的说法，社会科学是“对人类社会和社会关系的科学研究”。以下部分传达了社会科学的三个重要学科，它们有助于 DevOps 的科学性：社会学、心理学和经济学。

4.1.1 社会学与心理学

根据吉丁斯（1923）的说法，“社会学是试图通过物理、生命和物理原因的运作来解释社会的起源、成长、结构和活动，并在进化过程中共同作用”（p.8）；根据阿姆尔特（1976），“心理学是对行为的研究；也就是说，研究人类和其他动物的可观察行为”（p.7）。虽然社会学和心理学是独特的领域，但它们将被一起检查，以更好地理解一个组织对 DevOps 的采用。以下部分探讨了 DevOps 文化和变革，特别是适用于采用这种做法的商业组织。然而，所分析的许多要点适用于其他类型的组织，如联邦和学术机构。

企业是社会系统的系统组织，努力有效地激励自主、自由意志的人来实现共同的行为和组织目标（Hersey&Blanchard，1977）。要让企业中的不同系统接受 DevOps，领导者和员工需要做出重大的承诺和努力。个体和集体都需要在文化上采用持续改进等 DevOps 原则，这会强制形成持续学习的环境。

DevOps 的采用将企业文化转变为在社会学和心理学新范式中的思维和行为。


当一个企业拥抱一个新的范式时，新的能力就会出现，需要评估当前能力的持续性。以前的业务范式下的能力可能与 DevOps 不一致，因此可能需要消除或转化为新的能力，以防止它们变得僵化（Leonard，1992）。


企业应该致力于根据需要进行调整或重塑，以满足向 DevOps 成功转型的需要。高管领导应该以透明的方式就DevOps转型进展向员工提供一致、积极主动的沟通，以消除障碍并确保成功。重塑经营理念、学习新的能力和消除转型障碍，可以采用 DevOps 原则和实践。领导层必须坚定不移地做出企业转型的承诺，并被员工有效执行，否则就会失败（戴明，2000）。

当过渡到 DevOps 时，新的能力无疑需要新的技能。企业必须致力于培养具备 DevOps 必要技能的员工队伍，如T型人才，为个体提供重要的心理价值，为劳动力提供社会学价值。为个体提供价值的能力加强了个人和企业之间的组织承诺（Margelyte-Pleskiene&Veinhardt，2018），这反过来又加强了向 DevOps 的成功文化转型。如果新技能得不到培养，个人可能会变得无归属感并寻求替代企业继续职业发展。

使用技术的企业必须认识到采用 DevOps 的必要性，否则就会出现组织退化（Le Mens et al.，2015）和组织犬儒主义（wanous et al.，1994）。此外，企业必须防范因傲慢的领导（Sadler-Smith et al.，2016）、集体傲慢（Sullivan&Hollway，2014）和成功综合症（Tushman&O’Reilly，1996）而对 DevOps 的抵制，所有这些都可能扼杀或阻碍向 DevOps 的采用和转变。

企业的转型并非易事。如果企业能够一开始就明确并向员工传达转型的价值，转型的障碍就更容易消除。从丰田的“丰田之道”中可以找到成功的文化转型的参考模型。通过采用 TPS 并积极拥抱员工以培养社会学和心理学价值，丰田的文化转变为“丰田之道”（Liker & Franz，2011）。丰田将“丰田之道”描述为植根于制造精神（日语为 ^monoz-ukuri）（Toyota Motor Corporation，nd）以及两个原则：持续改进（日语为kaizen）和尊重人（Liker，2004 年） ）。“丰田之道”的原则将丰田的文化转变为积极的学习环境，这加强了员工的组织承诺（Allen&Meyer，1990），并为行业的长期成功做出了重大贡献（Sobek II&Smalley，2008）。

DevOps 文化类似于关于积极、有影响力的业务和文化价值的“丰田之道”。DevOps提供了一种独特的组织文化，通过基于科学的持续改进方法，实践持续交付高效、有质量保证的解决方案。DevOps鼓励集体和个人建立一个基于可重复信息的科学环境来组织、研究、开发和评估解决方案（Wallace，1971）。

4.1.2 经济学

根据马歇尔（1890）的说法，“经济学一方面是对财富的研究，另一方面是对人的研究的分支”（p. l）。经济学有两个主要分支：宏观经济学和微观经济学。宏观经济学研究全球经济，而微观经济学研究个人和企业的经济。为了本文的范围和简洁考虑，本节描述了DevOps如何通过减少高效、有质量保证的产出（如产品/服务）进入市场所需的时间这一重要特征来增加个体企业的财富。虽然本节侧重于企业的DevOps，但如果不承认更快的上市时间对大学和联邦实验室等研究机构的价值，那就太过分了，尽管如此应用，该短语需要稍微修改为更合适的“Faster-Time-to-Science”（NASA，2013）。

DevOps 的应用为业务运营加快了提供向市场投放有质量保证的产品。通过DevOps带来的生产的加速可以被视为更快的投产时间，从而实现更快的上市时间。更快的上市时间的概念源于“上市时间”，与产品到达消费者市场的前置时间缩短相关（Charney，1991）。

DevOps 通过其对敏捷、精益、质量保证、文化转型和自动化等关键概念的普遍应用，为企业提供了重大影响。上述概念的整合为管理和改进业务流程提供了附加值，最终目的是降低成本，同时保持甚至提高客户满意度。企业DevOps的整合通过降低成本和差异化来改善价值链，这可以在竞争激烈的行业中提供竞争优势（波特，1985）。此外，DevOps 增强了组织以更快的频率为市场提供有质量保证的产品的能力（更快的上市时间），从而增加了满足客户的机会。一家公司比竞争对手更快、更频繁地提供客户满意度的能力是竞争优势和对抗其行业内竞争力量的堡垒 (Porter, 1997)。

由于消费者支出和消费者保留带来的现金流，提高客户对交付产出的满意度是任何业务的关键成功因素。因此，企业可能会花费大量资源通过一致性质量来获得客户满意度和留存率，一致性质量侧重于在市场发布前识别和消除缺陷，以确保产品达到或超过预期的设计规范（Garrison et al.，2017）。DevOps 通过其高效、有质量保证的持续改进和交付方法，增强了企业获得一致性质量的能力。有质量保证的产出越早在竞争对手之前进入消费市场，就越早有机会从消费者支出中进行销售（即流入现金流）。如果企业知道流入的现金流量，那么由于潜在的不确定性和失败的不足之处，该货币资源当前的价值将高于未来：内部人员、流程和技术；或者外部与宏观经济和地缘政治不确定性有关（国际清算银行，2011年）。此外，时间就是金钱；货币的时间价值原则认为今天的一单位货币比未来的同一单位货币更有价值（Kimmel et al.，2018）。因此，更及时的流入现金流的实现和购买力允许企业更快地做出货币决策；这是在竞争激烈的市场中的一种关键能力。如果一家企业获得了相对于竞争对手的竞争优势和比较优势，这些优势对企业来说将变得非常宝贵，并被用来引领行业。


虽然宏观经济和地缘政治风险超出了企业的控制范围，但运营风险并非如此。运营风险包括技术系统和技术风险，两者对 DevOps 的实践和持续都具有重要意义。由于技术的购买和使用可能不会提供增值，因此企业会精心制定战略和成本管理：技术如何通过规模经济或范围经济形式的提供运营效率提从而提供增值（Saunders&Cornett，2017）。DevOps通过提高产出速度（更快上市时间）来提供增值，以获得规模经济，并进一步提高满足产出需求的能力，实现范围经济。DevOps希望帮助企业提供一种更快上市的方法（更快上市时间），这反过来又为设计和实施DevOps所需的技术提供了一个有效的投资回报。因此，通过全面质量管理和运营风险管理的协同作用，DevOps 可以补充并进一步增强已经理解的业务成功范式（Luburic，2012 年）。DevOps 提供持续改进和持续交付解决方案（输出），同时对当前质量状态进行基准测试，以努力实现高效、有质量保证的解决方案的增量改进。

4.2 应用科学


根据史密斯（1967）的说法，“应用科学可以被视为一组实验方法、实验确定的常数和理论”…“这可能对工程师和其他必须解决社会问题的人有帮助 通过使用任何可用的方法和概念，而不管其内在的智力兴趣或或缺乏这种兴趣”（第57页）。以下部分传达了有助于 DevOps 科学性质的应用科学的重要学科：工程。
4.2.1 工程学


根据《工程世界》（1919年），工程是“通过组织、设计和建造，安全和经济地应用支配自然力量和材料的科学定律的实践，以造福人类”（第 34 页） ）。

正如本文前面提到的，DevOps起源于软件工程，同样，贯穿实践的重要术语源于各自的工程领域。软件工程包括以下领域的知识：计算机编程、架构（例如数据、软件、系统）、解决方案工程；以及各种学科，如：计算机科学、数学、质量管理、系统工程（Bourque et al.，2014）。

DevOps 工程方法通过坚持合理的数学和工程原则，极大地提高了效率和成功，这些原则包括：抽象（Russell，1903），模块化（Gausier&Pont，1970），多态性（Cardelli&Wegner，1985），可移植性（Newey et al.，1972），封装（Pamas，1972），可重用性（Rich&Waters，1983）。

工程自动化是 DevOps 的一个重要方面，也是其成功的关键组成部分。此外，自动化对现代和未来的计算技术至关重要。2001年，IBM宣布自主计算是必要的，并通过四个概念提供了自我管理能力的原则：自我配置、自我优化、自我修复和自我保护（Kephart&Chess，2003）。然后在2005年，IBM为自主计算提供了一个架构蓝图（IBM，2005）。约翰·冯·诺依曼（John von Neumann）在自主计算领域开创了先河，他就自动计算机器与人类神经系统进行了详细的比较（冯·诺依曼（von Neumann），1951年），后来又提出了自复制自动机的概念（冯·诺依曼（von Neumann），1966年）。DevOps 成功的一个重要贡献在于工程 CI/CD 流水线的实践，以自动化配置、优化、修复和保护高效、质量有保证的工程解决方案。

DevOps CI/CD 流水线的实施利用复杂的技术来增强和促进不同系统的自动化，这需要非平凡的、定制的互操作性，然而开发的软件已经简化了实现（Klein等人，2020）。软件和系统运维团队，或全栈工程团队协调接口以开发、管理和运维用于建立所需流水线的系统。尽管如此，DevOps CI/CD流水线的集成需要进行工程设计以实现表达自动化，从而工程自动化以实现自动化工程（即构建构建机器的机器）。

DevOps 中的工程自动化，例如但不限于 CI/CD 流水线，由协同、可重用、多态的构建块组成：图像、脚本、应用程序编程接口（API）（Klein&Miner，2018）。DevOps中的工程构建块类似于计算机科学中的抽象数据类型和数学中的函数（高阶函数）。在设计通用的、可重用的架构模式和解决方案时，构建块以最抽象的形式被无类型化，然后在实例化时被类型化，以开发高效的、有质量保证的解决方案。


DevOps 中工程构建块的组合为架构师和工程师设计各种可重用模式和解决方案提供了更高的表现力，从琐碎到复杂。由于工程构建块可以被软件定义，因此已经进行了自动化和计算的高级开发。整个系统和SoS（系统的系统）已经演变为与软件定义的解决方案进行集成（Juve&Deelman，2011）。完全软件定义的系统和SoS已经部署到各种物理和数字环境中，用于各种生产工作目的（Gannon et al.，2017）。即使物理调制解调器系统和SoS成为软件定义的非典型命题（Miner&Klein，2018）也已经初始化（Miner et al.，2018）。


由于工程构件之间的表现性相互作用，DevOps 中存在先进的高效、质量有保证的计算解决方案。这些工程构件增强了完全开发的软件定义系统和/或SoS解决方案的使用，这些解决方案提供了一系列有利的战术架构模式以快速使用，如：保存点、短暂性、不可变性和幂等性。与视频游戏或数据库的保存点概念相似，软件定义的解决方案可以表现地保存整个生态系统（如图像、脚本、API）。一旦生态系统被保存，CI/CD 流水线可以重新部署解决方案，以恢复或回滚到所需的状态；和/或继续存在于不同的生态系统中以求生存或合规（Hadgu et al.，2016）


临时解决方案只在它们特别需要的那一刻有效，然后关闭直到再次需要或通过 CI/CD 流水线终止。短暂的，通过计算，短暂的、软件定义的计算环境的使用有所增加（Cotta 等人，2016 年）。不可变的解决方案被设计为具有不变和持久的状态。但是，如果在解决方案中发生不期望的改变，那么改变的解决方案被破坏，并通过 CI/CD 流水线重新实例化到最初预期的期望状态。将不可变性实现到整个解决方案中的这种实现包括不可变基础设施（Mikkelsen et al.，2019）。无论通过 CI/CD 流水线部署或应用的次数如何，幂等解决方案都旨在始终如一地提供不变、持久的存在和行为。这种幂等的软件定义计算解决方案包括分布式云环境 (Ramalingam & Vaswani, 2013)。


DevOps 自动化在现代技术、解决方案架构和高级计算领域的工程中普遍存在，例如云计算、高性能计算、大数据、机器学习/人工智能、物联网、机器人和扩展现实。当基于软件的解决方案的开发和部署的自动化相结合时，实现了更高的表达能力和DevOps自动化的成功。通过DevOps CI/CD流水线和工程构建块的结合，通过工程自动化开发高效、质量有保证的解决方案的能力变得可实现和可维护。

5、结论

DevOps 是一个多方面的、折衷的概念和实践，起源于学术界和行业公认的方法和实践。DevOps 背后的哲学和科学是其被快速采用和成功的原因。本文通过认识论和本体论的分支，在信念、知识和真理的分类下，涵盖了哲学领域的 DevOps。此外，讨论根据科学领域解释了 DevOps，因为社会科学和应用科学的子领域通过社会学、心理学、经济学和工程学等领域进行了研究。通过关键的DevOps概念和实践进一步审查了哲学和科学子域的兼容实例，并将其应用于业务框架。（转自 Brandon T. Klein）