FreeWheel 創(chuàng)建于 2007 年，總部位于美國硅谷，主要業(yè)務(wù)是提供互聯(lián)網(wǎng)視頻廣告投放、監(jiān)測、預(yù)測、增值等解決方案。經(jīng)過十多年的發(fā)展，FreeWheel 的業(yè)務(wù)量不斷增長，系統(tǒng)架構(gòu)日趨復(fù)雜，公司運維團隊面臨的挑戰(zhàn)也越來越大。FreeWheel 的運維團隊經(jīng)歷了從最初的小規(guī)模傳統(tǒng)運維，到按照職能細分的運維團隊組織模式，再到最近幾年轉(zhuǎn)換 DevOps 思想，進而到 SRE 的演變，目前正在探索實踐 AIOps。作為積極擁抱新技術(shù)和新思想的團隊，FreeWheel 結(jié)合自身的痛點對團隊、工具和流程進行持續(xù)改進，其轉(zhuǎn)向 AIOps 的例子十分典型，他們踩過的一些坑對想要采用 AIOps 的企業(yè)和團隊也很有借鑒意義。

FreeWheel 運維團隊的演進

從公司 2007 年創(chuàng)立到現(xiàn)在，FreeWheel 運維團隊的發(fā)展大致經(jīng)歷了以下幾個階段：

• 傳統(tǒng)運維。公司成立初期業(yè)務(wù)量較小，系統(tǒng)的復(fù)雜性也不高，各方面挑戰(zhàn)都不大。此時運維團隊規(guī)模很小，各項工作基本都是大家一起完成，包括網(wǎng)絡(luò)規(guī)劃、硬件安裝、軟件部署、監(jiān)控報警等。日常管理工作通常是通過直接執(zhí)行命令或編寫簡單腳本來完成。

• 運維職責分化。隨著 FreeWheel 的業(yè)務(wù)快速成長，產(chǎn)品線不斷擴展，系統(tǒng)模塊數(shù)量及相互間關(guān)聯(lián)依賴的復(fù)雜度隨之增加，基礎(chǔ)設(shè)施也變得越來越龐大，整體運維工作變得非常復(fù)雜，運維團隊面臨的挑戰(zhàn)直線上升。在這段時期 FreeWheel 將整個全球運維團隊進行細分，包括系統(tǒng)運維、網(wǎng)絡(luò)運維、數(shù)據(jù)庫運維以及產(chǎn)品運維。產(chǎn)品運維更側(cè)重在產(chǎn)品部署、服務(wù)運行等產(chǎn)品環(huán)境，跟軟件開發(fā)人員的溝通交流更為緊密，通常會結(jié)合自身的運維經(jīng)驗和需求提出建議，協(xié)助設(shè)計和搭建監(jiān)控、報警系統(tǒng)，從而使 FreeWheel 業(yè)務(wù)產(chǎn)品能夠更好、更穩(wěn)定地運行。這個階段運維團隊的組織結(jié)構(gòu)變得更加清晰，各運維小組的職責變得更加明確。

• DevOps。FreeWheel 有一段時間成立了專門的 DevOps 團隊，負責建設(shè)從代碼管理、打包測試、上線部署到配置管理、報警監(jiān)控的一整套管道流程和工具平臺，力爭打破開發(fā)和運維之間的邊界，實現(xiàn)更好、更快的代碼上線及服務(wù)變更。但在具體實踐中，由于該團隊所招聘的人員運維經(jīng)驗偏少，對系統(tǒng)上線和監(jiān)控的理解不夠深入，同時和眾多的開發(fā)團隊之間也難以保障充分溝通，導(dǎo)致開發(fā)和運維兩方面的具體需求都得不到快速有效的響應(yīng)。這一階段 FreeWheel 走過了一些彎路，值得反思。

• SRE。SRE 的角色定義在 Google 首先建立和推行，FreeWheel 的產(chǎn)品運維組在過去一年中也進行了相關(guān)實踐，結(jié)合自身現(xiàn)實情況，嘗試使用工程的思想和手段來審視與改進生產(chǎn)環(huán)境的運維工作，并盡可能推動運維自動化。具體工作包括和產(chǎn)品開發(fā)團隊一起梳理并建立 CD（持續(xù)部署）流程和平臺，對業(yè)務(wù)和產(chǎn)品進行實時監(jiān)控，關(guān)注報警以及系統(tǒng)的穩(wěn)定性、可用性，明確定義 SLO（Service Level Objective），確保對用戶承諾的 SLA（Service Level Agreement）。

