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

1

FreeWheel 運維團隊的演進

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

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

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

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

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

2

哪些痛點促進團隊轉向 AIOps

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

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

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

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

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

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

3

FreeWheel 的 AIOps 平臺建設

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4

如何看待 DevOps，SRE 和 AIOps

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

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

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

AIOps 則貫徹整個運維領域，從硬件資源規(guī)劃、管理、實施，操作系統安裝配置，到中間件及應用軟件的上線、變更，以及后續(xù)的監(jiān)控、報警、維護、優(yōu)化等各方面都需要關注?；诤Ａ康男畔⒃匆约按髷祿治黾夹g，結合大量運維專家的豐富經驗及人工智能算法，在各個領域、各個階段以更自動化、更智能化的方式推動運維工作的變革。

5

關于 AIOps 實踐的建議

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

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

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

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

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

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

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