IT作業管理–利用 Micro Focus Operations Bridge 實現自主式 IT 維運

By 2019-02-18電子報專刊

利用 Operations Bridge 實現自主式 IT 維運

Gartner 研究報告:讓您的新世代監控工具與未來基礎架構及應用架構並駕齊驅

IT 必須有所改變。就像數位轉型意味著現代應用,那些開發人員所使用的複雜新技術,界定了各種現代業務服務設計與全新的管理挑戰。

新世代…是什麼?

在這個高度競爭環境的 IT 管理挑戰,到處都充斥著改變。其中一項改變來自於 IT 要成為高階主管更具策略性合作夥伴的需求,提供企業維持競爭力的機敏度,並服務目前已經習慣所有事物「隨時上線」的使用者。IT 維運遭遇的眾多挑戰,持續擴展的大數據 (Big Data),全新技術及使用更少的資源完成更多工作,在在都驅策 IT 轉型為服務成熟的部門,且安全、高成本效益地運用雲端技術。

這些的確都是挑戰,但其中某些也代表了絕佳的機會。

  • 隨著企業應用採用容器化 (containerization) 以隔離並保護應用邏輯和客戶資料,監控工具也必須採用相同架構以確保部署的擴充性和機敏度
  • 隨著企業使用大數據,監控工具也必須如此
  • 隨著物聯網 (IoT) 將所有人與裝置互相連接,監控工具也必須善加利用此連結能力,以及我們因此得以存取的資料
  • 統計數據及產生統計數據的分析工具,已成為企業評量進度的關鍵元件,因此監控工具必須嵌入分析功能
  • 由於現在的 IT 已變成業務角色,監控功能必須能夠在事件發生時將事件揭露給所有利害關係人。昨日的新聞已經緩不濟急,利害關係人必須被賦予觀察並更快做出決策的能力

聽起來幾乎就像規格書,但這些也是常識。它們定義了新世代監控與管理能力。

儘管這些改變可能定義了持續進化的傳統監控方式與工具,但事實上您也確實缺乏更多身懷更高技能的人員能參與進化。

利用相同或更少的人數去完成更多工作,將需要提供自動化、自助及機器學習功能的強大技術和工具,以建立自主維運的環境,讓 IT 不用再執行重複性工作,並以業務速度善用分析工具。

目前 Micro Focus 推出的 Operations Bridge 監控工具,從根本上涵蓋所有前述需求,可偵測、分析、適應及解決 IT 的挑戰與改變。

OpsB_Automation_WP_01
從業務角度執行維運

接著讓我們看看此一解決方案的功能。

偵測 IT 狀態

偵測不光只是監控。

而是持續搜尋被管理的物件及物件之間的依存關係,並利用此資料進行事件分析以確認事件的根本原因。

Operations Bridge 對整個混合式 IT,即傳統、虛擬和雲端環境,執行上述所有偵測工作。

此軟體的設計宗旨在管理 Micro Focus 系統監控收集器 (包括終端使用者體驗的監控、代理及無代理程式監控工具),並整合來自第三方管理工具的 IT 資料,這些工具包括常見的 Nagios、Microsoft SCOM,以及其他許多採用由 Micro Focus 及我們合作夥伴所開發支援的連接程式 (connector)。

大數據-麻煩還是機會

誰都無法事先得知哪種資訊會是解決議題所需的最恰當資料。

不論您目前使用的工具組為何,可確定的是,絕大部份資訊是來自裝置上的偵測器、智慧型手機、工業系統、車輛,基本上每個地方都是資訊來源:這些都是可提供重要洞察力的資訊來源。

物聯網突顯出互聯資訊來源的高速成長,而物聯網的使用者對業務服務有著比以往更高的期待。

其後續衍生的資料雖造成令人頭痛的局面,也為 IT 創造機會,讓IT 隨時可取得所需的資訊,並在某些情況下,在問題發生任何影響前利用該資訊來解決問題。

「善用大數據及機器學習技術,建立以資料為中心的可用性及效能監控作業。