哪些痛點促進團隊轉(zhuǎn)向 AIOps

在 FreeWheel 的發(fā)展過程中，業(yè)務(wù)和技術(shù)層面的多個痛點促使運維團隊嘗試從運維智能化的發(fā)展趨勢中尋求有效的解決方案。例如：

• FreeWheel 一個突出的業(yè)務(wù)模式是在直播賽事中投放廣告。近年來公司服務(wù)的直播源大幅增加，從用戶過來的廣告數(shù)量包括流量峰值都難以預(yù)測，這對廣告服務(wù)器以及后端的技術(shù)平臺和架構(gòu)的可擴展性和穩(wěn)定性都提出了很高的要求。同時，直播賽事中廣告播放的時間點和時長也是不可預(yù)測的，出問題的時間可能短至幾秒甚至幾毫秒，但對客戶的即時影響很大，這時要捕捉到問題并及時解決故障的難度非常高。依靠傳統(tǒng)的人工操作及簡單自動化已難以有效應(yīng)對上述的運維挑戰(zhàn)。

• 在 FreeWheel 所聚焦的廣告領(lǐng)域，另一個極具代表性的痛點來自于欺詐和無效流量（IVT）對數(shù)字廣告生態(tài)系統(tǒng)所構(gòu)成的重大威脅。所謂“道高一尺，魔高一丈”，IVT 的不斷演變使得對應(yīng)的解決方案不可能簡單的一蹴而就，而需要具備持續(xù)性和智能化的特點，包括持續(xù)收集和分析流量來源、行為方式以及進行特征理解，以更好地解決 IVT 這一威脅。

• 同時，隨著 FreeWheel 業(yè)務(wù)系統(tǒng)越來越復(fù)雜，基礎(chǔ)設(shè)施各技術(shù)層面都出現(xiàn)了不同的挑戰(zhàn)。例如監(jiān)控層面，就出現(xiàn)監(jiān)控系統(tǒng)多樣化，報警條目和數(shù)據(jù)海量化，但同時報警信息不規(guī)范，各類報警郵件的主題和內(nèi)容都不統(tǒng)一，一個問題經(jīng)常引發(fā)多條報警。在這種情況下，如何在海量的報警消息中甄別有效關(guān)鍵信息，并在報警風(fēng)暴的壓力下快速準確地定位問題解決問題，成為運維團隊所面臨的巨大挑戰(zhàn)。

• 同樣在技術(shù)層面，如何對現(xiàn)有基礎(chǔ)設(shè)施的使用進行有效的優(yōu)化，以支撐業(yè)務(wù)的穩(wěn)定運行，也是運維所面臨的難題。比如在網(wǎng)絡(luò)層面，業(yè)務(wù)量增大帶來流量增多、類型復(fù)雜，同時云戰(zhàn)略的推行也使得云端資源的訪問日趨復(fù)雜，網(wǎng)絡(luò)運維團隊需要智能化的手段來有效識別流量，并做出靈活的判斷和優(yōu)化處理，比如給優(yōu)先級高的流量預(yù)留足夠的帶寬，以支撐各關(guān)鍵類型業(yè)務(wù)的順利開展。

隨著近年來人工智能技術(shù)的快速發(fā)展，以及各領(lǐng)域運維數(shù)據(jù)和經(jīng)驗的積累為智能化運維提供數(shù)據(jù)基礎(chǔ)，AIOps 正成為運維的下一個發(fā)展趨勢。FreeWheel 希望借助這個趨勢解決業(yè)務(wù)和技術(shù)層面所面臨的各種挑戰(zhàn)，進一步提升運維水平，同時推進運維團隊的成長，適應(yīng)公司業(yè)務(wù)、技術(shù)架構(gòu)以及整體團隊發(fā)展的需要。

FreeWheel 的 AIOps 平臺建設(shè)

FreeWheel 的 AIOps 平臺目前還在構(gòu)建過程中，如上文所述在某些領(lǐng)域已經(jīng)開始了探索性的工作，同時也逐步規(guī)劃好未來的演進方向。

上文提到，監(jiān)控層面的挑戰(zhàn)是 FreeWheel 探索 AIOps 的重要驅(qū)動力之一，也是重點考慮的切入點。由于業(yè)務(wù)的復(fù)雜性和快速演進，FreeWheel 監(jiān)控系統(tǒng)的報警來源變得非常多樣。單就監(jiān)控系統(tǒng)而言，FreeWheel 使用了流行的 Nagios 和 Zabbix 以及開源的 ELK 技術(shù)棧，也使用了在云端應(yīng)用較多的商業(yè)軟件 Datadog，以及 Splunk 等產(chǎn)品。下圖展示了 FreeWheel 目前監(jiān)控體系（包括統(tǒng)一報警、事件收集、分析通知平臺）的架構(gòu)圖：

