十多年ML系統SRE經驗，Google練出4大ML可靠性戰略

「不只是為了省錢，或只是減少丟臉時刻，避免影響顧客，更重要的價值是，SRE是確保ML創新速度的關鍵。」Google ML SRE團隊負責人Todd Underwood在去年10月全球SRE年會演講時，他特別強調，這才是Google早在13年前開始將SRE經驗和知識運用到ML系統的關鍵理由。

Google在 2003 年首創了第一個SRE（Site Reliability Engineering，服務可靠性工程）團隊，透過系統架構設計、維運流程改善等各種做法，來確保系統運作的更可靠。2014年，Google公開了這套SRE方法論和經驗，後來也成了許多企業維運自家網站和線上服務可靠性的重要參考。

不只是用來確保網站和線上服務的可靠性，13年前，Google已經將SRE成功運用到搜尋服務，儲存系統、廣告資料儲存系統的可靠性維運上，當時開始思考，是不是能將SRE運用到ML系統上，決定先從匹茲堡辦公室的Google Ads品質團隊開始，運用到仰賴大量機器學習演算法的Google的廣告推薦機制上。

因為Google關鍵字廣告採點擊計費，點擊才會計價，靠ML模型來推薦的廣告越符合搜尋需求，就會能成功吸引瀏覽者來點擊。

Todd Underwood指出，廣告系統越穩定可靠，營收就能越穩定，因此決定開始從這套系統開始導入SRE做法，稱為「ML SRE」。Todd Underwood 就是13年前發起了Ads ML SRE團隊的關鍵人物之一，

Todd Underwood表示，AI跟ML其實很不一樣，AI是從人、應用需求角度來看，但ML則是要讓電腦系統可以運用機器學習技術來解決問題，是一種利用資料來訓練模型的做法，ML是AI的一個子集。

Todd Underwood也公開了Google內部所用ML系統概略架構，跟大多數企業常見的ML訓練流程差異不大。這個ML系統架構包括了5個流程，從資料搜集、資料準備、模型訓練、品質控管到提供推論服務，Google打造了一套模型管理工具和流程調度系統，用來追蹤模型、特徵和資料的後設資料。Google也特別重視資料讀取、資料檢查、特徵資料的分布和變動等資料品質的控管。

Google SRE工程師Mary McGlohon正是過去4年來負責維運和開發這套超大規模ML系統的工程師之一。

Mary McGlohon指出，機器學習系統過於複雜和龐大，必須要打造工具來分析，才能探索問題，對ML SRE來說，就不用知道每一件事的業務邏輯，也可以做事。

因此，Google也自行發展了不少ML SRE工具，從更大的尺度來觀察系統，找出各種可能出錯的狀態，並依據過去的錯誤設計更好的實作方式。

雖然，Google沒有公開這些 ML SRE工具，但Mary McGlohon歸納出四個Google用來提高ML可靠性的SRE戰略，這正是他們過去十多年確保ML系統可靠性的關鍵秘訣。

這四個策略，包括了，第一，要讓失效問題看得見，才能知道為何出錯。其次，也需要盡可能驗證各種異動，才能避免異動帶來的錯誤，並且要釐清對資料完整性的要求，最後則是得妥善管理工作流程的等待任務。

Mary McGlohon指出，若誤以為ML是魔術，這是一個迷思，對在乎系統穩定的工程師來說，今天的偷懶， 可能會帶來明天的技術債，先分析ML系統的特徵，才能知道系統出錯時會有哪些風險，讓我們知道可以如何管理風險。

ML系統的特別之處，第一是大量資料的相依性。因為機器學習演算法非常強大，可以有效辨識訊號和雜訊，這就導致不需要篩選或過濾資料，也能提升預測能力。

甚至，不需要知道哪些資料來源更有價值直接全部匯入，這會帶來一個後果，累積越久，就會有越多資料相依性（data dependencies）問題，這也是Google ML系統的一大特質。其次，ML系統其實是一套龐大交互作用的流程系統，必須知道如何安排這些流程，才能管理風險。

最後一點，ML是一種超大規模的非典型工作負載，不同的ML批次運算，會有不一樣的運算和資料I/O需求，這對資源調度工作帶來很大的挑戰。

