现代软件交付完全是繁文冗节，对吗？不完全正确。文档和管控的流程仍旧是防止企业陷入困境，保证员工不丢掉工作的有效方式，让文档和管控成为进展缓慢的同义词是因为一些历史原因。软件版本引入的相同的自动化也适用于文档领域。DevOps文档也不例外：它正在改革。
如果我们意识到过去IT企业是如何记录基础架构的，那么结论就是文档已经不完整很久了。文档上花费了大量时间创建永远也不会使用的信息。完成文档的核心动力是满足检查条件，而不是给团队带来实际受益。这里的问题是信息是发散的。文档以瀑布方式创建，很少更新，很容易出错并且缺少一致性。有时候团队太忙没时间完成整个文档，以致一起被废弃了。
但是，当需要解决问题，以及加速恢复时间时，文档是了解配置是什么以及哪里出错的唯一选择。因此，当文档成为阻碍现代开发速度的原因时，这并不是合理的借口。
在DevOps发布链里，不能指望手动写文档。很多人认为文档应该随之消失。但实际上，文档应该大幅加强才对。现代开发里，文档不但没有消失，而且其生成和目标都发生了本质的变化。
实际上，文档的生成很透明，以致于其看上去像消失了一样。真正的DevOps实践会花专门时间在实时收集应用和日志数据。它们将这些信息存储到智能日志分析平台，基于这些信息之上构建神奇的报警系统，持续跟踪正在发生的事情并且作出响应。但是他们没有意识到的是同时，他们已经构建出了自动化的文档系统。
DevOps文档的来源是：
1.代码
2.配置管理脚本
3.应用性能日志
3.基础架构日志
5.报警工具和警报
6.组件监控
可能一开始使用这些系统并不是为了写文档，但这正是DevOps流程真实发生的情况：
通过使用流行的设计架构模型视图控制器和自动化的文档创建系统，合适的应用程序架构本身就可以生成有质量的文档。
配置脚本，比如Puppet和Chef是文档服务器。脚本能够提供关于生产环境里的所有基础架构如何搭建的清晰视图。
应用性能管理和服务器日志成为应用和基础架构的历史视图。
报警工具成为所有失败事件以及如何组织响应的历史记录。
组件监控工具展示使用了哪些组件， 以及是否什么时候有相关更新或者失败。
所有这些工具和流程替代了手动创建文档的需求，并且，它们一起构成了环境的完整文档。有时候称之为持续文档。它们比手动文档有高得多的覆盖率。它看上去可能不是带着很多截屏的大型Word文档，但是它们的价值是一样的。
但是，持续DevOps文档必须使用合适的引入方式和恰当的计划才能落地。如果你没有决定如何消费这些信息，那么其价值会快速消散。