企業(yè)級性能管理與容量規(guī)劃概述

1、企業(yè)數(shù)據(jù)中心建設(shè)最佳實踐企業(yè)數(shù)據(jù)中心建設(shè)最佳實踐構(gòu)建高性能，高可擴展性及高可用性的企業(yè)信息系統(tǒng)構(gòu)建高性能，高可擴展性及高可用性的企業(yè)信息系統(tǒng)企業(yè)級性能管理與容量規(guī)劃概述企業(yè)級性能管理與容量規(guī)劃概述建立企業(yè)級容量規(guī)劃、性能管理的業(yè)務(wù)效益建立企業(yè)級容量規(guī)劃、性能管理的業(yè)務(wù)效益針對業(yè)務(wù)部門的需求，集成信息科技主管部門、軟件開發(fā)中心、測試中心針對業(yè)務(wù)部門的需求，集成信息科技主管部門、軟件開發(fā)中心、測試中心及運行中心等部門，通過統(tǒng)一、規(guī)范化的管理平臺，對業(yè)務(wù)服務(wù)生命周期及運行中心等部門，通過統(tǒng)一、規(guī)范化的管理平臺，對業(yè)務(wù)服務(wù)生命周期的容量規(guī)劃、性能管理的流程。的容量規(guī)劃、性能管理的流程。通過對通過對IT

2、IT資源容量有效的管理及對運行性能持續(xù)地監(jiān)控，降低業(yè)務(wù)服務(wù)中資源容量有效的管理及對運行性能持續(xù)地監(jiān)控，降低業(yè)務(wù)服務(wù)中斷的風險。斷的風險。提前在新應(yīng)用開發(fā)、測試階段，建立起性能管理、容量規(guī)劃的基線，從而提前在新應(yīng)用開發(fā)、測試階段，建立起性能管理、容量規(guī)劃的基線，從而了解新應(yīng)用、或現(xiàn)有應(yīng)用大版本變更對于現(xiàn)有生產(chǎn)運營帶來的影響，從而了解新應(yīng)用、或現(xiàn)有應(yīng)用大版本變更對于現(xiàn)有生產(chǎn)運營帶來的影響，從而降低與新的或改進的服務(wù)項目相關(guān)的風險。降低與新的或改進的服務(wù)項目相關(guān)的風險。提高提高ITIT資源容量的利用效率，在恰當?shù)臅r候及時適量投資，這意味著采購資源容量的利用效率，在恰當?shù)臅r候及時適量投資，這意味著采購

3、流程再也不需要應(yīng)付臨時的采購或超前于需求而購買過度的容量，從而總流程再也不需要應(yīng)付臨時的采購或超前于需求而購買過度的容量，從而總體成本降低了。體成本降低了。通過在確定變更對通過在確定變更對ITIT容量的影響時與變更管理密切配合，防止了由于不恰容量的影響時與變更管理密切配合，防止了由于不恰當或不正確的容量估計所導致的緊急變更，從而降低了業(yè)務(wù)運作中斷的次當或不正確的容量估計所導致的緊急變更，從而降低了業(yè)務(wù)運作中斷的次數(shù)。數(shù)。更為靈活的預(yù)測使得對業(yè)務(wù)需求的響應(yīng)變得更快速和更準確。更為靈活的預(yù)測使得對業(yè)務(wù)需求的響應(yīng)變得更快速和更準確。 職業(yè)裝定制職業(yè)裝定制 工服定做工服定做容量規(guī)劃、性能管理及相互關(guān)系

4、容量規(guī)劃、性能管理及相互關(guān)系容量規(guī)劃主要管理以下幾個方面：容量規(guī)劃主要管理以下幾個方面：-處理容量的購買成本相對于業(yè)務(wù)需求來說，是否合理以及處理容量是否以最有效處理容量的購買成本相對于業(yè)務(wù)需求來說，是否合理以及處理容量是否以最有效的方式的方式( (成本成本vsvs容量容量) )被加以利用？被加以利用？-當前的處理容量是否足夠滿足業(yè)務(wù)當前以及未來的需求當前的處理容量是否足夠滿足業(yè)務(wù)當前以及未來的需求( (供給供給vsvs需求需求) )？-現(xiàn)有的處理容量是否發(fā)揮了最大的效率現(xiàn)有的處理容量是否發(fā)揮了最大的效率( (性能管理、調(diào)整性能管理、調(diào)整) )？-額外的處理容量準確地講應(yīng)該在什么時候形成？額外的

5、處理容量準確地講應(yīng)該在什么時候形成？-是否知道未來需要什么樣的是否知道未來需要什么樣的ITIT容量以及何時需要這種容量？容量以及何時需要這種容量？容量規(guī)劃與性能管理是互為包含的關(guān)系，是一個循環(huán)的交互關(guān)系容量規(guī)劃與性能管理是互為包含的關(guān)系，是一個循環(huán)的交互關(guān)系: :-性能管理：為優(yōu)化整體運營績效而評價、監(jiān)控和調(diào)整性能管理：為優(yōu)化整體運營績效而評價、監(jiān)控和調(diào)整ITIT基礎(chǔ)設(shè)施組件的性能的活基礎(chǔ)設(shè)施組件的性能的活動。動。-容量規(guī)劃：根據(jù)容量管理數(shù)據(jù)庫分析當前的情況、預(yù)測容量規(guī)劃：根據(jù)容量管理數(shù)據(jù)庫分析當前的情況、預(yù)測ITIT基礎(chǔ)設(shè)施未來的使用情基礎(chǔ)設(shè)施未來的使用情況以及為滿足預(yù)計的況以及為滿足預(yù)計的

6、ITIT服務(wù)需求而需要的資源，從而制定容量計劃的過程。服務(wù)需求而需要的資源，從而制定容量計劃的過程。-建模：使用分析、模擬和趨勢預(yù)測模型來確定服務(wù)的容量需求以及確定最佳的容建模：使用分析、模擬和趨勢預(yù)測模型來確定服務(wù)的容量需求以及確定最佳的容量方案的過程。模擬需要分析各種不同的情形，并分析各種量方案的過程。模擬需要分析各種不同的情形，并分析各種“如果如果怎么辦怎么辦”式的問題。式的問題。 職業(yè)裝定制職業(yè)裝定制 工服定做工服定做通過獲取系統(tǒng)性能信息通過獲取系統(tǒng)性能信息, ,全面掌控歷史性能與容量趨勢全面掌控歷史性能與容量趨勢依據(jù)當前系統(tǒng)信息依據(jù)當前系統(tǒng)信息, ,預(yù)測業(yè)務(wù)增長的情況下預(yù)測業(yè)務(wù)增長的

