提升 DevOps 文档成熟度的过程与达到 DevOps 或 DevSecOps 成熟化的历程是类似的。

为了能在软件迭代交付周期内按时交付优质的文档，DevOps 和 DevSecOps 的文档实践也需要是敏捷的。这与实现 DevOps 类似，只是更偏向自动化和敏捷的内容处理方法。如果文档现在才进入你的机构的 DevOps 讨论，那么是时候让文档实践追上 DevOps 的步伐了。

下面是 DevOps 文档成熟度的四个层次：

第一层：临时且孤立

在最低一级成熟度（最不成熟），文档编制工作没有和 DevOps 开发对齐。开发团队和文档团队按照各自的路线开展工作，常常导致文档落后于开发。在竞争激烈的“云”世界里，因为文档问题而推迟产品发布是不可接受的。

人员

这个阶段的文档编制人员还没有摆脱传统的工作方式。 技术写作 technical writer 人员隶属于一个中心化的单独团队，与开发团队是脱节的。技术写作组和开发团队之间的鸿可能是由多方面原因造成的：

• 造成团队分裂和孤立的公司政治
• 团队只是将技术文档视为项目验收清单上的检查项，而不是推动项目成功的资产
• 事后才雇佣技术写作人员
• 技术写作的优先级与开发团队的实际情况不匹配

这个阶段，另一个在人员配置上的挑战是如何“界定工作完成”。刚接触敏捷实践的技术写作可能难以适应 CI/CD 工具链和流程。

文档工具和流程

这个阶段的技术写作仍习惯于使用传统的办公工具，比如办公套件和布局程序。这些工具不够敏捷，没有版本控制和内容管理的要求。它们无法与 DevOps 工具链高效集成，不能支撑快速开发。在这个成熟度，技术写作仍然参照遗留的模板和流程。

成果

这个级别交付的文档可能是过时的，甚至缺乏技术准确性的。如果开发团队以 DevOps 的速度推进工作，而技术文档编制却遵循传统的非敏捷流程（使用专有的工具和交付格式），这就很难让文档迭代速度并跟上应用程序的变化。

第二层：实验和试点

DevOps 文档成熟度的第二层是实验/试验阶段。这个阶段是 DevOps 团队主管和技术写作采取行动打造更敏捷的文档实践和工具的第一步。

理想的情况下，这些实验是 相关方 stakeholder 支持的试点项目的一部分。他们能够从文档交付流程的改善以及其与 DevOps 实践的集成中获益。

人员

本阶段的人员可能来自以下三种形式：

1. 有远见的技术写作为了更好地完成工作，用自己的时间来实验更敏捷的工具。并且向领导层提出更敏捷的文档编制过程的想法。
2. DevOps 负责人或工程师试用 Hugo 和 Jekyll 等工具，并将这些工具集成到 CI/CD 流水线中。然后 DevOps 小组教授技术写作如何使用它们。
3. 团队引入了第三方承包商或顾问，他们在 DevOps 文档工具方面具有专业知识，并且了解文档工具适合嵌入到 CI/CD 工具链和 DevOps 生命周期的位置。

文档工具和实践

Hugo 和 Jekyll 是本阶段开始出现的工具。在这个阶段也出现新的内容策略和技术写作方法。

成果

实验试点阶段理想的成果应该能够“ 落地并推广 land and expand ”。也就是说其它项目组也可以将其付诸实践。

这个阶段的实验也包括内容策略和发布流程上的根本性变化。其它非试点项目组的技术写作可以学习和使用它们。

试点带来的另一个可能的产出是 技术写作招聘流程 的变化。你需要针对 DevOps 和你新引入的文档工具对内部编写人员进行培训。

新的文档工具和流程是此阶段的关键成果，你需要通过演示、状态报告和内部案例研究等方式，将这一成果推给领导层、相关方和其它团队。

第三层：部分自动化和扩展

DevOps 文档成熟度的第三层（部分自动化和扩展）就是“落地并推广”的进一步行动。在这个阶段，其它 DevOps 团队借用试点项目中产生的 DevOps 文档工具和流程，吸取其中的经验教训。

人员

在这个成熟度，技术写作和 DevOps 团队开始更紧密的协作。招聘新的技术写作主要关注具有 DevOps 环境经验的人选。

工具和文档实践

技术写作开始从抛弃传统的工具和流程，转到更敏捷的文档工具上，比如：

• docToolchain
• Docbook
• Hugo
• Jekyll

在这个成熟度，技术写作也负责调整遗留的文档实践。

成果

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 自动化。

DevSecOps

DevSecOps 算是另一个流行趋势，它与在开发操作中的安全问题有关。最近与 漏洞 vulnerabilities （log4j）， 安全泄露 security breach （谷歌、脸书、微软），和安全攻击相关的问题增加了 DevSecOps 在企业中的重要性。 左移 shift left 方法强调了在软件生命周期的早期处理安全性和质量的重要性。在架构阶段就需要考虑隐私和 遵从性 compliances （如 GDPR）。这有助于降低成本，并且提升软件交付的速度。审计工具和安全检查列表是 DevOps 工具和系统的一部分，现在我们称为 DevSecOps。

AIOps

AI 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中国 荣誉推出