即使在一些有著(zhù)穩健和健康的文檔編寫(xiě)文化的組織中，應用的進(jìn)化和修改速度也會(huì )遠遠快于文檔編寫(xiě)速度?，F實(shí)情況是軟件變化速度遠遠快于文檔編寫(xiě)速度，即使有自動(dòng)化文檔系統，有時(shí)候我們仍然需要人工編寫(xiě)一些文檔。這種文檔需要通過(guò)一定的技術(shù)轉換，方能提供給在特殊閱讀環(huán)境中的讀者閱讀，因此無(wú)法通過(guò)自動(dòng)化方法維護。
 
API參考文檔以及其他高度技術(shù)化的文檔，則很可能通過(guò)編程語(yǔ)言平臺的自動(dòng)化文檔編寫(xiě)機制完成(如Java的 Javadoc、Ruby的RDoc Python的 Pydoc等)。然而，有些需要人類(lèi)表達(這是最寶貴的交流方式)的文檔，則不像技術(shù)文檔一樣與應用程序和基礎架構有緊密關(guān)系。為此，技術(shù)文檔可能在一個(gè)月內(或更短的時(shí)間內)就會(huì )過(guò)期，而有一些文檔可能幾年時(shí)間都未曾更新過(guò)一一不過(guò)，這種情況實(shí)際上比沒(méi)有技術(shù)文檔還要槽，因為會(huì )進(jìn)上程帥以為不需要從別處獲取信息，而誤認為這些過(guò)期文檔就是正確的信息。


 
除此之外，當文檔創(chuàng )建后，許多工程師就不會(huì )再更新文檔了。定期檢查文檔才能讓文檔保持最新?tīng)顟B(tài)。
 
解決方法:通知工程師更新文檔
 
在整個(gè)組織范圍內，人們不太可能詳細閱讀文檔管理系統(如Wi) 中的所有文檔，但在一個(gè)部門(mén)級別上，卻可能會(huì )出現一些文檔修改和編輯。但是，使用隨機方法的效率是遠遠不夠的，我們必須通過(guò)某種機制，讓文檔管理系統能夠通知文檔所有人或管理員，讓他們在一段時(shí)間后更新文檔。開(kāi)源Wiki系統 Twiki提出了一種解決方案，它的頁(yè)面像報紙一樣在時(shí)間長(cháng)了之后會(huì )變黃。而且，在系統認為文檔可能需要更新時(shí)，它會(huì )向文檔所有人發(fā)送一封通知郵件。
 
但只有工具還不夠，運維與開(kāi)發(fā)團隊還必須轉變認識，他們必須將使用文檔視為一種軟件改進(jìn)手段。例如，需要更新的頁(yè)面會(huì )變成黃色但這并不意味著(zhù)有人會(huì )去更新它。必須有人去響應這個(gè)通知，如果接收者不理解創(chuàng )建及維護文檔對于代碼和系統的價(jià)值，那么這個(gè)響應可能就不會(huì )出現。如果技術(shù)人員知道當文檔需要更新時(shí)，系統才會(huì )通知他們，那么當他們接收到一個(gè)通知時(shí)，他們就很可能會(huì )跟進(jìn)處理這個(gè)通知。這似乎有一些瑣碎，但是對技術(shù)人員予以告知可以鼓勵他們認真對待文檔。
 
好處:將文檔整合到常規活動(dòng)中
 
當網(wǎng)站設計開(kāi)發(fā)人員習慣了接收更新通知并響應這些通知之后，他們就會(huì )看到文檔在改進(jìn)軟件方面的價(jià)值，這樣將進(jìn)一步激勵他們及時(shí)響應通知。構成大型網(wǎng)站基礎架構的軟硬件通常由一定數量的位于數據中心內的服務(wù)器組成。目前，這些基礎架構的安裝及維護在一定程度上仍然通過(guò)人工方式完成。我們將介紹隨著(zhù)計算領(lǐng)域內的突破性進(jìn)展，虛擬化基礎架構是如何減少人工需求的，以及如何實(shí)現其中一些流程的自動(dòng)化。不過(guò)，在考慮實(shí)施自動(dòng)化之前，最好先了解一下當前的工作流程。