敏捷與DevOps

Policy (政策) 政策! 是什麼東東 ? 提到政策，就會不小心想到治理、授權等等讓人頭皮發麻的詞。然而，政策在軟體服務中是相當常見的某種需求。簡單來說，軟體服務的政策是什麼呢？ 一組管理軟體服務行為的規則。 舉凡，定義哪些是受信任的主機、使用者能夠存取哪些功能、網路路由、和服務可以部署到何處等，都能視為服務管理政策。所以當你試著實作 feature toggle、試著實作管理員和一般用戶等功能時，便已經涉及到服務政策的機制了。 傳統上的作法，工程師會在服務中實作相關的資料存取與檢查。先不論此類實作所耗費的額外運算資源，如果有多個團隊在實作多個服務，而都需要基於相同規則進行檢查時，要如何進行？如何能夠和服務管理政策管理者有更好的合作？落實管理政策與提供服務彼此之間如何不互相拉扯等待，而導致服務提供效率降低？ 追根究柢，可以把問題濃縮成： 如何讓開發團隊專注在產品主功能開發，讓政策管理者能夠用一致的方法進行管理，而且兩者之間的更動不會輕易地影響對方？ Open Policy Agent 為這個問題提供了一個新的解決方式！ Open Policy Agent (OPA) Open Policy Agent(OPA, 讀音為 歐趴) 最初是由 Styra 所建立，後來貢獻到 CNCF。目前由 Styra、Google、Microsoft、和 VMWare 構成開源專案的主要貢獻者團隊，撰文的當下它也已經順利地從 CNCF 畢業了。OPA 實現了一個輕量的政策管理服務，因此可以作為服務的 sidecar 運行，也能作為獨立的政策管理服務運行於整體服務群內。軟體服務可以基於給定的資訊透過 RESTful API 的方式「查詢」相關政策的判斷結果。此舉成功地解耦了政策管理的相關實作，讓軟體服務可以專注於使用者功能，至於政策則可以透過一個獨立的服務來實現。政策的管理者與資源的提供者，可以透過統一的管理服務來更新相關政策，從而改變團隊的合作模式，並且可以更高效且一致地施行政策。

是否正在煩惱如何更有效地促進資料科學家、軟體工程師、和維運工程師之間的合作？ 是否苦於找尋如何穩定地研發與交付機器學習模型服務？ 是否正在找尋如何持續維持機器學習模型服務效能的方式？ 如果曾經為以上的問題煩惱，或者是希望持續提升團隊交付機器學習服務的能力，那麼 MLOps 肯定是你不會錯過的議題。 機器學習模型並非是交付機器學習服務中 唯一 的工作，由上圖1，可以了解模型本身只不過佔據了實現模型服務的眾多任務中的一小部分而已。機器學習模型服務的開發，不僅僅涉及如何實現模型，還含括了軟體開發與後續維運的議題，因此相較於常見的軟體服務開發來說，複雜度更高也更容易產生技術債務的累積。MLOps 是希望能夠透過 DevOps 的優良實務作法來提升模型服務交付的水準，並且降低或免於技術債務的累積。DevOps 所提倡的持續整合與交付和溝通與協作，也讓習於沉浸在資料與模型實驗的資料科學家們有機會以全局的角度看待服務交付的議題，並且讓整個價值流上的其他人員可以更有效地與資料科學家們合作註2 三個核心概念 1. 版本控制不只侷限於程式碼 版本控制的基本目的是為變更建立可追蹤性，以便作為之後除錯與改善的基礎。 程式開發者透過 Git 之類的工具，為程式實作進行版本控制可能是相當直覺的作法，而這樣的作法，對於資料科學家或者是模型工程師來說，應該也不是太陌生的操作。透過對程式碼進行版本控制，可以妥善管理模型與資料處理的相關實作內容。但對於一個機器學習專案來說，只是管理程式碼實作則是遠遠不足的！ :thinking: 試著想像一下機器學習專案可能會遭遇的場景! 首先，用來建立模型的資料會隨著時間的推移與相關的系統操作而持續發生變動。另外，在進行模型開發過程中，也會對資料進行處理與篩選，這些過程都會影響當下模型的實作與訓練結果(如精確率、召回率等)。為了能夠提供之後改善的基礎，以及提供模型建立的可再現性，環繞於模型建立的相關資訊都應該進行版本控制，當然也必須包含訓練完畢的模型本身。

