生產(chǎn)過程中出現(xiàn)的問題正逐漸得到中層和最高管理層的重視。不管是身為開發(fā)人員還是架構(gòu)師，下列的事項都應(yīng)該得到你足夠的重視以避免陷入未來的尷尬境地。你也可以把它作為排查問題的便簽。

#1、不在屬性文件或 XML 文件中外化配置屬性。比如，沒有把批處理使用的線程數(shù)設(shè)置成可在屬性文件中配置。你的批處理程序無論在 DEV 環(huán)境中，還是 UAT（用戶驗收測試）環(huán)境中，都可以順暢無阻地運行，但是一旦部署在 PROD 上，把它作為多線程程序處理更大的數(shù)據(jù)集時，就會拋出 IOException，原因可能是 JDBC 驅(qū)動版本不同，也可能是#2 中討論的問題。如果線程數(shù)目可以在屬性文件中配置，那么使它成為一個單線程應(yīng)用程序就變得十分容易了。我們不再需要為了解決問題而反復地部署和測試應(yīng)用了。這種方法也同樣適用于配置 URL、服務(wù)器和端口號等。

#2、測試中使用的數(shù)據(jù)集規(guī)模不合適。比如，生產(chǎn)過程中一個典型的場景就是只使用 1 到 3 個賬戶進行測試，而這個數(shù)量本應(yīng)是 1000 到 2000 個的。在做性能測試時，使用的數(shù)據(jù)必須是真實并且未經(jīng)裁剪的。不貼近真實環(huán)境的性能測試，可能會帶來不可預料的性能、拓展和多線程問題。只有使用更大規(guī)模的數(shù)據(jù)集對應(yīng)用程序進行測試，才能保證它正常運行并滿足非功能屬性的 SLAs（服務(wù)水平標準）。

#3、天真地認為應(yīng)用程序中所調(diào)用的外部和內(nèi)部服務(wù)是可靠的，并且是始終可用的。不允許出現(xiàn)服務(wù)調(diào)用超時和重試，將會對應(yīng)用程序的穩(wěn)定性和性能造成不利地影響。需要進行適當?shù)姆?wù)中斷測試。這一點十分重要，因為如今的應(yīng)用程序多是分布式并且面向服務(wù)的，都需要大量的網(wǎng)絡(luò)服務(wù)。無限地請求不可用的服務(wù)會損害應(yīng)用程序。也需要對負載均衡器進行測試，以確保它能正常工作，使每個節(jié)點達到平衡。

#4、沒有遵循最低限度的安全要求。正如上文提到，網(wǎng)絡(luò)服務(wù)隨處可見，從而使得黑客可以輕易地利用它進行拒絕服務(wù)攻擊。所以，在使用安全套接層時，必須完成基本的驗證并使用 Google skipfish 等工具進行滲透測試。不安全的應(yīng)用程序不僅會威脅其自身穩(wěn)定性，還可能會因為數(shù)據(jù)完整性問題對公司的聲譽造成負面影響，例如出現(xiàn)了客戶 “A”可以瀏覽客戶“B”數(shù)據(jù)的情況。

#5、沒有進行跨瀏覽器的兼容性測試。如今的網(wǎng)絡(luò)應(yīng)用程序多是豐富的單頁應(yīng)用程序，它們使用 JavaScript 編程語言以及 angular js 這樣的框架。為了使你建設(shè)的網(wǎng)站能夠流暢地運行于不同的設(shè)備和瀏覽器之間，必須實現(xiàn)與之對應(yīng)的設(shè)計。所以為了確保你的應(yīng)用程序可以適用于所有設(shè)備和瀏覽器，必須對其進行兼容性測試。

#6、沒有外化可能經(jīng)常發(fā)生變化的商業(yè)規(guī)則。例如稅法、政府或行業(yè)相關(guān)要求、分類法等?？梢允褂孟?Drools 這樣的引擎來處理商業(yè)規(guī)則，它幫助你通過存入數(shù)據(jù)庫或 excel 的形式，來外化這些商業(yè)規(guī)則。企業(yè)掌握了這些商業(yè)規(guī)則，就能以最少的變化和測試完成對稅法或相關(guān)要求地快速反應(yīng)。

#7、沒有提供下列文檔

1. 編寫單元測試文檔并使其擁有良好的代碼覆蓋率。
2. 集成測試。
3. 一個綜合的或者百科全書式的頁面列出了所有的軟件構(gòu)件，比如類、腳本、配置文件等，而這些構(gòu)件要么是被修改了的，要么是新創(chuàng)建的。
4. 高層次的概念圖描述了所有的組件，交互和結(jié)構(gòu)。
5. 而基礎(chǔ)文檔則告訴開發(fā)者“如何結(jié)合數(shù)據(jù)源的詳細信息來搭建開發(fā)環(huán)境”。

除了 COS（滿足的條件）這種由 MindMap 創(chuàng)建的形式之外，敏捷開發(fā)中還有 1 和 2 這兩種主要的文檔形式。

#8、沒有適當?shù)臑?zāi)害恢復計劃以及系統(tǒng)監(jiān)視和歸檔策略。在項目截止日期來臨之際，常常因為急于部署項目而遺漏了這些事項。沒有通過 Nagios 和 Splunk 建立合適的系統(tǒng)監(jiān)視機制不僅會威脅到應(yīng)用程序的穩(wěn)定性，還會妨礙目前的診斷和將來的改進工作。

#9、沒有為數(shù)據(jù)庫表設(shè)計方便整理的列，比如 created_datetm、update_datetm、created_by、updated_by 和時間戳，也沒有提供有條理的刪除記錄列，如可以取‘Y'或‘N'的‘deleted'列或是可以取‘Active'或‘Inactive'的 ‘record_status'列。

#10、沒有制定適當?shù)幕爻酚媱潯?/strong>導致在系統(tǒng)發(fā)生故障時，沒有辦法將系統(tǒng)恢復到部署前的穩(wěn)定狀態(tài)。這個計劃需要反復推敲并有相關(guān)團隊簽字保證。計劃包括了，退回到軟件先前的版本，去除插入到數(shù)據(jù)庫中的所有數(shù)據(jù)以及屬性文件的所有條目。