【隨筆】學習 DevOps 與 MLOps 帶來的一些啟發
Let’s small talk — Some enlightening moments when I started to learned the concept of DevOps/MLOps
Disclaimer : 我不是專家，就隨便寫寫，以下任何論點皆沒有經過科學與統計數字佐證，你大概也不會得到任何 Takeaways，說這麼多就是希望專業人士鞭小力點XD前言
雖然說從以前開始就陸陸續續與許多工程團隊合作過，但基於 Project 的合作與參與到整個團隊文化去思考整個組織如何更有效率這件事情上，終歸有一點差距 : 過去的我終究還是個商業分析師與 Data Guy，我執行的分析與建模很少考慮到自動化這回事，或者即使有，也是基於固定 I/O 下去做的一些簡單 OOP 的概念而已，當我遇上要把整個模塊或報告真的做成 One-Click 的精度時，我開始遭遇到不少的 Cultural Shock。
平心而論工程師就是一種懶還要更懶的生物，當我一方面面對管院學生對我在資料處理上的迅捷留露出的羨慕時，我也用很羨慕的眼光看著公司裡頭對 CI/CD 瞭若指掌能夠輕鬆搞定組態管理的大神們，這個在外人聽起來會有點不可思議 : 「當有人已經能用一兩個小時搞定以往業務單位拉個 Excel 報表可能就要用掉一下午的工作時，他居然還不滿足地認為一兩個小時太長 ? 」呃，是的，真的長，我連 Retrain 一次 PyTorch，那怕已經花大量力氣做 GPU 轉移與資料預存記憶體，讓其迭代次數壓縮到三分鐘內，我都覺得那是人生中最漫長的時光了。
然後一方面羨慕於大神們不用等待的同時 (雖然他們會裝作他們在等待，但其實都在打混呵呵)，我也一方面被所謂的 "鄙視鏈" 給深深教育了一遍，就像某個台灣大型 BBS 論壇流傳的一句話，有些東西，不是本科資工出來的是不會的，這類東西包括但不限於 : 「Design Pattern、Vim (對真的好用，但也真的難學= =)、Shell Scripting (Unix 打包文件新世界)、DevOps」，尤其時最後面的東西，好像不管你做啥類型的 Engineer 似乎人手都會一樣，我才方知井底之窄與天之浩大 — 額，這樣說有點誇張，我其實也沒有仔細深究到底是本科一畢業就會這些有的沒的還是大家都是被社會毒打的結果，總之，我覺得我被毒打了，每次被凱瑞的時候都像隻鴕鳥一樣想找地方埋好。
特別是任何 ML/DL 的專案，每次看著由於 DevOps (對就是今天的主角) 能力太差，導致 Deploy 最後都只能上 Server 吐成 API 的方式，導致 Data Pulling 與 Training 永遠都在複製貼上模塊等等，族繁不及備載，我的心如同在滴血一樣，關鍵是，ML 專案有些原生的性質關係，與以往傳統的 DevOps 方法也不盡相同，代表你今天不把它搞定，未來也沒人能幫你搞定，那怎麼辦，嗚嗚，只好乖乖捧著書本與 Documentation，趕緊開始啃起來啦 T_T! 陣痛期則是在所難免，畢竟商業分析師多半不學無術 (欸我這樣會不會得罪一票人哈哈哈，我算是有自嘲噢XD)
當然啦，DevOps 包含許多東西，其中有一些如 Git 是本來就很熟悉的，因此我上面說被爆打的經歷，其實更多的是所謂的組態管理相關，而今天這篇文章也算是啃了一陣子之後的有感而發，我無意介紹一些很 Fancy 的 DevOps/MLOps 工具或學習方法，恩因為我不是專家，所以純粹是一些抱怨以及灌自己雞湯的部分，如果沒興趣的話請直接右上叉叉，可以不用浪費生命中的十分鐘在這裡沒關係，你可以去學 DevOps，相信我會有用的。
好吧，廢話不多說，開始進入我們今天的廢話 :
我怎麼看待 DevOps 的
OK 首先，我想大部分人應該都會承認，直接被現實案例爆打的學習曲線總是比死讀書要來得陡峭許多，只要你有那種從生活中各種小事發現學習點的目光，你就能成長得比別人快，為甚麼我會說這個勒? 因為老實講，我很幸運地，從頭到尾在 Deploy 那塊都有人罩我。
「嗯，沒事，你就那啥 API 做出來然後跑得通，不要跑太慢就行了，剩下我來搞定」
「噢.... 好的(默默補上兩行 Code) … 好了大大 … 」
if cuda.is_available():
self.device = 'gpu'「噢，好窩，我看看 (敲敲敲敲敲)」
再回來的時候，整個專案架構都不一樣了，原本大概是這樣 :
- Log/
- Utils/
-- getData.py
-- data_utils.py
- Models/
-- model.py
-- ab_test_compile.py
- main.py
- requirements.txt突然多出了 :
- ansible/
- GNUmakefile
- pyproject.toml
- poetry.lock
- travis.yml
- ... ... 嗯 ... 你確定我們做的是同一個專案嗎 XDDD
大概就是這樣的一個過程，當然對於這些流程比較熟悉的朋友大概知道，這東西應該是可以 run 的而且絕對比我原先的 code 順利許多，反正，自從那次之後我深刻體會了一個道理，真的，你不被毒打一遍你不會知道有那麼多刑具可以用 ... (hmm)。
於是總之所以呢，我就嘗試著把每個東西都搞懂，也大概就是在這個過程中慢慢接觸到了一個觀念 -- DevOps，一個小專案是不重要但大型協作會搞死你的大坑，但同時也因為資料的量與雜亂程度，我深知這是一個難以單獨研究的學問，需要有整理與實作機會我才有辦法補上這些知識，因此，我搞來了一本從未讓人失望的歐萊禮 (O'Reilly) :
比較讓我驚豔的點是，由於網路上對於 DevOps，我不知道是不是一些奇怪的職業病，總會在工具的應用上爭吵半天，比如 Configuration Management 用 Ansible 好啦還是其他的 (遠目某台灣 backend 社團)，不由得讓我想起對非 Excel 深惡痛絕的那幫商業顧問們 (唉你們至少學點 pivot table，不要加班都花在這上面阿...)。總之本書開頭花了大量篇幅在探討所謂 DevOps 的核心，其實還是在於團隊合作的文化改革上。
有一段話是這樣寫的 (翻譯)，我非常喜歡 : 「在一個人為錯誤 (Human Error) 會被譴責與懲罰的環境下，恐懼會建立起一到壁壘妨礙明確的溝通與資訊透明度。而與之對比的另一種環境，則是當問題發生後，問題會被人們一起合作解決並將之視為個人和組織的學習機會。」
在一年多管理顧問的生涯中，其實有一個最令人百思不得其解以及成為多少人栽跟頭的原因是，設想策略以及執行落地程度的不對等，當然這並不是說他們不知道原因 — 一些顯而易見的原因如項目成本、執行複雜度、客戶關係管理與派系爭鬥等等都是導致最終策略落地不理想的因素，因此更進一步說這個問題應該在於，我們應該怎麼樣將這些問題提前納入策略思考的環節中，除了思考解決問題本身，也在同時為解決問題畫上一個 Boundary : 解決、且好執行。
這的確也是許多顧問公司正在努力的，也就是將 Implementation 做得更加深入一些，不只是因應時代趨勢更是為了能夠談成更多生意，而對我而言這一切的關鍵還是在於 KPI 的設置，當我們能用可量化的方式衡量那些非帳面價值以外的好處時，我們就可以讓整個策略的 Compile 更加優美一些，而這也是 DevOps 在工程端追求的一個最大目標。
在學習 DevOps 以及實際應用的一系列交互中我發現，其實整個 DevOps 的關鍵還是在於對於我們接下來要執行的業務，以及團隊成員的能力有充分了解後，設計一套長期來看最有效益的方法來加速運作流程並創造人們願意合作解決問題的環境而已，說起來的確是不難，但很多東西的確常被忽略掉，比如 :
在一個規模龐大的 ML 專案中，尤其如果在比較數據敏感的團隊進行應用時，對於變數的定義、來源表、使用方式與處理方式等，往往需要經過層層審核，不僅是人工對於業務理解的審核，也包含了多項團隊協作時機器組態運作上的審核。而當我們的目標被定義在最大化業務指標，比如說更準確地預測用戶流失的機率，這樣比較細小的數字時，我們對於短期利益的追求就會忽視掉長期利益的平衡，因此往往在第一次部屬並上交結果至管理階層後，各式各樣的底層問題就會接二連三地冒出 : 你客戶的工程團隊在遷移到自家搭建非 Unix 系統時候模型炸了，或是底下的業務團隊拿到了你精心設計的五十個變量彙整表後，還是拿起了自己小本本上記載的 VIP 客戶的電話開始聊天氣如何。
不僅僅是在客戶端，在公司端也一樣，每天行銷團隊總是有數不完的為甚麼，我為甚麼這檔活動成效差，為甚麼這群人死都不接電話，為甚麼你說要打七天內活躍的用戶比較有機率成功，我打八天不行嗎? 諸如此類，可當一個完整的 ML Report 或 Internal Product 提交給他們之後，還是照著之前的做法一個一個搞，然後隔天又發 ticket 要你拉數字給他們。
任重而道遠矣，一個好的 DevOps 就如同一個好的 Training Session 一樣，消弭對方因工具不熟產生的恐懼感，同時在一個規範好的協定下一起做事，明白 Report 的對象與開發的責任歸屬在誰，這一點不論在工程端的調整或是在策略執行面上的修正，我認為都是大同小異的。
所以，甚麼才叫做好的 DevOps ?
我也不知道啊XDDD
市場上不乏一種職業叫做 Technical Consultant，舉凡 IBM、Amazon 都有一堆這樣的人，他們帶著市(ㄗˋ)場(ㄐㄧㄚ)上的最新技術，要來協助你導入並改善現有亂七八糟的流程，不過使用者畢竟感受沒這麼深，你使用十年前的老技術改善 10% 的效率，與使用最新的技術改善 15% 的效率，老實講，使用者感受可能根本沒差，而且你還量化不出來。
因此如果先撇開一些業務話術，真的單純回到 DevOps 本身，我會說好的 DevOps 就是在可預見的未來下都堪用的技術流程，所以根本撇開工具不說，畢竟工具這種東西 — 如同我某個台大電機大神朋友說的，只要是工具就一定學得會的這種狂妄發言 — 總是可以讓我們找到一個 SoTA 方案的，所以總得來說還是回歸到商業模式分析，你有哪些元素是要查看的，其長遠效益與成本評估怎麼去量化，大抵還是這些。
類似以上的圖可能很多人也都看過，將程式開發流程遇到的問題以及對應的解決方案都給挖了出來，撇除那些真的可以在大公司裡面自己搞出專屬工具的神人們來說，其實這些東西也已經很充分了。
當然，實際應用上你還得考量，該問題發生的程度與嚴重性如何，我花費該工具得到的預期收益與前期投入比怎麼算，如果放到管理顧問面臨到的問題，嗯，比較殘酷，我幫你工程團隊搞定這些問題真的划算嗎，還是你根本只會應用這麼一次性而已?
如果專案是這麼策略層面的東西，那當然沒啥問題，畢竟上面的人動得起來就行了，可你終究有脫離乙方出來單幹或自己管理一個團隊或一隻KPI的一天，這時候，遲早這些問題還是得面臨到的。
當然，如我一開始所說，嚴格來講比較令我覺得學習良多的其實是所謂的 Configuration Management 以及 CI/CD 這些面向，我認為一個對許多新創公司與新手學習著很友善的資源在於參考 gitlab 的 Auto DevOps Pipeline :
基本上常見的 Pipeline 像是 Build > Code Quality > Test 這些面向都已經有很泛用的 Script 在等著你了，當然前提是你對於一些基本的工具如 :
等等，有些基礎的認識。
至於那些整天聲稱著 DevOps 一定有一套專業 Pipeline 與 Tools Set 的人士，還是洗洗睡吧，不然你以為為何你的手機塞不下一坨 YOLO v5? 人生就是如此的，洗洗睡。
Data Scientist 也要學 DevOps?
學，都學，哪次不學。
首先，由於 ML 專案的許多特殊性，其實與傳統比較常見的 DevOps 工具是有一些脫節的，這些特殊性我認為可以參考 2015 年提出的一篇文章:
這些特殊性包括 :
- 更強的 Dependencies 管理 : 以當前 Sklearn、XGBoost、PyTorch or Tensorflow 基本上時常一同出現的環境下，其實對套件相依性的管理真的會是 Deploy 的噩夢，比如著名的 Tensorflow 1.0 migrate to 2.0，讓許多人直接就在 Code 最上面加上 :
import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()
# 多麼慘烈XD - 複雜的回饋機制 : 一個模型光是調試到上線可能就是多重 CV 與參數組合折磨，更別提隨著業務需求的微小變動、資料組成的差異，之前調整過的參數等等可能會全數死亡，甚至到了要你修正整個 Code Structure 的時候也是時有耳聞
- 反直覺的程式語言設計 : 許多問題如 Glue Codes、Pipeline Jungles 在 ML 裡面是更常出現的，許多過去的 OOP 概念要遷移過去是需要一些成本去試誤的，而業務時限通常不會因此而延長，造成 Technical Debt 如滾雪球一般長大。
當然這些問題也是族繁不及備載了，而也是因應這些問題，近兩年來許多人的目光轉向了一個嶄新的名詞 MLOps，比如 Stanford 就開了類似這樣的一門課 (2021 Winter) :
歐萊里也多出了一本新書叫做 Introducing MLOps (2020/11) :
這些東西對比以往來說其實都是新舊知識的重組，而且可想而見其重要性會越來越提升，而這些差異雖然說在各大公司都已先行被探索過，但對於整個業界或學界來說的確也還缺乏一些比較公認的標準或習慣來管理這些問題。未來從業者對於 Model 的知識也隨著各種簡要 API 釋出降低成本之下，會轉而對於 Deployment 有更加深刻的了解 :
舉個例子，同樣是做推薦系統，以我自己的經驗做的比較多是屬於所謂的 Cloud Computing，不管是模型更新的即時性、輸出形式與多人訪問要求等程度都會遠小於如 Search Engine、Ads 等大規模且即時的部署網絡，但即便如此我們還是為了如何部署而煞費苦心，不僅是包含我們需要讓其能適應日漸增長的用戶，也包含設計出能即使反饋與調整的一套機制。
總之，這麼一套說下來也是身心俱疲。
當然啦，許多都市傳說也會告訴你比如說 Data Scientists Focus on Research、Machine Learning Engineer Focus on Deployment，然後公司裡頭會有專門的 DevOps Engineer 啊、SRE 等存在去管理這些問題。
但是，你嘛幫幫忙，當社畜這麼久總是會知道，能夠遇到這些規範好的公司其實也是燒香拜佛求來的，何況那怕讓你在 Google、Amazon 當螺絲釘，如果大家不是抱持著一種把自己操死的態度在學習新東西，你確定新專案就落得到你頭上嗎? (看看四周都是名校畢業的大神們)
綜上所述，我就是個，被資方壓榨的可悲奴隸而已哭哭。
總而言之，對於要不要學這個問題，我一向都是抱持著，如果有時間就多學吧的態度，比如以前學過的金融計量方法，偶爾還是得拿出來摸一摸的，DevOps 亦同，廢物如我，對這些東西也只是懂個大概而已，希望看到這裡的讀者如果你對這些領域比較專業的，噴我噴得小力些QQ
結尾
抱怨的話與廢話都不宜過多，我認為到這邊已經差不多可以了，目前是凌晨 12:38，我也不知道為甚麼還在敲鍵盤。總之，偶爾發一些隨筆紀錄，其實也滿能轉換心情的，然後與此同時我的 Docker Image 還是 Error，唉。
