即便在一些有着稳健和安康的文档编写文化的组织中，应用的进化和修正速度也会远远快于文档编写速度。理想状况是软件变化速度远远快于文档编写速度，即便有自动化文档系统，有时分我们依然需求人工编写一些文档。这种文档需求经过一定的技术转换，方能提供应在特殊阅读环境中的读者阅读，因而无法经过自动化办法维护。
API参考文档以及其他高度技术化的文档，则很可能经过编程言语平台的自动化文档编写机制完成（如Java的 Javadoc、Ruby的RDoc Python的 Pydoc等）。但是，有些需求人类表达（这是最珍贵的交流方式）的文档，则不像技术文档一样与应用程序和根底架构有严密关系。为此，技术文档可能在一个月内（或更短的时间内）就会过时，而有一些文档可能几年时间都不曾更新过逐个不过，这种状况实践上比没有技术文档还要槽，由于会进上程帅以为不需求从别处获取信息，而误以为这些过时文档就是正确的信息。
除此之外，当文档创立后，许多工程师就不会再更新文档了。定期检查文档才干让文档坚持最新状态。
处理办法：通知工程师更新文档
在整个组织范围内，人们不太可能细致阅读文档管理系统（如Wi） 中的一切文档，但在一个部门级别上，却可能会呈现一些文档修正和编辑。但是，运用随机办法的效率是远远不够的，我们必需经过某种机制，让文档管理系统可以通知文档一切人或管理员，让他们在一段时间后更新文档。开源Wiki系统 Twiki提出了一种处理计划，它的页面像报纸一样在时间长了之后会变黄。而且，在系统以为文档可能需求更新时，它会向文档一切人发送一封通知邮件。
但只要工具还不够，运维与开发团队还必需转变认识，他们必需将运用文档视为一种软件改良手腕。例如，需求更新的页面会变成黄色但这并不意味着有人会去更新它。必需有人去响应这个通知，假如接纳者不了解创立及维护文档关于代码和系统的价值，那么这个响应可能就不会呈现。假如技术人员晓得当文档需求更新时，系统才会通知他们，那么当他们接纳到一个通知时，他们就很可能会跟进处置这个通知。这似乎有一些琐碎，但是对技术人员予以告知能够鼓舞他们认真看待文档。
益处：将文档整合到常规活动中
当网站设计开发人员习气了接纳更新通知并响应这些通知之后，他们就会看到文档在改良软件方面的价值，这样将进一步鼓励他们及时响应通知。构成大型网站根底架构的软硬件通常由一定数量的位于数据中心内的效劳器组成。目前，这些根底架构的装置及维护在一定水平上依然经过人工方式完成。我们将引见随着计算范畴内的打破性停顿，虚拟化根底架构是如何减少人工需求的，以及如何完成其中一些流程的自动化。不过，在思索施行自动化之前，最好先理解一下当前的工作流程。
更多精彩请关注：http://www.jmseo.com.cn
