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

　　1

　　FreeWheel 運維團隊的演進

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

　　傳統運維。公司成立初期業務量較小，系統的複雜性也不高，各方面挑戰都不大。此時運維團隊規模很小，各項工作基本都是大家一起完成，包括網路規劃、硬體安裝、軟體部署、監控報警等。日常管理工作通常是通過直接執行命令或編寫簡單指令碼來完成。

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

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

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

　　2

　　哪些痛點促進團隊轉向 AIOps

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

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

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

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

　　同樣在技術層面，如何對現有基礎設施的使用進行有效的優化，以支撐業務的穩定執行，也是運維所面臨的難題。比如在網路層面，業務量增大帶來流量增多、型別複雜，同時雲戰略的推行也使得雲端資源的訪問日趨複雜，網路運維團隊需要智慧化的手段來有效識別流量，並做出靈活的判斷和優化處理，比如給優先順序高的流量預留足夠的頻寬，以支撐各關鍵型別業務的順利開展。

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

　　3

　　FreeWheel 的 AIOps 平臺建設

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

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

　　左側的所有監控平臺和日誌系統都是 FreeWheel 現在的監控資料來源，通過公司的郵件系統和 Slack 訊息系統進行整合和整合，運維團隊(主要是 NOC – Network Operation Center 團隊)重點關注這兩個渠道的報警資訊。NOC 系統內部有資料可以進行訓練，會預先設定某些條件，對報警訊息的主題或內容做標識，這樣 NOC 就能通過識別標識，進而觸發圖中右側的 OpsGenie 自動化平臺。OpsGenie 提供豐富的介面，能夠實現多種自動化流程和動作，例如傳送即時訊息、簡訊甚至直接打電話。這樣，嚴重的報警或事件就能第一時間進行通知並及時得到響應。　　鄭州婦科醫院:http://yyk.39.net/zz3/zonghe/1d426.html/鄭州哪家醫院看婦科好:http://yyk.39.net/zz3/zonghe/1d426.html/鄭州無痛人流多少錢:http://yyk.39.net/zz3/zonghe/1d426.html/鄭州同濟婦科醫院:http://yyk.39.net/zz3/zonghe/1d426.html/