1. 降低IT變化成本的良方：IT紀律和IT自動(dòng)化

　　如果IT組織對他們的應用交付和管理行動(dòng)采用嚴格的紀律和自動(dòng)化，那么可以消除大部

　　部分改變的成本。

　　1.1應用交付

　　很多應用故障是由于在開(kāi)發(fā)和部署新應用和應用改變時(shí)缺少控制和紀律導致的。

　　如果不能正確控制應用的計劃，開(kāi)發(fā)和部署，那么將導致：

　　●對其他組建或應用產(chǎn)生意外的副作用；

　　●由于不完善的版本控制，丟失改變的源代碼或其他程序；

　　●由于錯誤的優(yōu)化和沒(méi)有在上線(xiàn)的壓力下測試，出現上線(xiàn)的性能問(wèn)題；

　　●由于費事且易于出錯的手工部署的錯誤，出現混合或不兼容的上線(xiàn)版本。

　　在應用生命周期的開(kāi)發(fā)和部署階段，進(jìn)行小心細致的計劃和控制可以消除這些問(wèn)題。

　　1.2計劃

　　嚴格的應用交付開(kāi)始于計劃。計劃中經(jīng)常會(huì )忽略的幾個(gè)方面包括：

　　●影響性分析

　　●容量計劃

　　●高可用性計劃

　　如果沒(méi)有實(shí)施應用改變的影響分析，可能會(huì )導致意外的停機和性能問(wèn)題。例如，為了滿(mǎn)足一個(gè)業(yè)務(wù)變化對數據庫模式作了一處簡(jiǎn)單的修改，可能也需要對其他模塊進(jìn)行改動(dòng)。如果沒(méi)有注意到這些改變而沒(méi)有做相應的修改，就可導致錯誤的結果，糟糕的性能或應用的停機。這樣的問(wèn)題通過(guò)對應用改變的影響作仔細分析就可以很好地避免。最有效的影響性分析最好是使用自動(dòng)化工具，該工具可以理解源代碼和程序對象之間或其他應用組件之間的關(guān)系。

　　缺少容量計劃是另一個(gè)可能導致意外應用故障的問(wèn)題。分析出在生產(chǎn)環(huán)境中可獲得充足應用性能所需要的處理器，內存和其他資源等是非常重要的。例如，如果不能提供足夠的計算資源處理預計的用戶(hù)數量，那么就可能導致應用的性能問(wèn)題和停機。

　　最后，缺少為滿(mǎn)足高關(guān)鍵應用的可用性而必要的冗余和快速恢復機制計劃可能導致代價(jià)高昂和長(cháng)時(shí)間的停機。某些故障是非常難以預料的。例如，硬件故障的發(fā)生通常沒(méi)有前兆，并發(fā)生在極不方便的時(shí)間。IT組織必須為這些故障作計劃，并且考慮高可用性體系結構和程序。

　　1.3開(kāi)發(fā)

　　控制良好的開(kāi)發(fā)過(guò)程為多種多樣的應用故障提供了重要防線(xiàn)。應該組織這些過(guò)程保證所有重要的開(kāi)發(fā)任務(wù)，例如說(shuō)明，編碼，優(yōu)化和測試，能夠正確執行。好的過(guò)程也需要在相關(guān)步驟上作嚴格的評審。這保證正確的檢查和平衡能夠捕獲不適當或不正確的改變。版本控制是所有良好開(kāi)發(fā)過(guò)程的關(guān)鍵環(huán)節。不充分的版本控制可能導致丟失源代碼的改變，模塊的混亂版本和喪失對運行的生產(chǎn)系統全面的信心。所有開(kāi)發(fā)成果都應該在版本控制系統中仔細保留和管理，以防止覆蓋重要的改變。

　　功能的正確性，性能和擴展性的驗證應該緊密地集成在開(kāi)發(fā)過(guò)程中。大多數開(kāi)發(fā)組織能夠認識到驗證軟件功能正確性的重要性。而性能和擴展性的問(wèn)題只是當在生產(chǎn)的負載下應用出現問(wèn)題時(shí)才會(huì )注意到。這里需要特別強調的是，性能和擴展性需求應該在普通開(kāi)發(fā)人員編碼和測試中驗證，同時(shí)也以應該在QA過(guò)程驗證。關(guān)鍵應用交易應該使用分析工具進(jìn)行準確測量。而且，應用性能也應該在生產(chǎn)級別的壓力下測量。最好使用壓力測試工具可以幫助你進(jìn)行自動(dòng)測試仿真適當的用戶(hù)負載程度。

　　1.4部署

　　正確的控制也應該擴展到應用的上線(xiàn)部署階段。通常，一個(gè)應用的更新版本需要在不同的系統上同時(shí)部署。另外，也可能依賴(lài)系統軟件，運行時(shí)庫和其他共享組件的不同版本。因此，局部或偶爾的部署可能導致錯誤，故障或糟糕的性能。

　　圍繞部署的問(wèn)題通常與手工部署有關(guān)，因為手工容易出錯。自動(dòng)部署機制可以保證把正確的組件在正確的是件交付到正確的系統，以防止部署的災禍。

