隨著業務越來越依賴於應用來產生的收入，所以非常有必要讓應用的宕機和故障時間降至最低。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 的許可證之下發布，網社群有限公司出版。保留所有權利。