文档写作的DevOps指南-不念博客

将文档写作加入到 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 实践的工作。即使他们的组织有技术写手，他们也可能跨开发团队工作。因此，开发人员和系统管理员能够捕捉、记录和交流他们的最佳实践是很重要的。这里有一些朝正确的方向发展的提示：