DevOps + Machine Learning = MLOps ?

前言：近日，企業智慧化轉型開源社群---星策社群組織了DevOps和MLOps的Meetup，是把DevOps和MLOps拉在一起進行分享的社群活動，筆者作為該活動的組織者，寫點東西來說下這兩者的關係和異同，並做回顧。

什麼是DevOps？

最近看好友喬梁（江湖人稱喬幫主）的朋友圈，他說他曾經在2012年QCon大會DevOps Track上預言“過去十年敏捷從熱詞成為市場主流，未來十年DevOps將成為市場的主流”，如今是2022年了，他的預言成為現實，DevOps基本上已經成為每個技術企業、每個工程師都耳熟能詳的一個詞了，也有很多企業已經在進行或多或少的DevOps實踐推行了。

那麼什麼是DevOps？

摘自百度百科上的定義如下：

DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程式/軟體工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。

它是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體交付”和“架構變更”的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。

它的出現是由於軟體行業日益清晰地認識到：為了按時交付軟體產品和服務，開發和運維工作必須緊密合作。

我總結一下，DevOps有如下三點是做的非常出色的。

1. 打破Dev和Ops之間的部門牆

在傳統研發模式下，Dev（即軟體開發人員）和Ops（IT運維人員）之間存在一個牆導致協作不順暢，我們來看看Google SRE團隊對DevOps的解讀（Google SRE團隊認為是SRE是DevOps的一種實現），我擷取其影片（http://www.youtube.com/watch?v=uTEL8Ff1Zvk&t=112s）中幾個圖來解讀一下。

在傳統研發模式下，Developers（軟體研發人員）和Operators（IT運維人員）分屬於不同的團隊，兩者之間有一個“部門牆”（專業術語叫Silos）。Dev關心Agility即產品功能的快速迭代，Ops更關心Stability，即系統的穩定性。從部門分工和崗位職責來看，Dev希望更多更快的Code Change，Ops則希望更少的程式碼修改，因為在傳統運維模式下，系統沒人動則出事概率小，而實際上很大概率的線上問題都是因為上線引起的，所以對於運維同學來說，線上出問題的第一反應是誰剛才上線了，是否可以無腦回滾來解決問題。

軟體研發人員做好開發和測試之後，把生成好的軟體包，扔過“牆”去，然後就交給IT運維團隊負責了。這個移交過程在某些公司做的比較規範，會設定一定的准入條件門檻，例如需要清晰完整的測試報告、完整詳細的上線文件（包括如何回滾）等，基本上都是為了運維方便，這種模式下研發不太關心線上穩定性。

IT運維團隊在接受這些軟體包之後，部署到線上環境裡面。他們負責這些系統的穩定性執行，可能會採用小流量到全流量部署，多地多機房分散式部署等，來提升系統的穩定性和健壯性。線上服務的穩定性，包括常見的幾個9，往往是運維同學的KPI。

DevOps首先是打破了這個牆，促使軟體開發人員和IT運維人員更好的協作，因此產生了很多落地的實踐，包括團隊組織上，例如更小的敏捷團隊、開發運維一體化；程式碼和配置共享，例如內部開源、Configuration As a Code；運維任務共享，例如研發也OnCall（即線上運維值班，第一時間處理業務報警和事故）等等。

2. 把自動化流水線擴充套件到了運維環節

包括Continuous Integration（簡稱CI）和Continuous Deployment（簡稱CD）。在DevOps之前的工程實踐為敏捷，往往只有Continuous Integration，只覆蓋了編碼，編譯，測試，打包環節，並沒有覆蓋部署環節。

這是非常著名的DevOps雙環流水線模型，左半邊集中在軟體研發階段，從Plan（需求定義），到Code（編寫程式碼），然後到Build（編譯），再通過Test（測試），最後生成軟體包，形成Release（釋出）。

右半邊集中在軟體部署階段，從獲得軟體包開始，Deploy（部署），然後Operate（線上運維），再到Monitor（監控線上服務）。

兩個環構成DevOps的完整流水線，這個流水線的運轉是持續的，左半邊一般稱之為持續整合（Continuous Integration），右半邊一般稱之為持續部署（Continuous Deployment）。顯然這個流水線運轉的速度說明了該研發運維團隊的工程能力。當然，是需要在保證一定質量的前提下的快。也不是部署頻率越多越快就越好，需要每次迭代都是朝著提升業務價值的目標，不斷逼近理想值的迭代。

