很多軟件系統(tǒng)由于性能問題導(dǎo)致了失敗，在開發(fā)生命周期和性能測試生命周期的每個階段都存在導(dǎo)致性能失敗的原因。有時候，性能問題是無法控制的，它不在項目經(jīng)理、技術(shù)架構(gòu)師或性能工程師的控制范圍之內(nèi)。從業(yè)務(wù)和個人層面來看，大多數(shù)的系統(tǒng)性能失敗僅僅是因為性能工程師、開發(fā)人員、 DBA、業(yè)務(wù)團隊和利益相關(guān)者之間從一開始就缺乏溝通，這導(dǎo)致了許多其他問題，這些問題將直接影響應(yīng)用程序的性能和 ROI。對任何應(yīng)用/產(chǎn)品進行有效性能測試的唯一目標是實現(xiàn)令人滿意的投資回報。性能測試和軟件工程是有風(fēng)險的，并且總是需要從開發(fā)的早期階段開始，進行大量的反復(fù)試驗。

系統(tǒng)性能的失敗必須與其他業(yè)務(wù)問題進行類似的處理。了解問題出在哪里，為什么會出問題，以及如何預(yù)防。在大多數(shù)場景中，需要每個人都了解/理解端到端全生命周期實現(xiàn)中的性能挑戰(zhàn)。他山之石，根據(jù)老碼農(nóng)的經(jīng)驗，總結(jié)了一個導(dǎo)致系統(tǒng)性能失敗的原因列表。

1. 對最終用戶反饋的置若罔聞

作為最終用戶，才會意識到的現(xiàn)有潛在性能問題。為了理解生產(chǎn)系統(tǒng)中現(xiàn)有的性能問題，需要從最終用戶那里獲得關(guān)于應(yīng)用程序在不同的預(yù)期負載條件下如何運行的持續(xù)反饋。總是有很多用戶在生產(chǎn)環(huán)境中使用某個功能，即使這一功能不能滿足他們期望的性能，他們也不會質(zhì)疑它，而且會假設(shè)它是正確的，當(dāng)用戶可以同時從多個位置訪問時，這可能是一個大問題。因此，如果想提高應(yīng)用程序的性能，就必須讓最終用戶參與進來，以獲得關(guān)于應(yīng)用程序或系統(tǒng)在生產(chǎn)環(huán)境中性能的持續(xù)反饋。當(dāng)然，與最終用戶的交互需要時間和精力，盡管如此，為了使產(chǎn)品/應(yīng)用提供最佳性能，這絕對是值得的。

2. 不關(guān)注性能目標

設(shè)定目標是確定系統(tǒng)性能的最重要方面之一。許多團隊經(jīng)常無法實現(xiàn)他們的性能目標以求改進，于是花費了大量時間修復(fù)系統(tǒng)中現(xiàn)有的和隱藏的性能問題。性能測試的完美目標應(yīng)該在最現(xiàn)實的條件下定義、設(shè)計和執(zhí)行，比如真實的瀏覽器、設(shè)備和多個地理位置。確定正確的指標來監(jiān)控，定義每個指標的最小閾值，執(zhí)行性能測試來得到基線結(jié)果，所有這些數(shù)字對于確定什么樣的變化可以創(chuàng)造性能改進是必要的。在軟件開發(fā)生命周期中盡早開始性能測試是一種很好的做法，可以首先消除瓶頸，并確保在用戶負載很重的情況下不斷檢查應(yīng)用程序的性能。

3. 不清晰及不完整的非功能性需求

收集完整的非功能性需求比功能性需求更復(fù)雜，因為它們被視為第二類甚至第三類需求。因此，它們經(jīng)常被誤解和忽視，只有少數(shù)組織將非功能性需求作為一等公民。這會在系統(tǒng)架構(gòu)/設(shè)計中導(dǎo)致嚴重的問題，經(jīng)常導(dǎo)致項目崩潰和網(wǎng)站崩潰，使系統(tǒng)無法使用。在大多數(shù)情況下，非功能性需求文檔不完整、不一致，或者在大多數(shù)不成功的項目中不存在。性能測試第一步是對應(yīng)用程序/系統(tǒng)進行可行性分析，并創(chuàng)建一組明確的非功能性需求。一個可靠的非功能性需求文檔將確定產(chǎn)品/應(yīng)用具有最佳性能的所有標準。此外，還需要:

