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

1

FreeWheel 運維團隊的演進

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

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

運維職責(zé)分化。隨著 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)變得更加清晰，各運維小組的職責(zé)變得更加明確。

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

SRE。SRE 的角色定義在 Google 首先建立和推行，F(xiàn)reeWheel 的產(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）。

2

哪些痛點促進團隊轉(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ā)展的需要。

3

FreeWheel 的 AIOps 平臺建設(shè)

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

上文提到，監(jiān)控層面的挑戰(zhàn)是 FreeWheel 探索 AIOps 的重要驅(qū)動力之一，也是重點考慮的切入點。由于業(yè)務(wù)的復(fù)雜性和快速演進，F(xiàn)reeWheel 監(jiān)控系統(tǒng)的報警來源變得非常多樣。單就監(jiān)控系統(tǒng)而言，F(xiàn)reeWheel 使用了流行的 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)分析等功能，這樣運維人員分析和定位問題的效率并未大幅提升。

為了解決上述問題，F(xiàn)reeWheel 計劃對目前的監(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 不僅可以為運維人員提示與當(dāng)前事件類似的過往事件，還可以通過時序分析提示當(dāng)前事件所聚合的成百上千報警信息中可能的根源（root cause）報警信息，以協(xié)助加速問題的分析與解決。在處理完某個報警事件后，運維人員還可以將所積累的知識標注和關(guān)聯(lián)到系統(tǒng)中，以支持系統(tǒng)模型的不斷提升。

在監(jiān)控層面，如上文所述，F(xiàn)reeWheel 另一個挑戰(zhàn)是期望在直播賽事過程中先于客戶發(fā)現(xiàn)問題。這就需要能做到實時監(jiān)控并有效預(yù)警。作為上述監(jiān)控體系的補充和增強，F(xiàn)reeWheel 的監(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)控層面之上，F(xiàn)reeWheel 也探索使用 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è)施，F(xiàn)reeWheel 也探索使用 AIOps 技術(shù)來優(yōu)化相關(guān)的運維工作。比如針對網(wǎng)絡(luò)基礎(chǔ)架構(gòu)所面臨的挑戰(zhàn)，F(xiàn)reeWheel 在積極的實施 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ù)之后，F(xiàn)reeWheel 團隊能明顯感覺到報警繁多的痛點得到了極大的緩解，一些智能決策的支持也讓團隊的效率明顯提升，尤其能幫助運維團隊快速有效地定位、識別、解決問題，降低 MTTR。對于 FreeWheel 這樣業(yè)務(wù)分布在全球的公司來說，AIOps 平臺和工作流程的優(yōu)化能切實解決很多問題，具備很好的應(yīng)用前景。

4

如何看待 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)域、各個階段以更自動化、更智能化的方式推動運維工作的變革。

5

關(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è)，F(xiàn)reeWheel 基于自己切身的經(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é)合自己的實際情況將運維工作做得更好。