7、情況下, ,系統(tǒng)資源的使用的和性能響應(yīng)系統(tǒng)資源的使用的和性能響應(yīng)目標目標:維持現(xiàn)有維持現(xiàn)有ITIT服務(wù)能力的成本相對于組織的業(yè)務(wù)需求而言是合理的嗎？服務(wù)能力的成本相對于組織的業(yè)務(wù)需求而言是合理的嗎？ 現(xiàn)有的現(xiàn)有的ITIT服務(wù)能力能滿足當前及將來的客戶需求嗎？服務(wù)能力能滿足當前及將來的客戶需求嗎？ 現(xiàn)有的現(xiàn)有的ITIT服務(wù)能力發(fā)揮了其最佳效果嗎？服務(wù)能力發(fā)揮了其最佳效果嗎？ 方法方法: 量化管理量化管理致力于解決以下問題致力于解決以下問題:評價和改進現(xiàn)有服務(wù)能力，確保服務(wù)水平的承諾評價和改進現(xiàn)有服務(wù)能力，確保服務(wù)水平的承諾評估當前評估當前ITIT資源的使用，確保高效地使用資源資源的使用，確保高效

8、地使用資源分析并預(yù)測未來的業(yè)務(wù)需求，據(jù)此確定當前最佳容量以及未來應(yīng)當配置的容量和對應(yīng)的服務(wù)水平能力分析并預(yù)測未來的業(yè)務(wù)需求，據(jù)此確定當前最佳容量以及未來應(yīng)當配置的容量和對應(yīng)的服務(wù)水平能力容量規(guī)劃和性能管理目標及方法容量規(guī)劃和性能管理目標及方法生成管理報告異常？分析異常性能瓶頸？需調(diào)優(yōu)？系統(tǒng)或應(yīng)用調(diào)優(yōu)生成容量計劃采購并部署新加容量是否下一個流程周期下一個流程周期否是是否采集數(shù)據(jù): 生產(chǎn)系統(tǒng)數(shù)據(jù) 新應(yīng)用性能數(shù)據(jù) 測試中心壓力測試數(shù)據(jù)容量和性能管理是一個持續(xù)的管理流程容量和性能管理是一個持續(xù)的管理流程容量規(guī)劃和性能管理是一個持續(xù)的管理流程容量規(guī)劃和性能管理是一個持續(xù)的管理流程 流程負責人流程負責人設(shè)

9、計并確定容量規(guī)劃和性能管理流程設(shè)計并確定容量規(guī)劃和性能管理流程 流程負責人流程負責人設(shè)計并確定該流程的角色和責任設(shè)計并確定該流程的角色和責任 技術(shù)專家分析并確定管理需求，相關(guān)指標以及需要使用的工具技術(shù)專家分析并確定管理需求，相關(guān)指標以及需要使用的工具 對于優(yōu)化建議，技術(shù)專家負責規(guī)劃優(yōu)化行動對于優(yōu)化建議，技術(shù)專家負責規(guī)劃優(yōu)化行動 技術(shù)專家負責利用相應(yīng)的調(diào)優(yōu)工具，進行相應(yīng)的系統(tǒng)或應(yīng)用的調(diào)優(yōu)工作技術(shù)專家負責利用相應(yīng)的調(diào)優(yōu)工具，進行相應(yīng)的系統(tǒng)或應(yīng)用的調(diào)優(yōu)工作 優(yōu)化后仍不滿足要求，容量規(guī)劃師負責提出增容建議優(yōu)化后仍不滿足要求，容量規(guī)劃師負責提出增容建議 各管理環(huán)境的數(shù)據(jù)采集專各管理環(huán)境的數(shù)據(jù)采集專家負責

10、建立數(shù)據(jù)采集機制家負責建立數(shù)據(jù)采集機制 數(shù)據(jù)采集專家根據(jù)流程定數(shù)據(jù)采集專家根據(jù)流程定義的采集周期定期地使用義的采集周期定期地使用相關(guān)的工具采集所需的容相關(guān)的工具采集所需的容量和性能指標并進行存儲量和性能指標并進行存儲收集數(shù)據(jù)收集數(shù)據(jù)生成容量計劃生成容量計劃規(guī)劃容量和性能管理流程規(guī)劃容量和性能管理流程監(jiān)控并分析數(shù)據(jù)監(jiān)控并分析數(shù)據(jù)規(guī)劃并啟動優(yōu)化行動規(guī)劃并啟動優(yōu)化行動匯報結(jié)果匯報結(jié)果 容量規(guī)劃師根據(jù)容量管理報告，根據(jù)歷容量規(guī)劃師根據(jù)容量管理報告，根據(jù)歷史信息定期預(yù)測未來容量需求史信息定期預(yù)測未來容量需求 對于增容建議，容量規(guī)劃師負責制定相對于增容建議，容量規(guī)劃師負責制定相應(yīng)的容量規(guī)劃應(yīng)的容量規(guī)劃 各

11、管理環(huán)境的數(shù)據(jù)評估專家根據(jù)已各管理環(huán)境的數(shù)據(jù)評估專家根據(jù)已存的容量和性能指標，生成所需的存的容量和性能指標，生成所需的性能管理報告、異常報告以及容量性能管理報告、異常報告以及容量管理報告管理報告 技術(shù)專家根據(jù)異常報告分析異常指技術(shù)專家根據(jù)異常報告分析異常指標，結(jié)合性能管理報告找到異常原標，結(jié)合性能管理報告找到異常原因并提出改進建議因并提出改進建議(優(yōu)化或增容優(yōu)化或增容) 流程負責人負責監(jiān)督管理流程流程負責人負責監(jiān)督管理流程的執(zhí)行的執(zhí)行 流程負責人定期向上級匯報容流程負責人定期向上級匯報容量規(guī)劃和性能管理的結(jié)果量規(guī)劃和性能管理的結(jié)果容量和性能管理是一個持續(xù)的管理流程容量和性能管理是一個持續(xù)的管理