左側(cè)的所有監(jiān)控平臺和日志系統(tǒng)都是 FreeWheel 現(xiàn)在的監(jiān)控數(shù)據(jù)源，通過公司的郵件系統(tǒng)和 Slack 消息系統(tǒng)進行集成和整合，運維團隊（主要是 NOC – Network Operation Center 團隊）重點關(guān)注這兩個渠道的報警信息。NOC 系統(tǒng)內(nèi)部有數(shù)據(jù)可以進行訓(xùn)練，會預(yù)先設(shè)定某些條件，對報警消息的主題或內(nèi)容做標識，這樣 NOC 就能通過識別標識，進而觸發(fā)圖中右側(cè)的 OpsGenie 自動化平臺。OpsGenie 提供豐富的接口，能夠?qū)崿F(xiàn)多種自動化流程和動作，例如發(fā)送即時消息、短信甚至直接打電話。這樣，嚴重的報警或事件就能第一時間進行通知并及時得到響應(yīng)。

在該體系中，Splunk 和 ELK 可以在一定程度上做機器學(xué)習(xí)，基于大量的 Metrics 和日志在內(nèi)部建立一些數(shù)據(jù)模型并進行訓(xùn)練，生成規(guī)則協(xié)助分析并解決問題，但它們并不能覆蓋所有的數(shù)據(jù)源。此外，由于報警來源太多，各種數(shù)據(jù)格式不規(guī)整，在加上監(jiān)控的頻度也不一樣，報警有快有慢，一個問題可能引發(fā)很多報警，雖然郵件系統(tǒng)和 Slack 對報警消息實施了初步的整合和歸集，但如圖所示，由于智能化應(yīng)用程度有限，它們并未能大幅消減報警風(fēng)暴，并提供有益的關(guān)聯(lián)分析等功能，這樣運維人員分析和定位問題的效率并未大幅提升。

為了解決上述問題，FreeWheel 計劃對目前的監(jiān)控體系進行優(yōu)化，主要是引入 MoogSoft 來替換上圖中郵件系統(tǒng)和 Slack 所占據(jù)的中心位置，使后兩者回歸通知渠道的本職功能，而 MoogSoft 將進行：

• 將監(jiān)控平臺集中化和統(tǒng)一化，規(guī)整來自各種數(shù)據(jù)源的報警信息，使之更利于理解和分析，包括機器學(xué)習(xí)技術(shù)的應(yīng)用；

• 匯總、關(guān)聯(lián)報警信息，比如根據(jù)時間、區(qū)域、主題等維度的相關(guān)性對報警信息進行歸類和壓縮等；

• 過濾、分析數(shù)據(jù)進行知識學(xué)習(xí)，比如根據(jù)過往處理的報警事件相關(guān)信息，通過機器學(xué)習(xí)建立模型（包括特定報警事件中報警消息的模式等），以用于識別未來發(fā)生的類似報警事件。

經(jīng)過如上處理，各個數(shù)據(jù)源關(guān)于同一個事件的多個報警通過機器學(xué)習(xí)的模型分析匯聚成一個報警，避免了報警風(fēng)暴造成的困擾，使運維人員可以快速準確地定位到問題。OpsGenie 再觸發(fā)流程及時通知相關(guān)技術(shù)響應(yīng)人員，處理報警的效率就會很高。這樣優(yōu)化后的監(jiān)控體系架構(gòu)如下圖所示：

此外，在分析報警事件的過程中，基于相關(guān)性的分析，Moogsoft 不僅可以為運維人員提示與當前事件類似的過往事件，還可以通過時序分析提示當前事件所聚合的成百上千報警信息中可能的根源（root cause）報警信息，以協(xié)助加速問題的分析與解決。在處理完某個報警事件后，運維人員還可以將所積累的知識標注和關(guān)聯(lián)到系統(tǒng)中，以支持系統(tǒng)模型的不斷提升。

在監(jiān)控層面，如上文所述，FreeWheel 另一個挑戰(zhàn)是期望在直播賽事過程中先于客戶發(fā)現(xiàn)問題。這就需要能做到實時監(jiān)控并有效預(yù)警。作為上述監(jiān)控體系的補充和增強，FreeWheel 的監(jiān)控團隊還構(gòu)建了集中統(tǒng)一、時效性更高的監(jiān)控平臺 PQM，如下圖所示：