• 為產(chǎn)品/應(yīng)用和系統(tǒng)建立明確的性能目標和期望
• 必須讓所有人(開發(fā)團隊、QA、管理團隊、 DBA、涉眾和業(yè)務(wù)團隊)達成一致。
• 在技術(shù)團隊、項目團隊和業(yè)務(wù)團隊之間建立溝通，以了解生產(chǎn)環(huán)境中最終用戶的實際性能問題
• 使用分析工具，獲取生產(chǎn)流量統(tǒng)計數(shù)據(jù)，以創(chuàng)建合適的工作負載模型
• 在收集非功能性需求時，了解應(yīng)用程序/產(chǎn)品的體系結(jié)構(gòu)、設(shè)計、問題和現(xiàn)有的性能問題
• 非功能性需求應(yīng)該從軟件開發(fā)過程的開始并在整個生命周期中進行討論; 如果應(yīng)用程序是全新的，基線和基準測試對于性能測試是必要的。
• 獲取所有涉及的內(nèi)部和外部組件的完整信息，并了解它們?nèi)绾瓮ㄐ?CDN、防火墻、 DNS、負載均衡器、服務(wù)器、網(wǎng)絡(luò)和系統(tǒng)、緩存等)
• 了解應(yīng)用程序內(nèi)存占用和第三方體系結(jié)構(gòu)限制
• 與涉眾和業(yè)務(wù)團隊交談，以了解目標并確定什么是基本的、現(xiàn)有的遺留系統(tǒng)性能問題、平臺約束和競爭對手。
• 有必要記錄所有內(nèi)容，并讓業(yè)務(wù)和其他涉眾一起參加會議，以確定現(xiàn)有的非功能性需求是否合適，并就定義的 SLA 達成一致。

4. 糟糕的架構(gòu)設(shè)計

最初，糟糕的架構(gòu)設(shè)計只會導(dǎo)致一些小問題，這些問題在開始時會比較少，但是會逐漸累積起來。簡單維護是一個挑戰(zhàn)，在一個區(qū)域中的任何更改都會破壞應(yīng)用程序的其他部分。如果在架構(gòu)設(shè)計階段作出了不恰當(dāng)?shù)臎Q定，應(yīng)用/系統(tǒng)可能會出現(xiàn)嚴重的性能下降，導(dǎo)致過多的網(wǎng)絡(luò)延遲和其他問題。由于不了解明確定義的系統(tǒng)架構(gòu)，在負載測試執(zhí)行階段會存在太多不確定性和復(fù)雜性的高風(fēng)險，這可能會給性能測試和工程團隊帶來意想不到的性能問題。在軟件開發(fā)生命周期的應(yīng)用程序設(shè)計和開發(fā)階段，由于性能方面的挑戰(zhàn)，軟件發(fā)布可能會推遲。

5. 對技術(shù)依賴缺乏預(yù)見

依賴關(guān)系是允許更多應(yīng)用和功能組件之間的連接。特定的操作系統(tǒng)版本、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器或 Java 虛擬機、通用語言運行庫和框架都是依賴關(guān)系的例子。然而，有些依賴關(guān)系更為復(fù)雜，比如由 Linux、 Java 中的各種包組成的依賴關(guān)系，以及 Python 和 Ruby 等腳本語言組成的依賴關(guān)系。理解每個技術(shù)在設(shè)計和基礎(chǔ)設(shè)施方面對每個組件的依賴性，使用哪些技術(shù)，以及使用哪些框架和工具來開發(fā)應(yīng)用程序，對于系統(tǒng)性能來說，以期望的結(jié)果完成性能測試是至關(guān)重要的。

6.新功能的過度擴展

過度的新功能擴展是軟件開發(fā)人員經(jīng)常遇到的一個主要障礙。處理這種情況的有效方法是定期舉行面向用戶體驗的會議和討論，每個團隊成員都參與其中，以驗證每個功能，并確保它有意義地解決了設(shè)定的問題。性能測試團隊必須從規(guī)劃發(fā)布的時間表開始，并且應(yīng)該主動地公布需要的時間，以防在發(fā)布前的最后一分鐘添加任何新功能。如果項目有一個固定的最后期限，就需要提前計劃環(huán)境需求，以確保意外的環(huán)境延遲不會影響性能測試的進度。如果在最后一刻繼續(xù)添加了新功能，交付的質(zhì)量大概率會受到影響。最終，客戶可能會拒絕最終的可交付成果，從而產(chǎn)生返工和額外資源短缺的情況。

