根據博客“停機成本是多少”，盡管同期每個組織的停機小時數有所減少，但從 2010 年到 2012 年，網絡停機費用平均增加了 65%。對這一趨勢的一種可能解釋是，大部分業務都是在線完成的，這使得停機時間對組織底線的整體影響更大。

隨著轉向云和基于軟件即服務（基于 SaaS）的交付模型，面向客戶的應用程序和整個 IT 基礎設施都暴露于在線服務，停機時間的影響很容易讓整個組織關閉。IT 部門正面臨來自企業的巨大壓力，要求其變得更加敏捷，而實現敏捷性的最簡單途徑之一就是遷移到基于云的環境。然而，這帶來的問題是，遷移到更動態的云環境會增加失敗的風險。大多數現有的 IT 管理系統都是為靜態環境構建的，最多只能提供需要人工干預才能解決問題的警報監控。這種類型的系統已經變得不切實際，隨著系統生成的數據量和事件數量增長到大多數人工操作員無法跟上的程度；結果是增加了人為錯誤。

Gartner 最近的一項研究預測，到 2015 年，“影響關鍵任務服務的 80% 的中斷將由人員和流程問題引起，其中超過 50% 的中斷將由更改、配置、版本集成和移交問題引起［2］。” 那么可以做些什么呢？解決方案是從靜態監控轉向完全反應式的系統，該系統可以在問題發生時識別和修復問題——無需人工干預。

解決方案

找出解決方案并不難。如果 80% 的停機時間是部署和恢復過程中的人為錯誤造成的，那么解決方案就是通過自動化消除這些錯誤。由于 IT 流程可能相當復雜且不易自動化，圖 2 概述了涉及人工干預的 IT 流程示例。例如，這些可能包括將新開發的軟件包投入生產、安裝新功能或應用程序的監控、性能調整和故障排除等等。

圖 2：需要人工干預的 IT 流程。

自動化應用程序部署和管理

通過用軟件驅動的流程代替手動程序來實現應用程序部署和相應實踐的自動化。基于云的基礎設施是這些技術的主要推動者，因為它們提供了一種通過軟件而不是人工操作員來控制整個數據中心的方法。圖 3 展示了自動化端到端應用程序部署的主要組件，包括：

圖 3：在反饋循環中自動化 IT 流程所需的組件

云基礎設施——通過應用程序編程接口 （API） 提供對所有 IT 資源的軟件驅動訪問。

智能編排——相當于人類操作員的軟件。

歷史數據——存儲以前的狀態和事件，用于確定應用程序是否按預期運行，并根據實際活動調整系統閾值。歷史數據也可用作發生故障時根本原因分析的來源。

實時分析——更新監控計數器，包括復雜的復合 CPU 延遲指標，并在事件超出特定閾值時觸發警報。

這種架構的核心是編排。編排器為給定應用程序創建一個定義，該應用程序通過軟件可讀指令集運行以繪制應用程序藍圖。編排器還負責確保應用程序符合服務水平協議 （SLA），這可能是其最具挑戰性的功能，因為這需要一定程度的人工智能 （AI）。

為了實現必要的 AI，必須建立一個反饋循環，該循環既能夠識別應用程序是否按預期運行，如果不是，則采取糾正措施。反饋循環首先從應用程序收集實時反饋，然后實時處理它們以檢測故障或容量問題。然而，確定給定警報是真實警報還是假警報通常涉及與歷史數據的相關性。例如，如果預期負載增加，高 CPU 利用率并不總是表明存在問題。同時，低 CPU 使用率可能表明流量不足，這不一定表示應用程序的穩定性。實時和批量報告的分析通過將當前和歷史數據報告回編排器來關閉循環，編排器反過來可以采取糾正措施。

自動化應用程序部署在行動

GigaSpaces 的Cloudify使用云應用程序的拓撲和編排規范 （TOSCA） 作為應用程序藍圖的標準框架是一個編排引擎，它定義了應用程序組件（節點）、它們的依賴關系，以及它們的指標和相關策略（例如，如何安裝組件、處理故障或擴展事件）以配置流程自動化的基礎網絡。運行應用程序定義并加載 TOSCA 藍圖后，Cloudify 編排引擎將執行藍圖以生成必要的虛擬機 （VM） 和相應的網絡資源（例如存儲）。編排器然后安裝應用程序的各種組件，根據它們在依賴鏈中的位置來組織它們。最后，應用程序監控作為插件集成，每個組件通過監控代理將指標發送回編排器。

之后，策略引擎使用復雜的事件服務來確定應用程序是否滿足其 SLA，并在可能包括生成新 VM 或重新分配系統負載的違規情況下觸發操作。圖 4 說明了基于 TOSCA 的模型中的多層應用程序部署。

圖 4： Cloudify 編排引擎采用基于 TOSCA 的藍圖框架來定義應用程序并使其流程自動化。

基于云的自動化——實時

由于企業的日常運營不斷被網絡基礎設施所吸收，傳統的 IT 流程將無法促進事件和數據的大量增加。此外，在流程管理中添加人為因素可能會首次在不斷發展的 IT 環境中引入挫折而不是收益。在正常運行時間對任務至關重要的情況下，基于云的自動化可以有效地減少停機時間，同時讓 IT 經理在最需要他們之前騰出時間。

審核編輯：郭婷