作為基礎設施的編撰工具，Pulumi 額外提供了基於屬性測試 (Property testing) 概念的 Policy as Code 工具 (“CrossGuard”)。基於這個工具，專案團隊或者是組織可以為所有採用 Pulumi 所撰寫的基礎設施程式，建立獨立於所有 IaC 專案的普遍規則 (比方說資源區域、數量、網路設定、IAM 等)，團隊亦可基於此再添加關於專案的額外限制。透過建立完成的可測試規則，開發者可以在本地端、持續整合流水線、以及在最後佈署前(已經產生基於各公雲或基礎設施服務的組態檔時)進行測試確認，避免需要透過人工檢閱比對，或者是已經佈署完畢後再進行確效，所產生的人力或資源的浪費。 本篇文章作為 Policy as Code 系列文章的起頭，會採用 Python 建立一個簡單的 Policy as Code 專案，為稍後建立基礎設施全面性的規則作暖身。 在開始之前 擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$ 安裝 Google Cloud SDK，並且確認已經設定好 application-default Python 為 3.

轉型就是一種營運模式的變動，單以組織內的任一職能單位來推動與進行轉變，其結果往往不如預期。 Agile 與 DevOps 這兩個在轉型鎂光燈下的寵兒，仍繼續在世界舞台上發光發熱，看著大型科技服務公司們的成功與新興的服務公司竄起，這些都成了追逐改變的主要驅力，大家都希望能夠在下個十年仍然持續茁壯。但當大家提及 Agile 與 DevOps 時，第一印象常是技術單位(比方說 IT)，貌似只要這些單位有了這些能力就會飛翔，或者是只有這些單位有能力推動相對應的改變。這些改變都是以技術單位為中心然後展開。但最終其結果呢？或許有了些新的工具、或許有了些新的名詞，但所謂的振翅高飛卻還需要些時日，大家都苦於找尋那轉型的聖杯。以我個人來看，聖杯是迷幻的，然而轉型的確有較好的方式與工具來協助提高成功的機會。 以價值驅動的服務 這幾年由於各種技術的躍進，服務越來越能以貼近每位使用者的方式來提供，然而這樣的交互模式，進一步的提高使用者對於服務取得的期待。除了服務本身，企業內的各個單位(比方說銷售、客服等)也必須能夠有相匹配的反應速度，讓使用者被提供的服務環繞著，並且取得確切的成果。上述所提及的就是最耳熟能詳的 端到端 的價值，而剛好 Agile 與 DevOps 的核心都在確保價值的產出。 那這些為什麼就獨厚了技術部門呢？ 其實也不盡然獨厚了技術部門！反倒是說，錯誤地獨厚了技術部門，才是讓所有轉型展開發生困頓的主因。 技術部門坐落於生產和後續服務維護的位置，也就說它們的產出與使用者的需求直接掛鉤，由於這幾年響應速度變快的原因，使得原本透過銷售與客服的隔熱服務，穩定產出服務的技術部門，反而必須更勇敢地向前一步與使用者互動。在此，必須意識到的是，由於數位思維的發展，公司內的營運與技術之間的融合，顯然技術部門很難自身於外，因此不管是做事的心態也好、或擔負的責任也好，都將技術部門推向 轉型漩渦的中心 。處於中心只不過是個客觀的事實(或許)，而漩渦所覆蓋的範圍才是轉型的全部！