FreeWheel創建於2007年，總部位於美國硅谷，主要業務是提供互聯網視頻廣告投放、監測、預測、增值等解決方案。經過十多年的發展，FreeWheel的業務量不斷增長，系統架構日趨複雜，公司運維團隊面臨的挑戰也越來越大。FreeWheel的運維團隊經歷了從最初的小規模傳統運維，到按照職能細分的運維團隊組織模式，再到最近幾年轉換DevOps思想，進而到SRE的演變，目前正在探索實踐AIOps。作爲積極擁抱新技術和新思想的團隊，FreeWheel結合自身的痛點對團隊、工具和流程進行持續改進，其轉向AIOps的例子十分典型，他們踩過的一些坑對想要採用AIOps的企業和團隊也很有借鑑意義。
FreeWheel運維團隊的演進
從公司2007年創立到現在，FreeWheel運維團隊的發展大致經歷了以下幾個階段：
- 傳統運維。公司成立初期業務量較小，系統的複雜性也不高，各方面挑戰都不大。此時運維團隊規模很小，各項工作基本都是大家一起完成，包括網絡規劃、硬件安裝、軟件部署、監控報警等。日常管理工作通常是通過直接執行命令或編寫簡單腳本來完成。
- 運維職責分化。隨着FreeWheel的業務快速成長，產品線不斷擴展，系統模塊數量及相互間關聯依賴的複雜度隨之增加，基礎設施也變得越來越龐大，整體運維工作變得非常複雜，運維團隊面臨的挑戰直線上升。在這段時期FreeWheel將整個全球運維團隊進行細分，包括系統運維、網絡運維、數據庫運維以及產品運維。產品運維更側重在產品部署、服務運行等產品環境，跟軟件開發人員的溝通交流更爲緊密，通常會結合自身的運維經驗和需求提出建議，協助設計和搭建監控、報警系統，從而使FreeWheel業務產品能夠更好、更穩定地運行。這個階段運維團隊的組織結構變得更加清晰，各運維小組的職責變得更加明確。
- DevOps。FreeWheel有一段時間成立了專門的DevOps團隊，負責建設從代碼管理、打包測試、上線部署到配置管理、報警監控的一整套管道流程和工具平臺，力爭打破開發和運維之間的邊界，實現更好、更快的代碼上線及服務變更。但在具體實踐中，由於該團隊所招聘的人員運維經驗偏少，對系統上線和監控的理解不夠深入，同時和衆多的開發團隊之間也難以保障充分溝通，導致開發和運維兩方面的具體需求都得不到快速有效的響應。這一階段FreeWheel走過了一些彎路，值得反思。
- SRE。SRE的角色定義在Google首先建立和推行，FreeWheel的產品運維組在過去一年中也進行了相關實踐，結合自身現實情況，嘗試使用工程的思想和手段來審視與改進生產環境的運維工作，並儘可能推動運維自動化。具體工作包括和產品開發團隊一起梳理並建立CD（持續部署）流程和平臺，對業務和產品進行實時監控，關注報警以及系統的穩定性、可用性，明確定義SLO（Service Level Objective），確保對用戶承諾的SLA（Service Level Agreement）。
哪些痛點促進團隊轉向AIOps
在FreeWheel的發展過程中，業務和技術層面的多個痛點促使運維團隊嘗試從運維智能化的發展趨勢中尋求有效的解決方案。例如：
- FreeWheel一個突出的業務模式是在直播賽事中投放廣告。近年來公司服務的直播源大幅增加，從用戶過來的廣告數量包括流量峯值都難以預測，這對廣告服務器以及後端的技術平臺和架構的可擴展性和穩定性都提出了很高的要求。同時，直播賽事中廣告播放的時間點和時長也是不可預測的，出問題的時間可能短至幾秒甚至幾毫秒，但對客戶的即時影響很大，這時要捕捉到問題並及時解決故障的難度非常高。依靠傳統的人工操作及簡單自動化已難以有效應對上述的運維挑戰。
- 在FreeWheel所聚焦的廣告領域，另一個極具代表性的痛點來自於欺詐和無效流量（IVT）對數字廣告生態系統所構成的重大威脅。所謂“道高一尺，魔高一丈”，IVT的不斷演變使得對應的解決方案不可能簡單的一蹴而就，而需要具備持續性和智能化的特點，包括持續收集和分析流量來源、行爲方式以及進行特徵理解，以更好地解決IVT這一威脅。
- 同時，隨着FreeWheel業務系統越來越複雜，基礎設施各技術層面都出現了不同的挑戰。例如監控層面，就出現監控系統多樣化，報警條目和數據海量化，但同時報警信息不規範，各類報警郵件的主題和內容都不統一，一個問題經常引發多條報警。在這種情況下，如何在海量的報警消息中甄別有效關鍵信息，並在報警風暴的壓力下快速準確地定位問題解決問題，成爲運維團隊所面臨的巨大挑戰。
- 同樣在技術層面，如何對現有基礎設施的使用進行有效的優化，以支撐業務的穩定運行，也是運維所面臨的難題。比如在網絡層面，業務量增大帶來流量增多、類型複雜，同時雲戰略的推行也使得雲端資源的訪問日趨複雜，網絡運維團隊需要智能化的手段來有效識別流量，並做出靈活的判斷和優化處理，比如給優先級高的流量預留足夠的帶寬，以支撐各關鍵類型業務的順利開展。
隨着近年來人工智能技術的快速發展，以及各領域運維數據和經驗的積累爲智能化運維提供數據基礎，AIOps正成爲運維的下一個發展趨勢。FreeWheel希望藉助這個趨勢解決業務和技術層面所面臨的各種挑戰，進一步提升運維水平，同時推進運維團隊的成長，適應公司業務、技術架構以及整體團隊發展的需要。
FreeWheel的AIOps平臺建設
FreeWheel的AIOps平臺目前還在構建過程中，如上文所述在某些領域已經開始了探索性的工作，同時也逐步規劃好未來的演進方向。
上文提到，監控層面的挑戰是FreeWheel探索AIOps的重要驅動力之一，也是重點考慮的切入點。由於業務的複雜性和快速演進，FreeWheel監控系統的報警來源變得非常多樣。單就監控系統而言，FreeWheel使用了流行的Nagios和Zabbix以及開源的ELK技術棧，也使用了在雲端應用較多的商業軟件Datadog，以及Splunk等產品。下圖展示了FreeWheel目前監控體系（包括統一報警、事件收集、分析通知平臺）的架構圖：
左側的所有監控平臺和日誌系統都是FreeWheel現在的監控數據源，通過公司的郵件系統和Slack消息系統進行集成和整合，運維團隊（主要是NOC – Network Operation Center團隊）重點關注這兩個渠道的報警信息。NOC系統內部有數據可以進行訓練，會預先設定某些條件，對報警消息的主題或內容做標識，這樣NOC就能通過識別標識，進而觸發圖中右側的OpsGenie自動化平臺。OpsGenie提供豐富的接口，能夠實現多種自動化流程和動作，例如發送即時消息、短信甚至直接打電話。這樣，嚴重的報警或事件就能第一時間進行通知並及時得到響應。
在該體系中，Splunk和ELK可以在一定程度上做機器學習，基於大量的Metrics和日誌在內部建立一些數據模型並進行訓練，生成規則協助分析並解決問題，但它們並不能覆蓋所有的數據源。此外，由於報警來源太多，各種數據格式不規整，在加上監控的頻度也不一樣，報警有快有慢，一個問題可能引發很多報警，雖然郵件系統和Slack對報警消息實施了初步的整合和歸集，但如圖所示，由於智能化應用程度有限，它們並未能大幅消減報警風暴，並提供有益的關聯分析等功能，這樣運維人員分析和定位問題的效率並未大幅提升。
爲了解決上述問題，FreeWheel計劃對目前的監控體系進行優化，主要是引入MoogSoft 來替換上圖中郵件系統和Slack所佔據的中心位置，使後兩者迴歸通知渠道的本職功能，而MoogSoft將進行：
- 將監控平臺集中化和統一化，規整來自各種數據源的報警信息，使之更利於理解和分析，包括機器學習技術的應用；
- 彙總、關聯報警信息，比如根據時間、區域、主題等維度的相關性對報警信息進行歸類和壓縮等；
- 過濾、分析數據進行知識學習，比如根據過往處理的報警事件相關信息，通過機器學習建立模型（包括特定報警事件中報警消息的模式等），以用於識別未來發生的類似報警事件。
經過如上處理，各個數據源關於同一個事件的多個報警通過機器學習的模型分析匯聚成一個報警，避免了報警風暴造成的困擾，使運維人員可以快速準確地定位到問題。OpsGenie再觸發流程及時通知相關技術響應人員，處理報警的效率就會很高。這樣優化後的監控體系架構如下圖所示：
此外，在分析報警事件的過程中，基於相關性的分析，Moogsoft不僅可以爲運維人員提示與當前事件類似的過往事件，還可以通過時序分析提示當前事件所聚合的成百上千報警信息中可能的根源（root cause）報警信息，以協助加速問題的分析與解決。在處理完某個報警事件後，運維人員還可以將所積累的知識標註和關聯到系統中，以支持系統模型的不斷提升。
在監控層面，如上文所述，FreeWheel另一個挑戰是期望在直播賽事過程中先於客戶發現問題。這就需要能做到實時監控並有效預警。作爲上述監控體系的補充和增強，FreeWheel的監控團隊還構建了集中統一、時效性更高的監控平臺PQM，如下圖所示：
該平臺採樣間隔粒度更細，數據庫選用專爲實時監控設計的時序數據庫，也引入了Kubernetes原生的Prometheus監控平臺來採集數據。在報警爆發以後，監控平臺可以自動做出響應，同時這套監控系統還會基於非實時流量對業務數據做異常流量的自動檢測，再結合上述監控體系智能化技術進行輔助決策，就可以很好地定位問題甚至預防問題。
在監控層面之上，FreeWheel也探索使用AIOps技術協助解決一些業務挑戰，比如欺詐和無效流量（IVT）的識別。在機器學習方面，通常需要一個數據集合來訓練模型，然後才能對其進行測試，但是建立一個準確的、表示複雜機器人流量的數據集幾乎是不可能的，也是非常昂貴的。但廣告決策平臺的特殊定位，使得FreeWheel有機會解決數字廣告生態系統中無效流量的問題。具體而言，應用機器學習理解最終用戶的行爲，形成模式構建模版，之後用聚類算法來模擬流量行爲，這樣可以識別突發流量，對流量進行有效的評估，更好地檢測欺詐行爲。FreeWheel已開始進行初步的探索，結合廣告服務器的事務日誌數據進行分析，幫助做出有關IVT檢測和刪除的有效決策。
在監控層面之下的基礎設施，FreeWheel也探索使用AIOps技術來優化相關的運維工作。比如針對網絡基礎架構所面臨的挑戰，FreeWheel在積極的實施SD-WAN技術解決方案，該技術允許針對數據中心間流量的數據包進行動態重新路由，其中的核心技術 First-Packet iQ可以根據某個應用的首個數據包進行應用識別，使其遠優於目前典型的數據包檢測以及端口檢測方法。這種智能化的技術有助於我們更快地識別惡意流量，減少被攻擊的可能性，並優化基礎設施的使用效率，更好的保障關鍵業務的運行，也減輕了基礎設施運維的壓力和風險。
總體而言，在逐漸探索採用AIOps技術之後，FreeWheel團隊能明顯感覺到報警繁多的痛點得到了極大的緩解，一些智能決策的支持也讓團隊的效率明顯提升，尤其能幫助運維團隊快速有效地定位、識別、解決問題，降低MTTR。對於FreeWheel這樣業務分佈在全球的公司來說，AIOps平臺和工作流程的優化能切實解決很多問題，具備很好的應用前景。
如何看待DevOps，SRE和AIOps
FreeWheel的運維團隊經歷過DevOps, SRE和AIOps的各個發展階段，轉型過程中也才踩過一些坑，對這幾種運維實踐有比較深的體會。
總體而言，DevOps是一種思想的轉變和進化，涉及到撰寫代碼、測試、發佈、上線各個環節，以及相應技術手段的推進和落地，目的是打通開發和運維之間的邊界，更關注從開發到生產之間的流程如何快速迭代，從而達到縮短週期並提高產品質量的目的。
SRE更關注運維階段，強調用工程的思想和手段來看待和解決運維問題，包括監控、報警、容量評估、系統擴展等，以及如何早期介入產品研發的架構決策，以更好地保障在線產品SLA的目標達成。
AIOps則貫徹整個運維領域，從硬件資源規劃、管理、實施，操作系統安裝配置，到中間件及應用軟件的上線、變更，以及後續的監控、報警、維護、優化等各方面都需要關注。基於海量的信息源以及大數據分析技術，結合大量運維專家的豐富經驗及人工智能算法，在各個領域、各個階段以更自動化、更智能化的方式推動運維工作的變革。
關於AIOps實踐的建議
AIOps的概念歸根結底是對運維規則的智能化發現與實施，即將人工經驗總結的過程變爲自動學習及輸出實施的過程，其目標是利用大數據、人工智能及周邊技術實現對運維效率、質量、成本等方面的優化和提升。
AIOps是運維領域發展的必然方向，凡是具有上述需求的企業，包括互聯網企業以及數字化轉型中的生產製造企業等，都可以考慮嘗試AIOps。FreeWheel運維團隊向AIOps演進是源自於自身的需求，實踐過程中雖然踩過不少坑，但也確實解決了很多問題。對於決心實踐AIOps的團隊或企業，FreeWheel基於自己切身的經歷給出了一些建議：
- 標準化是基礎。比如報警的標準化和規範化，就是AIOps的重要基礎，否則後續的工作代價就很大。最好能有架構師團隊從架構決策層面整體把控技術平臺的選型、走向以及相關的標準規範，並通過強有力的治理（Governance）來統一協調，推進項目，做好平衡。
- 技術選型很關鍵。實施AIOps，既可以選用相對成熟的商業化工具，也可以考慮自主研發，關鍵是結合企業自身的業務特點和能力，注意投入產出比和時效性。
- 找準切入點。如FreeWheel選擇監控體系層面切入，因爲數據最豐富、痛點最突出、價值最彰顯。同時FreeWheel也選擇在業務層面、基礎設施層面的一些點狀問題（如IVT、SD-WAN）上探索實踐。這些切入點的選擇需要結合企業的特定情況，爭取達成好的示範效應，同時培養團隊，夯實技術支撐體系，爲後續的進一步推廣應用打下基礎。
- 人員從業經驗很重要。在團隊方面，人員的素質和經歷很重要，只有在實踐中切實踩過坑，解決過實際問題，才能對技術、流程、進度有深入理解和切身體會。
希望正在看文章的你也能從FreeWheel的經歷中吸取經驗，結合自己的實際情況將運維工作做得更好。
作者簡介
劉顯：Director, FreeWheel Operations, APAC。17年IT領域從業經驗，涉獵開源生態系統，高性能、高可用技術解決方案，對大數據、容器化、雲計算等技術領域有非常濃厚的興趣。目前帶領FreeWheel北京運維團隊在DevOps、SRE及AIOps方向進行相關的探索和實踐。
楊順祥 ：VP, FreeWheel Operations, APAC。多年IT從業經驗，先後服務於IBM及中國平安集團，參與負責雲平臺和行業解決方案的研發、實施和運維工作。2018年11月加入FreeWheel，負責亞太地區運維團隊相關工作。