技能和能力：展現靈活性和適用性
可以這樣說，效能管理中最重要的技能是靈活性。任何應用程式架構的目標都是實現所需的結果，對吧？其結果可能因組織不同而有很大的差別，但總的說來，不能得到所需結果的架構只能算是失敗的專案。部署之後發現架構存在問題總會讓人有些洩氣。而這就是需要靈活性的地方。當架構存在缺陷時，要把您的自尊放在一邊，保持足夠的靈活性，敢於承認這一事實。您將從經驗中得到重要教訓，並保持足夠開放的態度，以考慮各種解決方案和問題。
同樣，適用性在管理架構的效能時也至關重要。有了適應能力後，方向的突然變化或意外的障礙並不會對您造成影響。您能夠看到它們所代表的機會，了解效能問題所帶來的各種可能性。靈活性可以幫助您認識問題，而適應性可幫助您容忍和接受變更。雖然只擁有其中一項也不錯，但如果同時擁有這兩項技能，就能從效能管理方面獲得更多的支援。
技能和能力：致力於溝通
作為架構的一部分，您應該在效能相關的關鍵時期求助於溝通團隊或自行制定溝通計畫。這個計畫並不需要多麼詳細，只需要能夠幫助您或其他人在出現效能問題時快速地確定應該通知哪些人，以及應該按怎樣的頻率更新問題解決進度。例如，簡單的效能管理溝通計畫可以列出應該通知的主要高層管理人員、他們需要了解的資訊以及將用於與其進行溝通的方式。無論一年後您是否仍然在處理此專案，其他人都可接替您進行相關工作，準確地知道和哪些人聯絡以及何時會出現效能問題。
技能和能力：展示分析能力
您分析問題的能力如何？毋庸置疑，這在應用程式架構師工作中占有極大的份量，因此您至少要習慣分析問題和查詢解決方案。這很好，因為效能管理對分析技能的要求很高。您這方面的技能將隨著在效能管理領域的使用而逐漸增強。
在開發階段，您將分析資訊，以進行**建模和作出基於事實的決策。在效能管理階段，您將以兩種主要方式使用分析技能。首先，需要整個架構，以確定不同的部分將對整個組織造成什麼樣的影響或**可能會與實際偏離的地方。這聽起來很簡單，但需要能夠對根本原因進行專研，而這就是在效能管理期間使用分析技能的另一種方式。將分析技能用於效能管理時，務必記住，您不僅在分析問題來得到解決方案，而且還要分析所涉及的風險和可能會給組織帶來的好處。
工具和技術：找到根源
在任何應用程式架構環境中，根源分析對有效的效能管理都是非常重要的。簡單說來，這就是以確定和找出效能問題根源為目標的解決方法技術。這可能會比較麻煩，因為有時候可能會發現某個問題存在多個根源。不過，最終是某個特定的東西觸發了「雪崩」，從而成為了效能問題。
從系統的角度而言，務必要在幾乎每次發現設計出現效能問題時找出問題的真正根源。否則，您將不斷地處理其表現症狀，但問題卻永遠得不到解決。這將浪費本來可處理其他事情的很多時間和資源。不過，請注意，我說的是「幾乎每次」。組織在大多數情況下都沒有無限的資源可用，因此合理使用這些資源是非常必要的。在標識和消除效能問題根源的過程中，詢問自己這些問題：
這些問題非常重要，因為它們可幫助您在出現問題時進行管理。例如，如果某個系統問題導致無法獲得支付款項，這可能對任何組織都是個大問題。顯然，必須要確定問題的根源並快速予以解決。但如果出現的問題導致員工必須手動將資訊輸入到系統中，而不能使用自動工作流進行此工作，又如何呢？組織仍然可以繼續正常的工作，因此這個特定的效能問題不需要根源分析——或者在完成根源分析前不能無限期地等待。
確定根源的工作可能很簡單，也可能極為複雜。任何問題都存在差異，而這經常使得根源分析有些像貓捉老鼠。甚至在發現問題之前，您可能需要在多個部門（還可能涉及到多個提供商）之間進行協調。不斷問「為什麼」，直到找到問題的根源為止。模式完整且不能再問「為什麼」的時候，通常就找到了根源。
工具和技術：確定解決選項
因為您了解問題並不意味著可以按照自己所想的方式解決問題。根據效能問題的實際根源，您的解決方法選項可能比較有限，也可能有多項選擇。預算考慮（例如僅僅因為資源不可用）可能會讓制定的解決方法計畫泡湯。如果您要處理訪問級別協議，可能會發現需要服務提供者的幫忙才能解決問題。此外，根源有時候可能是無法處理的。例如，有可能是軟體內固有的問題。因此，發現根源時，需要確定能夠用於管理此問題的一系列解決方法選項。
任何時候進行問題確定時，管理層都希望知道所有可用的選項。向他們提供資訊時，不要犯僅僅列出選項的錯誤。相反，應該列出每個解決方法選項的優缺點。以下是乙個例子：
問題：在客戶來電訂購部件時，銷售代表不再能自動檢索即時客戶詳細資訊了。
解決方法 a：銷售代表可以使用不同的流程在兩分鐘內手動檢索客戶詳細資訊。
解決方法 b：可以實現修復程式來恢復自動檢索，成本為 50,000 美元。
從表面來看，解決方法 a 似乎是個合理的解決方案，對嗎？只需要兩分鐘，然後銷售工作就恢復正常了。在考慮預算的環境中，這可能比解決方法 b 更好。不過，如果您擁有 300 位銷售代表，每位代表每個小時平均處理 4 位客戶，這額外的兩分鐘就意味著每月要損失 9,600 個小時的生產力和銷售時間。9,600 個小時！將此值乘以平均小時工資（僅按每小時 8 美元算），您會突然發現讓銷售代表持續進行手工檢索，會每月 浪費您組織超過 75,000 美元的資金。
突然之間解決方法 b 開始變得非常經濟合理了，對不對？不過，您的管理層可能不會立即認識到這一點。如果您簡單地列出前面提到的選項，他們可能永遠不會認識到採用乍看之下最合理的選項可能會浪費多少資金。您需要負責幫助他們了解所給出的每個解決方法選項的全部影響。
工具和技術：權衡需求
在處理效能管理問題時，最好使用需求管理技術來幫助確定問題對業務的影響。對問題影響的所有區域的需求進行權衡並不容易，但應該進行此工作，以確保解決方案對每個人都有效。例如，採用滿足業務需求但卻繞開了使用者需求的解決方法並不一定很好。
為準確起見，每次對效能問題進行管理時，都應該考慮以下需求領域：
在解決問題時，不要嘗試避開其中任何乙個領域。如果忽略了其中的某個方面，您會發現某一類需求突然超越了其他需求，而這會在以後帶來更多的麻煩。在對所有這些需求進行權衡時，您的溝通技能又要扮演很重要的角色了。例如，您需要幫助業務部門了解為何不能忽略使用者需求，或者可能需要幫助管理層了解為何不能在考慮功能需求時忽略流程需求。
在元件級別，問題管理需要更為精細的權衡。您可能希望使用 ibm® websphere® 之類的軟體幫助您監視元件級別的效能，以全面了解設計中的應用程式的工作情況。此類軟體還允許您深入各個粒度級別，以幫助將問題分離出來。
從業務角度而言，任何效能管理問題都必須與業務管理實踐保持一致。這意味著，如果要實現設計的最佳效能，必須將資訊科技 (it) 目標與組織的目標保持一致。如果必須遵循一系列命令，則按照其執行——但要記錄何時通知了哪些人以及所得到的回應是什麼。在考慮業務一致性的情況下確定所有解決方法，不要害怕讓上級管理人員知道為何您的解決方案可全面解決業務問題。
工具和技術：管理問題
如果在根源分析期間確定某個應用程式需要退役，或需要對其進行更改，請考慮集中管理或分布式管理技術是否可以解決問題。這兩個方法都有效，但如果您發現採用集中管理能更好地處理根源，請毫不猶豫地和您的高層管理人員談談這個想法。組織趨向於相信某個方法比另乙個方法好，但在很多情況下兩個方法可以同時使用。
這樣做還會導致在處理效能問題時突然出現解決方案開發問題。這是因為元件級別的效能解決方法可能會對整個解決方案造成影響。利用這個機會從新的角度審視一下您的設計。實現設計時，可能會非常完美。不過，現在您有機會對其再次進行評估，確定是否可以或應該在實現問題解決方法時一併進行提公升。還記得本文前面的示例嗎？從預算角度而言，其中的解決方法 b 實際上更為明智。那麼，如果您還能在設計中實現另乙個小的改進，成本為 20,000 美元，這如何呢？加上原來的 50,000 美元，仍然能為公司節約資金，而且還能夠額外帶來一些改進。這就提出了反映此概念而且需要進一步發揮溝通技能的解決方法 c。您可以將效能問題變成組織勝利的號角。
里程碑既然我們已經考慮了效能管理的各個方面，接下來就要看看效能管理工作中涉及的里程碑。雖然這可能會根據組織不同而有所變化，但可將此處所討論的內容作為良好的開端。
使用關鍵效能指標
關鍵效能指標（key performance indicator，kpi）設計用於幫助組織定義和測定到業務目標的進度。您知道哪些關鍵效能指標是針對組織的？哪些是針對遇到效能問題的部門的？在任何時候管理效能問題時，獲得這些資訊都是乙個重要里程碑。
每次面對要處理的效能問題時，您的第乙個里程碑應該為獲得和了解這些指標。沒有這些指標，就無法清楚地確定所面臨的情況的影響廣度。當然，組織的商業**崩潰是個大問題。但通過使用關鍵效能指標，可以了解這個問題對組織的哪些領域有多大意義，從而快速確定崩潰的站點對**造成的問題最多。通過此方法，可以得到合適的解決方案，首先處理這些受到極大影響的區域，然後處理受到影響較小的區域。
建立報告
在本文前面，我建議在效能問題出現前制定溝通計畫。作為危機期間的里程碑，您需要快速向管理層和受到影響的人員報告問題。這幾乎與解決問題本身一樣重要。如果組織中沒有其他人知道發生了什麼事，害怕、恐慌和憤怒很快就會蔓延開來。問題一出現，就發出標準報告，以便其他人能夠了解目前已經發現了什麼問題並在進行處理。
在報告中，請確保至少列出以下事項：
總結在本文中，我們了解了如何計畫和實現效能管理技術，以保持設計平穩地執行。從很多方面而言，應用程式架構師的工作永遠也不會結束，因此可以將效能管理問題視為帶著偽裝的機會。有時候這些問題可能會讓您煩心或感到挫敗，但就長遠來看，從中得到的經驗教訓可幫助您更好地進行自己的工作。
參考資料
學習
參考 「應用程式架構本質」系列的其他部分。
訂閱 「應用程式架構本質」系列的 rss，以獲取本系列更新的資訊。
閱讀「用 db2 performance expert 簡化效能管理和調優: 如何快速排除問題和調優 db2 udb 伺服器」（developerworks，2004 年 11 月），以了解如何將 db2 performance expert 用於進行監視、分析和優化工作。
閱讀 ibm 紅皮書®摘要： 「business performance management meets business intelligence」，了解如何採用全面的方法管理業務效能和實現業務目標。
在 developerworks 的 architecture 架構專區中，獲取用以提高您在體系結構方面的技能的各種資源。
檢視 ibm on demand 演示程式，以了解有關 ibm 各種軟體產品和技術的更詳細的資訊。
了解關於 developerworks 技術事件和網路廣播的最新訊息。
第8章 應用程式架構
第8章 應用程式架構 之前，介紹了讓團隊可以對問題域的有用概念抽象建模的技術。不過，這一章將介紹可以在應用程式上下文中利用領域模型的模式，其中考慮到了持久化，展現以及其他技術需求。應用程式架構 遵循ddd原則開發軟體不需要使用任何特殊的應用程式架構方式，但架構必須支援的一項內容是保持領域邏輯的隔離性...
Android 應用程式架構
android應用程式架構 1 可擴充套件檢視 view 建立應用程式 2 內容管理器 content providers 訪問其他應用程式資料 共享自身資料 3 資源管理器 resource manager 提供非 資源訪問，本地字串 分層檔案 4 通知管理器 notification manag...
spark應用程式的執行架構
spark應用程式的執行架構 幾個基本概念 1 job 包含多個task組成的平行計算，往往由action催生。2 stage job的排程單位。3 task 被送到某個executor上的工作單元。4 taskset 一組關聯的，相互之間沒有shuffle依賴關係的任務組成的任務集。乙個應用程式由...