提升 DevOps 文档成熟度的过程与达到 DevOps 或 DevSecOps 成熟化的历程是类似的。为了能在软件迭代交付周期内按时交付优质的文档，DevOps 和 DevSecOps 的文档实践也需要是敏捷的。这与实现 DevOps 类似，只是更偏向自动化和敏捷的内容处理方法。如果文档现在才进入你的机构的 DevOps 讨论，那么是时候让文档实践追上 DevOps 的步伐了。下面是 DevOps 文档成熟度的四个层次：第一层：临时且孤立在最低一级成熟度（最不成熟），文档编制工作没有和 DevOps 开发对齐。开发团队和文档团队按照各自的路线开展工作，常常导致文档落后于开发。在竞争激烈的“云”世界里，因为文档问题而推迟产品发布是不可接受的。人员这个阶段的文档编制人员还没有摆脱传统的工作方式。 技术写作 technical writer 人员隶属于一个中心化的单独团队，与开发团队是脱节的。技术写作组和开发团队之间的鸿可能是由多方面原因造成的：造成团队分裂和孤立的公司政治团队只是将技术文档视为项目验收清单上的检查项，而不是推动项目成功的资产事后才雇佣技术写作人员技术写作的优先级与开发团队的实际情况不匹配这个阶段，另一个在人员配置上的挑战是如何“界定工作完成”。刚接触敏捷实践的技术写作可能难以适应 CI/CD 工具链和流程。文档工具和流程这个阶段的技术写作仍习惯于使用传统的办公工具，比如办公套件和布局程序。这些工具不够敏捷，没有版本控制和内容管理的要求。它们无法与 DevOps 工具链高效集成，不能支撑快速开发。在这个成熟度，技术写作仍然参照遗留的模板和流程。成果这个级别交付的文档可能是过时的，甚至缺乏技术准确性的。如果开发团队以 DevOps 的速度推进工作，而技术文档编制却遵循传统的非敏捷流程（使用专有的工具和交付格式），这就很难让文档迭代速度并跟上应用程序的变化。第二层：实验和试点DevOps 文档成熟度的第二层是实验/试验阶段。这个阶段是 DevOps 团队主管和技术写作采取行动打造更敏捷的文档实践和工具的第一步。理想的情况下，这些实验是 相关方 stakeholder 支持的试点项目的一部分。他们能够从文档交付流程的改善以及其与 DevOps 实践的集成中获益。人员本阶段的人员可能来自以下三种形式：有远见的技术写作为了更好地完成工作，用自己的时间来实验更敏捷的工具。并且向领导层提出更敏捷的文档编制过程的想法。DevOps 负责人或工程师试用 Hugo 和 Jekyll 等工具，并将这些工具集成到 CI/CD 流水线中。然后 DevOps 小组教授技术写作如何使用它们。团队引入了第三方承包商或顾问，他们在 DevOps 文档工具方面具有专业知识，并且了解文档工具适合嵌入到 CI/CD 工具链和 DevOps 生命周期的位置。文档工具和实践Hugo 和 Jekyll 是本阶段开始出现的工具。在这个阶段也出现新的内容策略和技术写作方法。成果实验试点阶段理想的成果应该能够“ 落地并推广 land and expand ”。也就是说其它项目组也可以将其付诸实践。这个阶段的实验也包括内容策略和发布流程上的根本性变化。其它非试点项目组的技术写作可以学习和使用它们。试点带来的另一个可能的产出是 技术写作招聘流程 的变化。你需要针对 DevOps 和你新引入的文档工具对内部编写人员进行培训。新的文档工具和流程是此阶段的关键成果，你需要通过演示、状态报告和内部案例研究等方式，将这一成果推给领导层、相关方和其它团队。第三层：部分自动化和扩展DevOps 文档成熟度的第三层（部分自动化和扩展）就是“落地并推广”的进一步行动。在这个阶段，其它 DevOps 团队借用试点项目中产生的 DevOps 文档工具和流程，吸取其中的经验教训。人员在这个成熟度，技术写作和 DevOps 团队开始更紧密的协作。招聘新的技术写作主要关注具有 DevOps 环境经验的人选。工具和文档实践技术写作开始从抛弃传统的工具和流程，转到更敏捷的文档工具上，比如：docToolchainDocbookHugoJekyll在这个成熟度，技术写作也负责调整遗留的文档实践。成果DevOps 文档工具和实践超越试点项目，成为标准实践。在这个成熟度，随着新团队使用新的文档工具和流程，持续学习是必不可少的。第四层：完全采用在最高一级的 DevOps 文档成熟度（完全采用且自动化）所有工具、实践和流程已经到位，以支持将文档为项目中的高优先级事项。要达到这一成熟度，需要不断实验、迭代和团队协作。人员完全自动化使 DevOps 团队与技术写作之间的协作更紧密。这一阶段的标志是，技术写作牢牢地融入到项目团队的工作流程中。文档工具的维护工作由一些大型企业负责，它们拥有专职维护 DevOps 工具链的工程师。文档工具和实践在这个成熟度，技术写作统一采用 Markdown 语言和自动化工具。成果本阶段的成果是一套完整的工具和实践，它们支持自动化在线文档发布。技术写作者可以按需发布和重新发布文档，以支持迭代开发流程。持续学习是这个阶段的另一项成果。技术写作和工具链维护者寻找改进自动化和流程的方法，以帮助文档实践。总结提升 DevOps 文档成熟度的过程跟达到 DevOps 或 DevSecOps 成熟化的历程是类似的。我希望行业能够将更灵活的文档实践和工具作为公司推进 DevOps 进程中的一个部分。提高 DevOps 文档成熟度应该作整体 DevOps 成熟化甚至 DevOps 到 DevSecOps 转型的一部分。（题图：MJ/154429b7-bdfc-4b34-9a81-55d9fe33ab07）via: https://opensource.com/article/22/2/devops-documentation-maturity作者：Will Kelly 选题：lujun9972 译者：toknow-gh 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
无论你是刚刚开始在你的组织中使用 DevOps，还是仅仅想改善你现有的文化，请考虑这些技巧以及它们与你组织的未来的关系。你为什么要构建 DevOps 文化？开发团队和运维团队的精简协作有很多好处。效率是首要目标：提高新软件部署的速度，减少等待的时间。培养同事之间的信任可以提升员工的满意度，激发新的创新，并对盈利能力产生积极的影响。DevOps 是一个很广泛的思想，大家的理解也见仁见智。每个公司对于如何实行 DevOps 也各不相同。这种意见的多样性实际上是一件好事 —— 这么多的观点对于建立更强大的团队是很有用的。本指南将探讨在 DevOps 文化中鼓励同事之间更好地合作的最高技巧。下面每个部分从不同的视角介绍 DevOps 文化，并探讨了将它引入员工队伍的方法。流程的持续发展DevOps 文化的这一核心原则使它与许多其他类型的工作场所的风气区别开来。DevOps 哲学说，犯错是有积极意义的，因为这表明你在尝试新的想法。DevOps 文化的核心是不停地创造。实际上，这意味着当测试结果显示事情由于你的改动而变坏时，不要懊恼。我们要认识到，进化的过程不是线性的，通往成功的道路也从来不是一条直线。DevOps 专家 Gene Kim 主张勇于承担风险和进行实验。鼓励你的团队尝试不寻常的任务，以得到新的领悟。你的组织应该以利润为导向吗？你能允许你的团队尝试一些新东西（非指个人兴趣项目）吗？持续的流程发展意味着对升级目前的方法持开放态度。优秀的销售领导懂得，结果比出勤率更重要，因此，关注团队的工作方式而不是工作量的多少始终是关键。随时提供反馈并积极寻求反馈成员之间增加信任是蓬勃发展的 DevOps 文化的另一个关键特征。无论你的员工是在学习如何建立联盟网络联系，还是试图设计他们的下一个 用户体验 调查，每个人都应该对他们工作的反馈持开放态度。但是，除非你的团队成员尊重彼此的意见，并相信反馈是本着善意的精神提出的，否则这永远不会发生。这种文化听起来可能是很难培养的；事实上，一些公司会比其他公司更努力地实现这一点。诚然，给予和接受反馈的成功很大程度上取决于员工的个性。在招聘过程中，也可以对此进行筛选。在你期望员工随时向同事提供反馈并主动寻求反馈之前，你应该以身作则。高管应该以身作则，公开要求公司成员对其战略决策提出探究性问题，并提供相应的反馈。不断改进在同事之间增加对智力信任的基础上，你的团队应该寻找方法来改善其工作。DevOps 的性质意味着软件开发团队将比传统方法更迅速地进行部署。这种开放的改进文化可以对开发和运维以外的部门产生积极的影响。你也可以自己去探索企业还有哪些领域会受到积极的影响。留意培训和提高技能的机会。即使一个培训课程没有广告上说的那么突出，但有机会与行业专家建立联系，并与未来建立联系，这可以提高你的组织内的思想多样性。为以后的开发保存当前的想法频繁使用的 Git 账户应该是你的 DevOps 工具链的一部分。你可以用 Git 作为软件开发和其他相关项目中产生的脚本的共同仓库。Git 作为 “版本控制” 工具而被熟知，Git 允许程序员保存他们工作的迭代、复用或改进其他人的工作。你的目标是能够保留好的想法以供将来使用。某个方法由于某种原因没有成功。然而，那套想法在当时是错误的，并不意味着它在未来永远无法成为有用的东西。由于 DevOps 的整个重点在于生产环境中的软件的端到端所有权，因此节省开发的迭代真正支持这一原则。你希望看到对手头的软件测试项目的持续关注和投入。一个简单的方法是要求开发者在开发者合同和最终项目报告中包含对未来工作的想法。确保技术服务经理知道他们应该要求提供在建设过程中出现的旁门左道的想法的例子。意识到这些小创新的人越多，在需要的时候就越有可能有人记住一个。坐在一起（物理上或逻辑上）目标是对彼此的工作角色以及它们之间的相互关系有一个共同的理解。你可以通过几个简单的方法实现这一目标，用一句话概括：坐在一起。邀请其他团队参加你们的会议，完整地分享用户反馈报告。一起吃午饭，一起计划虚拟的快乐时光，一般来说，要确保你的同事都在一起。大约 90% 的拥有成熟的 DevOps 协议的团队报告说，他们清楚地了解自己对其他团队的责任，而在不成熟的 DevOps 团队中，只有大约 46% 的工作者清楚地了解自己的责任。虽然与志同道合的人结成小团体，只与被雇来执行与你相同任务的员工在一起是很诱人的，但这对整个企业来说是很糟糕的。无论你喜欢与否，所有的人都是多面手，能够在一系列的情况下贡献自己的独特才能。密切协作的理念是尊重任何人对其周围正在进行的产品或工作流程提出改进建议的能力。如果你与公司内的其他部门保持一定的距离，你将会错过无数次分享智慧想法的机会。毕竟，你往往在交流中学习得最好。致力于自动化你应该以提高效率和加速流程的名义，寻求将单调的和重复的任务变为自动化。每个行业都有无聊的 —— 说得直白一点，就是愚蠢的 —— 每天或每周都要进行的工作。无论是手工将数据从一页复制到另一页，还是手工打出音频记录，每个级别的工作人员都应该坚持让机器在可能的情况下承担这些负担。现实是自动化技术每年都在进步，操作流程也应该如此。自动化测试 对 DevOps 非常关键，它是 CALMS 框架的第二个原则（其中的 “C” 代表 “文化”）。你怎样才能实现这一点？邀请员工公开表达他们认为工作的哪些方面可以自动化，然后 —— 这里是关键的部分 —— 支持实现自动化所需的设施。这可能意味着每年花 600 美元订阅一个软件程序、一套完整的企业应用现代化解决方案，或开发人员用两天时间来建立一个在内部使用新工具。无论哪种方式，你都应该评估自动化的好处，考虑你可以为每个人节省多少时间。DevOps 的统计数据不断表明，现代公司通过整合这些有益的原则，年复一年地得到了很大的改善。探索成功的新工作方式文化转变不会在一夜之间发生。不过，你越早开始，就越早看到结果。根据我的经验，当变化真正对以前进行了改进时，人们会接受它。DevOps 为这种改进提供了一个框架。无论你是刚刚在你的组织中开始使用 DevOps，还是仅仅想改善你现有的文化，请考虑以上几点以及它们与你组织的未来的关系。via: https://opensource.com/article/23/1/tips-effective-devops-culture作者：Yauhen Zaremba 选题：lkxed 译者：lxbwolf 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
将文档写作加入到 DevOps 的生命周期中。DevOps 正在挑战技术文档的规范，这在 IT 历史上是前所未有的。从自动化到提高交付速度，再到拆除瀑布式软件开发生命周期模型，这意味着业务和技术文档写作的理念需要做出巨大改变。以下是 DevOps 对技术文档写作不同方面的影响。技术写手的角色变化技术写手必须适应 DevOps。好消息是，许多技术写手已经加入到开发团队中，并且拥有合作关系和不断增长的产品知识的技术写手很具优势。但是如果一个技术写手习惯于独立工作，并依赖于领域专家的草稿作为文档的基础，那么就需要做一些调整。进行一些投资，以确保文档和其他与项目有关的内容开发工作获得所需的工具、结构和支持。从改变 技术写手聘用方式 开始。以 DevOps 的速度 编写文档需要重新思考内容规划，并打破 DevOps 团队和支持项目的技术写手之间长期存在的隔阂。DevOps 使开发团队摆脱了传统文档实践的束缚。首先，文档 完成的定义 必须改变。一些企业的文化使技术写手成为软件开发的被动参与者。DevOps 提出了新的要求：随着 DevOps 文化的转变，技术写手的角色也应发生变化。技术写手需要（且必须适应）DevOps 提供的透明度。他们必须融入 DevOps 团队。取决于组织如何塑造这个角色，将技术写手带入团队可能会带来技能上的挑战。文档标准、方法和规格虽然 DevOps 还没有影响到技术文档本身，但开源社区已经加强了对应用编程接口（API）文档的帮助，已经有不同规模的企业的 DevOps 团队正在使用这些文档。用于记录 API 的开源规范和工具是个非常值得关注的领域。我想这是由于 谷歌文档季 的影响，它使开源软件项目能够获得专业的技术写作人才来解决他们最关键的文档项目。开源 API 属于 DevOps 文档讨论的一部分。云原生应用集成需求的重要性正在上升。OpenAPI 规范（一个定义和记录 API 的开放标准）是在 DevOps 环境下 API 文档的良好资源。然而，该规范会导致文档的创建和更新过程变得很费时，这使其饱受批评。曾经也有短暂尝试过创建 持续文档 Continuous Documentation ，并且还有一个来自 CA（现在的 Broadcom）的创建 DocOps 框架的运动。然而，DocOps 从来没有作为一个行业运动流行起来。DevOps 文档标准的现状意味着 DevOps 团队（包括技术写手）需要在项目的最初阶段就开始创建文档。要做到这一点，你需要把文档作为一个敏捷故事和（同样重要的）管理期望，并且把它与年度绩效评估放在一起执行。文档工具文档的编写应该以一种所有团队成员都可以使用的格式或平台在线进行。MediaWiki、DokuWiki、TikiWiki 和其他 开源维基 为 DevOps 团队提供了一个编写和维护文档的中央仓库。让团队选择他们的维基平台，就像让他们选择他们的其他持续集成/持续开发（CI/CD）工具链一样。开源维基强大之处在于其可扩展性。例如，DokuWiki 包括一系列的扩展，你可以通过安装这些扩展来创建一个符合你的 DevOps 团队的创作要求的平台。如果你有足够的野心来加强你的团队的编写和协作能力，Nextcloud（一个开源的云协作套件）是一个让你的 DevOps 团队上网并给他们提供编写文档所需工具的选择。DevOps 最佳实践文档在 DevOps 转型中也发挥着作用。例如，你会想要记录组织从 DevOps 实现效率和流程增益的最佳实践，这些信息太重要了，不能靠着 DevOps 团中之间口耳相传。如果你所在的组织有多个 DevOps 团队，那么文档就是统一的力量，它可以促进最佳实践的标准化，并设置了衡量代码质量的基准指标。一般情况下，开发人员承担了记录 DevOps 实践的工作。即使他们的组织有技术写手，他们也可能跨开发团队工作。因此，开发人员和系统管理员能够捕捉、记录和交流他们的最佳实践是很重要的。这里有一些朝正确的方向发展的提示：提前花时间为 DevOps 最佳实践创建标准模板。不要陷入复制在线模板的陷阱。采访利益相关者和团队来创建一个符合团队需求的模板。寻找一些创造性的信息收集的方法，例如记录团队会议和使用聊天系统日志来作为文档的基础。建立一个用于发布最佳实践的维基。使用维基可以跟踪编辑和更新。这样的平台可以帮助团队在最佳实践发生变化时进行更新和维护。当在构建 CI/CD 工具链时记录依赖关系是非常明智的。尤其是当加入新的团队成员时，你会发现这些记录非常有用，另外当团队成员忘记一些事情时，这也是一种保险。最后，自动化对 DevOps 利益相关者和从业者都很有吸引力。在自动化中断之前，一切都很有趣。拥有自动化运行手册、管理指南和其他内容的文档（并且是最新的）意味着无论何时发生故障，员工都可以让自动化重新工作。最后一些想法DevOps 对于技术文档来说是一个积极的因素。它将内容开发纳入 DevOps 生命周期，并打破组织文化中开发人员和技术作者之间的隔阂。在没有技术写手的情况下，团队就可以使用工具来加快文档创作的速度，以与 DevOps 的速度相匹配。你的组织将如何把文档加入到 DevOps 生命周期？请在评论区分享你的经验。via: https://opensource.com/article/21/3/devops-documentation作者：Will Kelly 选题：lujun9972 译者：Veryzzj 校对：校对者ID本文由 LCTT 原创编译，Linux中国 荣誉推出
当商业 DevOps 工具市场着眼于平台时，是时候让开源 DevOps 工具重新定义它们的未来了。DevOps 的开源根基是无法动摇的，即便有预言称全球的 DevOps 市场将在 2026 年之前达到 178 亿美元。不断变化的工作环境、安全和合规性问题，以及风险投资公司等等因素正在将市场推向 DevOps 平台，开发团队可以在云中获得完整的端到端 DevOps 工具链。开源 DevOps 工具现状我们要搞清楚一件事：开源工具不可能从 DevOps 世界中消失。现在，在开源和供应商提供的 DevOps 工具之间存在着一种平衡，开发人员会在两者间选择适合他们的工具。事实上，很多情况下，一个开发团队起初会为他们的 DevOps 流水线选择一个开源工具，后来又升级到商业版本。三种开源 DevOps 工具实例下面我们介绍一些开源 DevOps 工具的例子，每种工具都已经有了围绕其建立的商业化生态。Git源代码管理工具 Git 作为源代码库，可能是 DevOps 工具链的主要基础之一。Git 的两个最佳商业案例是 GitLab 和 GitHub。GitLab 接受开发者对其贡献开源项目。GitHub 也在着手努力成为一个 DevOps 平台，推出了人工智能版的结对编程 GitHub Copilot，在推出后受到了一些开源团体的褒贬不一的评价。Jenkins作为一个开源的自动化服务，Jenkins 因其易于安装、配置和可扩展性而受到推崇。CloudBees 提供了 JenkinsX，JenkinsX 是一套开源的解决方案，可以为 Kubernetes 上的云原生应用提供自动化持续集成和持续交付（CI/CD）以及自动化测试工具。他们还为JenkinsX 提供商业支持，包括：访问 CloudBees 的专业技术技能24x7 技术支持访问 CloudBees 的文档和在线知识库Kubernetes随着越来越多的组织寻求企业级的容器编排解决方案，Kubernetes 的发展成为必然。尽管有人批评其复杂性。自然而然的，Kubernetes 周边有完整的、蓬勃发展的产业。根据 Allied 市场调研的数据，全球容器和 Kubernetes 安全 市场在 2020 年的估值为 7.14 亿美元，预计到 2030 年将达到 8.42 亿美元。目前的 DevOps 工具链各个行业仍有很多 自建 build-your-own （BYO）的 CI/CD 工具链在发挥作用。支持 DevOps 功能的开源项目仍在蓬勃发展。BYO 工具链可以集成其他工具，而且非常具有扩展性，这对于持续迭代其 DevOps 实践的组织来说一直是一个优势。在出于业务、IT 和安全原因寻求标准化的企业中，缺乏标准的材料清单可能是个麻烦。虽然 DevOps 平台的出现并没有被忽视，但许多组织早在大流行之前就将他们的 CI/CD 工具链迁移到了公有云。长期以来，工具链本身的安全性一直是一个不断上升的问题，而公有云基础设施提供了身份访问管理（IAM）和其他安全功能来控制访问。DevOps 平台是敌是友？DevOps 平台是一个端到端的解决方案，它将 CI/CD 工具链的所有功能放入云中。DevOps 平台的例子包括 GitLab 和 Harness。GitHub 也在采取行动，使自己成为一个 DevOps 平台。优势（即便只从企业买家角度考虑）DevOps 平台对那些已经适应了 SaaS 和云计算行业的基于消费和订阅的定价的企业买家很有吸引力。在这个远程和混合工作的世界里，对可维护性、安全、合规性和开发人员的生产力的担忧肯定是技术领导者的首要考虑。对这些人来说，在 DevOps 平台上实现标准化是很有吸引力的。劣势在依赖供应商提供的 DevOps 工具链时，人们会想到对供应商锁定功能的古老担忧。开发团队构建和维护其工具链的可扩展性不会像他们从头开始制作工具链时那样，更不用说引入新的工具来改善他们的工作流程了。DevOps 平台供应商也有潜在的经济方面的劣势。想一想，一个被高估的 DevOps 工具初创公司如果没有达到其投资者的高额财务目标，可能会发生什么。同样，也可能有一些较小的初创供应商得不到下一轮的资金，而慢慢消失。虽然 DevOps 平台的出现在很多方面都是有意义的，但它确实违背了促成我们今天使用的 DevOps 工具的开源精神。DevOps 工具：一个拐点随着工作模式的改变，人们对 DevOps 工具链的安全和合规性的关注必然会增加。正在变化的工作环境我们的工作方式与企业其他部门一样影响着 DevOps 团队。远程和混合 DevOps 团队需要安全的工具链。整个流水线中不断变化的协作和报告要求，如异步工作和经理要求返回办公室等，也是日益增长的必要条件。软件供应链安全市场在高调的攻击和美国联邦政府的回应之后，软件供应链安全市场引起了很多关注。目前还没有组织将软件供应链的攻击归咎于开源，但我们将看到 DevOps/DevSecOps 实践和工具的延伸，以对抗这种威胁。不过，当一切都结束时，DevOps/DevSecOps 的工具和实践将超过一些转向这一趋势的初创公司。结语对于 DevOps 领域的开源软件（OSS）项目来说，这还远远没有结束，但 DevOps 利益相关者有权开始询问未来的工具链。然而，OSS DevOps 项目确实需要考虑它们的未来，特别是考虑到日益增长的直接影响流水线的安全和合规性问题。DevOps 平台供应商与开源工具的未来趋势是合作性竞争，即 DevOps 平台供应商向作为其平台基础的开源工具贡献时间、金钱和资源。一个有趣的例子就是 OpsVerse，它用他们为客户管理的开源工具提供了一个 DevOps 平台。然后，还有一个未来，随着更多的企业构建的工具链迁移到云端，开源 DevOps 工具项目将继续繁荣和创新。via: https://opensource.com/article/22/10/open-source-devops-tools作者：Will Kelly 选题：lkxed 译者：lxbwolf 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
微软、谷歌、亚马逊、IBM 和甲骨文如今都在关注云上的 DevOps。这些大公司正在给企业提供 IT 自动化的服务。然而，DevOps 仍然在持续的演进中。DevSecOps、AIOps 和 NoOps 正在成为下一个流行词。随着开发和管理人员看到及时交付高质量软件的商业价值， 敏捷 Agile 方法论和 DevOps 也变得流行起来。拥有灵活的发布周期，并且交付具有 可扩展 scalable 和 可定制 customizable 的软件，是世界上每个企业的目标。通过将 CI/CD 工具和 管道 pipeline 部署到云端，DevOps 使发布过程变得更加流畅。融合了 DevOps 的 Polyglot 微服务架构正在帮助企业降低总拥有成本（TCO）。他们现在有能力用渐进式网络应用程序和最新的 UI 框架升级他们的技术栈。总的来说，团队正在以更好的效率执行任务，并且正在开发高质量的软件模块。自治 DevOps容器和 DevOps 与云原生应用走到了一起。Kubernetes 和 Docker 正在被用作容器，一个新的名词 NoOps 现在正在流行。对于不同的容器， 编排 Orchestration 都是一个重要的功能。为了扩展应用，开发环境中要创建容器集群。有一些新的容器正在进入云原生应用这个领域，比如 Mesos、Swarm、Openshift Rancher 和 Nomad。NoOps 有助于缩短编码周期，从而监控和管理应用程序。缺陷修复和热修复是不同的活动，它们都是 NoOps 的一部分。NoOps 有助于提高技术团队和业务运营人员之间的协同作用。它也有助于更好的监控、管理和流程自动化。NoOps 基础设施能够控制应用程序在云上的部署。企业从中获得的好处包括更好的交付、弹性的服务、更快的发布、良好的质量和 CI/CD 自动化。DevSecOpsDevSecOps 算是另一个流行趋势，它与在开发操作中的安全问题有关。最近与 漏洞 vulnerabilities （log4j）， 安全泄露 security breach （谷歌、脸书、微软），和安全攻击相关的问题增加了 DevSecOps 在企业中的重要性。 左移 shift left 方法强调了在软件生命周期的早期处理安全性和质量的重要性。在架构阶段就需要考虑隐私和 遵从性 compliances （如 GDPR）。这有助于降低成本，并且提升软件交付的速度。审计工具和安全检查列表是 DevOps 工具和系统的一部分，现在我们称为 DevSecOps。AIOpsAI DevOps 现在被称为 AIOps。据预测，将来 AI 应用会由 AIOps 来管理。与 AIOps 相关的工具和软件正在开发中，并且将很快发布首个版本。AI/ML 应用部署和模型更新可以由 AIOps 来处理。这将在 工业 4.0 Industry 4.0 以及数据科学中扮演重要角色。有一种观点认为，NoOps 将会是 AIOps 的最终形态。AIOps 包括数据集管理、模型训练、模型服务、元数据管理、模型更新和服务更新。分布式训练将由 AIOps 来完成，这会提供 超参数 hyper parameter 优化，工作流程管理和“ 假设 what if ”的分析能力。微服务配置管理当前，DevOps 和微服务正在成为标准部署和 架构蓝图 architectural blueprints 来实施。应用可以在模块级别上就进行扩展。微服务可以在简化缺陷修复和问题区域隔离上提供帮助。经过设计，微服务可以通过添加更多 计算能力 computing power 的 实例 instances 来进行扩展。但是当它们没有被正确实现的时候，数据安全和管理的问题就会突然出现。平台即产品云上的 软件即服务 Software as a Service 和 平台即产品 Platform as a Product 最近非常流行。通过加速向平台部署和功能交付，DevOps 使这些变成现实。从编码到上线阶段，CI/CD 管道有助于可视化应用的部署。持续交付、集成和部署都是 DevOps 的一部分。DevOps 生产线模拟工业生产线是未来要关注的。DevOps 正在慢慢地向 DevSecOps 和 AIOps 转变。对于企业，NoOps 才是未来。现在需要的是减少与安全相关的攻击、事故和破坏发生。对于企业来说，数据安全和隐私的优先级更高，并且这些新技术都将在这方面有所帮助。via: https://www.opensourceforu.com/2022/09/where-is-devops-headed/作者：Bhagvan Kommadi 选题：lkxed 译者：Yufei-Yan 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
2021 年，我们的顶级 DevOps 文章聚焦于工具、最佳实践和最关键的部分：转型。2021 年对于 DevOps 来说是激动人心的一年，开发团队不断适应远程和混合工作模式。这一年最受欢迎的 DevOps 文章展示了我们的社区如何关注工具、创新、最佳实践和转型。DevOps 工具和创新该行业的工具仍然是读者的首选读物。Nimisha Mukherjee 是红帽的一名工程经理，她编写了 面向开发人员的 13 个开源工具。她将工具分为“内环”和“外环”两个部分，“内环”是开发人员最常见的任务，“外环”是开发人员的代码通过持续集成和交付（CI/CD）部署到生产环境的地方。我们的读者对实现 DevOps 工具链的兴趣也很高。首次投稿的 Tereza Denkova 是一家 IT 专业服务公司 Accedia 的营销助理，他撰写了 如何实现 DevOps 工具链，并将其与创新紧密联系在一起。DevOps 实践Daniel Oh 是我们的主要支持者，也是一位多产的内容创作者，他写了 2021 年需要关注的 3 个无服务器策略，概述了当今无服务器应用程序开发和部署方法是如何加速采用 DevApps 实践的。Evan “Hippy” Satis 在他的文章 解决 CI/CD 中的存储库阻抗不匹配 中提供了调整部署映像和描述符的策略。他是红帽公司的高级顾问，他在文章中采用的有条不紊的方法证明了他的行业经验。另外，请参阅他的文章 在 shell 中处理模块化和动态配置文件。在我的文章 DevOps 文档指南 中，我提出了让文档成为 DevOps 讨论的一部分的理由。我从读者那里得到了一些有见地的评论，因此我正在为未来的一篇文章跟进这些评论。DevOps 转型我们有时不相信 DevOps 能够适应组织需求。理解其他形式的运维的潜在影响是非常必要的，这些运维可能在现在或将来补充或增强 DevOps。Bryant Son，一个自称是 章鱼猫 Octocat 的人，在 GitOps 和 DevOps 有何不同？ 中提出 GitOps 是 DevOps 的进化形式。Mike Calizo 是新西兰奥克兰的一位红帽公司解决方案架构师，他撰写了 如何成功采用 DevSecOps。本文将介绍他作为解决方案架构师的经验。他解释了在你迁移到 DevSecOps 的过程中可能会遇到的一些安全挑战。我写了一系列关于 DevOps 到 DevSecOps 转型的文章。它们是：启动从 DevOps 到 DevSecOps 的转型开始 DevSecOps 转型的 3 个阶段遵循 DevSecOps 成熟度模型DevSecOps 转型的另外 3 个阶段使 DevSecOps 的采用成为团队努力的 4 个步骤2022 年和 DevOps 的未来看到 DevOps 的文章登上了 2021 年最受欢迎的名单，说明 DevOps 将迎来一个更加有趣的 2022 年，因为组织正在继续掌握他们的工具，改进他们的战略，并继续他们的 数字化转型，以便在不断变化的市场中有效地竞争。感谢所有阅读我们的 DevOps 文章、喜欢这些文章，并通过网站和社交媒体给我们发送评论的人。via: https://opensource.com/article/22/1/devops-transformation作者：Will Kelly 选题：lujun9972 译者：CN-QUAN 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
使用 Powershell 来自动化 Linux、macOS 以及 Windows 流程
自动化是 DevOps 的关键，但是，是否任何事都可以自动化？自动化控制了那些手工的、费力的和容易出错的过程，用运行自动化脚本的计算机代替了执行手工任务的工程师。每个人都认同手工流程是健康的 DevOps 模式的敌人。一些人认为自动化不是一件好事，因为它取代了辛勤工作的工程师，而另一些人则意识到它提高了一致性、可靠性和效率，节省了时间，（最重要的是）使工程师能够聪明地工作。“DevOps 并不只是自动化或者基础架构即代码。” — Donovan Brown自从上个世纪 80 年代早期开始使用自动化流程和工具链以来，每当我听到或读到“自动化一切”的建议时，我总是会激动不已。虽然在技术上可以实现一切自动化，但自动化是复杂的，并且需要付出开发、调试和维护方面的代价。如果你曾经重新启用一个许久不用的 Azure 资源管理器（ARM）模板或很久以前编写的宝贵维护脚本，并期望它在几个月或几年之后仍然能够完美地执行，那么你就会明白，自动化就像任何其他代码一样，是脆弱的，需要持续的维护和培养。所以，你应该对什么进行自动化并在何时进行自动化？当你手动执行自动化流程超过一两次当你需要经常地持续地执行自动化流程自动化任何可被自动化的更重要的是，什么是你不应该自动化的？不要自动化一次性的流程，因为不值得投入，除非你会重新使用它作为参考文档，并定期验证它的可用性不要自动化高度不稳定的流程，因为太复杂且昂贵不要自动化有问题的流程，在自动化前先修复它们举例来说，我的团队使用我们通用的协作和工程系统来不断的监控数百个用户活动。如果一个用户在三个月或者更长时间处于非活动状态，并且这个用户被分配了一个昂贵的许可证，我们就会重分配这个用户一个功能少一些但是免费的许可证。如图 1 所示，这是一个没有技术挑战性的流程。这是一个令人费解且容易出错的过程，尤其是在执行上下文时与其他开发和运维任务切换时。图 1 手工流程切换用户许可证顺带的，这里有一个用简单三步创建的价值流图的例子:可视化所有活动: 列出用户、过滤用户、重置许可证。确定利益相关者，即运营和授权团队。措施：* 总交货时间（TLT）= 13 小时 * 总周期时间（TCT） = 1.5 小时 * 总效率百分比 = TLT/TCT*100 = 11.5% 如果你在人群流量大和容易看到的区域挂一个这些可视化的副本，比如在你的团队的讨论区、餐厅，或在去洗手间的路上，你将引发大量的讨论和主动反馈。例如，从视觉上看，很明显，手工任务是一种浪费，主要是由于漫长的流程等待时间造成的。让我们研究一个简单的 PowerShell 脚本，它可以自动化该流程，如图 2 所示，将总交付时间从 13 小时减少到 4 小时加 60 秒，并将总体效率从 11.5 提高到 12.75%。图 2 半自动化的 PowerShell 脚本切换用户许可PowerShell 是一种开源的基于任务的脚本语言。它可以在 GitHub 上找到。它构建在 .NET 上，允许你自动化 Linux、macOS 和 Windows 流程。具有开发背景的用户，特别是 C# 用户，将享受到 PowerShell 的全部好处。下面的 PowerShell 脚本示例通过它的服务 REST API 与 Azure DevOps 进行通信。脚本结合了在图 1 中的手动列表用户和过滤用户任务，识别了 Demo 组织中的所有两个月没有活动的、使用基本许可证或更昂贵的基本+测试许可证的用户，并将用户的详细信息输出到控制台。很简单！首先，设置认证标头和其他变量，这些变量将在稍后的初始化脚本中使用：param( [string] $orgName = "DEMO", [int] $months = "-2", [string] $patToken = "<PAT>" ) # Basic authentication header using the personal access token (PAT) $basicAuth = ("{0}:{1}" -f "",$patToken) $basicAuth = [System.Text.Encoding]::UTF8.GetBytes($basicAuth) $basicAuth = [System.Convert]::ToBase64String($basicAuth) $headers = @{Authorization=("Basic {0}" -f $basicAuth)} # REST API Request to get all entitlements $request_GetEntitlements = "https://vsaex.dev.azure.com/" + $orgName + "/_apis/userentitlements?top=10000&api-version=5.1-preview.2"; # Initialize data variables $members = New-Object System.Collections.ArrayList [int] $count = 0; [string] $basic = "Basic"; [string] $basicTest = "Basic + Test Plans"; 接下来，使用此脚本查询所有授权，以识别不活动用户：# Send the REST API request and initialize the members array list. $response = Invoke-RestMethod -Uri $request_GetEntitlements -headers $headers -Method Get $response.items | ForEach-Object { $members.add($_.id) | out-null } # Iterate through all user entitlements $response.items | ForEach-Object { $name = [string]$_.user.displayName; $date = [DateTime]$_.lastAccessedDate; $expired = Get-Date; $expired = $expired.AddMonths($months); $license = [string]$_.accessLevel.AccountLicenseType; $licenseName = [string]$_.accessLevel.LicenseDisplayName; $count++; if ( $expired -gt $date ) { # Ignore users who have NEVER or NOT YET ACTIVATED their license if ( $date.Year -eq 1 ) { Write-Host " **INACTIVE** " " Name: " $name " Last Access: " $date "License: " $licenseName } # Look for BASIC license elseif ( $licenseName -eq $basic ) { Write-Host " **INACTIVE** " " Name: " $name " Last Access: " $date "License: " $licenseName } # Look for BASIC + TEST license elseif ( $licenseName -eq $basicTest ) { Write-Host " **INACTIVE** " " Name: " $name " Last Access: " $date "License: " $licenseName } } } 当你运行脚本时，你将得到以下输出，你可以将其转发给授权团队，以重置用户许可证：**INACTIVE** Name: Demo1 Last Access: 2019/09/06 11:01:26 AM License: Basic **INACTIVE** Name: Demo2 Last Access: 2019/06/04 08:53:15 AM License: Basic **INACTIVE** Name: Demo3 Last Access: 2019/09/26 12:54:57 PM License: Basic **INACTIVE** Name: Demo4 Last Access: 2019/06/07 12:03:18 PM License: Basic **INACTIVE** Name: Demo5 Last Access: 2019/07/18 10:35:11 AM License: Basic **INACTIVE** Name: Demo6 Last Access: 2019/10/03 09:21:20 AM License: Basic **INACTIVE** Name: Demo7 Last Access: 2019/10/02 11:45:55 AM License: Basic **INACTIVE** Name: Demo8 Last Access: 2019/09/20 01:36:29 PM License: Basic + Test Plans **INACTIVE** Name: Demo9 Last Access: 2019/08/28 10:58:22 AM License: Basic 如果你将最后一步自动化，自动将用户许可设置为一个自由的利益相关方许可，如图3所示，你可以进一步将总体交付时间减少到65秒，并将总体效率提高到77%。图 3 完全自动化的基于 Powershell 的流程来切换用户许可证。这个 PowerShell 脚本的核心价值不仅在于能够实现 自动化，还在于能够 定期、持续 和 快速地 执行这个流程。进一步的改进是使用 Azure 管道等调度器每周或每天触发脚本，但我将把程序化的许可证重置和脚本调度保留在未来的文章中。这里有一个图表，可以直观地看到进展情况：图 4，措施，措施，措施我希望你能喜欢这个简短的关于自动化、PowerShell、REST API 和价值流图的介绍。请在评论中分享你的想法和反馈。via: https://opensource.com/article/20/2/devops-automation作者：Willy-Peter Schaub 选题：lujun9972 译者：FigaroCao 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
一套完整启用的 DevOps 工具链可推动你的创新计划，实现快速部署并节约成本。不同规模和不同行业组织都致力于为提高软件交付的速度和质量提供解决方案。这不仅保证了他们的生存，还令他们在全球市场取得了成功。DevOps 可以帮助他们规划出一条最佳路线。DevOps 是一个系统，通过引入不同的工具链连接不同工作流程，以便及时交付项目并降低所需的开销。在我工作的 IT 服务公司 Accedia，我们会帮助客户落地一套完整的 DevOps 工具链，这套工具链能帮助他们达到甚至超越他们的业务目标。在这篇文章，我会分享目前为止从 DevOps 项目中汲取的经验。DevOps 工具链是什么？一套完善的 DevOps 工具链可以在不同阶段中使用不同的 DevOps 工具来解决特定的业务带来的挑战。一条工具链能保证前端和后端开发者、质量测试人员、客户都能够从中获得收益。构建工具链的目的是为了自动化开发和部署过程，以确保快速、可靠、预算友好地交付与创新。我们发现成功构建一套 DevOps 工具链不是一个简单的事情。它需要实验和不断的完善，保证必要的流程是完全自动化的。为什么你需要 DevOps 工具链DevOps 工具链自动化了工作流中的所有技术元素。它能让不同团队在一个平台上进行工作，因此可以使你专注于业务战略以推动组织走向未来。我们总结了五个实现 DevOps 工具链所带来的好处。你可以让管理层相信，是值得为 DevOps 工具链的开发投入资源和时间的。更快、更高效的生产部署：DevOps 工具自动化了大部分软件开发进程。这会使产品开发专注于创新，交付更加敏捷，更领先于竞争对手。预算和时间优化：将手动的任务转变为自动化会使你的组织节省时间和资源。当没有人为的错误和时间管理不足带来的额外支出，预算自然会得到优化。高效的开发：DevOps 工具链会减少开发工作中不必要的延时，提高开发效率。前端、后端、质量测试人员的工作是一致的，所以没有人需要协调不同团队之间人员的交付。更快的部署意味着更高的质量：DevOps 工具链保证了缺陷能够很快被解决，并且迅速完成高质量的部署进程。怎么样？它可以生成有针对性的告警，并将重要的事件通知给你的团队。这会让你主动地发现并解决潜在的问题，从而规避故障的不断的升级从而导致的客户服务不可用。及时事件管理：DevOps 工具链有助于优化事件管理记录。它能够识别 IT 事件并且逐渐升级事件级别，通知给指定团队的成员，直到问题被解决。这意味着消息的接受和处理会更加的迅速，因为它们发送给了正确的目标。DevOps 工具链的实践对我的团队来说，DevOps 并不新鲜。我们已经敏捷开发很长时间了，并且我们总是热衷于探索最优的工作流。在我们的实践中，往往都是应用复杂性增加从而带来了自动化的需求。这是我们为一个客户配置的工具链。这个项目包含了移动运营方案，连接了金融交易的所有参与者 （卖方、买方、银行）。这个客户需要动态响应用户反馈并且将故障时间缩短到最小，从而来提高用户体验。我的团队设计了一套工具链用于自动化应用的维护和部署新功能。(Accedia, CC BY-NC-SA 4.0)首先，我们团队编写了自动化测试，可以立即识别应用程序的变更。当新版本已经准备就绪的时候，代码将被提交到 Gitlab 中。通过 Gitlab，提交会自动触发 Jenkins 构建。在 持续集成中，新的代码版本通过 Chai 和 Mocha 进行了测试，以检测是否运行正常。当测试通过，持续部署阶段 将会开始并创建一个可用的 Docker 镜像并上传到 Sonatype 的 Nexus。（这是 Sonatype 公司的的一个开源工具）最后，新版本应用会通过 Nexus 下载并且部署到线上环境中，例如 Docker 容器 （持续部署阶段）简而言之，每当有人在仓库中创建一个新的提交，又或者团队上传新的代码版本、功能、升级、缺陷修复等，应用程序包都会自动更新并且交付给客户。这套系统拥有良好的事故控制能力以保证快速部署，但不以牺牲质量为代价。它对于用户的反馈是动态的，意味着新功能和旧功能的和更新只需要之前一半的时间，同时将故障时间降低到最低。把它封装起来一套完整并且正确实施的 DevOps 工具链可以从始至终推动你的创新计划并且加速部署。根据你的需求，你的工具链可能看起来和这些不一样，但是我希望我们的工作流能够让你了解如何将自动化作为一种解决方案。via: https://opensource.com/article/21/1/devops-tool-chain作者：Tereza Denkova 选题：lujun9972 译者：AnyISalIn 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。什么是《代码英雄》 代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。本文是《代码英雄》系列播客第一季（4）：DevOps，拆掉那堵墙的音频脚本。当应用开发的争斗暂告一段落，横亘在开发者与运维之间的那堵墙开始崩塌。在墙彻底倒塌的时候，墙两边的人都应该学会如何合作，彼此变得亲密无间。不过到底什么是 DevOps？开发者一方的嘉宾，包括来自微软的 Scott Hanselman 和 Cindy Sridharan（即 @copyconstruct），他们从开发者的角度认为 DevOps 是一种惯实践。而来自运维一方的成员则他们一直在努力捍卫的东西。双方依然存在差异，不过因为 DevOps 的诞生，大家的合作效率会比之前更上一层楼。这集节目讲述了这种方法的诞生对于大家有多重要。Saron Yitbarek： 请你想象这样一堵墙：这堵墙从你目之所及的最右侧延伸到最左侧。墙比你高，你无法看见墙背后。你知道墙的另一侧有很多很多人，但你不清楚他们是否和你一样，不清楚他们是敌是友。00:00:30 - Gordon Haff： 开发者创造代码，然后把代码扔过墙丢给运维，之后发生的问题都是运维的责任了。Richard Henshall： 他们随心所欲，并不真正关心服务质量。Sandra Henry-Stocker： 墙这两面的人几乎做着相反的工作 —— 一方做出改变，另一方尽可能抵制那些改变。Richard Henshall： 但对于他们到底想共同达成什么，却没有在同一幅蓝图中规划过。00:01:00 - Saron Yitbarek： 我是 Saron Yitbarek，这里是《代码英雄》，由红帽公司推出的原创播客栏目。第四期，我们的标题是《DevOps，拆掉那堵墙》。是的，数十年来，IT 界划分为各种角色。一边是开发者，他们要尽可能快地去创造更多变化。然后另一边是运维团队，他们要去阻止太多改变发生。与此同时，代码在没有充分共鸣和沟通的条件下，被盲目扔过两方之间的墙。怎样才能拆掉这堵墙呢？这需要一个重大的转变。00:01:30 - Saron Yitbarek： 开源运动震撼了整个战场。上一期，我们看到了新的敏捷方法论，它重视不间断的迭代改进，而这种对速度的要求将迫使我们改变彼此的工作方式。一群彼此孤立的人工作的速度是有极限的，而这个极限是一个问题，因为……00:02:00 - Richard Henshall： 因为都是为了更快的将产品推向市场、提高敏捷性、更多的迭代，而不是长期而大量的工作。Saron Yitbarek： Richard Henshall 是 Ansible 的一位产品经理。Richard Henshall： 是的。还记得你以前下单购买服务器，四个月后到货。所有东西都整合在一起，所以整个堆栈是一个整体，要花几年时间来设计和建造那些东西。现在这种情况已经不存在了，对于很多组织来说，这种方法已经……已经寿终正寝，偶尔拿过来试试，然后放弃它。00:02:30 - Saron Yitbarek： 如今，像亚马逊这样的公司每分钟都会部署几次新的代码。想象一下，用按部就班的瀑布式工作流，简直不可能完成这些工作。所以为了继续快速完成工作，那些关于稳定性、安全性、可靠性的顾虑都会被运维丢到一边不管。00:03:00 - Saron Yitbarek： 同时，开发者也没有意识到他们的责任是创造真实环境可用的代码。开发者对稳定性和安全性毫无兴趣，但这些恰恰是我们需要解决的问题。所以，我们最终会有很多无谓的修改，在双方之间来来回回。想象一下过度分工会如何拖慢公司效率，但开发法者很少被鼓励思考除代码之外的其他事务。Sandra Henry-Stocker： 他们的目录规模只会越来越臃肿，但他们从不清理。除非已经无法工作才不得不清理。00:03:30 - Saron Yitbarek： Sandra Henry-Stocker 是位退休的系统管理员，为 IDG 杂志撰稿。Sandra Henry-Stocker： 我过去经常劝说别人，说，“嘿，你看，你用了这么多的磁盘空间。是不是有什么东西你可以整理一下，这样我们就有更多的存储空间来运行了 —— 因为服务器上的存储空间快用完了。”是的，我们经常经历这些事。Saron Yitbarek： 归根结底，这是一个心态问题。这种开发者和运维之间的态度分裂，一方不必去理解另一方的担忧。好吧，在过去这还没太大问题，但随着开发速度成为一种重要的优势，这种分裂的文化急需改进。孤立在自己的工作圈子里，效率太低了。Jonah Horowitz 在 Stripe 的可靠性工程团队工作。他描述了即使开发人员和运维人员想一起工作，他们也无法做到。因为从某种意义上说，他们被安排在对立的团队中。00:04:30 - Jonah Horowitz： 运维团队经常以正常运行时间和可靠性来衡量，而提高正常运行时间的最大方法之一，就是减少系统的变化量。当然，发布新功能就是在改变系统，而做产品工作的软件工程师有动力去尽快发布尽可能多的功能。所以，当开发和运维的职责不同时，他们自然有了冲突。00:05:00 - Saron Yitbarek： 开发者致力于新建功能，运营致力于维持运行，两者目标相互矛盾。但就像我说的，由于对速度的需求越来越大，对快速迭代发布的需求越来越大，开发和运维之间的脱节已经到了一个临界点，必须要有所改变。00:05:30 - Saron Yitbarek： 在 2009 年左右，将开发和运维分开的那堵墙看起来像是监狱的墙。我们需要的是一种新的方法论，它能使开发和运维之间的隔阂顺畅过度，让双方以更快、更整体化的方式工作。视频平台 Small Town Heroes 的首席技术官 Patrick Debois 为想要拆掉这堵墙的人发起了一场会议。他把这个的脑洞叫做 DevOps Days（开发运维日）。为了便利，他将其缩短为 DevOps，于是这场改革就有了名字。00:06:00 - Saron Yitbarek： 不过名字并不代表改革的一步，我们知道为什么我们需要 DevOps，但究竟该如何做？我们应该如何将开发和运维结合起来而不引发战争？幸运的是，我有 Scott Hanselman 来指导我。Scott 是微软 .NET 和 ASP.NET 的首席项目经理。所以，Scott，我认识你确实有几年了，但感觉还是相见恨晚啊。00:06:30 - Scott Hanselman： 我也是，相见恨晚哈。Saron Yitbarek： 我想和你聊聊你如何成为一个开发者，和 DevOps 这些年的变化。觉得如何？Scott Hanselman： 嗯，听上去挺有意思。00:07:00 - Saron Yitbarek： 好的。我认为究竟什么是 DevOps 是一个好的开场问题。你会怎么定义它呢？Scott Hanselman： 在 2008 年，维基百科有个关于 DevOps 的定义确实很棒。它说，这是一套“惯例”，目的是在保证质量的前提下，缩短提交变更和变更投入生产之间的时间。所以，如果你想想，假如今天是周二，我检查了一些代码，而这些代码将在 6 月的版本中上线。这就很糟糕了，因为这不是持续集成，而是一年几次的集成。00:07:30 - Scott Hanselman： 如果你有一个健康的 DevOps 体系，如果你已经有“ 设置 - 上线 set - up ”的惯例，那么你就可以不断地将代码集成到生产中去。那么，你能做什么？你可以定义、创造怎样是最佳“惯例”，这将决定你能否成功。所以，我在周二检查的一些代码，周四就上线了。那么现在，为了保证高质量，最重要的事情就会是 —— 谨慎上线。00:08:00 - Saron Yitbarek： 这个定义真的很有趣呢，是个“惯例”。但我觉得当我听人们谈论 DevOps 时，它具体一点。他们谈论它就像它是一个角色、一个工作、一个职位或一个头衔。你觉得这与它是一套“惯例”的观点是否有冲突？Scott Hanselman： 我认为，当一套新的方法或一个新的流行语出现时，人们喜欢把它加在名片上。我不是不尊重那些正在收听这个播客，并且感到被我冒犯、正骂骂咧咧把名片掏出来看的人们。虽然，他们现在可能正要怒盖笔电、退出这个播客。00:08:30 - Scott Hanselman： 有一个帖子写得非常好，作者是 Brian Guthrie，他是一个脑力劳动者，在 SoundCloud 工作。他是一个超级聪明的人，几天前他在 Twitter 上的帖子中说到 DevOps。他说 DevOps 就是一套惯例，不是一个工作头衔、不是一个软件工具、不是一个你安装的东西、也不是一个团队的名字。00:09:00 - Scott Hanselman： 他的原话是：“DevOps 不是神奇的‘企业万能药’”。如果你没有好的惯例，如果你没有良好的习惯，你就没有 DevOps。所以，这更多的是一种心态，而不是摆出一个工作头衔，然后“我们要雇佣一个 DevOps 工程师，然后我们要把这些神奇的 DevOps 工程师撒到组织中。虽然整个组织没有意志力，也没有信奉 DevOps 的想法。” 所以，如果你认为 DevOps 是一个工具或者是用来安装的东西，那么你就完全理解错了。00:09:30 - Saron Yitbarek： 好吧，让我们回到过去，在 DevOps 这个名词出现之前，在我们往名片上写 DevOps 或者把它作为一套“惯例”来讨论之前。在 10 年前，你会如何描述开发者和那些运维人员之间的关系？Scott Hanselman： 那是相当的水火不容。举个例子，运维控制着生产，但开发人员从来没有接近过生产。我们站在一堵不透明的墙的两侧。我们在开发部的时候，尽可能地去做一些看起来像生产环境能用的东西，但实际上从来没有……从来没有像样的产品。00:10:00 - Scott Hanselman： 我们有相当多问题。我们的开发环境从各个方面来说都不像生产环境，所以你不可避免地会遇到那些 “嘿，它在生产环境中的工作方式和在开发环境中的不同” 的问题。然后，从开发到投入生产之间的间距是几周几周的长久间隔，所以你的大脑甚至不在正确的频道上。比如说，我在一月份的时候就在研究这个功能，现在四月份才刚刚上线，那么当 bug 不可避免地出现的时候，要等到六月份才能修复，我甚至不记得我们之前在干嘛。所以运维团队的人，他们的工作是……他们的工作几乎就是有意识地让我们慢下来。好像他们的存在是为了让开发人员更慢，然后他们还觉得我们随时会让生产环境崩坏。00:11:00 - Saron Yitbarek： 那么为什么会这样呢？是对开发者想要做什么和他们做了什么不了解？还是信任问题？为什么会有这么大的冲突？Scott Hanselman： 我觉得你已经回答了，而且回答得很到位。你说的很对，确实是信任的问题。我觉得开发人员认为他们是特殊的，或者某些方面比 IT 人员更优越，而 IT 人员认为开发人员不尊重生产。00:11:30 - Scott Hanselman： 我认为这种文化的产生，一部分来源于高层。他们认为我们是不同的组织，并且我们的目标也不同。我认为软件业正在走向成熟，因为我们都意识到，无论业务是什么，我们写软件都是为了推动业务发展。所以现在有种 “我们都在往正确的方向推进” 的感觉，就像他们说的，“专注一件产品并做到极致”。但这是需要绝对的信任，可 DevOps 工程师不信任产品工程师来部署代码，对吧？00:12:00 - Scott Hanselman： 但 DevOps 工程师传统上并不写代码，所以他们并不了解什么被修改了。所以他们对于在各个层面的人都缺乏信任。没有人理解部署过程，人们只信任自己，他们的心态……举个例子，就像“我只信任自己的工作。我不能相信 Saron 的工作，她甚至不知道她在干些什么。我会做完所有的事情。”00:12:30 - Scott Hanselman： 所以如果没有人真正理解这个系统，那么 全栈工程师 full stack engineer 的概念就是一个神话。但是现在，我们开始将一整个组织称之为全栈。我们已经有了 全产品所有权 full product ownership 这样的名词，敏捷方法论也出现了，也就是说每个人都应该拥有产品。社区对于软件所有权和对于代码的想法都慢慢发生了变化，这种改变带来了一个充满信任的环境。00:13:00 - Saron Yitbarek： 我是 Saron Yitbarek，你现在收听的是《代码英雄》，来自红帽公司的一档原创播客栏目。所以，要想让 DevOps 发挥出它的潜力，我们就需要双方都有更多的信任，这就意味着要有更多的沟通。回到 Richard Henshall 身上，他认为双方的共情是 DevOps 的基石 。00:13:30 - Richard Henshall： 一些 DevOps 的从业者，一群真正优秀的从业者，都参与过这两种角色。我认为这才是真正的力量所在 —— 当人们真正做过了两种角色，而不是只看到其中一种。所以，你不该保持孤立，你实际上……你应该去和双方都一起工作一段时间。我想这才是让人恢复同理心的方法。Saron Yitbarek： 现在，这不仅仅是为了温情的沟通。Richard Henshall 所描述的是行业重点的转向 —— Scott 刚刚提到过。00:14:00 - Saron Yitbarek： 一个关于 持续集成 continuous integration （CI）的观点。软件不仅要以小批量快速编写和发布，还要以小批量进行快速测试。这意味着，开发人员需要即时反馈他们正在编写的代码在现实世界中的表现。随着上市时间从几个月缩短到几天，再到几个小时，我们四处寻找一套新的工具，可以将任何可以自动化的元素自动化。00:14:30 - Gordon Haff： 你需要一个全新的生态系统和工具，来最有效地进行 DevOps。Saron Yitbarek： Gordon Haff 是一位红帽公司高级工程师。Gordon Haff： 我们看到有很多巨大的、DevOps 可以利用的新种集合工具和平台，它们都诞生于开源。Saron Yitbarek： Gordon 是对的。新的集合工具是很庞大，关于开源这点他说的也对。在一个严格的专有系统中，自动化工具是不可能发展的。00:15:00 - Gordon Haff： 其中有很多监控工具，Prometheus 是其中一个常见的工具。它开始引起很多人兴趣，用于编排服务的 STO 也出自这里。Saron Yitbarek： GitHub 让你跟踪变化，PagerDuty 管理数字业务，NFS 可以跨网络挂载文件系统，Jenkins 让你自动测试你的构建。00:15:30 - Saron Yitbarek： 这么多工具，这么多自动化流程。最终的结果是，开发人员可以将他们的变更直接推送到生产现场，自动创建构造，实行经过严格管理的编译与针对性的自动测试。Sandra Henry-Stocker 描述了这是怎样的变化。Sandra Henry-Stocker： 所以，我可以把我正在工作编写的东西快速部署。我可以只在一个系统上，通过命令行控制许多系统，而不是必须在在很多不同的系统上工作，也不用学习就可以利用网络，将代码部署到其他机器上。00:16:00 - Sandra Henry-Stocker： 现在，在计算机系统中进行改动更容易了。坐在一个地方，就能实行一切操作。Saron Yitbarek： 自动化工具已经解决了速度问题。但我不希望我们只赞美工具，而忽略了实际的方法论，文化的转变。Scott Hanselman 和我谈到了这个微妙的界限。00:16:30 - Saron Yitbarek： 你在这次谈话开始时说，DevOps 是一套惯例，是一种心态，是一种思维方式。听起来，我们创造的工具是我们应该思考和操作方式的具体代码实现。Scott Hanselman： 我喜欢这句话，你真是个天才。没错，我们以前让产品开发在 Word 文档中写下这些代码是如何工作的。他们写的是规范，对吧？这些文档过期了吗？00:17:00 - Saron Yitbarek： 没错。（答非所问）Scott Hanselman： 哈？Saron Yitbarek： 好吧，我只是很高兴 Scott 刚才说我是天才。但我也确实认为，这些工具几乎是我们文化转变的象征。它们鼓励我们拓宽我们的角色定义。我们开发者已经被迫，至少偶尔关注代码的运行。这样一来，开发和运维的主要职责就部分统一了。事实上，DevOps 的兴起告诉我们的是，在一个速度不断提升的世界里，没有人能够保持孤岛状态。00:17:30 - Saron Yitbarek： Jonah Horowitz 曾在湾区多家公司工作，包括 Quantcast 和 Netflix。他说即使是世界上一些最大的公司，也从这个角度重新塑造了他们的文化。Jonah Horowitz： 我们在文化上得到了整个公司的认同，就像，“这就是我们要部署软件的方式，我们将以小批量的方式进行部署，我们将使用这些程序帮助部署。” 如果 DevOps 只是被运营团队所驱动，我不认为它可以……我不认为它可以成功。00:18:00 - Jonah Horowitz： 这必须成为公司的管理层和领导层所认同的东西才能发挥作用，而这件事很大程度上，意味着一种文化转变。Saron Yitbarek： 当 MacKenzie 对 800 名 CIO 和 IT 高管进行调查时，80% 的人表示，他们正在规划让自己的一部分下属组织实施 DevOps，超过一半的人计划到 2020 年，在全公司范围内实施。高管们意识到，自动化工具可以提升交付速度。00:18:30 - Saron Yitbarek： 这些人过去也是这样的人，他们习惯于让一个货板先到达数据中心，然后在新机器上线之前让它在那里放上整整一个月。不过在今天，如果你等待的时间超过 10 分钟，就说明你做错了什么。随着竞争对手的速度增加，没有人能够承受得起落后。00:19:00 - Saron Yitbarek： 我可以想象，运维团队一定很紧张，因为他们把所有的工具都交给开发人员。运维团队习惯了做成年人，而现在叫他们把车钥匙交给一贯的孩子 —— 开发人员？呀，我想我们开发人员正在学习，如何在不破坏东西的前提下快速移动。但随着 DevOps 革命的尘埃落定，变化最大的可能是运维团队。00:19:30 - Saron Yitbarek： DevOps 是否真的威胁到了运维的存在？开发是否在用它闪亮的新工具来吃掉运维？Cindy Sridharan 是一位开发者，她写了一篇长篇调查文章来讨论这些问题。在你的文章和博客中，你提到运维人员对事情这样的发展并不一定满意。到底发生了什么？你会说什么？Cindy Sridharan： 这么说吧，DevOps 的理想是责任共享。开发者和运维将有，就像你知道的，更多的是五五分成，以真正确保软件的整体交付。00:20:00 - Cindy Sridharan： 我认为很多运维工程师的不快乐源于这样一个事实，那就是这些改变都没有实际功效。他们仍然是总被鸡蛋挑骨头的人，他们仍然是总做苦力工作的那些人，他们还是那些主要肩负着实际运行应用的责任的人，而开发者不一定要做得足够好。Saron Yitbarek： 这个问题在未来几年将至关重要。DevOps 的作用到底有多大？随着我们的自动化进程，运维的作用是会被削弱，还是会发生转变？00:20:30 - Saron Yitbarek： 但是我们要记住，DevOps 不仅仅是工具和新技术的应用。这种方法论实际上是在塑造技术，反过来技术也在塑造方法论，这样就有了一个神奇的反馈循环。文化造就了工具，而工具又强化了文化。00:22:00 - Saron Yitbarek： 最后，我们在节目开头描述的那堵墙，也就是把开发和运维划分开来的那堵墙，我甚至不知道五年后“把你的代码扔过墙”的比喻对一个开发者来说是否有意义，如果五年后大家都听不懂这个比喻，那真是一件大好事。不过目前为止的访谈很有价值，我听到了很多新的故事。现在说话的是云架构师 Richard Henshall。Richard Henshall： 我觉得 DevOps 开始让人们意识到对方关心的是什么，我看到了更多对彼此的理解。00:23:00 - Saron Yitbarek： 现在是系统管理员 Jonah Horowitz。00:23:00 - Jonah Horowitz： 我认为你需要很棒的技巧来写出真正好的软件，我在与我合作过最棒的开发者身上看到了一件事，那就是他们真的，他们贡献了关于的软件工程新技巧，或者说他们推动了软件开发这个行业的发展。Saron Yitbarek： 最后一个是系统管理员 Sandra Henry-Stocker。Sandra Henry-Stocker： 我认为，开发者会变得更加精明、更加谨慎。他们始终要提升自己的技能，我知道这需要很多辛苦的学习。00:23:30 - Saron Yitbarek： DevOps 是个爱的结晶。原来，在那堵墙的另一边还有一些朋友，很高兴认识你们。所以，坦白一下，我以前总觉得 DevOps 很无聊，就是一堆硬核的自动化脚本和扩展问题。我的抵触情绪有一部分是出于它的实践难度。作为开发者，我每周都要面对一些新出来的工具，一些新的框架。DevOps 一直是那些可怕的、快速变化的一部分。但现在，尤其是听了这些故事之后，我明白了。00:24:00 - Saron Yitbarek： DevOps 不仅仅是其工具。它是教导我们如何合作，更快地构建更好的产品的方法。好消息是，随着为你我这样的开发者准备的新平台出现，我们的工作变得更好、更快、更能适应不同的环境，我的业务圈也可以不断扩大。你会看到人们将 DevOps 扩大到安全部分，所以我们能得到 Sec DevOps。或者他们开始包含商务，那我们就得到了 Business DevOps。我们现在要辩论的话题是：对于一个开发者来说，不仅要了解如何使用这些工具，还有了解所有 DevOps 的东西是如何工作的必要吗？以及我们需要所有开发者都去了解这个新世界吗？00:24:30 - Saron Yitbarek： 这场辩论的结果将决定未来一期《代码英雄》的内容。你可能已经注意到，在所有关于工具和自动化的谈话中，我漏掉了一些工具。好吧，我把这些留到下一期，当所有这些 DevOps 自动化达到光速时，我们将追踪容器的崛起。00:25:00 - Saron Yitbarek： 是的，这些都会留到第五期。《代码英雄》是红帽公司推出的原创播客栏目。想要了解更多关于本期节目和以往节目的信息，请访问 redhat.com/commandlineheroes 。在那里，你还可以注册我们的新闻资讯。想免费获得新剧集的自动推送，请务必订阅该节目。00:25:30 - Saron Yitbarek： 只要在苹果播客、Spotify、Google Play、CastBox 中搜索《代码英雄》，或者通过其他方式收听，并点击订阅，这样你就能在第一时间知道最新剧集。我是 Saron Yitbarek。感谢您的收听，编程不止。什么是 LCTT SIG 和 LCTT LCRH SIGLCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。via: https://www.redhat.com/en/command-line-heroes/season-1/devops-tear-down-that-wall作者：Red Hat 选题：bestony 译者：LikChung 校对：acyanbird本文由 LCRH 原创编译，Linux中国 荣誉推出
两者之间的区别在于开发完毕之后发生的事情。早期，软件开发并没有特定的管理流程。随后出现了 瀑布开发流程 Waterfall ，它提出软件开发活动可以用开发和构建应用所耗费的时间来定义。那时候，由于在开发流程中没有审查环节和权衡考虑，常常需要花费很长的时间来开发、测试和部署软件。交付的软件也是带有缺陷和 Bug 的质量较差的软件，而且交付时间也不满足要求。那时候软件项目管理的重点是长期而拖沓的计划。瀑布流程与 三重约束模型 triple constraint model 相关，三重约束模型也称为 项目管理三角形 project management triangle 。三角形的每一个边代表项目管理三要素的一个要素: 范围、时间和成本。正如 Angelo Baretta 写到，三重约束模型“认为成本是时间和范围的函数，这三个约束以一种确定的、可预测的方式相互作用。……如果我们想缩短时间表（时间），就必须增加成本。如果我们想增加范围，就必须增加成本或时间。”从瀑布流程过渡到敏捷开发瀑布流程来源于生产和工程领域，这些领域适合线性化的流程：正如房屋封顶之前需要先盖好支撑墙。相似地，软件开发问题被认为可以通过提前做好计划来解决。从头到尾，开发流程均由路线图清晰地定义，沿着路线图就可以得到最终交付的产品。最终，瀑布模型被认为对软件开发是不利的而且违反人的直觉，因为通常直到开发流程的最后才能体现出项目的价值，这导致许多项目最终都以失败告终。而且，在项目结束前客户看不到任何可以工作的软件。 敏捷 Agile 采用了一种不同的方法，它抛弃了规划整个项目，承诺估计的时间点，简单的遵循计划。与瀑布流程相反，它假设和拥抱不确定性。它的理念是以响应变化代替讨论过去，它认为变更是客户需求的一部分。敏捷价值观敏捷由 敏捷宣言 Agile Manifesto 代言，敏捷宣言定义了 12 条原则（LCTT 译注：此处没有采用本文原本的简略句式，而是摘录了来自敏捷软件开发宣言官方的中文译本）：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项目中的每一天都不例外。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。面对面沟通是传递信息的最佳的也是效率最高的方法。可工作的软件是进度的首要度量标准。敏捷流程倡导可持续的开发，责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量的艺术。最好的架构，需求和设计出自自组织团队团队定期地反思如何能提高成效，并依此调整自身的举止表现。敏捷的四个核心价值观是（LCTT 译注：此处译文同样来自敏捷软件开发宣言官方）：个体和互动 高于流程和工具工作的软件 高于详尽的文档客户合作 高于合同谈判响应变化 高于遵循计划这与瀑布流程死板的计划风格相反。在敏捷流程中，客户是开发团队的一员，而不仅仅是在项目开始时参与项目需求的定义，在项目结束时验收最终的产品。客户帮忙团队完成验收标准，并在整个过程中保持投入。另外，敏捷需要整个组织的变化和持续的改进。开发团队和其他团队一起合作，包括项目管理团队和测试团队。做什么和计划什么时候做由指定的角色领导，并由整个团队同意。敏捷软件开发敏捷软件开发需要自适应的规划、演进式的开发和交付。许多软件开发方法、框架和实践遵从敏捷的理念，包括：Scrum 看板 Kanban （可视化工作流） 极限编程 Xtreme Programming （XP） 精益方法 Lean DevOps 特性驱动开发 Feature-Driven Development （FDD） 测试驱动开发 Test-Driven Development （TDD） 水晶方法 Crystal 动态系统开发方法 Dynamic Systems Development Method （DSDM） 自适应软件开发 Adaptive Software Development （ASD）所有这些已经被单独用于或一起用于开发和部署软件。最常用的是 Scrum、看板（或 Scrumban）和 DevOps。Scrum 是一个框架，采用该框架的团队通常由一个 Scrum 教练、产品经理和开发人员组成，该团队以跨职能、自主的工作方式运作，能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是较小增量的快速迭代。看板 是一个敏捷框架，有时也叫工作流管理系统，它能帮助团队可视化他们的工作从而最大化效率（因而变得敏捷）。看板通常由数字或物理展示板来呈现。团队的工作在展示板上随着进度而移动，例如从未启动到进行中，一直到测试中、已完成。看板使得每个团队成员可以随时查看到所有工作的状态。DevOps 价值观DevOps 是一种文化，是一种思维状态，是一种软件开发的方式或者基础设施的方式，也是一种构建和部署软件和应用的方式。它假设开发和运维之间没有隔阂，他们一起合作，没有矛盾。DevOps 基于其它两个领域的实践: 精益和敏捷。DevOps 不是一个公司内的岗位或角色；它是一个组织或团队对持续交付、持续部署和持续集成的坚持不懈的追求。Gene Kim（Phoenix 项目和 Unicorn 项目的作者）认为，有三种方式定义 DevOps 的理念：第一种: 流程原则第二种: 反馈原则第三种: 持续学习原则DevOps 软件开发DevOps 不会凭空产生；它是一种灵活的实践，它的本质是一种关于软件开发和 IT 或基础设施实施的共享文化和思维方式。当你想到自动化、云、微服务时，你会想到 DevOps。在一次访谈中，《加速构建和扩张高性能技术组织》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 这样解释到：软件交付能力很重要，它极大地影响到组织的成果，例如利润、市场份额、质量、客户满意度以及组织战略目标的达成。优秀的团队能达到很高的交付量、稳定性和质量；他们并没有为了获得这些属性而进行取舍。你可以通过实施精益、敏捷和 DevOps 中的实践来提升能力。实施这些实践和能力也会影响你的组织文化，并且会进一步对你的软件交付能力和组织能力产生有益的提升。懂得怎样改进能力需要做很多工作。DevOps 和敏捷的对比DevOps 和敏捷有相似性，但是它们不完全相同，一些人认为 DevOps 比敏捷更好。为了避免造成混淆，深入地了解它们是很重要的。相似之处毫无疑问，两者都是软件开发技术。敏捷已经存在了 20 多年，DevOps 是最近才出现的。两者都追求软件的快速开发，它们的理念都基于怎样在不伤害客户或运维利益的情况下快速开发出软件。不同之处两者的差异在于软件开发完成后发生的事情。在 DevOps 和敏捷中，都有软件开发、测试和部署的阶段。然而，敏捷流程在这三个阶段之后会终止。相反，DevOps 包括后续持续的运维。因此，DevOps 会持续的监控软件运行情况和进行持续的开发。敏捷中，不同的人负责软件的开发、测试和部署。而 DevOps 工程角色负责所有活动，开发即运维，运维即开发。DevOps 更关注于削减成本，而敏捷则是精益和减少浪费的代名词，侧重于像敏捷项目会计和最小可行产品的概念。敏捷专注于并体现了经验主义（适应、透明和检查），而不是预测性措施。敏捷DevOps从客户得到反馈从自己得到反馈较小的发布周期较小的发布周期，立即反馈聚焦于速度聚焦于速度和自动化对业务不是最好对业务最好总结敏捷和 DevOps 是截然不同的，尽管它们的相似之处使人们认为它们是相同的。这对敏捷和 DevOps 都是一种伤害。根据我作为一名敏捷专家的经验，我发现对于组织和团队从高层次上了解敏捷和 DevOps 是什么，以及它们如何帮助团队更高效地工作，更快地交付高质量产品从而提高客户满意度非常有价值。敏捷和 DevOps 绝不是对抗性的（或至少没有这个意图）。在敏捷革命中，它们更像是盟友而不是敌人。敏捷和 DevOps 可以相互协作一致对外，因此可以在相同的场合共存。via: https://opensource.com/article/20/2/devops-vs-agile作者：Taz Brown 选题：lujun9972 译者：messon007 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出