DevOps業內的有名的調研報告《State of DevOps 2021》（http://cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report）

中指出，Elite團隊（即在DevOps領域內做的出色的團隊）能做到按需部署（每天可以做很多次部署），而一般的團隊部署週期在一週或者一個月左右，再差一點的團隊部署週期在一個月到半年左右，最差的團隊部署週期在半年以上。

3. 利用工具來支援自動化，並形成了繁榮的工具生態

這只是我在網際網路上隨機找的一個圖，類似的圖還有很多種，特點是DevOps的流水線上每個環節都有多個工具在支援，在協作。這裡面有開源的軟體，例如git，gitlab，gradle，jenkins，也有商業的軟體和服務，包括Azure和AWS等。

DevOps的推廣和運營如此成功，之後又有很多類似的名詞產生出來。包括DevSecOps，GitOps，DataOps，ModelOps，AIOps，NoOps，MLOps等等。其中AIOps是指用AI的能力提升傳統運維的能力，包括利用機器學習來進行流量預測來幫助進行流量排程，利用機器學習來進行硬體壽命預估來幫助進行硬體成本控制等。NoOps指的是減少業務的運維操作，把業務系統的運維操作下沉到底層的基礎設施的運維上。

其他各種Ops都是各種Operation（Ops）的自動化，都包含相應的流程和工具（即通過工具自動化來完成所需要流程），Ops都包含相應的角色，不同點是具體哪個領域內，哪些任務的自動化，流程、工具、角色各異。

例如MLOps就是在機器學習領域內，目標是為了提升機器學習落地的效率。

下面將詳細的介紹MLOps。

什麼是MLOps

MLOps目前沒有特別清晰一致的定義。

來自Wikipedia的定義如下：

MLOps  is a set of practices that aims to deploy and maintain Machine Learning models in production reliably and efficiently.

（有人認為MLOps和ModelOps是同一個概念，筆者認為MLOps的ML是指Machine Learning，而不只是Model的縮寫，MLOps所包含的概念比ModelOps的概念要廣泛，ModelOps指的是模型（Model）相關的開發和運維自動化，而MLOps關心的內容不只是Model，還包括Data和Code。）

也有人認為MLOps 就是機器學習領域的DevOps， 即

DevOps + Machine Learning = MLOps

對此，我的看法是MLOps跟DevOps有很多觀念和實踐是相同的，但是MLOps相對DevOps也還有不少獨特的地方。

我們先來對照上文中DevOps的三個優點來理解MLOps；

1. 打破部門牆

DevOps是打破了軟體研發運維活動中關鍵角色Dev（軟體研發人員）和Ops（IT運維人員）的部門牆，推動他們更高效的協同工作。

MLOps同樣也是打破了機器學習研發運維活動中關鍵角色Data Scientist（資料科學家）和Software Engineers（軟體工程師）之間的部門牆，推動他們更高效的協同工作。

其中資料科學家，職責是利用資料訓練出較好的模型出來；經常是基於給定的資料集進行工作；工作重點是改進模型從而達到模型所需要的準確率、召回率等效能指標；往往是在Jupyter Notebooks上進行工作；他們很擅長構建模型和特徵處理；但是並不關心模型大小、成本、延遲、QPS等指標。

而軟體工程師，職責是拿到模型之後在線上進行部署，對線上請求進行預測，從而實現商業價值；他們對最終產品負責，關心成本、效能和穩定性，關心客戶的滿意度，對可擴充套件性和自動化花很大力氣，他們往往需要長期維護一個產品。

這兩種角色都是機器學習在企業落地的必不可少的橘色。但是在如今的機器學習開發上線流程和組織架構設計中，往往這兩個部門因為關心點不同，存在很厚重的部門牆，導致機器學習落地時間長，效果不達預期，而且有可能因為時間流逝而出現預測效果回退的情況。

所以，MLOps也需要跟DevOps一樣，打破部門牆，關鍵角色之前需要緊密的協作。

2. 同樣需要流水線。

流水線是自動化操作的集合，能極大的加速開發和運維的運轉。

上圖是我從網際網路找到的一個雙環流水線MLOps的圖，還有三環模型的MLOps圖。我個人比較傾向雙環模型。

雙環模型中，左半邊是機器學習訓練過程，目標是通過資料訓練出比較好的模型，來找出資料間的規律，模型需要有比較好的預測結果；右半邊是機器學習的預測過程，當模型已經得到之後，部署到線上，進行各種線上配置，並持續進行監控線上服務。