12、流程容量規(guī)劃和性能管理是一個持續(xù)的管理流程容量規(guī)劃和性能管理是一個持續(xù)的管理流程重要角色重要角色企業(yè)系統(tǒng)性能架構(gòu)師企業(yè)系統(tǒng)性能架構(gòu)師從宏觀把控性能與容量的需求，技術(shù)以及流程業(yè)務(wù)代表業(yè)務(wù)代表作為業(yè)務(wù)部門的代表，提供性能標準，未來新業(yè)務(wù)開展及已有業(yè)務(wù)增長情況數(shù)據(jù)評估與采集專家數(shù)據(jù)評估與采集專家采集，存儲基礎(chǔ)數(shù)據(jù)，生成所需的報告容量規(guī)劃師容量規(guī)劃師跟蹤項目確保與容量相關(guān)的服務(wù)級別合乎既定的要求技術(shù)專家技術(shù)專家作為某個特定領(lǐng)域的資深技術(shù)人員，深入分析優(yōu)化的可能性并優(yōu)化流程負責人流程負責人類似于項目經(jīng)理的角色，確保流程合規(guī)執(zhí)行容量和性能管理的人員組成容量和性能管理的人員組成容量和性能管理的人員組成容量和

13、性能管理的人員組成管理報表分類管理報表分類報表類型-管理層報表，技術(shù)層報表-概況、趨勢、異常、詳細報表-固定報表(日、周、月、年趨勢)和交互報表專業(yè)條線報表-專業(yè)條塊分類l主機系統(tǒng)，分布式系統(tǒng)l網(wǎng)絡(luò)系統(tǒng)l存儲系統(tǒng)-專業(yè)報告類型l性能報表l健康檢查報表l性能對比報表l系統(tǒng)容量報表l容量預(yù)估報表業(yè)務(wù)條線-交易種類和渠道統(tǒng)計報表主機平臺主機平臺容量和性能管理報表容量和性能管理報表性能管理日報-生產(chǎn)主機系統(tǒng)性能健康檢查日報-生產(chǎn)主機系統(tǒng)性能管理日報-生產(chǎn)主機操作系統(tǒng)專業(yè)性能日報-生產(chǎn)主機系統(tǒng)RMF III日報-生產(chǎn)主機聯(lián)機子系統(tǒng)性能管理日報-生產(chǎn)主機數(shù)據(jù)庫子系統(tǒng)性能管理日報-生產(chǎn)主機批量性能日報-生產(chǎn)

14、主機存儲性能及容量指標日報性能管理周報-生產(chǎn)主機系統(tǒng)性能健康檢查周報-生產(chǎn)主機系統(tǒng)性能管理周報性能管理月報-生產(chǎn)主機系統(tǒng)性能健康檢查月報-生產(chǎn)主機系統(tǒng)性能管理月報系統(tǒng)容量管理報表容量預(yù)估管理報表 哪些由性能容量工具產(chǎn)生？ 哪些需要系統(tǒng)手段產(chǎn)生分布式系統(tǒng)平臺監(jiān)控系統(tǒng)硬件資源的性能報表分布式系統(tǒng)平臺監(jiān)控系統(tǒng)硬件資源的性能報表系統(tǒng)信息-包括虛擬空間利用率、頁面讀寫錯誤情況、物理內(nèi)存和虛擬內(nèi)存使用情況、CPU利用率、平均負載情況磁盤資源-包括空間利用率、節(jié)點(i-node)利用率、磁盤讀寫繁忙程度等。進程-包括CPU利用率的進程、耗用內(nèi)存最大的十個進程、進程利用情況列表其它監(jiān)控資源-磁盤性能-RPC調(diào)

15、用的性能情況-用戶訪問情況-服務(wù)器網(wǎng)絡(luò)使用情況-文件情況網(wǎng)絡(luò)硬件資源的性能報表，端口或線路的質(zhì)量和使用率網(wǎng)絡(luò)硬件資源的性能報表，端口或線路的質(zhì)量和使用率網(wǎng)絡(luò)設(shè)備級報表-CPU利用率-內(nèi)存利用率-Buffer利用率端口、線路的報表：-端口速率-帶寬利用率-丟包率-錯包率-SAA存儲容量和性能管理報表存儲容量和性能管理報表與系統(tǒng)有關(guān)的性能管理,參照主機系統(tǒng)、開放系統(tǒng)相關(guān)的內(nèi)容就存儲子系統(tǒng)本身而言-卷和數(shù)據(jù)的均衡分布是使性能達到最大的最重要的因素-需要考慮cache block與文件系統(tǒng)及數(shù)據(jù)庫的匹配-聯(lián)機交易系統(tǒng)l最重要的IO性能指標是每秒的IO數(shù)和響應(yīng)時間l其次是吞吐量-批處理應(yīng)用l吞吐量是最需

16、要重點考慮的-采用TPC等工具來實現(xiàn)對存儲性能的監(jiān)測。其中TPC所監(jiān)測到的存儲前端性能指標，可以和服務(wù)器上取得的RMF report，IO stat的值相對應(yīng)。-監(jiān)測存儲前端的卷的性能參數(shù)包括IO rate, data rate, response time，讀寫比，IO塊大小等，其中讀操作的cache命中率是判斷IO特性的重要指標-后端性能參數(shù)主要包括array和rank級別的IO rate, data rate，response time，NVS full等參數(shù)，可以判斷存儲后端是否存在瓶頸，這些參數(shù)通常無法在服務(wù)器上取得-通過取得的性能指標，結(jié)合disk magic和capacity m

17、agic可以對存儲更好地planning容量、性能管理貫穿在整個解決方案的生命周期中容量、性能管理貫穿在整個解決方案的生命周期中異地災(zāi)備中心異地災(zāi)備中心運行中心運行中心及及同城災(zāi)備中心同城災(zāi)備中心開發(fā)中心開發(fā)中心測試中心測試中心數(shù)據(jù)中心數(shù)據(jù)中心信息科技信息科技主管部門主管部門SLA的性能需求業(yè)務(wù)部門業(yè)務(wù)部門1.建立 容量、性能管理委員會，由一部三中心的人員組成2.按照SLA形成、維護性能的KPI3.技術(shù)研究（產(chǎn)品性能白皮書，性能基線）4.定期的容量規(guī)劃評估會5.根據(jù)容量預(yù)測，安排資源采購1.性能監(jiān)控及跟蹤2.性能、容量信息收集，分析，評估3.系統(tǒng)性能調(diào)優(yōu)1.新應(yīng)用性能預(yù)估、建模2.大版本變更性