該平臺采樣間隔粒度更細，數(shù)據(jù)庫選用專為實時監(jiān)控設(shè)計的時序數(shù)據(jù)庫，也引入了 Kubernetes 原生的 Prometheus 監(jiān)控平臺來采集數(shù)據(jù)。在報警爆發(fā)以后，監(jiān)控平臺可以自動做出響應(yīng)，同時這套監(jiān)控系統(tǒng)還會基于非實時流量對業(yè)務(wù)數(shù)據(jù)做異常流量的自動檢測，再結(jié)合上述監(jiān)控體系智能化技術(shù)進行輔助決策，就可以很好地定位問題甚至預(yù)防問題。

在監(jiān)控層面之上，FreeWheel 也探索使用 AIOps 技術(shù)協(xié)助解決一些業(yè)務(wù)挑戰(zhàn)，比如欺詐和無效流量（IVT）的識別。在機器學(xué)習(xí)方面，通常需要一個數(shù)據(jù)集合來訓(xùn)練模型，然后才能對其進行測試，但是建立一個準確的、表示復(fù)雜機器人流量的數(shù)據(jù)集幾乎是不可能的，也是非常昂貴的。但廣告決策平臺的特殊定位，使得 FreeWheel 有機會解決數(shù)字廣告生態(tài)系統(tǒng)中無效流量的問題。具體而言，應(yīng)用機器學(xué)習(xí)理解最終用戶的行為，形成模式構(gòu)建模版，之后用聚類算法來模擬流量行為，這樣可以識別突發(fā)流量，對流量進行有效的評估，更好地檢測欺詐行為。FreeWheel 已開始進行初步的探索，結(jié)合廣告服務(wù)器的事務(wù)日志數(shù)據(jù)進行分析，幫助做出有關(guān) IVT 檢測和刪除的有效決策。

在監(jiān)控層面之下的基礎(chǔ)設(shè)施，FreeWheel 也探索使用 AIOps 技術(shù)來優(yōu)化相關(guān)的運維工作。比如針對網(wǎng)絡(luò)基礎(chǔ)架構(gòu)所面臨的挑戰(zhàn)，FreeWheel 在積極的實施 SD-WAN 技術(shù)解決方案，該技術(shù)允許針對數(shù)據(jù)中心間流量的數(shù)據(jù)包進行動態(tài)重新路由，其中的核心技術(shù) First-Packet iQ 可以根據(jù)某個應(yīng)用的首個數(shù)據(jù)包進行應(yīng)用識別，使其遠優(yōu)于目前典型的數(shù)據(jù)包檢測以及端口檢測方法。這種智能化的技術(shù)有助于我們更快地識別惡意流量，減少被攻擊的可能性，并優(yōu)化基礎(chǔ)設(shè)施的使用效率，更好的保障關(guān)鍵業(yè)務(wù)的運行，也減輕了基礎(chǔ)設(shè)施運維的壓力和風(fēng)險。

總體而言，在逐漸探索采用 AIOps 技術(shù)之后，FreeWheel 團隊能明顯感覺到報警繁多的痛點得到了極大的緩解，一些智能決策的支持也讓團隊的效率明顯提升，尤其能幫助運維團隊快速有效地定位、識別、解決問題，降低 MTTR。對于 FreeWheel 這樣業(yè)務(wù)分布在全球的公司來說，AIOps 平臺和工作流程的優(yōu)化能切實解決很多問題，具備很好的應(yīng)用前景。

如何看待 DevOps，SRE 和 AIOps

FreeWheel 的運維團隊經(jīng)歷過 DevOps, SRE 和 AIOps 的各個發(fā)展階段，轉(zhuǎn)型過程中也才踩過一些坑，對這幾種運維實踐有比較深的體會。

總體而言，DevOps 是一種思想的轉(zhuǎn)變和進化，涉及到撰寫代碼、測試、發(fā)布、上線各個環(huán)節(jié)，以及相應(yīng)技術(shù)手段的推進和落地，目的是打通開發(fā)和運維之間的邊界，更關(guān)注從開發(fā)到生產(chǎn)之間的流程如何快速迭代，從而達到縮短周期并提高產(chǎn)品質(zhì)量的目的。

SRE 更關(guān)注運維階段，強調(diào)用工程的思想和手段來看待和解決運維問題，包括監(jiān)控、報警、容量評估、系統(tǒng)擴展等，以及如何早期介入產(chǎn)品研發(fā)的架構(gòu)決策，以更好地保障在線產(chǎn)品 SLA 的目標達成。

