DevOps 可幫助降低宕機時間，更快的修復問題

隨著業務越來越依賴于應用來產生的收入，所以非常有必要讓應用的宕機和故障時間降至最低。IDC 和 AppDynamics 研究表明，在24小時服務環境里，基礎架構的故障成本是 每小時$100,000美元 。雖然從現實的角度來看，完全的避免應用故障是不可能的，但是用來預計和修復故障的時間仍然是一個可以提高的因素。

盡管如此，在這個相同的報告里面，35%的業務估計 IT 故障花費了12個小時修復，17%的受訪者說修復一些關鍵應用程序故障可以花費好幾天時間。

當應用失敗時，收入損失迅速增加，顯然，改變這一情況就意味著要為大量業務上的方案做出改進。然而，不合標準的硬件和架構常常處理著業務，不僅要找出還要修復問題，這是引發問題的主要原因。

在內部，企業組織的開發和運營團隊之間都有明確的界線，兩個部門在工作關系上還需要做出許多。當應用出現問題，責任最初被劃歸到運營部門，他們 常使用大量的監測和管理工具，探索具體的和豎井式（siloed）架構組件，諸如CPU，內存和網絡，而在這之前常常發現開發團隊也需要被保證。

開發團隊常常使用他們自己的診斷工具，這導致了數據有多個來源，多種來源的信息與最終多源頭的結論相關。結果就是發現導致問題的根本原因的時間 變得更長，對客戶在商業上的損失還有自身的收入上都不幸地造成了影響。此外，開發團隊常常工作在不同的模式及不同的地點，在開發團隊能證明挑戰時才能挑選 正確的人。

但是，這不是一條必由之路。在DevOps文化的支持下，它的目標是讓一個在開發團隊和運營團隊之間形成協作關系，并已經在IT部門顯示出靈活性的改進，同樣這也能提高應用修復的速度。

采用DevOps, 應用性能的責任是由兩個部門分擔的，這就意味著開發團隊從開始就更參與其中。不是簡單地開發代碼，然后把代碼給運維團隊來部署上線，整個過程會被更平等地分擔，確保兩個團隊對應用的性能都可見的。

例如通過實施應用性能監控(APM)，并讓所有的干系人了解，IT部門可以更快地解決問題。另外，通過使用記錄代碼變更的源碼控制系統，允許兩個團隊的成員理解雙方的工作方式以及代碼變更的原因。

DevOps的方式同時也讓在生產環境的bug更容易更快地被發現和修復。在傳統的模式下，開發環境同生產環境隔離，因為環境的差異，當新的特新和bug修復發布到現實世界的時候，它們有時不能正確的工作。

結果一旦代碼上線，這會增加了出故障的可能性，并會增加故障的平均解決時間(MTTR)。環境的差異同時也意味著在代碼部署到生產環境之前，運 維團隊經常需要修改配置，這又增加了代碼的部署時間。結果開發和生產環境的數據不一致延緩了代碼部署和變更的過程，這不可避免地增加了業務成本。

然而，通過采用作為 DevOps 一部分的自動化，許多這樣的問題就可以避免了。通過自動化代碼測試和環境的提供，可以大大地縮短花在這兩個任務上的時間，并且確保兩個環境是基于相同的配置。

這意味著開發人員可以開發更短的代碼并以更快地速度部署到開發環境，這極大地降低了部署新特性、變更和 bug 修復的時間。實際上，IDC 和 AppDynamics 報告顯示業務預計 DevOps 將會提高15-20%的交付能力，這表明了這種模式可以帶來的速度的改進。

然而，當 DevOps 加快新的應用和特性的交付速度，優化了員工的生產率和提高客戶滿意度，很重要的一點是在變更加快的同時，沒有造成應用的宕機時間增加。

例如 Gartner 預測2015年80%的服務中斷將是由 人和流程引起的 ， 其中超過50%將會由變更配置和發布整合引起的。

通過讓運維和開發團隊了解整個的應用的生命周期，業務可以使用 APM 作為一種反饋和前饋相關的信息到軟件開發周期(SDLC)。 這有助于確保新的發布和變更不會在運行或生產環境造成業務影響。

為了讓 DevOps 起作用，CIO 們將需要克服不少的文化挑戰，包括在業務的工作方式，和在招聘合適IT技術人員以支持 DevOps 的采用。

例如，組織現在需要理解或者有能力承擔復雜的基礎架構自動化任務的開發人員，以及具有所需軟件基本的編程技能的運維人員。

就像之前說的，保持應用的平穩運行和作為結果可以實現的成本縮減的必要性意味著這些變化是為了滿足客戶需求和產生收益所必須的。

John Rakowski 是 AppDynamics 解決方案的講師。

在從 ITProPortal.com 的許可證之下發布，網社區有限公司出版。保留所有權利 。