Micro Focus Operations Bridge 解決方案採用領先業界的大數據資訊管理及分析平台 Micro Focus Vertica,並結合了我們以事件相關性及預測分析為基礎的專利架構,符合業界專家對 AIOps(algorithmic IT operations) 及 ITOA (IT operations analytics) 的建議需求。

監控雲端服務交付

當雲端服務嵌入現代化架構時,有人可能以為如此一來就無須監控作業了。但想像您是服務提供廠商,試圖透過服務來取得差異化、營收與滿意度。因此,對於任何可能影響這些目標的問題,都應該加以偵測、解決;但如果是其他人的資料中心所造成,您要如何才可以確認?

同樣地,若您正在使用其他人的服務,您有辦法仰賴他們告知服務何時改變,效能何時下降嗎?您該如何確定原因是來自您的資料中心、業者或連線問題?

只要類似的情況發生,服務的交付就會受到影響。

在毫無幫助的情況下自行摸索、不瞭解,就意味著接受風險,而且可能是未知的風險。

使用自動化輔助的適當監控技術可解決此問題,並提供服務保障。

Micro Focus Operations Bridge 所做的就是自動執行此功能。它能自動搜尋公有雲及私有雲並監控您的服務,將演算智慧應用於此資料,在異常發生時即主動確認、提出維運警示,並在遵守標準 IT 流程下執行修復作業,這些都對提供服務保障有相當大的助益。

此方案同時涵蓋以 Docker 為基礎的架構設計,並與 Docker 主機端的監控作業整合。當容器 (container) 反覆故障、急需資源或連結時,OpsBridge 可搜尋容器內的應用並萃取關鍵資訊。

自動化智慧讓 IT 維運專注於機會點

如同剛剛所提到的,資訊風暴所帶來的事件及效能資訊量超乎想像,讓工具與維運人員陷於困境。因此我們自然會期望運用運算功能取得理想效果,將智慧運算以超乎人類思考的速度應用至此資料,並隨著時間學習以便適應及預測。利用演算法分析可以很簡單,例如採用智慧及可調適過濾工具來處理資訊風暴,判斷什麼樣的資訊與真正的根本原因相關,還是只是問題的徵候。

OpsB_Automation_WP_02
Micro Focus Operations Bridge 管理 AWS、Docker 與 Azure

其他演算法協助機器學習以加速大海撈針的效率,以前所未有的高速及更卓越的整體可見度 (visibility),引領使用者走出巨量的資料迷宮。

結合業務背景資訊,例如拓樸分析,分析作業是正確的重點。即使已確認到根本原因,當某些問題發生時,您將採取何種行動?服務影響分析及可見度已證明可用來定義優先順序。IT 維運需要工具以專注在被分析工具隔離出來、對維運最具影響性的事件上,從而分配活動所需資源。

同時,DevOps 團隊有愈來愈多以支援營運流程的新技術目錄可供選擇 (通常是行動應用);IT 選用混合式 IT 架構支援上述需求,接著還有私有雲、公有雲、容器及整合等更多的技術,讓執行環境更加複雜。IT 管理解決方案必須涵蓋上述所有不同架構的選擇,並善用上述架構所產生的監控資料。

自主式 IT 維運

Gartner 指出,現代解決方案必須使用自動化,以搜尋並監控部署在混合式 IT 內的服務 (包括應用程式及支援這些應用程式的基礎架構)。

Micro Focus Operations Bridge 內建的 IT 服務樹 (service tree) 的資料,來自 Micro Focus 代理器型及無代理器型原生收集器所提供的監控資料,以及整合在其內的第三方產品所匯入的資料。此資料收集流程持續不斷,能隨時更新 IT 環境的真實狀況。

結合智慧型過濾工具來隔離相關性最高的事件,再利用自動化的拓樸分析結果來確認根本原因的組成元素,及顯示最可能干擾重要服務的作業。

即使有了可以確認的工具,一旦問題發生時,IT 人員正忙碌中或無法支援的話會如何?