18、能預(yù)估、建模3.應(yīng)用性能調(diào)優(yōu)4.應(yīng)用性能建模1.按照SLA進行性能測試2.壓力測試需求、設(shè)計需求、設(shè)計開發(fā)開發(fā)測試測試發(fā)布發(fā)布生產(chǎn)生產(chǎn)研討：公司在構(gòu)建企業(yè)級容量評估、性能管理方面需要研討：公司在構(gòu)建企業(yè)級容量評估、性能管理方面需要做哪些改進？做哪些改進？思考一下-組織架構(gòu)？-規(guī)范流程？-人員技能？-輔助工具？-預(yù)算開銷？企業(yè)級性能、容量管理總體功能架構(gòu)企業(yè)級性能、容量管理總體功能架構(gòu)容量Performance投資回報服務(wù)級別報告性能報告技術(shù)條線，業(yè)務(wù)服務(wù)管理報表記錄/結(jié)構(gòu)定義歷史數(shù)據(jù)儲存SQL 查詢被管理技術(shù)模塊主機開放網(wǎng)絡(luò)存儲數(shù)據(jù)收集容量/性能分析匯總報表監(jiān)控系統(tǒng)性能建?；跇I(yè)務(wù)的性能管理企

19、業(yè)級性能、容量管理總體平臺參考架構(gòu)企業(yè)級性能、容量管理總體平臺參考架構(gòu)TivoliPerformance Modeling RMF, SMFEnterprise Portal開發(fā)中心開發(fā)中心測試中心測試中心數(shù)據(jù)中心數(shù)據(jù)中心信息科技信息科技主管部門主管部門性能管理的定義性能管理的定義性能管理就是計劃、定義、測性能管理就是計劃、定義、測量、分析、報告和調(diào)整計算機量、分析、報告和調(diào)整計算機資源性能的過程。這些資源包資源性能的過程。這些資源包括：括：-主機系統(tǒng)硬件，如主機系統(tǒng)硬件，如CPUCPU，I/OI/O等等-操作系統(tǒng)和子系統(tǒng)，如操作系統(tǒng)和子系統(tǒng)，如z/OSz/OS，CICSCICS，DB2DB2

20、等等-數(shù)據(jù)網(wǎng)絡(luò)數(shù)據(jù)網(wǎng)絡(luò)-應(yīng)用系統(tǒng)應(yīng)用系統(tǒng)-服務(wù)服務(wù)歷史趨勢分析和報告以及資源歷史趨勢分析和報告以及資源容量的規(guī)劃也是和性能管理相容量的規(guī)劃也是和性能管理相關(guān)的重要內(nèi)容關(guān)的重要內(nèi)容性能管理的目標性能管理的目標性能管理的目標就是：通過有效地使用資源來達到性能服務(wù)水性能管理的目標就是：通過有效地使用資源來達到性能服務(wù)水平平(SLA)(SLA)的承諾。的承諾。通過對性能的調(diào)整降低響應(yīng)時間、提高吞吐量，在滿足通過對性能的調(diào)整降低響應(yīng)時間、提高吞吐量，在滿足SLASLA的的基礎(chǔ)上減少消耗?；A(chǔ)上減少消耗。性能管理的目標性能管理的目標統(tǒng)一的性能報告統(tǒng)一的性能報告制定性能管理的標準和程序手冊制定性能管理的標準

21、和程序手冊性能管理的組織架構(gòu)性能管理人員和他們的職責性能管理所適用的環(huán)境性能測量的標準報告的需求性能管理工具歷史文件趨勢分析性能管理例會報告和解決性能管理中的問題。性能管理的主要模塊性能管理的主要模塊數(shù)據(jù)收集：每日收集性能數(shù)據(jù)，積累形成周、月、年度等數(shù)據(jù)為性能分析和趨勢分析提供原始數(shù)據(jù)；每日收集性能數(shù)據(jù)，積累形成周、月、年度等數(shù)據(jù)為性能分析和趨勢分析提供原始數(shù)據(jù)；數(shù)據(jù)保留：制定性能數(shù)據(jù)的保存介質(zhì)和期限；制定性能數(shù)據(jù)的保存介質(zhì)和期限；信息處理：日常規(guī)定的性能報告或管理層要求的報告處理作業(yè)；日常規(guī)定的性能報告或管理層要求的報告處理作業(yè)；信息報告：主要以管理層的要求為主。主要針對性能瓶頸的分析和確定

22、何時需要進行升級。主要以管理層的要求為主。主要針對性能瓶頸的分析和確定何時需要進行升級。性能管理周期性能管理周期當解決了一個瓶頸后，重新測量、重新評估性能來驗證沒有造成別的限制并確保所做的變更升效了性能管理的步驟性能管理的步驟定義服務(wù)水平目標（SLA）和度量標準收集性能數(shù)據(jù)從性能數(shù)據(jù)中創(chuàng)建有價值的報表分析性能報告來確定是否滿足了目標識別系統(tǒng)中的潛在瓶頸分析可疑瓶頸處的詳細性能數(shù)據(jù)決定從哪可以獲得所需的資源驗證是否消除了性能瓶頸主機性能指標主機性能指標 - -宏觀性能指標宏觀性能指標響應(yīng)時間(Response Time)外部吞吐率(ETR)和內(nèi)部吞吐率(ITR)系統(tǒng)飽和點(SDP)資源使用率(U

23、tilization)主機性能指標主機性能指標 - -宏觀性能指標宏觀性能指標 響應(yīng)時間響應(yīng)時間主機性能指標主機性能指標 - -宏觀性能指標宏觀性能指標 吞吐率吞吐率ETR: 按照Elapse Time來測量，注重系統(tǒng)容量；ITR: 按照CPU時間來測量，注重CPU的容量提問：對于相同的工作負載提問：對于相同的工作負載, 哪個系統(tǒng)更好？哪個系統(tǒng)更好？主機性能指標主機性能指標 - -宏觀性能指標宏觀性能指標 系統(tǒng)飽和點系統(tǒng)飽和點SDPSDP的定義是，為保證一個的定義是，為保證一個系統(tǒng)在小間隔內(nèi)的使用率不系統(tǒng)在小間隔內(nèi)的使用率不超過超過100%100%，最大的平均大間，最大的平均大間隔的使用率。隔

