IBMTivoliAPM解決方案咨詢HOBBIT2077應用系統管理的維度2應用運維管理ApplicationOperationManagement應用開發管理ApplicationDevelopmentManagement應用系統管理ApplicationSystemManagement+=應用交易管理ApplicationTransactionManagement應用基礎設施管理ApplicationInfrastructureManagement應用配置管理ApplicationConfigurationManagement應用運行時管理ApplicationRealtimeManagement應用運維管理ApplicationOperationManagement應用開發管理ApplicationDevelopmentManagement應用系統管理的維度3應用運維管理ApplicationOperationManagement應用開發管理ApplicationDevelopmentManagement應用系統管理ApplicationSystemManagement+=應用交易管理ApplicationTransactionManagement應用基礎設施管理ApplicationInfrastructureManagement應用配置管理ApplicationConfigurationManagement應用運行時管理ApplicationRealtimeManagement應用運維管理ApplicationOperationManagement應用開發管理ApplicationDevelopmentManagement應用系統管理應用交易管理：關注應用程序的運行，應用交易，應用交易所體現的業務功能管理應用基礎設施管理：關注是應用所直接依賴的平臺，如J2EE中間件，消息中間件，分布式交易中間件，數據庫的管理應用配置管理：關注靜態的應用系統配置信息，了解企業的業務服務，業務應用，IT基礎設施之間的關系，并控制，IT基礎設施變更對業務服務帶來的影響。應用運行時管理：關注的是動態的應用系統在運行狀態下的可用性，以及性能，涵蓋感知問題，隔離故障，查找根源，修復問題4個環節應用運維管理：關注的是應用系統投產后，保證系統持續健康高效工作應用開發管理：應用系統的構建，測試與發布，并在應用開發構建環節，實現對運維環節的支撐4藍色為客戶當前關注的范圍，淺藍色為對關注范圍的直接支撐應用系統運行時的問題診斷診斷方案

應用類型診斷方法相關的IBM產品，能達到的程度客戶的環境基于Web的應用應用類型關注點：速度和成敗監控方法產品客戶環境-基于J2EE,.NET架構HTTP/S交易的響應時間業務邏輯中各步驟對響應時間，和系統資源的消耗監控HTTP層面，終端客戶的感受，以及終端響應時間在網絡，客戶端，服務段的消耗通過專業的J2EE/.NET應用管理工具，實現對可用性，性能，以及J2EE資源的全方位管理應用日志監控ITCAMforApplicationDiagnosticsITCAMforWebResponseTimeWebLogic10onHPUX-基于SOA/WebService架構Service調用的成敗Service調用的時間在ESB內駐留的時間先明確SOA架構所涉及到的相關中間件和具體的SOA架構如果SOA架構基于專有的ESB系統,通過專業的SOA應用管理工具，如果是自開發ESB系統，需要根據具體的情況監控HTTP層面，終端客戶的感受，以及終端響應時間在網絡，客戶端，服務段的消耗應用日志監控ITCAMforSOAPlatformITCAMforWebResponseTime-其他基于Web架構HTTP/S交易的響應時間監控HTTP層面，終端客戶的感受，以及終端響應時間在網絡，客戶端，服務段的消耗應用植入API獲取更多的交易追蹤信息應用日志監控ITCAMforWebResponseTime非Web應用類型關注點：速度和成敗診斷產品客戶環境-Client/server架構C/S通信響應時間駐留client和服務端響應時間通過應用拓撲隔離故障節點應用植入API獲取更多的交易追蹤信息應用日志監控ITCAMfTT（TTAPI）TuxedoBased-基于分布式的交易和消息驅動的架構批處理類型關注點：成敗-所有批處理任務批處理交易是否成功應用日志監控TivoliWorkloadScheduler-運行時應用的基礎設施監控—KPI的設計（OS為例）XX銀行網銀架構7應用開發對應用監控的支撐（樣例分析）8最右側：有4個（DSR）個人營銷：8個進出個人營銷（1對），進出數據庫（3對）應用開發對應用監控的支撐（樣例分析）-方案19應用開發對應用監控的支撐（樣例分析）-方案210應用開發對應用監控的支撐（樣例分析）-對比數據11應用開發對應用監控的支撐（樣例分析）-對比分析12根據以上數據分析：采用方案一時，基金最新凈值查詢交易（純平臺）處理能力約降低10%，應用服務器CPU資源消耗增加約19%；客戶信息查詢交易（上主機）處理能力降低約4%，應用服務器CPU資源消耗增加約5%，網關服務器CPU資源消耗增加約1%，主機CPU消耗增加約9%.采用方案二時，基金最新凈值查詢交易（純平臺）處理能力約降低2%，應用服務器CPU資源消耗增加約2%；客戶信息查詢交易（上主機）處理能力降低約8%，應用服務器CPU資源消耗增加約3.5%，網關服務器CPU資源消耗增加約3.5%，主機CPU消耗增加約7%.方案一和方案二對比，基金最新凈值查詢交易（純平臺）方案一處理能力約低8%，應用服務器CPU資源消耗增加約20%；客戶信息查詢交易（上主機）方案一處理能力高約5%，應用服務器CPU資源消耗增加約1%，網關服務器CPU資源消耗減少約3%，主機CPU消耗低約4%.綜上所述，測試交易監控采用方案二整體性能較好，應用服務器CPU資源消耗增長不明顯。主機由于需要啟用CICSTTAPI監控軟件，導致主機CPU資源消耗均有所增加，而且方案二需要修改網關、主機外聯（EMUL程序）的程序，增加了一定的資源消耗。13應用系統監控接口帶來的好處對容器的依賴：通過純產品層面的應用交易監控，極度依賴客戶的應用允許與何種容器，業界對J2EE容器的管理，MQ，MB很成熟；對Tuxedo，TXSeries，.NET平臺尚可；但對standalone的