AIOps 則貫徹整個運維領(lǐng)域，從硬件資源規(guī)劃、管理、實施，操作系統(tǒng)安裝配置，到中間件及應(yīng)用軟件的上線、變更，以及后續(xù)的監(jiān)控、報警、維護、優(yōu)化等各方面都需要關(guān)注。基于海量的信息源以及大數(shù)據(jù)分析技術(shù)，結(jié)合大量運維專家的豐富經(jīng)驗及人工智能算法，在各個領(lǐng)域、各個階段以更自動化、更智能化的方式推動運維工作的變革。

關(guān)于 AIOps 實踐的建議

AIOps 的概念歸根結(jié)底是對運維規(guī)則的智能化發(fā)現(xiàn)與實施，即將人工經(jīng)驗總結(jié)的過程變?yōu)樽詣訉W(xué)習(xí)及輸出實施的過程，其目標是利用大數(shù)據(jù)、人工智能及周邊技術(shù)實現(xiàn)對運維效率、質(zhì)量、成本等方面的優(yōu)化和提升。

AIOps 是運維領(lǐng)域發(fā)展的必然方向，凡是具有上述需求的企業(yè)，包括互聯(lián)網(wǎng)企業(yè)以及數(shù)字化轉(zhuǎn)型中的生產(chǎn)制造企業(yè)等，都可以考慮嘗試 AIOps。FreeWheel 運維團隊向 AIOps 演進是源自于自身的需求，實踐過程中雖然踩過不少坑，但也確實解決了很多問題。對于決心實踐 AIOps 的團隊或企業(yè)，FreeWheel 基于自己切身的經(jīng)歷給出了一些建議：

標準化是基礎(chǔ)。比如報警的標準化和規(guī)范化，就是 AIOps 的重要基礎(chǔ)，否則后續(xù)的工作代價就很大。最好能有架構(gòu)師團隊從架構(gòu)決策層面整體把控技術(shù)平臺的選型、走向以及相關(guān)的標準規(guī)范，并通過強有力的治理（Governance）來統(tǒng)一協(xié)調(diào)，推進項目，做好平衡。

技術(shù)選型很關(guān)鍵。實施 AIOps，既可以選用相對成熟的商業(yè)化工具，也可以考慮自主研發(fā)，關(guān)鍵是結(jié)合企業(yè)自身的業(yè)務(wù)特點和能力，注意投入產(chǎn)出比和時效性。

找準切入點。如 FreeWheel 選擇監(jiān)控體系層面切入，因為數(shù)據(jù)最豐富、痛點最突出、價值最彰顯。同時 FreeWheel 也選擇在業(yè)務(wù)層面、基礎(chǔ)設(shè)施層面的一些點狀問題（如 IVT、SD-WAN）上探索實踐。這些切入點的選擇需要結(jié)合企業(yè)的特定情況，爭取達成好的示范效應(yīng)，同時培養(yǎng)團隊，夯實技術(shù)支撐體系，為后續(xù)的進一步推廣應(yīng)用打下基礎(chǔ)。

人員從業(yè)經(jīng)驗很重要。在團隊方面，人員的素質(zhì)和經(jīng)歷很重要，只有在實踐中切實踩過坑，解決過實際問題，才能對技術(shù)、流程、進度有深入理解和切身體會。

希望正在看文章的你也能從 FreeWheel 的經(jīng)歷中吸取經(jīng)驗，結(jié)合自己的實際情況將運維工作做得更好。

作者簡介

劉顯，Director, FreeWheel Operations, APAC。17 年 IT 領(lǐng)域從業(yè)經(jīng)驗，涉獵開源生態(tài)系統(tǒng)，高性能、高可用技術(shù)解決方案，對大數(shù)據(jù)、容器化、云計算等技術(shù)領(lǐng)域有非常濃厚的興趣。目前帶領(lǐng) FreeWheel 北京運維團隊在 DevOps、SRE 及 AIOps 方向進行相關(guān)的探索和實踐。

楊順祥 ，VP, FreeWheel Operations, APAC。多年 IT 從業(yè)經(jīng)驗，先后服務(wù)于 IBM 及中國平安集團，參與負責云平臺和行業(yè)解決方案的研發(fā)、實施和運維工作。2018 年 11 月加入 FreeWheel，負責亞太地區(qū)運維團隊相關(guān)工作。

總結(jié)

以上是生活随笔為你收集整理的转向AIOps之前，你应该做好哪些准备？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。