最佳實務修復作業可自動執行,而 OpsBridge 內建領先業界的Operations 協調技術,提供超過 8,000 種預先定義的工作流程可供選用及隨時客製化。如此一來,便可執行閉迴式矯正措施作業,以及規定清楚的合規性流程。範例包括:執行各項變更,如分配額外的容量、重新導引交易路徑、擴充資料庫;流程方面則通常包含在服務管理工具內開啟 ITSM 標籤(ticket)、產生稽核報告等。

這些技術可減少 IT 維運人員的重複性工作、確保一致性並避免人為失誤。一致性也有利於合規性的達成。監控自動化、自動搜尋,及自動分析與修復等功能,均為 Swiss Mobiliar 與其他眾多使用 Micro Focus Operations Bridge 的客戶,提供了高度的自主維運能力。

將「O」放進 DevOps

對 Swiss Mobiliar 與其他使用者而言,DevOps 是用來打破已知流程,進而建立能善用新科技以提升機敏度、競爭力和差異化的方法。但 Operations Bridge 如何協助 DevOps 團隊?

OpsB_Automation_WP_03
「自主維運對節省成本及加快速度相當重要,還能讓我們更專注在真正的難題。」Thomas Baumann, Swiss Mobiliar – 觀賞影片

監控工具握有可發揮絕大作用的大量資訊。從監控資料可看出應用程式和基礎設施的行為特徵,而其所產生的分析結果猶如黃金一般,可協助開發人員與測試人員改善並發布更好的版本。

但這些工具要如何存取資訊?

Micro Focus Operations Bridge 提供數種協助方式。

  1. IT 的「CNN」

    首先是一項革命性的簡單方法,讓使用者可在一般平板或其他裝置上存取資料。著名的中國古諺云:「聞而忘之、視而記之、行而知之。」

    示範給我看!這是企業長久以來一直要求 IT 的一件事。事實是,當他們可以親眼看到所發生的事情、IT 在事件發生之際即時分享,就有機會產生大量的合作。

    我們的商業價值儀表板正是為了達成這個目的而設計。儀表板可忠實顯示事件狀況,其格式便捷、簡單,可安全存取、快速理解,且 IT 可立即提供。

    了解如何從業務角度實現自主式維運
    OpsB_Automation_WP_04

  2. ChatOps

    其次,有了 ChatOps,DevOps 團隊即可在沒有 OperationsBridge 平台帳號的情況下,存取重要資訊。

    此機器人技術利用一般常見的訊息傳送軟體,提供互動的資訊存取功能。

    當大家合作解決問題時,此軟體會擷取對話與所採取的措施,並套用新的修復作業。

    作業中的 ChatOps (此範例中使用 Slack,但非強制性)

    OpsB_Automation_WP_05

    觀賞 ChatOps 展示影片

新世代…即此刻

Micro Focus Operations Bridge 多年來為各種企業的 IT 提供相當重大的價值,這些企業橫跨金融服務、電信、健康照護、物流與生命科學等領域。

和這些企業一樣,我們也不會停滯不前。「Micro Focus OperationsBridge 模組化」可作為我們應用上述技術時的總提要,Gartner 在此份文件中也肯定了這些技術。

我們瞭解您在面對現代業務轉型時的挑戰。不論您是大型跨國企業或較小型企業,我們皆能應對自如。可隨您的業務面貌如物聯網而改變。

我們的某些客戶結合分析工具和即時儀表板來運用分散式監控功能,以滿足鐵路規範的要求。他們使用即時監控功能以監測、控管火車移動,提供更安全的運輸體驗。

其他客戶則監控風力發電廠,電廠內的大量感測器利用船舶負荷產生資訊,在確認可靠性及協助生態電力傳輸上有相當的助益。

另外,還有客戶考量輸電塔及輸電設備對使用者體驗有何影響,並利用分析工具執行主動管理,避免異常事件影響任何使用者、或降低服務品質。

Gartner 研究報告

讓您的新世代監控工具與未來基礎架構及應用架構並駕齊驅

商業應用的管理架構正逐漸依據微服務、NoSQL 資料庫及串流分析來建立。基礎架構及維運主管必須導入可有效管理新世代基礎架構及應用程式堆疊的監控系統。