24、的使用率。大間隔、小間隔的選擇（例大間隔、小間隔的選擇（例如如1 1小時、小時、1 1分鐘），決定于分鐘），決定于用戶的忍耐程度。用戶的忍耐程度。例如，用戶在一小時內(nèi)不能例如，用戶在一小時內(nèi)不能容忍任何一分鐘的使用率達容忍任何一分鐘的使用率達到到100%100%，那么小時平均使用，那么小時平均使用率就不能超過計算出的率就不能超過計算出的SDPSDP值。值。假設(shè)，小時平均值為假設(shè)，小時平均值為80%80%，而此小時內(nèi)分鐘峰值為而此小時內(nèi)分鐘峰值為92%92%，則，則SDP=80SDP=80* *100/92 = 87%100/92 = 87%0102030405060708090100CPU %

25、 busy0.000.501.001.502.00Response Time (seconds)Low PrtyMedium PrtyHigh PrtyResponse Time vs CPU (%) BusyCompares Different Prty Workloads混合工作負載時響應(yīng)時間與混合工作負載時響應(yīng)時間與CPUCPU利用率關(guān)系圖利用率關(guān)系圖主機性能指標主機性能指標 - - 微觀性能指標微觀性能指標 I/O I/OIO Response = IOSQ + Pending + Connect + DisconnectI IOS Queue Time: 表示在表示在z/OSz/OS

26、中設(shè)備等待的時間中設(shè)備等待的時間. . Pending time: 表示從發(fā)出表示從發(fā)出SSCHSSCH指令直到指令直到ChannelChannel和和I/OI/O控制器之間開始對話控制器之間開始對話. .Disconnect time: I/OI/O操作已經(jīng)開始，但是操作已經(jīng)開始，但是ChannelChannel和和I/OI/O控制器之間沒有對話控制器之間沒有對話. .Connect time: ChannelChannel和和I/OI/O控制器控制器CacheCache之間作數(shù)據(jù)傳輸或交換控制信息之間作數(shù)據(jù)傳輸或交換控制信息. .應(yīng)用性能指標應(yīng)用性能指標 不同的代碼編寫方式對系統(tǒng)性能的影響

27、是不一樣的不同的代碼編寫方式對系統(tǒng)性能的影響是不一樣的應(yīng)用程序性能指標體現(xiàn)在應(yīng)用程序性能指標體現(xiàn)在-代碼的編寫方式-CICS指令寫法-DB2 SQL語句寫法-文件組織方式及定義屬性-其他如果應(yīng)用程序存在性能問題，如果應(yīng)用程序存在性能問題，ITRITR往往不會線性增長，導致不能正確預(yù)估系統(tǒng)容往往不會線性增長，導致不能正確預(yù)估系統(tǒng)容量量如果某支交易存在應(yīng)用程序性能問題，往往會影響其他如果某支交易存在應(yīng)用程序性能問題，往往會影響其他80%80%正常交易的運行正常交易的運行性能管理的工具性能管理的工具聯(lián)機工具-Tivoli OMEGAMON 系列-SMF-CICS CMF-DB2 Trace-RMF-

28、z/OS Management Console-后處理工具-Tivoli Decision Support-CICSPA-DB2 PE-應(yīng)用性能分析工具-Application Performance Analyzer -高級管理系統(tǒng)-包括性能數(shù)據(jù)倉庫以及報表/展現(xiàn)工具性能管理交付件性能管理交付件性能管理手冊性能管理的系統(tǒng)和數(shù)據(jù)倉庫SMFRMF IRMF IIITDSTPMC programDB2DSDSDSDSREPORTHTMLWEBUIWebBIRTWASPer & Cap DataData CollectTWSDataSourceBusinessLogicView Layer各種日常報

29、告和趨勢分析報告、系統(tǒng)資源調(diào)優(yōu)/升級建議等性能管理日志性能管理自動化及其主要需求性能管理自動化及其主要需求全面的數(shù)據(jù)源采集，支持技術(shù)人員在對性能問題進行深層次的分析時能夠及時獲取所需的所有數(shù)據(jù)，提高問題分析的效率數(shù)據(jù)采集、加工與存儲應(yīng)形成一個高度自動化的流程根據(jù)管理需要，采集關(guān)鍵的性能指標性能分析支持中長期分析和短期分析通過生成日趨勢、周趨勢、月趨勢報告支持長期歷史趨勢分析性能好壞的評判通常是通過與歷史同期性能數(shù)據(jù)對比得出的相對結(jié)論提供面向業(yè)務(wù)的性能統(tǒng)計信息易于擴展及維護，盡量避免由于核心系統(tǒng)軟件升級，SMF數(shù)據(jù)格式改變時所帶來的開發(fā)維護工作量難點難點直接從SMF中抽取并加工數(shù)據(jù)，確保主機性能

30、容量數(shù)據(jù)的完整性生產(chǎn)SMF數(shù)據(jù)的龐大，要求數(shù)據(jù)抽取的高效率支持對用戶自定義數(shù)據(jù)包括業(yè)務(wù)數(shù)據(jù)的采集存放。例如為主機成本核算系統(tǒng)提供參數(shù)數(shù)據(jù)（交易與業(yè)務(wù)的對應(yīng)表、業(yè)務(wù)與部室的對應(yīng)表等）確定由于新需求或核心系統(tǒng)軟件升級引起的SMF格式變更，所帶來的開發(fā)和維護工作量實現(xiàn)高度自動化的統(tǒng)計加工機制設(shè)定歷史數(shù)據(jù)的維護策略，自動清理大量的過期數(shù)據(jù)實現(xiàn)方法實現(xiàn)方法采用專門管理工具，做到：-實現(xiàn)SMF數(shù)據(jù)抽取、統(tǒng)計加工、存儲以及報表生成的高度自動化-在出現(xiàn)SMF格式變更時只需通過打補丁的方式即可支持-提供最佳管理經(jīng)驗的樣本報表，提高實施速度利用一個現(xiàn)有的、不太繁忙的LPAR進行性能容量管理每天晚間通過批量方式自動

