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

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

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

解決方案

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

圖 2：需要人工干預(yù)的 IT 流程。

自動(dòng)化應(yīng)用程序部署和管理

通過(guò)用軟件驅(qū)動(dòng)的流程代替手動(dòng)程序來(lái)實(shí)現(xiàn)應(yīng)用程序部署和相應(yīng)實(shí)踐的自動(dòng)化?；谠频幕A(chǔ)設(shè)施是這些技術(shù)的主要推動(dòng)者，因?yàn)樗鼈兲峁┝艘环N通過(guò)軟件而不是人工操作員來(lái)控制整個(gè)數(shù)據(jù)中心的方法。圖 3 展示了自動(dòng)化端到端應(yīng)用程序部署的主要組件，包括：

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

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

智能編排——相當(dāng)于人類(lèi)操作員的軟件。

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

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

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

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

自動(dòng)化應(yīng)用程序部署在行動(dòng)

GigaSpaces 的Cloudify使用云應(yīng)用程序的拓?fù)浜途幣乓?guī)范 （TOSCA） 作為應(yīng)用程序藍(lán)圖的標(biāo)準(zhǔn)框架是一個(gè)編排引擎，它定義了應(yīng)用程序組件（節(jié)點(diǎn)）、它們的依賴關(guān)系，以及它們的指標(biāo)和相關(guān)策略（例如，如何安裝組件、處理故障或擴(kuò)展事件）以配置流程自動(dòng)化的基礎(chǔ)網(wǎng)絡(luò)。運(yùn)行應(yīng)用程序定義并加載 TOSCA 藍(lán)圖后，Cloudify 編排引擎將執(zhí)行藍(lán)圖以生成必要的虛擬機(jī) （VM） 和相應(yīng)的網(wǎng)絡(luò)資源（例如存儲(chǔ)）。編排器然后安裝應(yīng)用程序的各種組件，根據(jù)它們?cè)谝蕾囨溨械奈恢脕?lái)組織它們。最后，應(yīng)用程序監(jiān)控作為插件集成，每個(gè)組件通過(guò)監(jiān)控代理將指標(biāo)發(fā)送回編排器。

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

圖 4： Cloudify 編排引擎采用基于 TOSCA 的藍(lán)圖框架來(lái)定義應(yīng)用程序并使其流程自動(dòng)化。

基于云的自動(dòng)化——實(shí)時(shí)

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

審核編輯：郭婷