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

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

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

解決方案

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

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

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

通過用軟件驅(qū)動的流程代替手動程序來實現(xiàn)應用程序部署和相應實踐的自動化?；谠频幕A(chǔ)設(shè)施是這些技術(shù)的主要推動者，因為它們提供了一種通過軟件而不是人工操作員來控制整個數(shù)據(jù)中心的方法。圖 3 展示了自動化端到端應用程序部署的主要組件，包括：

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

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

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

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

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

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

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

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

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

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

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

基于云的自動化——實時

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

審核編輯：郭婷