31、提交SMF數(shù)據(jù)采集作業(yè)，自動生成固定報表考慮所在系統(tǒng)和數(shù)據(jù)庫的性能，建議只采集管理所需的數(shù)據(jù)根據(jù)用戶角色對用戶訪問權(quán)限進行設(shè)定對原始數(shù)據(jù)表設(shè)定過期清理策略對特定時間段，建立專門的數(shù)據(jù)表，永久保存性能趨勢分析功能 可以生成日報、周報和月報等性能趨勢報表性能健康檢查功能 可以對異常指標進行提示完善數(shù)據(jù)采集功能 通過批量作業(yè)方式完成對SMF等歷史數(shù)據(jù)的全面采集 報表功能 可以生成概況、趨勢、異常、詳細等各種類型的性能報表圖形化視圖功能 提供Web圖形報表展現(xiàn)短期性能分析功能 可以收集RMFIII數(shù)據(jù)，并存儲到性能容量數(shù)據(jù)庫中，通過SQL生成相應(yīng)報表 用戶分級訪問功能 可以提供多角色報表訪問功能具體的

32、功能要求具體的功能要求原理示例原理示例SMF數(shù)據(jù)其它日志數(shù)據(jù)日志收集器性能容量數(shù)據(jù)倉庫各種性能容量報表SQL SMF數(shù)據(jù)日志定義日志例外處理記錄定義記錄例外處理加工定義映射表數(shù)據(jù)表加工定義SQL查詢報表數(shù)據(jù)采集流程數(shù)據(jù)采集流程主機平臺容量規(guī)劃主機平臺容量規(guī)劃容量規(guī)劃的定義容量規(guī)劃的定義容量規(guī)劃就是根據(jù)容量管理數(shù)據(jù)庫分析當前的性能和容量規(guī)劃就是根據(jù)容量管理數(shù)據(jù)庫分析當前的性能和容量情況、預(yù)測容量情況、預(yù)測ITIT基礎(chǔ)設(shè)施未來的使用情況以及為滿基礎(chǔ)設(shè)施未來的使用情況以及為滿足預(yù)計的足預(yù)計的ITIT服務(wù)需求而需要的資源，從而制定容量計服務(wù)需求而需要的資源，從而制定容量計劃的過程劃的過程容量規(guī)劃包括了

33、系統(tǒng)建模，即使用分析、模擬和趨勢容量規(guī)劃包括了系統(tǒng)建模，即使用分析、模擬和趨勢預(yù)測模型來確定服務(wù)的容量需求以及確定最佳的容量預(yù)測模型來確定服務(wù)的容量需求以及確定最佳的容量方案的過程。建模需要分析各種不同的情形，并分析方案的過程。建模需要分析各種不同的情形，并分析各種各種“如果如果怎么辦怎么辦”式的問題式的問題當前、歷史趨勢以及容量規(guī)劃也是和性能管理相關(guān)的當前、歷史趨勢以及容量規(guī)劃也是和性能管理相關(guān)的重要內(nèi)容重要內(nèi)容容量規(guī)劃的目標容量規(guī)劃的目標容量規(guī)劃的目標就是：在恰當?shù)臅r間增加容量來達到服務(wù)水平容量規(guī)劃的目標就是：在恰當?shù)臅r間增加容量來達到服務(wù)水平(SLA)(SLA)的承諾。的承諾。通過對容量

34、的科學分析和預(yù)測，準確預(yù)測出未來的容量需求和通過對容量的科學分析和預(yù)測，準確預(yù)測出未來的容量需求和服務(wù)水平服務(wù)水平創(chuàng)建容量規(guī)劃數(shù)據(jù)庫創(chuàng)建容量規(guī)劃數(shù)據(jù)庫業(yè)務(wù)預(yù)測 服務(wù)數(shù)據(jù) 技術(shù)數(shù)據(jù) 財務(wù)數(shù)據(jù) CDB 管理報告 容量規(guī)劃 技術(shù)報告 容量規(guī)劃報告容量規(guī)劃報告容量規(guī)劃報告描述了當前及未來對IT基礎(chǔ)設(shè)施容量的需求、IT服務(wù)需求方面的預(yù)期變化容量規(guī)劃報告還說明了在考慮未來服務(wù)級別需求的情況下，以可接受的成本提供SLA中約定的服務(wù)級別而需要做出的變更容量規(guī)劃報告不僅需要描述預(yù)計的變更，而且要指出相關(guān)的成本容量規(guī)劃報告應(yīng)當每年進行一次修訂，同時為保證其準確性應(yīng)當每季度進行一次審查容量規(guī)劃報告是容量規(guī)劃流程最重

35、要的交付件容量規(guī)劃報告應(yīng)當包含性能預(yù)測、升級點、基礎(chǔ)設(shè)施升級的預(yù)計成本等方面的信息容量規(guī)劃自動化容量規(guī)劃自動化根據(jù)性能容量管理數(shù)據(jù)庫分析當前的情況、預(yù)測IT基礎(chǔ)設(shè)施未來的使用情況以及為滿足預(yù)計的IT服務(wù)需求而需要的資源，從而制定容量計劃的過程使用分析、模擬和趨勢預(yù)測模型來確定服務(wù)的容量需求以及確定最佳的容量方案的過程。建模需要分析各種不同的情形，并分析各種“如果怎么辦”式的問題容量規(guī)劃的效益：-防止由于不恰當或不正確的容量估計所導致的業(yè)務(wù)風險-前瞻性地科學預(yù)測為容量采購的決策提供了依據(jù)，避免超前于需求而購買過度容量的采購行為，從而節(jié)省總體成本關(guān)鍵點 - - 確保滿足服務(wù)水平確保滿足服務(wù)水平 -

36、 - 及時的、主動的、前瞻性預(yù)測及時的、主動的、前瞻性預(yù)測 - - 性能是核心指標性能是核心指標( (而不是利用率而不是利用率) )上級主管部門有時會問難以量化回答的問題上級主管部門有時會問難以量化回答的問題- 如果不升級，情況會糟糕到什么程度?- 如果升級，情況會好到什么程度?- 在下次升級前，可以維持多長時間? 需要借助于方法論及自動化工具進行量化預(yù)測需要借助于方法論及自動化工具進行量化預(yù)測- 模擬方法- 分析方法 需要具備性能建模的能力需要具備性能建模的能力驅(qū)動力一：量化驅(qū)動力一：量化 不斷變化的復(fù)雜環(huán)境不斷變化的復(fù)雜環(huán)境 工作負載的性能取決于多個因素：工作負載的性能取決于多個因素：-