7. 推崇好大喜功

在性能測試執(zhí)行的最初版本中，直接關(guān)注目標 SLA 以達到可接受的限制可能是不現(xiàn)實的。性能測試是一個迭代過程，需要大量持續(xù)的性能測試來識別和消除所有的性能瓶頸。需要花費額外的時間優(yōu)化每一行代碼和組件，以提高系統(tǒng)/應(yīng)用程序的性能。在性能測試中，每個 SLA 和 KPI 都是必要的，并且只有通過持續(xù)的性能測試、代碼分析、內(nèi)存分析、性能工程、監(jiān)控以及客戶端和服務(wù)器端的調(diào)優(yōu)才能獲得所需的響應(yīng)時間、吞吐量、網(wǎng)絡(luò)延遲和資源利用率，這有時需要花費很長的時間。分析所有的性能結(jié)果和降低，并從用戶級、操作系統(tǒng)級、系統(tǒng)級、網(wǎng)絡(luò)級和服務(wù)器級使用適當(dāng)?shù)闹笜耸占瘮?shù)據(jù)，對所有導(dǎo)致性能問題根本原因的分析是至關(guān)重要的。

8. 容量規(guī)劃的匱乏

許多基礎(chǔ)設(shè)施未能實施有效的規(guī)劃，簡單地說，容量規(guī)劃過程并不簡單直接。我們可以創(chuàng)建一個場景、添加流量、評估結(jié)果、解決性能問題，然后重復(fù)，直到滿意為止，但是實際的問題往往伴隨著糟糕的容量規(guī)劃。糟糕的容量計劃增加了性能缺失的可能性，風(fēng)險會完全暴露，最終導(dǎo)致失敗。所有這些都可以通過仔細的容量規(guī)劃來適當(dāng)解決。來自基礎(chǔ)設(shè)施領(lǐng)域的系統(tǒng)工程師、來自數(shù)據(jù)庫領(lǐng)域的DBA和來自應(yīng)用程序開發(fā)領(lǐng)域的程序員是最需要參與有效容量規(guī)劃過程的三類人。許多人有時會將容量管理與容量計劃混淆，不能準確地預(yù)測和錯誤預(yù)測未來的工作負載。需要確保識別準確的資源需求(CPU、內(nèi)存、磁盤空間和網(wǎng)絡(luò)帶寬) ，以支持當(dāng)前和未來增加的工作負載，以滿足業(yè)務(wù)需求并避免容量規(guī)劃失敗。使用正確的度量標準進行持續(xù)監(jiān)控將幫助我們進行有效的容量規(guī)劃，并且還有助于處理流量增加后未預(yù)料到的工作負載。

9. 性能問題沒有完全解決

當(dāng)應(yīng)用的用戶量增加時，往往會看到更多的性能問題。隨著時間的推移，系統(tǒng)中隱藏的性能問題和已知的性能問題是導(dǎo)致性能持續(xù)下降的主要原因。必須與項目中的每個團隊成員討論確定的每個瓶頸，以成功地確保客戶 SLA 的性能。當(dāng)涉及到性能問題時，每一秒都很重要，如果忽略現(xiàn)有的性能問題，系統(tǒng)將會變慢，甚至更糟。例如，某些服務(wù)可能會停止在嚴重超載的服務(wù)器上運行，從而使應(yīng)用程序無法訪問。找出監(jiān)控數(shù)據(jù)，檢查服務(wù)的健康狀態(tài)，一般就能找出性能問題的常見原因。

10. 方法論的缺失

缺乏合適的方法來建立性能測試策略及其覆蓋范圍的話，會很難獲得有效的性能測試結(jié)果。理解性能測試方法和過程將幫助團隊中的每個工程師，特別是當(dāng)性能問題出現(xiàn)時，為每個發(fā)生問題的瓶頸提供正確的修復(fù)。性能測試過程應(yīng)該有良好的計劃和定義，并且文檔化。好的文檔可以在開發(fā)人員、 DBA和QA之間建立有效的溝通。隨著軟件變得更加復(fù)雜和多元化，并且有越來越多的平臺和位置需要測試，需要有一個強有力的性能測試方法，以確保正在開發(fā)的軟件系統(tǒng)經(jīng)過充分的性能測試，以確保它們滿足特定的業(yè)務(wù)要求，并且能夠在所有預(yù)期的負載條件和環(huán)境中高性能地運行。