native程序，缺乏有效的手段。粒度的控制缺乏靈活性：交易的端到端跟蹤，涉及到顆粒度的問題，粗可以到機器與機器之間的調用，細可以到每個函數的調用，而其中的權衡，完全需要根據客戶的要求來定制。在運行時，不同顆粒度之間的動態切換，也很難通過產品直接實現。業務信息的攜帶：對交易的監控非常必要攜帶其執行的業務，很多客戶的交易在技術層面是成功的（比如HTTP返回碼200，但標示業務執行失敗），純技術層面的監控，不能準確的識別這類錯誤，并且，告警信息，不能告知所影響的業務和執行此業務的客戶。控制開發質量：大型的金融客戶的業務系統通常來有多個來源，外部，自開發，等等。監控接口的規范，其潛在的反應的被監控系統——即應用本身，在運維時被高度關注的執行環節，監控接口實現的位置，可一定程度統一來自不同開發團隊的開發質量。Source: Ifapplicable,describesourceorigin對應用交易追蹤的目的是精確的定位交易執行發生問題的位置14應用系統監控接口的實現原理通過在交易的開始，結束，外聯，獲得響應等關鍵位置，通過調用API（IBM的實現是TTAPI）向外拋出事件，通過一個服務集中匯聚，分析這些事件，形成交易拓撲，響應事件，交易執行成敗的關鍵指標。Source: Ifapplicable,describesourceoriginTTAPITTAPITTAPITTAPITTAPI的事件1516應用系統端到端實現效果Source: Ifapplicable,describesourceorigin17應用系統端到端實現效果

（XXBANK案例）Source: Ifapplicable,describesourceoriginProcedureAccessOpStep是CTP中執行存儲過程的opstep別名。ORACLE*是在op中定義的oracle存儲過程別名。8OC10300是DSR網關調用的交易名TTAPI所收集的事件18TTAPI所支持的平臺19支持的編程語言：

CC++EnterpriseCOBOL(z/OS?only)EnterprisePL/I(z/OSonly)IBMHighLevelAssembler(HLASM-z/OSonly)Java1.4and1.5支持的主機環境：C,C++andJavaapplicationsrunningin64bitmodeonz/OSCandC++XPLINKandnon-XPLINKprogramsonz/OSCandC++programsstaticallyanddynamicallylinkingTransactionTrackingAPICOBOLandPL/IprogramsstaticallylinkingTransactionTrackingAPI20應用系統監控接口對應用系統帶來的影響對開發的工作量的影響：開發團隊需要額外的工作量，來植入監控的代碼，比如交易開始，調用OnTransactionStart(),交易結束，調用OnTransactionFinished()，外調服務，調用OnTransactionOutbould()，