主要挑戰

  • 「監控即服務」的發展,將造成 IT 利害關係人對監控資料有更多的不確定需求
  • 對於依現代架構原則而建立的系統,是理解及修改這些系統行為所需的資料集,量大又複雜,已超越一般 IT 維運從業人員所擁有的技能.
  • 許多目前運作中的 IT 監控工具,並非針對雲端原生架構的多變特性而設計
  • 移轉至新的監控架構時,大多都會造成後續監控服務的中斷,因此很少執行此作業

建議

基礎架構與維運主管人員應:

  • 購買或建置使用模組化元件的系統,以確保監控架構的擴充性及復原彈性
  • 要求將自動化服務搜尋內建於監控架構內,或要求介接目錄服務功能
  • 採用四層的監控資料存取流程:包括針對資料搜尋與彙整的彈性查詢及視覺化流程,資料內指標 (metric) 的統計分析,透過機器的輔助搜尋資料項目間的相關性,最後,透過機器的輔助從相關性網路萃取因果路徑
  • 在選擇工具時高度重視遞增部署監控技術的能力

導言

若基礎架構與維運 (I&O) 主管為滿足數位企業需求,打算建構一個動態、可逐步擴充的基礎架構,就必須確保 IT 部門的監控工具能趕上需求。基本上,企業在目前眾多現代監控工具的「表面」下,已採用一套新的技術「堆疊」 (參見圖 1)。

圖 1 是我們觀察到在監控領域所採用的部分技術範例。傳統企業可能不需要像 Facebook 或 Google 一樣,可每秒監控上百萬個事例 (instance),收集數十億筆資料的功能;但是,未來數位企業持續增加的可用性及效能需求,必然要有全新的監控架構才能保持競爭力。

此處所提供的為現今數位企業對現代監控技術所要求的部分關鍵功能。幾乎每一家大型雲端或 Web 規模服務供應商的監控工具組都有許多重複,因此企業不必奢想一夜之間就能移轉到此類架構上。新增 NoSQL 資料管理及更先進的分析功能通常是很好的著手點,因為部署所需要的技術時,通常只要小幅調整既有的監控功能和產品就能可以了。

■圖 1
OpsB_Automation_WP_06

避免使用透過單一元件型平台完成所有工作的解決方案 (即使該平台採模組化元件建構而成)。在不中斷服務的情況下循序漸進,並持續評估何處的監控需要改善。務必選擇未來可讓您在監控架構內移轉的工具。

分析

購買或建構模組化元件的系統,以確保監控架構的擴充性及復原彈性

許多傳統與非 SaaS 監控系統都是單一元件性質 — 例如,資料收集 (檢查)、匯整、甚至運算功能 (如警示與資料儲存) 都在同一個核心元件內執行。這代表絕大部分可用的 CPU 效能都消耗在環境 (context) 切換上。儘管硬體升級 (垂直擴充) 可暫時緩解效能問題,但這種作法仍只是個短期對策,原因在於:

  • 終端使用者愈來愈多,造成資料消費模式難以預測。來自使用者的監控資料愈多,收集到的度量指標 (metric) 也更多。更糟的是,由於這些新度量指標的使用者會「實驗」其資料細微度 (granularity) 及頻率需求,也會造成資料收集流程更加難以預測
  • 企業為確保機敏度而持續交付應用,造成程式碼發布量不斷增加,這可能產生度量指標風暴,並壓垮監控架構中復原彈性較差的區域

建議:

  • 建置或部署可分解主要功能的監控架構 (參見圖 2)。模組必須簡單,並透過良好定義的介面連接。這種作法可讓最佳化僅限於需要的地方,不需要大幅升級全部的導入方式,或中斷監控活動
  • 必要時以地理 (或其他) 層級來複製元件,以降低整體資料量,並透過本地化資料累計匯報,改善發布流程。這套自主或半自主方法,將改善整個監控系統的可用性

確保您的監控架構內含自動服務搜尋,或您可介接至目錄服務