Google也曾從分析了過去15年ML系統上百起當機事件的檢討報告後歸納，出19種ML系統當機問題，Mary McGlohon指出，其中只有30%的問題，是來自ML系統內部的問題，像是標記錯誤，模型配置設定錯誤，但高達40%的問題是來自分散式系統的內部問題，例如負載平衡出錯，資料結構沒有最佳化，工作排程安排錯誤等。

「從這個結果告訴我們，ML系統的維運可以借鏡其他分散式系統的維運和最佳實務做法。」Mary McGlohon指出，Google的ML系統是一種分散式系統，資料密集，流程化的系統，我們挑選了分散式系統最佳實務，資料完整性最佳實務，和工作流程最佳化實務來緩解風險。

ML SRE關鍵策略1：讓失效問題看得見

「要知道如何解決故障之前，得先知道何時會故障，看得見故障是一件重要的事。」Mary McGlohon表示。

Google內部有一套協調調度平臺，可以用來設計模型開發流程，可以設定模型配置，並提供儀表板來檢查模型效能，可以用來觀察模型如何運作。

不過，Mary McGlohony則是建議，SRE團隊最好可以建立一些模型品質預警通知，通知模型開發者以及系統維運人員，一但模型品質開始下滑，可以在更多使用者發現之前，讓模型開發者可以展開行動，退回前一版，或趕快開始調查原因。

「儀表板是一種降低事故風險的好方法，發生事故時，要確保開發這個模型的核心人員也能觀察到系統的資訊，他們可以成為解決問題的幫手。」Mary McGlohon說。

ML SRE 關鍵策略2：盡可能驗證各種異動

但只靠預警機制還不夠，更主動的SRE方法是進一步驗證各種系統上線的變動，可以從二進位檔和資料的變動來追蹤。

如何最有效追蹤系統的變動，Mary McGlohon建議，任何系統都會有帶有業務邏輯的二進位檔案，不管是，特徵處理，模型訓練，或推論服務等，都會用到二進位檔，因此，可以驗證這些二進位檔來確保是否順利運作，另一個可以追蹤變動的地方是系統配置檔的變動。例如像是資料Schema配置， 不同階段的各種配置。

追蹤二進位檔和配置檔的變動，最好的做法就是建立一個上線前的Staging（準備）階段和環境，在這個環境中，複製一份正式系統，進行測試，驗證效能，來確保異動的影響符合預期，確定沒有問題才正式上線。

在Staging階段較容易發現可能導致當機的錯誤，但不容易發現效能問題的影響，例如I/O用量，CPU用量，一條工作流程跟大量工作流程同時執行的影響不一樣，後者可能導致很多等待的任務，而影響了系統運作。

Google還會追蹤另外一種變動，就是資料變動，可以從原始資料變動，特徵資料更新的脧中，模型表徵的變動，推論資料的產生等。「偵測資料本身的異動，是一種防止事故的做法。」Mary McGlohon表示。

如何最有效追蹤系統的變動，Google建議，任何系統都會有帶有業務邏輯的二進位檔案，不管是，特徵處理，模型訓練，或推論服務等，都會用到二進位檔，因此，可以驗證這些二進位檔來確保是否順利運作，另一個可以追蹤變動的地方是系統配置檔的變動。例如像是資料Schema配置， 不同階段的各種配置。Google還會追蹤另外一種變動，就是資料變動，從原始資料變動，特徵資料更新的脧中，模型表徵的變動，推論資料的產生等。圖片來源／Google

ML SRE 關鍵策略3：更清楚掌握對資料完整性的要求

另外，建立模型後，在正式上線之前，Google會先用測試資料來了解模型的效能，或是在準備好特徵資料後，先篩選出異常資料，避免對模型訓練產生影響。Mary McGlohon表示，對特徵資料越熟悉，就越能這樣事先過濾，而且不能單靠資料異常檢查，還是需要搭配對配置檔和二進位檔異動檢查，來確保ML環境準備正常，也才能避免壞資料產生問題。

如何分辨哪些資料是異常資料，就得對資料完整性的要求，清楚了解送入ML系統的資料是否符合訓練所需，而且能準時送達。

