靖本

隨著 COVID-19 疫情的發展，數位轉型不再是個猶豫與曖昧不清的選項。 當昔日可選項變成必選題時，企業不得不細細思量轉變所帶來的意義與價值，以便在市場、利害關係人、公司永續與競爭力之間取得平衡。綜觀這幾年台灣企業在數位轉型議題上多半圍繞在新技術與工具的採用，這樣直觀且具體的作法的確為企業帶來了短期且明顯的改變與效益，不過這樣的效益卻很難延續與擴大，甚至有時還會與企業原有制度和流程產生衝突。或許過往的小打小鬧，還能期待透過時間來找尋解套的方法，但在轉變的需求強勢叩門時，企業需要一個具備系統性的指引方法，來協助自身透過重新審視治理的方式來確保目標達成的同時，還能提供組織應變市場快速腳步的能力! 從資訊部門到全組織 大部分企業內的資訊部門所肩負的多半為企業內部系統，主要的工作在於除錯與維穩，因此資訊系統的管理著重於資訊部門內部… 「穀倉效應」在指出組織內部由於各自責付功能與利益的不同，而產生協同困難，價值流不效率的問題。我們可以在近似領域的不同職責單位 (如，同屬技術領域的維運、安全、開發等各單位) 觀察到這樣的現象，而在不同領域(如技術與商務單位)這樣的問題也就更為嚴重。得助於雲端運算，企業有機會採用數位的方式，更有效地為客戶提供服務。 但是，如果服務管理仍只限於資訊部門，那將會有怎樣的結果呢? 試著思考以下的問題： 1. 如果資料安全僅在資訊部門，資料安全真的安全嗎? 2. 心急如焚的顧客上線尋找協助，需要轉幾手才能安撫顧客，提高滿意度呢? 3. 資訊部門在採用大量開源工具時，如何確保智財與法務上的安全? 4. 當引入新的工具與技術，如何知道它為公司帶來哪些效益呢? 如何知道錢花在刀口上呢? 5. 如何確保上線的新服務，不僅能為公司帶來利潤，同時也符合當地政府的期待呢? ... 那麼，數位時代下的服務是什麼呢?

牆上掛著滿滿的待辦事項，大家你一言我一句地為團隊產品貢獻自己的想法與點子！ 上述是當我們談起設計思維，甚至是敏捷時，頭腦中會浮現的景象。然而，當待辦事項在不同成員齊力產生出不同抽象程度的工作項目時，試問我們要如何有效地從中找出最重要的事情，並且準時地交付給客戶？ User Story Mapping 是管理使用者故事的一種有效技巧，不僅能夠協助團隊逐步地構建產品的待辦項目，也能夠用來整理已經開始迷航的待辦項目黑洞。它具體有以下好處： 以使用者為出發點，透過使用者旅程逐步具體化使用者故事; 確保所有參與者圍繞在同一個產品目標與主題上; 具有全局觀的排序，產生可執行的釋出計畫; 簡單易懂的可視化待辦事項結構; 引起討論，促進協作。 環境與工具 便於走動與張貼的環境，可以善用團隊常用的戰情室； 白報紙數張(如果不夠大可以接在一起)或白板一個； 建議人數 <= 8 人/組； 白板筆 x 三種顏色 ； 便利貼一包 x 三種顏色； 計時器； 安全可開放討論的氛圍。 流程 步驟一：由召集者或者是產品管理者，說明此次的目標，並且確保所有參與者了解 (~ 10 分鐘)： a.

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: 試著想像一下機器學習專案可能會遭遇的場景! 首先，用來建立模型的資料會隨著時間的推移與相關的系統操作而持續發生變動。另外，在進行模型開發過程中，也會對資料進行處理與篩選，這些過程都會影響當下模型的實作與訓練結果(如精確率、召回率等)。為了能夠提供之後改善的基礎，以及提供模型建立的可再現性，環繞於模型建立的相關資訊都應該進行版本控制，當然也必須包含訓練完畢的模型本身。