　　2.管理上線(xiàn)應用在應用交付中再多的計劃和控制也不會(huì )消除應用的故障。即使最完善的質(zhì)量控制過(guò)程也不會(huì )發(fā)現所有的缺欠。同時(shí)，最好的容量規劃過(guò)程也不會(huì )預見(jiàn)到意外應用的使用。因此，需要以及時(shí)和主動(dòng)方式管理應用的可用性和性能。

　　早期的識別和解決方式的關(guān)鍵是減少應用問(wèn)題的影響。通過(guò)正確的監測，很多應用問(wèn)題可以在停機前被發(fā)現和解決。

　　最終用戶(hù)的體驗監測是應用監測的重要部分。最終用戶(hù)的響應時(shí)間應該一直被測量，并與現有的服務(wù)等級協(xié)議比較，在問(wèn)題變得嚴重之前，能幫助識別和解決性能變化趨勢。

　　時(shí)間應該一直被測量，并與現有的服務(wù)等級協(xié)議比較，在問(wèn)題變得嚴重之前，能幫助識別和解決性能變化趨勢。

　　現在我們可以采用先進(jìn)的技術(shù)幫助組織捕獲，分析和回放完整地最終用戶(hù)會(huì )話(huà)。這樣的數據對于再現和診斷與應用功能相關(guān)的問(wèn)題而言是非常重要的。這些技術(shù)可以被用來(lái)分析電子商務(wù)和其他自助服務(wù)Web應用的可用性問(wèn)題。

　　除最終用戶(hù)的體驗數據外，資源利用情況和性能數據應該根據應用技術(shù)棧的層次進(jìn)行采集，包括Web Server，應用服務(wù)器，數據庫和網(wǎng)絡(luò )。這些數據可以在情況變得嚴重前提供有關(guān)問(wèn)題的重要信息。例如，缺少一個(gè)索引導致的性能問(wèn)題，只有在過(guò)量的表掃描時(shí)才能采集到特征數據。在對最終用戶(hù)產(chǎn)生嚴重影響之前，表掃描監測應該很早就可以發(fā)現這個(gè)問(wèn)題。與此類(lèi)似，Java應用中的內存泄露問(wèn)題往往很長(cháng)時(shí)間都不會(huì )被發(fā)現，通過(guò)監測內存使用就可以在災難之前發(fā)現這種問(wèn)題。對相關(guān)組件（包括網(wǎng)絡(luò )，操作系統，應用服務(wù)器，數據庫和應用等）的細粒度監測和報警，通�？梢栽谕�機前發(fā)現應用的問(wèn)題。

　　即使采用最好的，能夠盡早報警的系統，有時(shí)應用也會(huì )很快出現問(wèn)題，導致嚴重的性能下降甚至停機。這時(shí)，公司才會(huì )切實(shí)感覺(jué)到銷(xiāo)售額的下降或成本的顯著(zhù)上升。不幸的是，在這種情況下，診斷問(wèn)題是很困難的。在當前的復雜應用環(huán)境中，一個(gè)問(wèn)題可能與很多變化的因素有關(guān)。下面是一些造成應用響應時(shí)間突然下降的可能原因：

　　更改應用代碼后未經(jīng)優(yōu)化、未經(jīng)優(yōu)化的SQL語(yǔ)句、意外刪除的索引、意外的數據庫資源競爭、Java內存泄露、Web服務(wù)器進(jìn)程數量過(guò)多、網(wǎng)絡(luò )性能問(wèn)題識別像上面的這些困難問(wèn)題可能需要多種IT技術(shù)。重要的是技術(shù)人員應該方便地掌握恰當的數據以便快速縮小問(wèn)題的可能性。技術(shù)人員應該能夠快速察看應用，應用服務(wù)器，數據庫，Web服務(wù)器，操作系統和網(wǎng)絡(luò )的性能和資源特征，并可將這些數據與具體的交易響應時(shí)間的下降相關(guān)聯(lián)進(jìn)行綜合分析。擁有合適的工具以簡(jiǎn)明的方式提供數據時(shí)快速解決問(wèn)題的關(guān)鍵。

　　3.結論

　　商業(yè)組織必須不斷地適應變化的市場(chǎng)環(huán)境。這給IT部門(mén)帶來(lái)很大壓力，必須保證公司的應用系統可以支持全面的戰略方向。因此，將面對更為復雜的一個(gè)用環(huán)境。沒(méi)有正確的控制和管理，應用環(huán)境的持續改變將導致糟糕的應用性能和停機。對于一個(gè)組織來(lái)說(shuō)，這些問(wèn)題意味著(zhù)銷(xiāo)售額和生產(chǎn)效率的大幅降低。Gartner估計任務(wù)關(guān)鍵應用的每小時(shí)停機成本是42，000美元。而通過(guò)在應用的整個(gè)生命周期（從開(kāi)發(fā)到生產(chǎn)）中采用嚴格的方法，可以避免大量的損失。采用適當的工具，謹慎地控制工作流程可以俄日大多數IT部門(mén)節省巨額成本。