部署文档撰写经验分享
2011年，公司調我和幾個同事去廣西，與現場的同事一起撰寫部署文檔。去之前還感覺領導有點小題大做，寫個部署文檔至于么？我在公司半天就能寫出一版了，還叫這么多人跑到廣西寫這個，真是崽賣爺田不心疼，公司費用隨便花。
到了廣西，負責人說了下部署文檔的要求：簡單明了、傻瓜部署。簡單明了指的是文字清楚、不能有歧義、不拽文、精練。傻瓜部署指的是文檔要寫好每一步的操作，傻瓜拿著這個文檔都能部署，不需要有專業的知識。
部署文檔分為平臺程序部署、數據庫部署、業務開通部署等模塊，筆者分到數據庫部署這一塊。平時我做部署時，對數據庫安裝有一些疑惑，趁此機會，把數據庫版本選擇及部署這塊也熟悉了一下。首先確認數據庫版本，下載版本后一步步安裝，并把每一步的截圖都放到文章里，即使只是點擊下一步即可的截圖也放進去。經過十幾次部署后，把部署過程中遇到的各種問題，和自己的一些疑問也記錄下來，并做說明解答。
數據庫部署完畢后，開始做數據庫建立，數據備份導入。日常做數據庫割接升級前，一定要做數據庫備份，并做備份還原驗證，看看備份后的數據是否能成功還原。然后再做數據割接升級。以一次升級割接數據庫為例，寫明這次割接的范圍、變更情況。把割接腳本每行寫上注釋，及是否需要根據本省情況進行調整。撰寫割接升級腳本時，把數據庫IP地址、庫名等標紅。各個省份現場升級時，修改為本地的數據庫地址和庫名即可。最后寫上FAQ，把一些日常工作答疑時，大家常問的一些數據升級問題和解決方案寫上。
最后寫數據割接腳本后，如何確認是否遷移升級成功，提煉了幾條list清單，按照這幾項檢查，基本上能夠確認本次升級成功。
文檔撰寫完畢后，我們幾個互相交換了下文檔，嚴格按照他們寫的文檔一步步操作，看是否能夠成功完成升級。然后整合大家提的意見，增加了部分自己認為是常識，未做說明或未寫上的事項。
兩周后，部署文檔撰寫完畢。發給各省，果然收到各省的一致好評。省份同事說，以前做升級割接時，都是先研究下部署文檔，然后重新寫一版部署文檔，過程中還需要請教研發、DBA、技術支持等人員。現在直接按照這份文檔進行升級即可。大大減少了省份的工作量，也減少了部署出現問題的幾率。
筆者后面也去了幾個省份做升級割接，發現每次升級割接時，按照之前撰寫的那版文檔，稍作改動，調整成本次的腳本和程序即可完成升級。而且根據文檔后面的檢查list清單，基本上能夠保證99%以上的功能點都能使用。而不是之前升級后，自己隨機選取一些頁面進行確認，自我感覺沒有問題，但第二天客戶使用時發現一堆問題。
筆者后來負責一個群組項目，剛接手時就趕上五六十個省份并發檢查測試。省份維護人員對如何部署程序一無所知，全靠總部幾個研發測試人員全國奔波升級，大家當時苦不堪言，其中一個人一個月跑了十幾個省升級。第二年我就召集各個省份的負責人來京，每個省份分配了幾項，總共61項。讓他們寫自己負責那幾項的部署確認，問題檢查，疑點剖析等，然后讓大家做交叉檢查。歷時兩周完成了這版文檔，之后的幾年內，檢查項也有調整，也出現過幾次五六十個省份并發測試檢查。但省份再也沒有提出部署割接的支持需求。
很多人對部署文檔都存在錯誤的認識，認為其只是一個簡單的文檔，隨便一個人寫寫就行。殊不知它是系統上線交付用戶使用的關鍵一環。前期需求調研反復修改確認，研發熬夜熬肝開發等，經歷了萬里長征到最后勝利在望時，因為部署升級的問題，導致好多功能不能正常使用，給客戶留下公司不專業的印象，那該多冤呢。
部署升級是現場維護人員日常維護的一項重要的指標和工作內容。如果公司總部不把部署文檔寫好，而靠各個現場根據自己的經驗和技術能力去保證割接升級的成功率，維護公司的形象。各個現場的人員水平層次不齊，而且各個現場維護人員做升級割接時，也不能保證自己的思路和想法能夠完美覆蓋公司的所有檢查項。那么升級割接的成功率可想而已，客戶對公司的印象也可想而知了。
總結
以上是生活随笔為你收集整理的部署文档撰写经验分享的全部內容，希望文章能夠幫你解決所遇到的問題。