等等，增加工作量的大小，取決于監控的顆粒度。對應用性能的影響：在一個進程內，初始化一個TTAPI的隊列，進程初始化的過程，對TTAPI初始化，需要花費30~70毫秒（依據不同機器的性能而定），一次性初始化結束后，交易調用事件發送事件消耗約為0。對資源的消耗：根據大型銀行測試結果，服務器CPU增加約2%。Source: Ifapplicable,describesourceorigin業務系統場景（應用系統監控的位置）21業務系統應用系統服務器系統存儲系統網絡系統LinkedDatafor

Monitoredresource

TopologyDelegated

Dialogs服務拓撲Service

Topologies(DEPENDENCIES)(entiretopologynotshown)Topologyresources

linkedto

monitoredresources業務系統管理

BusinessSystemsManagement問題管理Manages問題樹ProblemTreeManages部署或者自動發現ManagesProblemslinkedtoservicetopology業務系統的依賴層次關系22業務系統

ServicesHealth應用系統

ApplicationsHealth主機服務器系統

ServersHealth存儲系統

StorageVolumesHealth中間件系統

MiddlewareHealth(TPCServiceProvider)Availibility(up/down),CapacityUtilizationPerformace(reponsetimeinms)(ITMServiceProvider)Availibility(up/down)Memory,CPU,DiskUtilizationProcessorQueueLength(ITMServiceProvider)

Availibility(up/down)Middlewaretype(db,appserver,etc)Cachehits/misses,Connectionwaittime(ITCAMServiceProvider)

Availibility(up/down)Userreponsetime(ms)Numberofconcurrentusers(TBSMServiceProvider)Availibility(up/down)KeyPerformanceIndicators一項業務服務依賴一個或者多個業務應用一個業務應用，依賴一個或者多個中間件系統，比如，各種中間件，數據庫各種中間件，數據庫，依賴承載他們運行的主機和服務器服務器依賴于與后臺的一個或者多個存儲資源門戶界面SolutionPortal(TIP)23監控整體架構圖IBMConfidential自定義擴展頁面LOBDashboards,ITOperationsDashboards,AppHealthDashboard,IsolationPageetc.DLAs集中事件平臺OmnibusEventsITCAMforTransactionsITCAMforApps/ADITMforVE事件轉發導入的IT基礎設施事件豐富引擎ImpactITM監控框架IBMTivoliMonitoringTADDM基礎設施依賴自動發現服務模型關聯事件關聯ITMforVEDashboardsTBSM(ServiceAdmin)Omnibus(AEL)TEPTADDMUI上下文關聯打開業務服務管理TBSMServiceModelServiceStatus事件豐富在TIP中打開發現的IT基礎設施數據倉庫TDW通用報表引擎TCRTCRReportsSmartDeploymentDeploymentofSoftwareStack+Gluecode+TIPPages+AutomatedconfigurationCURIProvider歷史數據ITDS單點登陸SSOSSOSSO網絡管理ITNMITNPMITNCM事件關聯IT基礎設施應用運維和應用開發的集成24DevOps是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它的出現是由于軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作應用系統管理規劃路徑25應用系統管理未來規劃路線26提高收益高中低慢中快提高的時間順序應用系統管理路線圖–優先級應用配置管理應用基礎資源的監控應用交易管理應用開發和應用運維集成應用與業務服務關聯分析通過API植入進行交易追蹤現有的系統，和應用系統管理位置27現有自開發系統，交易關系梳理工具。Omnibus事件集中管理平臺。EventConsolidationOVO+OMS

監控了部分系統資源，如OS,DB。OS/DBMonitoring實現時間表（這是XX的例子）第一階段（2012年）應用交易管理：實現交易層面監控，了解業務運行的質量應用基礎設施管理的完善：補充OVO未能覆蓋到的重要的應用基礎資源監控應用系統API植入的嘗試：挑選出典型的應用系統，考慮API植入的方式實現對個性化系統的監控第二階段（2013年）推廣：在第一階段的基礎上推廣和完善交易管理，將最佳實踐覆蓋更多的應用系統（迭代）應用基礎設施配置管理：應用基礎設施的配置管理（新增）關聯應用系統和業務服務，實現面向業務服務的管理：實現交易層面監控，了解業務運行的質量（新增）第一階段（2014年）推廣：在第二階段的基礎上推廣和完善交易管理、和業務服務管理，將最佳實踐覆蓋更多的應用系統（迭代）系統運維和系統開發的集成管理：嘗試系統開發和運維的整合??（新增）28藍色為XX銀行當前關注的范圍，淺藍色為對關注范圍的直接支撐29客戶需要認真考慮的因素IT和企業的關系IT