Will Kelly 发布的文章

提升 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 环境经验的人选。

工具和文档实践

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

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

成果

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 的生命周期中。

title=

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

2021 年，我们的顶级 DevOps 文章聚焦于工具、最佳实践和最关键的部分：转型。

title=

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 转型的文章。它们是：

2022 年和 DevOps 的未来

看到 DevOps 的文章登上了 2021 年最受欢迎的名单，说明 DevOps 将迎来一个更加有趣的 2022 年，因为组织正在继续掌握他们的工具，改进他们的战略，并继续他们的 数字化转型，以便在不断变化的市场中有效地竞争。

感谢所有阅读我们的 DevOps 文章、喜欢这些文章，并通过网站和社交媒体给我们发送评论的人。

via: https://opensource.com/article/22/1/devops-transformation

作者：Will Kelly 选题：lujun9972 译者：CN-QUAN 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你如何定义持续集成/持续部署管道取决于你组织的要求。

title=

持续集成 continuous integration / 持续部署 continuous deployment （CI/CD）管道是每个 DevOps 计划的基础。 CI/CD 管道打破了传统的开发孤岛，使开发和运营团队能够在整个软件开发生命周期中进行协作。

更好的是，转向 DevOps 和 CI/CD 管道可以帮助你的组织以更高的速度更安全地 交付软件。

拆解 CI/CD 管道

CI/CD 管道有很多定义，所以我总是建议组织定义自己的 CI/CD 管道版本和其他 DevOps 概念，而不是使用其他人的。开源 CI/CD 工具为你提供构建满足组织要求的 CI/CD 管道的自由和选择。

形成 CI/CD 管道的阶段是将不同的任务子集分组为 管道阶段。典型的管道阶段包括：

  • 构建：开发人员编译应用程序代码。
  • 测试：质量保证（QA）团队使用自动化测试工具和策略测试应用程序代码。
  • 发布：开发团队将应用程序代码交付到代码库。
  • 部署：DevOps 团队将应用程序代码分阶段投入生产。
  • 安全性和合规性：QA 团队根据项目要求验证构建。这是组织部署容器扫描工具的阶段，这些工具根据 常见漏洞和暴露 Common Vulnerabilities and Exposures （CVE）检查容器镜像的质量。

这些是 CI/CD 管道的标准阶段，但一些组织调整 CI/CD 管道模型以满足他们的要求。例如，为医疗保健市场构建应用程序的组织，具有严格的合规性标准，可以在整个工具链中分发测试、验证和合规性门槛。

其他示例可能是依赖于具有开源软件（OSS）的复杂软件供应链的组织。商业组件可能会设立一个门槛，开发团队成员可以在其中为 OSS 包生成 软件物料清单 software bill of materials （SBOM），或者外部商业软件供应商必须将 SBOM 作为其合同可交付成果的一部分进行交付。

CI/CD 管道的障碍

实施 CI/CD 管道会改变团队的流程和文化。尽管许多开发人员愿意接受某些任务和测试的自动化，但人员可能成为采用 CI/CD 的障碍。

从瀑布式流程转向 CI/CD 可能会动摇某些组织中基本的和隐含的权力结构。由于 CI/CD 管道提高了软件交付速度，旧手动流程的“守门人”可能会受到这种变化的威胁。

整合机会

随着你在文化、流程和工具中达到更高的 DevOps 成熟度水平，包含 CI/CD 工具链的工具的开源根源为一些激动人心的集成创造了机会。

分析公司 Forrester 在 2020 年预测， 即时学习 just-in-time learning 将加入 CI/CD 管道。如果你考虑一下，会发现这是有道理的。在当前远程工作的时代，甚至对于新员工的远程入职，这更有意义。例如，组织可以将文档 wiki 与内部流程文档集成到其管道中。

更雄心勃勃的组织可以将学习管理系统（LMS）（例如 Moodle）集成到其 CI/CD 管道中。它可以使用 LMS 发布有关新 DevOps 工具链功能的简短视频，开发人员在加入时或在整个管道中更新工具时需要学习这些功能。

一些组织正在将群聊和其他协作工具直接集成到他们的 CI/CD 管道中。聊天平台提供警报并支持团队之间的协作和沟通。将 Mattermost、Rocket.Chat 或其他 企业聊天 平台集成到你的 CI/CD 管道中需要预先规划和分析，以确保管道用户不会被警报淹没。

另一个需要探索的集成机会是将分析和高级报告构建到你的 CI/CD 管道中。这有助于你利用通过管道传输的数据。

总结

CI/CD 管道是 DevOps 的基础。开源使其能够适应并灵活地满足你在 DevOps 之旅中实施的运营变更所产生的新需求。

我希望看到对统一 DevOps 平台趋势的开源响应，在这种趋势中，组织寻求端到端的 CI/CD 解决方案。这种解决方案的要素就在那里。毕竟，GitLab 和 GitHub 将他们的平台追溯到开源根源。

最后，不要忘记每一个成功的 CI/CD 工具链背后的教育和外展。记录你的工具链和相关流程将改善开发人员入职和持续的 DevOps 团队培训。

你和你的组织如何定义你的 CI/CD 工具链？请在评论中分享你的反馈。

via: https://opensource.com/article/21/6/what-cicd-pipeline

作者：Will Kelly 选题：lujun9972 译者：baddate 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出