十多年ML系統(tǒng)SRE經(jīng)驗，Google練出4大ML可靠性戰(zhàn)略

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

Google在2003年首創(chuàng)了第一個SRE（Site Reliability Engineering，服務(wù)可靠性工程）團隊，通過系統(tǒng)架構(gòu)設(shè)計、運維流程改善等各種做法，來確保系統(tǒng)運行的更可靠。2014年，Google公開了這套SRE方法論和經(jīng)驗，后來也成了許多企業(yè)運維自家網(wǎng)站和線上服務(wù)可靠性的重要參考。

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

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

Todd Underwood指出，廣告系統(tǒng)越穩(wěn)定可靠，營收就能越穩(wěn)定，因此決定開始從這套系統(tǒng)開始導入SRE做法，稱為“ML SRE”。Todd Underwood就是13年前發(fā)起了Ads ML SRE團隊的關(guān)鍵人物之一，

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

Todd Underwood也公開了Google內(nèi)部所用ML系統(tǒng)概略架構(gòu)，跟大多數(shù)企業(yè)常見的ML訓練流程差異不大。這個ML系統(tǒng)架構(gòu)包括了5個流程，從資料搜集、資料準備、模型訓練、品質(zhì)管控到提供推論服務(wù)，Google打造了一套模型管理工具和流程調(diào)度系統(tǒng)，用來關(guān)注模型、特征和資料的元數(shù)據(jù)。Google也特別重視資料讀取、資料檢查、特征資料的分布和變動等資料品質(zhì)的管控。

Google SRE工程師Mary McGlohon正是過去4年來負責運維和開發(fā)這套超大規(guī)模ML系統(tǒng)的工程師之一。

Mary McGlohon指出，機器學習系統(tǒng)過于復雜和龐大，必需要打造工具來分析，才能探索問題，對ML SRE來說，就不用知道每一件事的業(yè)務(wù)邏輯，也可以做事。

因此，Google也自行發(fā)展了不少ML SRE工具，從更大的尺度來觀察系統(tǒng)，找出各種可能出錯的狀態(tài)，并依據(jù)過去的錯誤設(shè)計更好的實例方式。

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

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

Mary McGlohon指出，若誤以為ML是魔術(shù)，這是一個偏見，對在乎系統(tǒng)穩(wěn)定的工程師來說，今天的偷懶，可能會帶來明天的技術(shù)債，先分析ML系統(tǒng)的特征，才能知道系統(tǒng)出錯時會有哪些風險，讓我們知道可以如何管理風險。

ML系統(tǒng)的特別之處，第一是大量資料的依賴性。因為機器學習算法非常強大，可以有效識別信號和噪聲，這就導致不需要篩選或過濾資料，也能提升預(yù)測能力。

甚至，不需要知道哪些數(shù)據(jù)源更有價值直接全部導入，這會帶來一個后果，累計越久，就會有越多資料依賴性（data dependencies）問題，這也是Google ML系統(tǒng)的一大特質(zhì)。其次，ML系統(tǒng)其實是一套龐大交互作用的流程系統(tǒng)，必須知道如何安排這些流程，才能管理風險。

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

Google也曾從分析了過去15年ML系統(tǒng)上百起宕機事件的檢討報告后歸納，出19種ML系統(tǒng)宕機問題，Mary McGlohon指出，其中只有30%的問題，是來自ML系統(tǒng)內(nèi)部的問題，像是標記錯誤，模型配置設(shè)置錯誤，但高達40%的問題是來自分布式系統(tǒng)的內(nèi)部問題，例如負載均衡出錯，數(shù)據(jù)結(jié)構(gòu)沒有優(yōu)化，工作調(diào)度安排錯誤等。

“從這個結(jié)果告訴我們，ML系統(tǒng)的運維可以借鑒其他分布式系統(tǒng)的運維和最佳實務(wù)做法?！盡ary McGlohon指出，Google的ML系統(tǒng)是一種分布式系統(tǒng)，資料密集，流程化的系統(tǒng)，我們挑選了分布式系統(tǒng)最佳實務(wù)，資料完整性最佳實務(wù)，和工作流程優(yōu)化實務(wù)來緩解風險。

ML SRE關(guān)鍵策略1：讓失效問題看得見

“要知道如何解決故障之前，得先知道何時會故障，看得見故障是一件重要的事?！盡ary McGlohon表示。

Google內(nèi)部有一套協(xié)調(diào)調(diào)度平臺，可以用來設(shè)計模型開發(fā)流程，可以設(shè)置模型配置，并提供儀表板來檢查模型性能，可以用來觀察模型如何運行。

不過，Mary McGlohony則是建議，SRE團隊最好可以創(chuàng)建一些模型品質(zhì)預(yù)警通知，通知模型開發(fā)者以及系統(tǒng)運維人員，一旦模型品質(zhì)開始下滑，可以在更多用戶發(fā)現(xiàn)之前，讓模型開發(fā)者可以展開行動，退回前一版，或趕快開始調(diào)查原因。

“儀表板是一種降低事故風險的好方法，發(fā)生事故時，要確保開發(fā)這個模型的核心人員也能觀察到系統(tǒng)的信息，他們可以成為解決問題的幫手?！盡ary McGlohon說。

ML SRE關(guān)鍵策略2：盡可能驗證各種異動

但只靠預(yù)警機制還不夠，更主動的SRE方法是進一步驗證各種系統(tǒng)上線的變動，可以從二進制檔和資料的變動來關(guān)注。