MLOps的流水線不僅僅只有持續整合（CI）和持續部署（CD），還包括持續訓練（CT）和持續監控（CM），而且對CI和CD的內容也有擴充套件。

• Continuous Integration（CI）：不僅僅是對程式碼（Code），還包括對資料（Data）和模型的持續測試和驗證。
• Continuous Delivery（CD）：不僅僅對軟體包進行持續部署，還包括對預測服務的持續部署和更新（因為更新預測服務有時候是隻更新模型，有時候是模型和資料一起更新，並不更新程式碼）
• Continuous Training（CT）：這是機器學習所特有的，需要對模型進行自動的持續訓練
• Continuous Monitoring（CM）：不只是監控服務的可用性，還需要監控預測服務的準確性、召回率等效能指標，如果有下降可能觸發持續訓練。

我比較喜歡用這張圖來表示MLOps的範圍：

（1） 它首先是覆蓋Machine Learning的整個生命週期的多個階段。從定義專案開始，到定義和蒐集加工資料，然後訓練模型和迭代，到最後的部署和監控，構成一個完整的lifecycle，而且每個階段都會跟前一個階段有互動和迭代。例如模型訓練效果不理想，可能需要回到上一個環節，收集更多資料，對資料進行更多加工；上線效果不理想，可能需要回到上一個環節，重新再訓練，如果還不理想，可能還需在回到上一個環節，對資料進行更多工作。這是一個迴圈迭代的過程。

（2）這張圖包含了Code，還包含Model，Data，因為MLOps所涉及的物件不僅僅只是程式碼，還包含模型和資料。正是引入了模型和資料，才帶來更多的複雜性。

（3）整體的流水線包括持續整合（CI） 和持續部署（CD）、持續訓練（CT）和 持續監控（CM）。

3. MLOps不只是Lifecycle相關的Pipeline，還包括各種平臺和工具

例如：

• Feature Store：存放線上業務和離線業務所需要的特徵
• Model Store： 存放模型的各種版本和版本資訊
• Model Monitoring：監控模型效能專用
• Metadata DB：存放模型、資料的各種meta data的資訊

這張圖是Google Cloud機器學習官網上的一張架構圖，表示了完整的全自動化的MLOps系統，

其中Feature Store， ML Metadata Store，Model Registry都是比較重要的模組。

所以說，DevOps和MLOps一方面有很多地方不一樣；

但是另一方面，DevOps和MLOps又有很多相同的地方。

1. 目標相同：

他們都是為了提升研發領域的效率，為了更好的給客戶提供價值。如果沒能達到給客戶提供價值的目標，各種實踐的推行，各種工具的採納都毫無意義。

2. 基本理念相同：

（1）自動化，儘可能的自動化

（2）系統思考、儘快反饋、持續改進。這是DevOps的the Three ways，對MLOps同樣適用。

 

10年前喬梁預測DevOps會在之後的10年風靡起來，成為業內的預設詞；我也來大膽預測一下，隨著企業數字化轉型紛紛進入到高階階段即智慧化階段，AI在企業大批的落地併發揮關鍵作用，MLOps也會成為熱詞，並在未來的10年內，成為業內AI落地的必不可少的預設詞。

 

Meetup回顧：

本次Meetup，我邀請了gitlab中國公司即極狐公司的工程師劉巍峰來介紹如何使用傳統的程式碼管理工具和流水線平臺Gitlab，來實現機器學習模型的開發自動化；同時也邀請了第四正規化公司的工程師盧冕來介紹OpenMLDB，一個開源的實時特徵計算平臺，可以優雅的解決特徵線上線下一致性的問題，極大的加速機器學習的開發和上線過程。

以下是回顧文章和影片，歡迎參考。

• 開場

http://www.bilibili.com/video/BV1NL4y1T7zd?spm_id_from=333.999.0.0

• MLOps在極狐GitLab中的應用探索

http://www.bilibili.com/video/BV1ZT411V7DT?spm_id_from=333.999.0.0

• OpenMLDB在MLOps的應用

http://www.bilibili.com/video/BV1zA4y1o7jY?spm_id_from=333.999.0.0

BTW：

我組織了MLOps愛好者討論群，群裡有大企業負責機器學習平臺、特徵平臺建設的工程師，也有關心MLOps賽道的投資人，還有相關開源專案的負責人，歡迎對此有興趣的同學加入此群和我們一起討論MLOps相關內容。