尤其，很多外部問題會影響資料品質，例如標記出錯，資料來源在不同時間來自不同地方，資料處理流程在第三方，甚至可能無法監控資料來發生了什麼事。Google SRE會要求，組織內部資料負責窗口，有任何資料需求的調整，也得通知SRE。

另一個做法是簡化ML，避免壞資料帶來長期的影響，也可以建立系統回復機制。例如遇到資料錯誤，或不完整的資料，訓練出了有問題的模型，若有回復機制，就可以回到一個安全不容易出錯的模型快照版本

ML SRE 關鍵策略4：妥善管理工作流程的等待任務

Google ML SRE最後一項關鍵策略是ML工作流程最佳化，因為經常有大量工作流程同時進行，過載會是常見問題，一但流程當機，或者資料晚到，就得有彈性來因應，因此，Mary McGlohon表示，需要建立流程退回機制，另外要有工作量優先順序機制，才知道哪一項任務可以延後，最後要讓調度機制更聰明，例如可以針對系統備援來進行資源調度，一但遇到當機時就可以採用。

Google ML SRE最後一項關鍵策略是ML工作流程最佳化，因為經常有大量工作流程同時進行，過載會是常見問題，一但流程當機，或者資料晚到，就倒有彈性來因應，因此，Google建議，需要建立流程退回機制，另外要有工作量優先順序機制，才知道哪一項任務可以延後，最後要讓調度機制更聰明，例如針對系統備援來進行資源調度，一但遇到當機時就可以採用。圖片來源／Google

ML SRE和SRE有兩大挑戰不一樣

Todd Underwood指出，ML SRE特別跟其他SRE做法，有兩件事不一樣。第一是，新模型和新團隊需要很大的彈性，可能有各種技術考量，業務需求，或資料限制，必須調整模型。

因為需要可以客製化的模型架構，容易增加新功能，超快速部署，負責團隊能快速修改問題直接執行模型來更新，也就是說，Todd Underwood表示，ML系統，希望能夠盡快正式上線，這意味著，機器學習訓練要高可用，容量分派自動化，調度自動化，SRE自動支援等。但是，要具備高度彈性，也代表了不容易標準化，這是第一個挑戰。

第二個不一樣之處是，ML SRE的另一個挑戰是「模型品質」，Todd Underwood指出，尤其要思考該如何對模型品質負責。Google常見做法是由模型開發者來確保模型品質，但在ML模型上線之後，很多問題是來自系統性問題，而非模型的問題，只靠模型開發者解決不了問題。

「如何對模型品質負責，這是一個還沒有答案的ML SRE大問題，這真的是一個非常難解的問題。」Todd Underwood強調。

為了解決這個模型品質問題，Google正在思考的做法是，建立升級檢查清單，也就是可以檢查一個ML模型是否能從實驗狀態，進入到正式上線狀態的檢查清單。這個挑戰也就是要定義一個模型的服務水準目標（SLO），關鍵是「如何判斷，一個模型可以正常運作。」Todd Underwood說。

目前，Google有幾項定義「模型正常運作」的角度，例如資料是否不完整，過大，過小，或者會出現不同版本。訓練速度太慢，或容易卡住。或是訓練過程太消耗資源、模型品質突然改變（準確度下滑）、服務無法載入模型、模型載入服務後變慢等。

Todd Underwood說：「這些就是我們會設立指標的地方，來量測數據和效能，來判斷什麼樣的模型品質夠好，可以升級到正式環境。還會搭配其他指標如Model後設資料是否完整，和其他模型的相依性檢查等。

下一步，Google ML SRE想要做到5件事，Todd Underwood分享，一方面說服組織使用稍舊的ML技術但搭配可以自動化建模的做法，夠用就好的ML，不是用最新技術。

其次，要打造一個兼顧各種功能和穩定性的端到端平臺，但要把這些功能盡量背景化，希望做到，一個按鈕就可以完成。

Todd Underwood也希望大幅降低訓練成本，並且把各種ML服務變成API，可以穩定且方便整合到各種應用中，讓ML無所不在，最後則是要建立ML品質評量機制，適用各處而且值得信任。