如何最有效關(guān)注系統(tǒng)的變動，Mary McGlohon建議，任何系統(tǒng)都會有帶有業(yè)務(wù)邏輯的二進制文件，不管是，特征處理，模型訓練，或推論服務(wù)等，都會用到二進制檔，因此，可以驗證這些二進制檔來確保是否順利運行，另一個可以關(guān)注變動的地方是系統(tǒng)配置檔的變動。例如像是資料Schema配置，不同階段的各種配置。

關(guān)注二進制檔和配置檔的變動，最好的做法就是創(chuàng)建一個上線前的Staging（準備）階段和環(huán)境，在這個環(huán)境中，復制一份正式系統(tǒng)，進行測試，驗證性能，來確保異動的影響符合預(yù)期，確定沒有問題才正式上線。

在Staging階段較容易發(fā)現(xiàn)可能導致宕機的錯誤，但不容易發(fā)現(xiàn)性能問題的影響，例如I/O用量，CPU用量，一條工作流程跟大量工作流程同時執(zhí)行的影響不一樣，后者可能導致很多等待的任務(wù)，而影響了系統(tǒng)運行。

Google還會關(guān)注另外一種變動，就是資料變動，可以從原始資料變動，特征資料更新的脧中，模型表征的變動，推論資料的產(chǎn)生等?！皞蓽y資料本身的異動，是一種防止事故的做法?！盡ary McGlohon表示。

如何最有效關(guān)注系統(tǒng)的變動，Google建議，任何系統(tǒng)都會有帶有業(yè)務(wù)邏輯的二進制文件，不管是，特征處理，模型訓練，或推論服務(wù)等，都會用到二進制檔，因此，可以驗證這些二進制檔來確保是否順利運行，另一個可以關(guān)注變動的地方是系統(tǒng)配置檔的變動。例如像是資料Schema配置，不同階段的各種配置。Google還會關(guān)注另外一種變動，就是資料變動，從原始資料變動，特征資料更新的脧中，模型表征的變動，推論資料的產(chǎn)生等。圖片來源／Google

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

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

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

尤其，很多外部問題會影響資料品質(zhì)，例如標記出錯，數(shù)據(jù)源在不同時來自不同地方，資料處理流程在第三方，甚至可能無法監(jiān)控資料來發(fā)生了什么事。Google SRE會要求，組織內(nèi)部資料負責窗口，有任何資料需求的調(diào)整，也得通知SRE。

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

ML SRE關(guān)鍵策略4：妥善管理工作流程的等待任務(wù)

Google ML SRE最后一項關(guān)鍵策略是ML工作流程優(yōu)化，因為經(jīng)常有大量工作流程同時進行，重載會是常見問題，一旦流程宕機，或者資料晚到，就得有彈性來應(yīng)對，因此，Mary McGlohon表示，需要創(chuàng)建流程退回機制，另外要有工作量優(yōu)先級機制，才知道哪一項任務(wù)可以延后，最后要讓調(diào)度機制更聰明，例如可以針對系統(tǒng)備援來進行資源調(diào)度，一旦遇到宕機時就可以采用。

Google ML SRE最后一項關(guān)鍵策略是ML工作流程優(yōu)化，因為經(jīng)常有大量工作流程同時進行，重載會是常見問題，一旦流程宕機，或者資料晚到，就倒有彈性來應(yīng)對，因此，Google建議，需要創(chuàng)建流程退回機制，另外要有工作量優(yōu)先級機制，才知道哪一項任務(wù)可以延后，最后要讓調(diào)度機制更聰明，例如針對系統(tǒng)備援來進行資源調(diào)度，一旦遇到宕機時就可以采用。圖片來源／Google

ML SRE和SRE有兩大挑戰(zhàn)不一樣

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

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

第二個不一樣之處是，ML SRE的另一個挑戰(zhàn)是“模型品質(zhì)”，Todd Underwood指出，尤其要思考該如何對模型品質(zhì)負責。Google常見做法是由模型開發(fā)者來確保模型品質(zhì)，但在ML模型上線之后，很多問題是來自系統(tǒng)性問題，而非模型的問題，只靠模型開發(fā)者解決不了問題。

“如何對模型品質(zhì)負責，這是一個還沒有答案的ML SRE大問題，這真的是一個非常難解的問題。”Todd Underwood強調(diào)。

為了解決這個模型品質(zhì)問題，Google正在思考的做法是，創(chuàng)建升級檢查清單，也就是可以檢查一個ML模型是否能從實驗狀態(tài)，進入到正式上線狀態(tài)的檢查清單。這個挑戰(zhàn)也就是要定義一個模型的服務(wù)水準目標（SLO），關(guān)鍵是“如何判斷，一個模型可以正常運行。”Todd Underwood說。

目前，Google有幾項定義“模型正常運行”的角度，例如資料是否不完整，過大，過小，或者會出現(xiàn)不同版本。訓練速度太慢，或容易卡住?；蚴怯柧氝^程太消耗資源、模型品質(zhì)突然改變（準確度下滑）、服務(wù)無法加載模型、模型加載服務(wù)后變慢等。

Todd Underwood說：“這些就是我們會設(shè)立指標的地方，來測量數(shù)據(jù)和性能，來判斷什么樣的模型品質(zhì)夠好，可以升級到正式環(huán)境。還會搭配其他指標如Model元數(shù)據(jù)是否完整，和其他模型的依賴性檢查等。

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

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

Todd Underwood也希望大幅降低訓練成本，并且把各種ML服務(wù)變成API，可以穩(wěn)定且方便集成到各種應(yīng)用中，讓ML無所不在，最后則是要創(chuàng)建ML品質(zhì)評量機制，適用各處而且值得信任。