37、負載優(yōu)先級- 高優(yōu)先級負載的占比- CPU的數(shù)量與速度- Paging - I/O子系統(tǒng)的限制- LPAR的影響 性能難于推測性能難于推測 沒有適當?shù)墓ぞ?，容量?guī)劃將只能依靠沒有適當?shù)墓ぞ?，容量?guī)劃將只能依靠“拍腦袋拍腦袋”驅(qū)動力二：預(yù)測驅(qū)動力二：預(yù)測 實現(xiàn)方法實現(xiàn)方法科學的預(yù)測手段：精確、簡便易用預(yù)測多維度：不僅關(guān)注CPU的性能，還要關(guān)注存儲的未來增長以具有代表性的高峰期數(shù)據(jù)為基準，而不是某段均值建立周期性預(yù)測機制環(huán)境變化時，需要重新依據(jù)新基準值進行預(yù)測不能忽略低優(yōu)先級負載的性能運行環(huán)境基本不變，包括交易模式、應(yīng)用和系統(tǒng)不變業(yè)務(wù)行為規(guī)律不變，根據(jù)業(yè)務(wù)行為規(guī)律，建立不同時期的模型分別進行建模預(yù)

38、測重大變更發(fā)生時，例如新應(yīng)用上線或系統(tǒng)核心組件升級，需要重新建模預(yù)測最佳實踐：建立容量規(guī)劃自動化操作流程，每月建模預(yù)測準確預(yù)測的前提準確預(yù)測的前提系統(tǒng)建模系統(tǒng)建模系統(tǒng)建模主要用于預(yù)測基礎(chǔ)設(shè)施的運行狀況建模方法-線性預(yù)測(趨勢分析，大致預(yù)測)-分析性模擬(結(jié)果可靠性不高)-仿真模擬仿真模擬( (預(yù)測復(fù)雜環(huán)境較準確預(yù)測復(fù)雜環(huán)境較準確) )-系統(tǒng)實際運行基線(最準確，但代價最高)建模結(jié)果應(yīng)包括反映服務(wù)水平的核心指標，為容量規(guī)劃提供量化依據(jù)仿真模擬技術(shù)示例仿真模擬技術(shù)示例根據(jù)實際數(shù)據(jù)，選擇具有代表性的時間段建立模型模型生成過程中，時間被劃分成多個時間片。在每個時間間隔(最小間隔為0.01秒）的開始，模

39、型會檢查每個工作負載。對于聯(lián)機交易來說，模型會決定是否產(chǎn)生一個新的交易。模型將根據(jù)平均到達率來產(chǎn)生新的交易模型產(chǎn)生后，將確定工作負載運行情況，確定每個工作負載的交易率和單個交易消耗的CPU以及I/O率等模擬指標利用假設(shè)條件，基于模型進行模擬運算，得出預(yù)測結(jié)果仿真模擬方法仿真模擬方法根據(jù)一個特定的時間段內(nèi)的實際系統(tǒng)的運行情況創(chuàng)建一個模型選擇的時間段非常重要，因為模擬會以此作為基準，來比較不同的預(yù)測場景最佳實踐是挑出一個典型的系統(tǒng)利用率比較高的時間段（不必盲目追求所有高峰期中的最高點） 模擬不是試圖去預(yù)測未來的平均性能情況，而是預(yù)測接近于最壞性能的情況，這種情況通常會導致服務(wù)中斷模擬數(shù)據(jù)收集與預(yù)測

40、模擬數(shù)據(jù)收集與預(yù)測從SMF記錄中生成CPU和工作負載報告作為基礎(chǔ)數(shù)據(jù)可以通過選擇若干天的某個特定時段來縮短報告的大小最佳實踐是選擇五個連續(xù)工作日的高峰時段的系統(tǒng)利用率 依據(jù)長期歷史趨勢分析出的交易增長結(jié)果作為預(yù)測假設(shè)條件，預(yù)測未來保持現(xiàn)有環(huán)境或假設(shè)硬件升級的情況下，CPU利用率和響應(yīng)時間主機平臺主機平臺應(yīng)用容量評估應(yīng)用容量評估54系統(tǒng)資源系統(tǒng)資源-CPU資源-內(nèi)存-存儲應(yīng)用交易處理容量衡量標準應(yīng)用交易處理容量衡量標準-吞吐量(每秒處理交易數(shù))-響應(yīng)時間應(yīng)用容量評估應(yīng)用容量評估55基準理論基準理論 吞吐量與吞吐量與CPUCPU使用率的關(guān)系使用率的關(guān)系56基準理論基準理論 響應(yīng)時間與吞吐量的關(guān)系響

41、應(yīng)時間與吞吐量的關(guān)系5720%20%的交易消耗的交易消耗80%80%的資源的資源20%20%的交易在某些情況下，微小的交易量變化會影響整個系統(tǒng)的交易的交易在某些情況下，微小的交易量變化會影響整個系統(tǒng)的交易處理處理在真實環(huán)境中，會同時有許多不同種類的交易并發(fā)運行，因為不同在真實環(huán)境中，會同時有許多不同種類的交易并發(fā)運行，因為不同交易占用的交易占用的CPUCPU資源不一樣，因此對系統(tǒng)影響也會不一樣，在實際環(huán)資源不一樣，因此對系統(tǒng)影響也會不一樣，在實際環(huán)境中，應(yīng)盡量避免長交易（高境中，應(yīng)盡量避免長交易（高CPUCPU消耗）的大量運行，比如可以通過消耗）的大量運行，比如可以通過設(shè)置設(shè)置TCLASSTC

42、LASS來保證系統(tǒng)資源的分配。來保證系統(tǒng)資源的分配。通常情況下，批量作業(yè)相當于長交易通常情況下，批量作業(yè)相當于長交易基準理論基準理論 二八定律二八定律58理想情況下，單系統(tǒng)交易處理的拐點在理想情況下，單系統(tǒng)交易處理的拐點在98-99%98-99%左右左右多節(jié)點環(huán)境下，因為并行耦合器有一定的內(nèi)耗，通常情況下，從多節(jié)點環(huán)境下，因為并行耦合器有一定的內(nèi)耗，通常情況下，從單系統(tǒng)到單系統(tǒng)到2 2節(jié)點的系統(tǒng)，內(nèi)耗在節(jié)點的系統(tǒng)，內(nèi)耗在10-12%10-12%左右左右隨節(jié)點數(shù)目的增加，每增加一個節(jié)點，內(nèi)耗會增加隨節(jié)點數(shù)目的增加，每增加一個節(jié)點，內(nèi)耗會增加2%2%左右左右耦合效率計算公式耦合效率計算公式基準理論

43、基準理論 多節(jié)點內(nèi)耗多節(jié)點內(nèi)耗59I/OI/O對交易處理能力的影響對交易處理能力的影響-如果交易有I/O問題，則交易響應(yīng)時間與吞吐量往往不呈線性關(guān)系，工作負載的增加對CPU利用率的變化也不呈線性關(guān)系。并行耦合器并行耦合器CPUCPU利用率對交易處理能力的影響利用率對交易處理能力的影響-理論上，并行耦合器的CPU利用率超過50%，會對交易處理有一定的影響其他因素對交易處理能力的影響60確保交易不存在明顯的確保交易不存在明顯的I/OI/O問題問題-如果交易存在有I/O問題，就無法通過增加CPU資源來提升交易處理能力。避免并行耦合器的避免并行耦合器的CPUCPU利用率過高，不要超過利用率過高，不要超

44、過50%50%確定交易混和比例確定交易混和比例-盡量與真實生產(chǎn)系統(tǒng)接近-考慮聯(lián)機交易和批量作業(yè)間的互相影響明確測試目標明確測試目標-通常以交易響應(yīng)時間為標準-明確交易優(yōu)先級別壓力測試前提壓力測試前提61當交易響應(yīng)時間合乎性能指標時，計算不同工作負載的當交易響應(yīng)時間合乎性能指標時，計算不同工作負載的ITRITR分析分析ITRITR是否線性增長，如果線性增長，以此是否線性增長，如果線性增長，以此ITRITR值來估算系值來估算系統(tǒng)容量配置統(tǒng)容量配置估算時，應(yīng)考慮估算時，應(yīng)考慮I/OI/O對交易的影響，工作負載越大，對交易的影響，工作負載越大，I/OI/O競爭競爭越多，建議工作負載應(yīng)盡量接近真實生產(chǎn)系

45、統(tǒng)環(huán)境越多，建議工作負載應(yīng)盡量接近真實生產(chǎn)系統(tǒng)環(huán)境測試結(jié)果分析測試結(jié)果分析What is Performance?響應(yīng)時間描述系統(tǒng)的速度響應(yīng)時間描述系統(tǒng)的速度 聯(lián)機響應(yīng)時間聯(lián)機響應(yīng)時間 批量運行時間批量運行時間吞吐量描述單位時間內(nèi)系統(tǒng)處理的業(yè)務(wù)量吞吐量描述單位時間內(nèi)系統(tǒng)處理的業(yè)務(wù)量 每秒交易數(shù)（每秒交易數(shù)（TPS） 每小時記錄數(shù)每小時記錄數(shù)容量描述系統(tǒng)擁有的各種資源總量容量描述系統(tǒng)擁有的各種資源總量 處理器顆數(shù)以及處理器速度處理器顆數(shù)以及處理器速度 磁盤空間磁盤空間 網(wǎng)絡(luò)帶寬網(wǎng)絡(luò)帶寬性能指標分為三大類：性能指標分為三大類：響應(yīng)時間，吞吐量，容量響應(yīng)時間，吞吐量，容量對于新應(yīng)用開發(fā)而言，容量估計

46、工作開始的越早越好對于新應(yīng)用開發(fā)而言，容量估計工作開始的越早越好全面的了解業(yè)務(wù)規(guī)模，各項應(yīng)用與系統(tǒng)指標是進行精確全面的了解業(yè)務(wù)規(guī)模，各項應(yīng)用與系統(tǒng)指標是進行精確性能估算的前提性能估算的前提如今的系統(tǒng)通常都包含了異構(gòu)的客戶機和服務(wù)器，跨多如今的系統(tǒng)通常都包含了異構(gòu)的客戶機和服務(wù)器，跨多個地理區(qū)域和邏輯層級個地理區(qū)域和邏輯層級性能架構(gòu)師必須端到端的考量整個系統(tǒng)結(jié)構(gòu)，包括涉及性能架構(gòu)師必須端到端的考量整個系統(tǒng)結(jié)構(gòu)，包括涉及到的單個組件的特征和應(yīng)用的特性到的單個組件的特征和應(yīng)用的特性系統(tǒng)是如何組織的？-邏輯層級，地理區(qū)域以及系統(tǒng)的拓撲邏輯-系統(tǒng)內(nèi)各個組件的功能系統(tǒng)內(nèi)有哪些資源可供調(diào)用？-它們的性能特征

47、又如何？應(yīng)用變更的影響有多大？-批量與聯(lián)機-響應(yīng)時間-補丁策略 有多種實現(xiàn)方法有多種實現(xiàn)方法 有有“胖胖”客戶端與客戶端與“瘦瘦”客戶端客戶端 根據(jù)具體配置進行分析根據(jù)具體配置進行分析 網(wǎng)絡(luò)流量非常關(guān)鍵網(wǎng)絡(luò)流量非常關(guān)鍵客戶機服務(wù)器客戶機服務(wù)器系統(tǒng)結(jié)構(gòu)系統(tǒng)結(jié)構(gòu)絕大多數(shù)新系統(tǒng)的架構(gòu)絕大多數(shù)新系統(tǒng)的架構(gòu) 把若干個單一功能的組件用多個邏輯層級的方式組裝起來把若干個單一功能的組件用多個邏輯層級的方式組裝起來 網(wǎng)絡(luò)是性能的關(guān)鍵所在網(wǎng)絡(luò)是性能的關(guān)鍵所在 良好的用戶體驗是一個極其重要的需求良好的用戶體驗是一個極其重要的需求 小心美工小心美工 負載難以預(yù)測負載難以預(yù)測 要充分考慮到可擴展性要充分考慮到可擴展性基于基于WebWeb的系統(tǒng)的系統(tǒng)系統(tǒng)結(jié)構(gòu)系統(tǒng)結(jié)構(gòu)操作系統(tǒng) 通訊控制器交易中間件數(shù)據(jù)庫等待I/O 服務(wù)時間 處理時間CPU (milliseconds)# I/OSELECT - one row352FETCH - next100.1DELETE - one row604典型的原子資源消耗典型的原子資源消耗處理器服務(wù)器處理器服務(wù)器組件特性組件特性l 內(nèi)存 盡可能消除頁面調(diào)度（paging） 估算工作集（working sets） 分別考慮系統(tǒng)自身的消耗以及各組件的消耗 千萬別按照軟件的最小需求配置內(nèi)存l 任務(wù)調(diào)度邏輯 管理