即使對許多大型的 Web 規模服務供應商而言,服務搜尋至今也還是一項挑戰。其原因牽涉到時間及空間兩個層面:

  • 時間方面指的是利用如容器或微服務等技術,在雲端內甚或是本地部署上,快速配置及解除配置資源的能力愈來愈強大。微服務通常是所謂不可變基礎架構的一部分,會使搜尋問題惡化,因其內含的虛擬機器 (VM) 或容器,建立與損壞的頻率比一般要高得多。這是因為不可變特性的重點,在於透過更換而非修改來達到理想狀態。
    ■圖2
    OpsB_Automation_WP_07
  • 與空間相關的問題,則在於被管理物件的目標領域。大部份企業不需和 Web 規模雲端公司一樣,管理數百萬個物件。但隨著 Web 規模雲端服務的出現,創造出各種微服務及架構型態,物件數量肯定會持續增加。Gartner 預期未來幾年將會經常看到企業監控系統必須管理遍及私有雲和公有雲環境的數十萬個物件。

建議:

  • 要求您的監控解決方案必須介接主要的基礎架構協調 API。請留意此領域的開放原始碼堆疊愈來愈重要,因此除了支援既有平台外,也要能介接 Kubernetes 與 Mesos (Marathon) 等技術
  • 所使用的監控解決方案,必須支援用以設定監控及搜尋組態的外部系統。除了您企業所支援的系統外,還要能支援開放原始碼技術,如Apache ZooKeeper、甚至是 Netflix OSS Eureka (由 Pivotal Spring Cloud 支援)。

採用四層的監控資料存取流程

傳統監控技術試圖將重點放在加入視覺上更具吸引力的直覺式介面,以支援各種監控團隊的需求與技術。儘管這種作法符合 IT 日漸「消費者化」的趨勢,但同時也帶來全新的挑戰:

  • 商業版圖形使用者介面 (GUI) 可能阻礙更複雜精巧的使用案例應用機會。在這類應用情況中,使用者需要彈性、指令列及查詢導向式介面,以便執行複雜精巧的資料處理及操作 (如為支援快速的資料檢查而建立度量指標的分位數或 bucket)
  • 許多常見的企業工具組在命名度量指標時,常使用冗長的標籤或名字,不利於靈活的過濾及搜尋作業

建議:

建置或購買支援四層資料存取與分析的監控系統:

  • 非符號的 (nonsymbolic) 視覺化功能可讓查詢語言更加豐富,在建議的大型模式中,仍能從複雜資料集中準確找出特定資料項
  • 資料項內嵌度量指標的統計分析,以呈現時間序列及其他數值結構
  • 透過機器輔助來搜尋資料項 — 數字、文字、語意及圖形 — 之間的相關性,可協助揭露對操作人員來說埋得太深或太複雜的相關性
  • 自先前建立的相關性內,藉由機器的輔助萃取因果途徑。加上此最後一層才能真正確認資料項間的行動導向關係

您的監控系統必須將上述四層存取及分析功能,除了套用在大量累積的歷史資料外,也要應用在被管理的應用程式及基礎架構所產生的串流資料。這幾乎等於一定要有一套 NoSQL 資料庫管理平台。

在選擇工具時高度重視遞增部署監控技術的能力

許多企業不想改變監控架構,是因為移轉至全新平台時通常會產生龐大費用。此外,轉換過程也可能額外發生無法遠端遙測的問題。傳統監控架構之所以發生這些問題是因為:

  • 在目標系統上運作的 Client Library (代理器) 只能向其上游匯集器及/或收集器回報
  • 許多商業型監控技術供應商通常不會把與其他 (競爭對手) 的監控系統整合當作重要事項,因為這些公司的目標是要在一家企業的所有監控與遠端遙測工具環境中,作為單一的「真相來源」

建議:

  • 所購買與部署的工具,其 Client Library (在伺服器上運作的代理器),必須能將資料寫入任何匯集器或主控台並產出報告,以減少代理器與管理器之間僵硬的束縛
  • 一開始先在既有系統上增加新功能,後續再規劃逐漸替換這些系統