现代软件交付完全是繁文冗节，对吗？不完全正确。文档和管控的流程仍旧是防止企业陷入困境，保证员工不丢掉工作的有效方式，让文档和管控成为进展缓慢的同义词是因为一些历史原因。软件版本引入的相同的自动化也适用于文档领域。DevOps文档也不例外：它正在改革。

如果我们意识到过去IT企业是如何记录基础架构的，那么结论就是文档已经不完整很久了。文档上花费了大量时间创建永远也不会使用的信息。完成文档的核心动力是满足检查条件，而不是给团队带来实际受益。这里的问题是信息是发散的。文档以瀑布方式创建，很少更新，很容易出错并且缺少一致性。有时候团队太忙没时间完成整个文档，以致一起被废弃了。

但是，当需要解决问题，以及加速恢复时间时，文档是了解配置是什么以及哪里出错的唯一选择。因此，当文档成为阻碍现代开发速度的原因时，这并不是合理的借口。

在DevOps发布链里，不能指望手动写文档。很多人认为文档应该随之消失。但实际上，文档应该大幅加强才对。现代开发里，文档不但没有消失，而且其生成和目标都发生了本质的变化。

实际上，文档的生成很透明，以致于其看上去像消失了一样。真正的DevOps实践会花专门时间在实时收集应用和日志数据。它们将这些信息存储到智能日志分析平台，基于这些信息之上构建神奇的报警系统，持续跟踪正在发生的事情并且作出响应。但是他们没有意识到的是同时，他们已经构建出了自动化的文档系统。

DevOps文档的来源是：

1.代码

2.配置管理脚本

3.应用性能日志

3.基础架构日志

5.报警工具和警报

6.组件监控

可能一开始使用这些系统并不是为了写文档，但这正是DevOps流程真实发生的情况：

通过使用流行的设计架构模型视图控制器和自动化的文档创建系统，合适的应用程序架构本身就可以生成有质量的文档。

配置脚本，比如Puppet和Chef是文档服务器。脚本能够提供关于生产环境里的所有基础架构如何搭建的清晰视图。

应用性能管理和服务器日志成为应用和基础架构的历史视图。

报警工具成为所有失败事件以及如何组织响应的历史记录。

组件监控工具展示使用了哪些组件， 以及是否什么时候有相关更新或者失败。

所有这些工具和流程替代了手动创建文档的需求，并且，它们一起构成了环境的完整文档。有时候称之为持续文档。它们比手动文档有高得多的覆盖率。它看上去可能不是带着很多截屏的大型Word文档，但是它们的价值是一样的。

但是，持续DevOps文档必须使用合适的引入方式和恰当的计划才能落地。如果你没有决定如何消费这些信息，那么其价值会快速消散。

它的好处比想象的更大。对于团队的新成员而言，这是培训他们的轻松方式。只需要使用这些工具一周，比起直接的课堂式讲授，团队的新成员能够更为清楚地知道系统是如何搭建的。它还在系统出错时避免不得不找到出问题领域的专家，因为无需特别去抓取某些信息，所有信息都已经在那里了。比传统IT里能想象的还要更大的覆盖率。DevOps文档并没有消失。该领域的变革极大地改进了使用文档的方式。现在，文档的生成是自动化的，其使用是成熟的，而且更加频繁，并且它是源于操作的，而不是被迫响应生成的。