Augustin Lu

前面的文章花了不少篇幅討論什麼是風險、誰應該參與風險管理、什麼樣的 AI 才值得信賴，以及導入 AI RMF 後應該期待哪些改善。但知道這些事情後，下一個問題自然就是： 這些風險管理的想法，到底要如何轉換成組織實際可以進行的活動？ 這也正是 NIST AI RMF 第五章，也就是 AI RMF Core 所要處理的事情。NIST 將 Core 定位為一組用來促進溝通、理解與風險管理活動的成果（Outcomes）與行動（Actions），並將整個 Core 劃分為 Govern、Map、Measure 與 Manage 四個 Function。每個 Function 之下又進一步區分為 Category 與 Subcategory，逐漸把高階的風險管理概念細化成組織可以思考與落實的成果與行動。

前三章討論了風險、關係人和信任，這也是在運用 AI 技術時應該思考並且尋求平衡的要素，但當我們認同這套方法，並且開始將 NIST AI RMF 導入組織時，又會浮出另一件重要的事那就是「這些規範或做法到底做對了嗎？」。NIST AI RMF 的第四章便是想要回答： 如果組織採用了 AI RMF，應該從哪些地方觀察它是否真的改善了 AI 風險管理能力？ 不過，可信任或 AI 風險等議題要如何有一套客觀且能作為基準的評估作法並不是一件簡單的事，所以 NIST 和相關社群目前也還在致力於找尋一套如何評估的框架或方法。不過，可以確認的是任何有效性或改善程度的確認，都需要透過週期性的評估才能得知，而觀察的範圍應該要包含政策、流程、實務做法、執行計畫的內容與狀況、指標、衡量方式和預期成果，以便能夠從風險管理能力和AI 系統的可信賴程度兩方面，了解組織在 AI 治理上是否達到預期的目標與效益。 在第四章中，特別羅列了運用 AI RMF 可能獲得的九項預期效益： AI 風險管理流程更加成熟且完整

這篇文章是介紹 NIST AI RMF 第三章系列文章的最後一篇。當 AI 系統真正進入組織與使用者的決策情境後，除了前一篇文章1中提到的三面向外，尚有另外四個面向，分別是可追溯與透明（Accountable & Transparent）、可解釋與可理解（Explainable & Interpretable）、隱私強化（Privacy-Enhanced），以及公平與有害偏見受到管理（Fair – With Harmful Bias Managed）。相較於前一篇較偏向系統本身的有效性、安全性與韌性，這四個面向更直接牽涉到 AI 與人、組織及社會之間的互動。換言之，AI 不只要「做得對」，還需要讓人知道它為什麼這樣做、誰該為結果負責、使用者的資料是否受到妥善保護，以及不同群體是否受到合理且公平的對待。接下來本文將分別介紹這四個面向： Accountable & Transparent 可信賴的 AI 必須具備問責（Accountable）性，而問責又建立在透明（Transparent）的基礎上。這裡的透明不是單純把所有資訊公開，而是依照 AI 系統所處的生命週期階段，以及不同角色的知識與需求，提供適當程度的資訊。這些資訊可能涵蓋系統設計決策、訓練資料、模型訓練方式、預期用途，以及部署與實際使用過程中的重要決策。 透明的目的之一，是讓人能夠理解 AI 系統發生了什麼事情，並在錯誤或負面影響發生時，具有追查與補救的可能性。因此，資料來源、決策紀錄以及相關文件都可能成為支援透明與問責的重要機制。當然提升透明與問責本身需要投入資源，也因此在思考此面向的實現時，還必須考量商業機密、專有資訊以及智慧財產權等限制。換言之，透明並不是資訊揭露越多越好，而是要在風險、使用需求與實施成本之間取得適當平衡。

這篇文章延續 NIST AI RMF 第三章，討論如何在有效、可靠、安全、資安與韌性等條件下思考 AI 的運用。這些概念分別集中在第三章七個可信賴面向中的三個面向，NIST 也引用 ISO 9000:2015 與 ISO/IEC TS 5723:2022 等標準中的相關定義來協助說明。接下來本文將分別介紹這三個面向： Valid & Reliable 此面向其實濃縮了四個軟體系統上的特性，不過我們可以直觀地先就字面意義來了解此面向。Valid 代表的是所期待即所得，而 Reliable 則是在既知範圍內保證系統仍持續提供有效的能力。進一步來討論這四個特性分別是： Validation 此特性關注的並非單純「模型準不準」，而是整合模型後的 AI 系統，是否真的滿足原先所設定的使用目的與需求。換言之，即使模型本身的評測結果很好，如果放進實際系統後無法完成原本期待的任務，仍然不能說這個 AI 系統已經被充分驗證。 Reliability 此特性並不是要求系統在任何情況下都必須提供可接受的回應，而是在已知且事先界定的使用條件與時間範圍內，能夠持續依照要求運作。這裡的重點在於持續性，一個偶爾能夠給出正確結果，卻無法在預期條件下穩定維持表現的系統，很難被稱為可靠。 Accuracy 此特性就相對直觀了，也就是系統所得出的結果與實際的結果或可接受的結果相當靠近，甚至是一模一樣，而在模型實作上，我們也往往追求此特性。不過需要注意的是 Accuracy 的追求是有其成本和代價的，所以在設定期望的 Accuracy 時，應該考量實際業務的需求和成本。 Robustness Robustness 代表的是當輸入、環境或使用情境產生變化時，系統是否仍能維持適當的功能與表現。這些變化甚至可能包含原先設計時沒有預期到的使用情況。因此，Robustness 並不只是「輸入變了還答不答得出來」，也包含系統進入非預期情境後，能否避免產生不合理或可能造成傷害的結果。 上述四個特性構成了 Valid & Reliable 面向，而此面向也是七個面向的基礎，畢竟不能持續提供可靠且值得相信的結果的系統，我想討論其他面向都是沒有意義的。

在討論了風險、風險管理和參與風險管理的不同利害關係人後，NIST AI RMF 要討論的一個核心問題是「到底怎樣的 AI 才是可以信任的？」畢竟風險來自於 AI 系統本身的不確定性，以及這些不確定性對系統可信賴所帶來的影響。 上圖是 NIST AI RMF 第三章針對 AI 可信賴議題所提出的七個考量面向1。當我們試圖討論 AI 系統是否可信時，思考的出發點必然是所有利害關係人對於此系統在這七面向上的要求與期待是什麼！若系統的設計與開發者能夠強化與重視這七面向上的議題時，系統所帶來的負面影響，才更有機會被控制在利害關係人較能接受的範圍內。反之，系統風險將會增加並且平添不要的問題。讀到這邊，聰明的讀者應該不難發現兩個沒被說清楚的問題： 強化七面向上的要求與議題，具體是哪個面向和哪些議題？ 所有利害關係人能接受的狀態，又是怎樣的狀態? 說到底人人都滿意的方案有正確的解答嗎？而這些解答與滿意是否能持續不變？ 想當然爾，上述的問題很容易會得到「依情境而定」與「權衡」兩個結論。這是因為可信賴性（Trustworthiness）並不只是技術或工程概念，同時也是一種具有社會性的概念（Social Concept）。換言之，答案和期望往往是如同光譜一樣展開，很難有非黑即白的答案。這也正是 AI 應用在帶來益處的同時，所帶來的棘手問題。 此外，除了各面向在不同利害關係人之間的答案有所不同外，面向之間也會產生影響。比方說，為了提升 AI 應用的可解釋性，可能需要保留或利用更多與使用者相關的資訊，但這是否又會侵蝕使用者的隱私權？又或者說，我們為了能夠保障使用的隱私，使得高維空間下資料分布過於稀疏，進而降低模型的準確度。那這樣所產生的結果是否又會影響推論結果的公平性呢？ NIST AI RMF 也明確地指出這樣的權衡並沒有唯一的解，所有參與規劃和設計的利害關係人需要面對的核心議題是「決策情境」和「價值」。簡單說就是在決策前搞清楚應用 AI 的情境和條件，並且確認這些設計與治理上的投入，是否真的能為既定目標帶來足夠的價值。與此同時，適當且充分地揭露這些資訊，以便讓 AI 應用變得可信賴。

延續系列文章的風險與風險管理，目前討論到的都是需要管理的目標和管理時的要點，但說到底誰來管理這些風險？又是誰來為識別與提出這些風險呢？ 因此，在討論完風險後，最重要的是了解在這些管理活動中，到底有哪些角色需要參與，才能讓整個風險管理活動更加周全。從直觀的角度來看，通常會想到組織內人工智慧相關技術的資深工程師，如資料科學家、模型工程師等，又或者是品質系統或治理單位的成員等，但實際當我們在思考人工智慧技術應用到組織內時，這些角色（Actor）應該考量所有會影響 AI 系統如何被設計、建置、部署、使用、評估，或會受到系統影響的人。 NIST AI RMF 認為人工智慧之於組織與人，並不是技術單方面產生影響，而是人與技術之間持續互動，也就是社會技術（Socio-Technical）的視角。因此,想要正確地理解所有利害關係人得先回到該規範第二章中所描繪的 AI 系統的生命週期與關聯面向，如下圖： 此圖1來源自 OECD，並且針對 Test, Evaluation, Verification, and Validation（TEVV）和 AI system 的 operational context 進行了強調與調整。從圖來看，第二圈指出思考模型的四個面向，而最外環則指出 AI 系統生命週期的各階段。不過整張圖的重點在於一件事，也就是 AI 系統的生命週期並不只是在於模型開發。AI 系統的生命週期涵蓋從資料蒐集與處理、模型建立、部署與使用，到營運與監控等活動，並且形成持續迭代的循環。

風險管理就是管理風險，聽起來好像很直觀，但具體來說要做哪些事情呢？是對風險進行評估？是來一場審查？是進行一次稽核？或者進行某種測試？感覺聽起來沒問題，但感覺好像又漏了些什麼！ NIST AI RMF 再一次沿用了 ISO 31000:2018 對於風險管理的定義： 組織為了針對風險進行方向引導與控制，而有系統地協調各項管理活動 簡單說，風險管理並不是進行某一種單一行動，而是協調多種管理活動，讓組織在面對風險時能夠建立一致的方向、做出適當的判斷，並採取相應的控制措施。 因此，風險評估、審查、稽核或測試都可能是風險管理的一部分，但單獨進行其中任何一項，都不能代表完整的風險管理。在後續的文章中，我們會逐步地去瞭解 NIST AI RMF 在風險管理上所主張的相關活動與舉措，但在進一步了解這些方法前，最重要的是有正確的 mindset，因為這樣才能讓自己在規劃與執行風險管理時仍持續地保持謹慎並且尋求更好的做法，而建構 mindset 的最好方法，不外乎就是了解風險管理的棘手挑戰。NIST AI RMF 在這裡進一步提出了四個 AI 風險管理需要面對的重要課題： 1. 風險衡量 組織的資源永遠都是有限的。為了能夠正確地將資源投到關鍵的風險，對風險進行衡量是相當重要的舉措。在面對尚無有效衡量方式或尚未進行衡量的風險時，很難憑藉直觀方式來判定是否需要投入資源，畢竟未能被衡量的風險，既不能假定是高風險也無法認為不能衡量就是低風險，而這也是規範裡開宗明義所指出的一個要點。 常見的風險衡量方式多半會設計一些評估條件並且透過風險矩陣來進行。不過聽起來貌似簡單，但面對 AI 應用，NIST 針對衡量又提出了七類的挑戰：

這些年，AI 的蓬勃發展和誘人的可能性，早已讓組織一股腦地投入 AI 相關應用與探索，以便提升自身的競爭力。不過隨著技術漸漸落地，應該也不難發現 AI 所帶來的不確定性。比方說，即便發送相同問題的請求，AI 也無法保證次次給出相同或預期的結果，而且這還不討論近幾年大語言模型的幻覺現象。因此，想要從 AI 獲得好處，我們需要思考的是如何管控這些不確定性，並且做出合理的權衡決策。 NIST AI RMF 便是用來協助組織管理 AI 所帶來的風險與影響，讓組織能在控制潛在危害的同時，真正取得 AI 所帶來的效益。 想要了解這個工具，首先得先來聊聊 Risk 在風險管理情境下的概念。在日常情境下，聽到 Risk 這個字多半會先想到負面的事件。不過在風險管理的角度上來看，Risk 卻有更為寬廣的定義。 ISO 31000 定義 Risk2 為不確定性對既定目標所產生的影響(effect of uncertainty on objectives)

生產！生產！生產！ 每當有新的技術出現時，肯定會以生產力倍增等讓人目亂神迷的字彙登場，不管是 20 年前的教你事半功倍的敏捷，還是十年前小步迭代快速前進的 DevOps，誰不想當菁英團隊呢？不只是老闆想，工程師也能從創造過程中得到滿滿的成就感。這次的 AI 風則吹得更強，不僅有快和生產力，連同取代誰取代誰的新聞也不停地被宣傳。 AI 已經成了不可逆的趨勢 軟體工程師或多或少都會使用 AI 工具來協助自己的開發，更何況現在大型組織甚至會以公司政策的方式推廣。用的人是變多，但相信的人呢? 從 2025 年的 stackoverflow 報告來看，卻只有 33% 的工程師相信 AI 的產出1。當然用或不用看個人需求，但新聞卻一直訴說著，AI 正在取代軟體工程師！組織內會有多少比例用 AI 取代之類云云。不過，隨著時間過去，這些訊息看起來顯得開始漸漸冷靜。開始有科技龍頭表示，他們有著新的軟體人才需求。說到底，到底怎了？，這訊息，這日子還要不要過了呢？ AI 變動了軟體開發過程的成本配比 一個軟體開發的團隊，不管怎樣配比，肯定寫程式的人比較多。畢竟這是一個現實的議題，需求沒實現出來，一切也就都白搭了。只是當軟體開發出來，就會發現還有很多工作等著要處理，所以全端、全循環、一條龍等工程師頭銜總是能夠喚起工程師們嘴角的苦笑。不過現在這個程式生產活，貌似有了一個沒心沒肝又不喊累的 AI 可以頂上了。 哇~瓶頸有解了！

端到端的價值與增長的技術債 面對遺留的程式碼，若要進行技術、架構或工具上的轉換，你會如何進行? 是規規矩矩地重新改善程式碼，還是先上再說? 這個問題對於工程師或者是開發團隊來說，通常不容易回答! 即便回答了，這個答案也會浮動。這是因為組織需要向著最終的產品價值持續發展，而這也導致研發團隊必需或不得不持續地讓技術債增長。DevOps 從維運在敏捷實務做法上的探索，到開發與維運之間的協作，再到端到端價值的追尋，但這就像雙面刃讓持續地價值追尋也等同於持續地增長技術債務。從 Gartner 的調查1中，可以發現技術債增長的前幾個主要原因(僅列出部分)有： 過度地為了市場的需要而造成軟體架構或設計的脆弱； 追求時效而更甚於軟體品質； 技能落差。 面對這些技術債的問題，研發團隊通常採取的行為，不外乎： 紀錄、追蹤、排入改善時程； 找尋重構機會； 透過測試案例維持最基礎的品質； 監控與偵測，以便即早發現問題並且解決來降地衝擊。 然而，我們真有時間和精力花在這些行為上嗎? 還是單純為了精神上的救贖? 這個問題在 LLMs 橫空出世後貌似有了一個解答，那就是： 用 AI 來提升我們的生產力吧?

今年有很多機會幫忙客戶處理軟體品質提升和測試執行效率的議題，每每檢閱各種資訊後總是感觸良深。 一般來說，軟體開發通常都會有測試，但多半會著眼在類驗收型的測試。這類測試通常是軟體開發的品質活動下限，畢竟你的交付對象不可能不驗貨。不過這類測試有個大家都知道的問題，那就是通常很晚期才會知道對錯，而且執行期會看起來很長，畢竟所有測試都在最後一刻統一驗收。一口氣驗出所有問題，然後解決問題，時間很難不長。如果再搭配窘迫的測試人員和資源，那問題就很驚人了。 通常想要改善這情況，有幾件事得思考： 降低最終測試案例數量。可以做的方式如只驗收影響的部分、等價類劃分、透過風險和覆蓋率因素來分散測項的執行或改良與刪除無效測項等。不過這些方式能否有效展開的前提在於對受測系統的功能與模組的掌握度和良善的測試案例管理。如果沒這兩個前提，那麼很難做好什麼減量的決策，畢竟沒有依據。 多樣的測試方式與早期測試，也就是我們常說的左移。在工程上，一個基礎的原則是 built in quality。簡單說就是在每個軟體開發階段都確保該階段交付物的品質，不讓瑕疵流到下個階段。話是這麼說，但想做好這件事卻很少有速解方案。以單元測試為例，或許會有一個單純的想法那就是從現在開始規定大家都要寫單元測試。通常很容易會觀察到兩種結果，那就是不了了之和施行效率不佳。接著就會開始常見的故事： 那麼到底是誰的錯呢？ 正解是整個開發系統的錯，或者非要說誰的錯的話，那大概就是全部參與者的錯。 為什麼是這樣的理由？如果組織在新產品或專案或團隊的一開始沒有左移測試的念頭或至少融入一些除了類驗收測試外的其他測試手段。通常亡羊補牢並不容易，因為組織內的工程人員和非工程人員早已經長期透過各種方式貼補或容忍品質議題，而這類慣性會成為引入所謂「正確」做法時的巨大阻礙。此外，從未考量類驗收型測試外測試的軟體系統要再為其撰寫其他類測試有可能是相當困難的事情，因為目前的軟體實作結構可能盤根錯節且沾黏嚴重(耦合度高)。面對這樣的軟體系統，一般做法都會從舊系統內的新實作開始落實。不過，這類施行方式會有幾個關鍵議題需要尋求所有該系統參與者的共識： 成效可能不容易立即彰顯，而且開發時間還變長了！畢竟既有系統的原有品質問題不會憑空消失，所以會產生一種雖然投資了品質活動，但怎還是有問題的現象。這類認知落差非常需要被重視和解決，否則可能加劇工程和非工程人員之間的摩擦。可能的解決方式不外乎事前溝通、對齊關注指標、或針對高度有問題的部分做一次性的改善等。 測試不只是學會工具就行。測試有時會需要軟體設計方面的知識，所以千萬別認為送人去學 xUnit 之類的工具，然後就要馬上雞犬升天。通常是會升天，但可能不是你想像的那種。因此，除了強化測試技術本身的學習之外，持續強化工程團隊在設計上的能力也是相當必要的。可能的進行方式除了培訓外，還可以考量組織內非正式研討活動和加深團隊對既有系統的理解等。 萬年不變的流程和政策造成的變革阻礙。此處的流程不只包含開發，還需要考量開發流程的上下游或分支流程。除非在意的只是有沒有某種測試技術活動，而成效次之，那麼的確還真不用想太多。若是希望這些活動能夠紮根並且持續發展和提升，那麼除了考慮工程相關流程外，最好也思考一下與該受測系統相關的業務流程或其他營運流程，同時重新審視這些流程所涉及範圍的政策，以便去除不必要的摩擦。

說到 DevOps 免不了會讓人直接聯想到各式各樣的工具，而這也是 DevOps 之所以能夠加速軟體生產力的方法之一。 工具的使用，如果只限於個人，那麼就只是個人的意願問題而已，但如果把工具引入團隊內，那麼這問題就會稍稍變得複雜！比方說： 團隊內的成員是否熟悉這類工具？ 工具要如何融入團隊目前的工作模式？ 如果是工具舊換新，那麼資料要如何遷移？ 團隊是否有空做出改變？ 工具使用的成本是否可以承擔？ 講到這裡是不是開始覺得一陣頭昏腦脹了呢？不過就用個工具嘛！ 可別在這邊危言聳聽~ 上述的問題，運氣好的話的確有可能經過一陣摩擦後順利落地。運氣好不好這得端看工具影響的範圍和深度而定，結局就又回到上述各個問題。筆者就曾經遇過團隊花了大價錢買了工具全年的訂閱也請了外部講師做了一套培訓，結局是工具從一開始的零星使用到最後無人使用。這樣的故事並不少見，而當工具導入擴及到全組織時，那問題就又顯得更加麻煩。當然講到這邊都還只是提到工具而已，而 DevOps 可不只有工具，還有許多工程上的最佳實務做法… 所以到底該怎辦比較好？ 掌握工具或實務做法的影響範圍是做出任何改變的重要第一步！ 流程說穿就是完成一件事情的一連串活動和做法。如果我們能夠了解導入目標所相關的流程的話，那不就可以順著流程知道哪些活動、人和工具會受到影響，從而掌握影響範圍。因此，筆者在協助企業進行各式 DevOps 導入時，第一件會做的事情就是進行流程對照(Process Mapping)的活動。流程對照名詞聽起來很厲害，但其實就是透過視覺化的方式來把做事過程塑模下來的活動。進行這類活動有以下幾個步驟：

今年剛好有機會受國家資通安全研究院的邀請去參加 DevSecOps 人才培養的討論，與會者有的來自學界而有的來自產業界。整個討論以核心、次核心、外圍的任務、知識和技能的超大表來進行，項目總計應該有近百項，所幸研究員設計了一個討論方式，讓整個討論不至於按表操課到枯燥乏味，但是最後討論還是持續了三個半小時多。過程中，還有一些共同表達意見的部分，則又提供了一些貼心的小舉牌(如下圖)。 特別提出這個小舉牌其實是因為這種做法是相當值得稱許的。直觀來說，想法表達大致上就是「是」或「不」，這種極端答案，但實際上團隊討論時的確會存在實質願意配合而沒有特別想法的成員。這種時候逼迫他們非要選隊站，很容易提升作出選擇的困難或是導致討論變得極端。 回到 DevSecOps 人才職能的議題上，目前職能的項目和類型是以歐盟標準為核心，輔以美國的標準。 標準設計上，DevSecOps 工程師一職是被設計在安全交付此面向上，但安全「交付」的交付二字為這個職能帶來許多挑戰。面對不同類型的組織，其組織內的資安角色並不見得有如這類標準所列出的精美配置，所以這也使得該職能工程師的工作範圍可大可小。不過，可能會有人認為 DevSecOps 它是一種機制、文化或做事的方法，而非一個角色，這說法自然也沒什麼毛病，但就像 DevOps 本質上也是種軟體開發的做法、機制和文化，但最後市場還是多了很多 DevOps 工程師和部門，所以 DevSecOps 也很自然地往這方向發展。往好的方面看，這也代表這樣的機制、做法和文化被期待內建到組織中。或許文化這樣的概念會因為這些內建的演進漸漸地在組織中形成吧!? 所以簡單來說，從當前標準的職能定位來看，DevSecOps 這類角色有點像是昔日的安全工程師加上 DevOps 工程師的味道！ 有這麼簡單!!!?? 這幾年在現場協助企業落地實施 DevSecOps 時，我比較容易感覺到這類角色常常就是我們半驕傲半苦笑說的一條龍工程師 再加上需要了解「安全知識」並且「知道如何將安全左移到每個軟體生命周期階段」，以便確保軟體在「端到端“交付”是安全的」。講到這兒~我不禁為這職能捏把冷汗，心裡直嘆好厲害的一個角色。

溝通是一切的起點，而最有效的溝通在於面對面 BizDevOps 的目標在於讓商業人員、管理人員和工程師能夠有一致的目標，並且在具備共同認知的情況下協同達成目標。為了能夠達成目標且提供客觀的基礎，資料驅動是必要的方法，透過資料我們可以將產出、任務、需求、流程和商業關係聯繫起來，從而能夠透過整體的角度來思考需求並且制定權衡的政策。 有了權衡的政策，下一步便是找出需求和制訂計劃，並且透過團隊的工程能力來實現需求。這一連串的過程涉及了不同人事物的溝通和資訊交換。單純地透過文字是很難在第一時間將彼此對齊在同一個認知上，需求的利害關係人必須面對面地確認和協調需求的樣貌。 基於面對面的溝通也才能有效地勾勒出需求的輪廓並且找出具體的實例來協助團隊中的每一個成員，運用自身的能力來實現需求。 完整的團隊仍然是一個關鍵要點 傳統組織按職能區分人員結構，這讓組織人才的技能得以深化且經驗得以順利傳遞，但這也使得面對面的溝通變得困難，甚至是讓不同職能的人對齊組織的價值目標也變得困難。畢竟每個人都專注於一整件事情的某一部分，對該部分負責也對專責的技能負責。 為了突破這種僵局，思考如何在組織內按照價值目標組建一個 5~15 人以內的完整團隊，就變得關鍵，但只是把一群人集合起來就想要獲得一個高效的團隊，這仍然是把事情想得過於簡單！不同的背景、不同的能力、不同的個性和各種不同會讓新組建的團隊深陷在風暴中，難以逃出，所以想要讓團隊快速脫離磨合期並且持續改善成長。團隊務必找出： 團隊協定:人與人之間合作的方式 任務標準:處理事情的標準 透過找尋協定與標準，會幫助團隊更加了解彼此，並且知道團隊內的障礙。 一個團隊就能夠頂全部的產出? 除非公司自行開發的資訊軟體很少或沒有，而且也不太使用軟體服務，否則單靠一個小團隊就要面對各種問題，恐怕團隊也會隨著組織的增長而慢慢吃不消。 因此，我們必須思考如何組建一個有機的大團隊！ 有機的大團隊以拓樸的角度看待每個自組織的小團隊，讓大團隊中的各種能力可以發揮在必要的目標上，而且也不會因為強迫拆分所造成部門牆導致價值目標的破碎和工作依賴所造成的浪費。 不過，就像團隊內需要有協定與標準！團隊之間也需要有協定和標準，以便讓各團隊之間可以快速地進行協作達成目標。團隊期待他人(團隊)與其合作的方式和標準就是團隊的 API。簡單說就是團隊的使用手冊 不管組織是透過自組織方式來組建各種團隊還是透過組織情境與需求來組建團隊，我們都可以透過團隊拓樸1的概念來思考。按照《Team Topologies: Organizing Business and Technology Teams for Fast Flow》一書中所言，組織裡的團隊按照其交付內容的質性可以分為四種基礎類型：

SBOM 雖說 VEX 並不盡然需要依賴於 SBOM，但在討論 VEX 之前，肯定必須先了解一下 SBOM（Software Bill of Materials, 軟體物料清單），因為這樣才能了解 VEX 的必要性和它所想解決的問題。 軟體物料清單提供了軟體組成的相關資訊。這些相關資訊會說明這些組成是由誰提供、由誰開發、包含哪些項目、何時建置和依賴訊息等訊息。這些資訊對於提升軟體的透明度相當有幫助。因為使用者能夠透過這些資訊了解該軟體所採用的套件或其他工具是否存在可被利用的漏洞而需要立即進行修補。 SBOM 之所以受到關注還是要歸因於從 2020 年後的三起重大的資安事件，包括 Solarwinds[1]、燃油管事件[2]和 Log4j[3]。這三個重大資安事件促使美國總統在 2021 年時簽署了行政命令，責令美國商務部和美國國家電信暨資訊管理局（National Telecommunications and Information Administration, NTIA）需要在 60 天內制定 SBOM 的最基本要件。雖然 SBOM 對提升透明度的確有所幫助，但它畢竟仍是一個靜態的資訊。軟體使用者仍需要從軟體供應者處取得該軟體相關組成的漏洞狀態，才能夠進一步確認當前軟體受到漏洞影響的狀態，而 VEX 正是提供此關鍵訊息的機制。

在許多場合談到最後負責時刻的時候，總是很容易引來質疑和訕笑的回應。 說到底只不過不想決定；做了再說講這麼多 最後負責時刻（Last Responsible Moment, LRM）指的是延遲決策造成的代價高於決策成本的時間點。簡單說就是期望在擁有最多必要資訊且還有賺頭時來進行決策，以便讓決策最貼近解答。只不過這個時刻往往是答案呼之欲出的時間，再不做出決策，那就是被決策了！理論上來說，這的確是一個很甜蜜的決策點，然而回到了現實，最後負責時刻彷彿成了拖延病或衝動的理由。 最後負責時刻聽起來很簡單，但基於這個概念做出決策前，其實有兩個要件需要思考，分別是：決策情境和資訊取得方式。 當處在「繁雜（Complicated）」的決策情境時，決策者可以透過分析資訊來了解該採取何種行動，而且在此情境下，想要收集哪些資訊和如何收集是相對清楚的，這是因為因果關係仍然可以理解。因此，最後負責時刻在這樣的情境下有最大的效益和清楚的時機點。至於「明確（Clear）」的情境就更不用說了，相關的資訊可能在映入眼簾的當下就已經清楚明確，而手邊也早有應對之策。從得知到決策到採取行動或許順暢到連決策者都沒有感覺到做了決策。 當情境變得模糊不清且「複雜（Complex）」時，資訊取得的手段往往需要額外採取行動，而無法單純靠既有機制來收集足夠的資訊。比方說，需要透過 MVP 或 A/B 測試來了解真實情況，然後再依據結果來做出最後的決策。這個時候會出現一種先行動再決策的直觀感受。如果決策情境進一步複雜到「混亂（Chaos）」狀態時，打帶跑的現象就會更明顯，而且被推著跑的感受也會跟著明顯。在這些情境下，行動被提前至最終決策之前，甚至最終決策的樣貌都慢慢不易被描出框線。決策和行動之間的界線變得模糊，而使得決策就像是被拖著，然而這卻是情境使然。最終，決策者仍需做出決策，而且必須加緊速度在嘗試仍然有效前做出決斷。 尚不論 Cynefin 的中央區域，其四種情境也只有「繁雜」情境在感受上有較為清楚的決策時刻，其餘要不是過於明確要不就是需要多試試。這讓最後負責時刻感覺起來顯得就像是遲延決策、沒有決策或不用決策做了再說的代稱詞。 在當前的商業與科技進展下，VUCA 就像是一種常態。最後負責時刻其實是相當重要的概念和原則。它能夠降低決策風險，讓組織更容易適應變化。決策終究是要下的，只是有時它需要一些前期的準備。與其埋怨決策被拖延了或沒人要做決策，倒不如思考如何提出一些行動來獲得更多資訊，以便最終決策的進行。不過有時團隊成員對於決策者的不耐煩有可能來自於資訊落差，所以身為決策者應該讓成員了解事情的梗概並且保持必要資訊的透明，而不是忍著而最後成了團隊的瓶頸點，這不僅無法提升決策效率，也會傷了團隊的凝聚力。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

這次訪談的對象很有趣，為什麼有趣呢？主要是因為受訪者是一家證券商的乙方，而此次談論的主體卻是甲方。受訪者並不是因為想八卦或吐苦水，倒不如說他展現了對於甲方環境的認同感。究其原因或許是配合的時間長而且甲方在領導上也有獨到而體貼之處吧！？不過再深入就變成相談所八卦了，讓我們趕緊來聚焦一下今天的主題吧！ 一如常見的配置「業務單位是需求方，IT 單位是實作方」，而這樣配置也出現了一如往常的問題。那就是需求模糊和實作衝突與延遲的狀況。不過，幸運的是甲方領導者對此有所認知，並且也公開支持透過迭代和需求規劃調適等方式來處理，而且還為此制定了需求拆解和評審的機制，然而不幸的是這些做法最終卻在現場撞個粉碎，沒有產生具體的效益。 日子仍然一如往常 價值總會在情境轉換時產生失真和磨耗，透過敏捷的方式能夠讓團隊聚焦於資訊充足且重要的需求上，但這一切都需要商業和工程雙方的搭配 才能夠達成。這不只是工程上的最佳實務做法，也是實現商業價值的最佳實務做法。雖然受訪者單位的領導者支持相關的改善，然而在訪談過程中可以觀察到幾個問題： 商業端最高主管高於工程端最高主管，使得商業端與工程端的衝突並沒有對等的糾紛處理平台，而且也會使得技術人才從組織中流失，或者只寧可轉往做人和商業方向前進，因為這樣才能獲得更好的發展。這種情況對於高度依賴資訊系統的商業體來說是相當危險的事情！這意味著組織裡的資訊系統會因為人才經常性流動而無法培養出具備技術且熟稔該系統的人員，進而使得組織在資訊系統危機處理上相當脆弱。這種不對等狀況也自然會反應在需求分析與調適上，畢竟商業說了算，而且研發人員的經驗相對資淺也難以做出合適判斷。 有條件地忍讓無法為改善做出調整的人。在組織中進行改善是一件涉及所有利害相關人的活動，所以不僅要謹慎地確立目標，而且也需要堅持目標。如果會因為組織中某些較為資深或任何具備特殊條件的人而有所轉彎，會使得其他參與者傾向取得特殊條件或推託執行。改善就只能往失敗的方向前進。 比較讓人感到遺憾的是在訪談過程中也發現了敏捷萎縮的狀況。由於長時間無法達到改善目標，而開始改採評審和各種細節規則的管理措施。倒不是說評審或細節管理不好，而是當制度的設計無視遵守者所處的決策情境時，就會導致制度失效、時間浪費和心理不安全的情況。雖然上述的狀況不容樂觀，但受訪者仍對於所處環境和工作抱持著熱情。訪談就在一來一往過程中接近尾聲，而我們也為訪談過程中的疑問提供了解答和一些改善舉措，並且約定後續保持聯繫來繼續提供建議和支持。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

這次訪談的對象是在中國設了研發單位的香港公司，由於 Covid-19 的影響使得這個年紀尚輕但又稍具規模的研發單位飽受困擾。該公司原先並未有明確的協作工具。成員之間的溝通靠的是線上會議和電子郵件的往來，但由於並沒有具體存放討論內容或思考內容的工具，彼此之間的知識交流也就靠著有有一搭沒一搭的零星紀錄來達成，而誤會和麻煩也就因此而起，比方說： 工作換手困難； 權責難清； 理解時間長； 資訊遺失。 即便這個新單位一開始就以敏捷的方式配置一切，最終迎接他們的就只剩下爭吵和無法達成目標。為此，他們採用了一個需求追蹤系統，其實就是自建了一個開源的知識管理工具，讓所有的人將各自的想法和平時的討論紀錄下來。這樣簡單的做法改善了他們的討論方式和協作的效率。 關鍵的改善往往勝過千萬個煙火式的實務做法，基於需求的單純解決方案，反而更有力量。當我們面對遠距協作需求時，有兩個很大的要點： 資訊共享； 體諒他人。 資訊驅動著人之間的討論。如果沒有一個共有而且即時的管道，人和人之間的討論將單純的基於假設和主觀認為。這樣的情境就算有爭吵也不會是太意外的狀況。不過，當回到了遠距，直覺上可能覺得大家會偷懶，但實際上大家更可能不知不覺地模糊了工作和生活的邊線，進而導致過勞。 因此，當團隊需要進行遠距協作，務必記得下列幾點： 提供便捷取得必要資訊的方式； 建立彼此之間的即時溝通平台； 尊重隱私並且建立溝通和協作原則； 在限制下，提供最多的團隊實體交流機會； 為他人設想。 當工作自由和生活自由重疊時，有時會造就出的不是更自由，而是更不自由且透支的狀態，而且遠距所造成的資訊不連續更是讓效率低落的元兇。此次的訪談對象透過簡單的工具（基本上沒做任何客製或特別技巧）解決了團隊工作推進的問題，並且降低了爭吵的狀況。這便是專注瓶頸解決問題的重要之處。不過，在訪談過程中，可以觀察到由於長時間遠距而加劇穀倉問題。因為他們原先透過明確職責分配和透過工具指派工作的做法，使得跨域成員之間的交流低落。或許他們接下來應該專注的是讓成員意識到跨域交流和技能學習，以及透過建立通用詞語交流需求的技巧！為此，我們還在與對方積極地保持聯絡，也期待能夠協助他們解決跨職能團隊建立和協作的問題。 – 如果你也正在思考如何導入 DevOps，並且追尋持續改善，那麼 CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.

今年有許多機會遇到外包許多 IT 研發人力的組織，組織規模不能說不大，但就是大到人不夠用。當內部開發人力不足時，很容易就遭遇到對技術缺乏良好掌控權和外包的系統理解不夠，甚至是對於其中程式碼的管理有些薄弱。當組織高速成長時，新系統和接連不斷的大功能滿足了組織實力展現需求和市場競爭力的需求，但當外部環境有些動搖時，組織開始希望有更好的成本效率，就不得不回頭檢討昔日的大量外包作為。不過，首要問題便會出在甲乙方交付模式與產出的管理方式了！此時，主事者會很直覺地想到需要開始收回對於產出的管理能力，而開始放大對於「工具」的渴求，彷彿有種工具能夠像神兵利器般解決一切的問題，重點是還很有成效，但事情真能這麼簡單嗎？ 此次的訪談剛好背景也是如此。受訪的組織為了更有效地管理產出，內部研發單位基於開源工具構建了一個管理平台，並且希望組織內的成員和外包商能夠全面運用，以便更好地管理產出和提升效率，但結果是自動化流水線成了上線前的最後一站測試，而整個管理平台最終也只是一個程式碼存放地，持續整合的概念說實在也談不上。受訪者委婉著說道「程式碼的確重回管控，但平台使用率不高，有沒有平台似乎也沒未工程師帶來太多誘因。」訪談過程中既能感受到他對於平台的用心和自信，但同時也感受到他的無奈。 工具對於日常操作的影響 「工具」有著較為具體的形象，既容易想像也能摸得著，但回到軟體開發或者是日常操作，終究得回到人而非單純的工具。在組織中，工具的確為每個成員帶來方便，但這些工具都會成為日常操作與營運的一部分，進而成為習慣。當引進任何工具或者平台時，除了工具的功能外，更應該考量的是工具對於日常操作的影響，比方說： 工具對於原來作法的衝擊； 工具是否對於原來流程產生影響； 組織成員對於工具的陌生感； 工具是否能夠進行客製，以便合於當下所需。 導入新工具前組織應先考量的事 上述都會是工具重要的考量，而非有了工具就能夠改善一切。有時強硬的導入工具反而會造成雙軌做法，徒增組織成員的痛苦。對於外包廠商就更是如此了，畢竟對於他們來說，更重要的是恰如其分的節約工時和不要做出越矩的事情。因此，對於正苦於如何導入新工具的組織來說，有以下的建議： 除了工具，請在意目前的做法； 提供人員足夠的培訓； 透明化目的與工具選擇的原因； 挑選正確的導入時間； 注意工具的必要性。切入重點，而非只為形式美。 與外包商的協作模式 當然對於有眾多外包商的組織來說，如果想要進一步推動外包商，更需要在意： 權限管理； 必要資訊的透明化； 增進外包人員的心理安全，並且引導他們提出改善措施 逐步增加外包人員的認同感和統一化組織價值觀。 訪談的最後，受訪者表示他們的平台在今年已經完備，目前重心就是推廣該平台。期盼他們能有好的結果，CPHT 也會繼續跟蹤後續的狀況，並且提供必要的協助，以便讓一切好事真的都會發生。

這次訪談對象是來自一間提供金融交易數位服務公司 PMO 的一位資深管理人員。從訪談間可以了解到該組織的管理者對於時間調配和公司規則都是帶頭施行，以身作則，因此公司在相關營運流程上的管理不僅嚴謹也有效率，更重要的是員工對於這樣的文化充滿了自信。「我相信能做到如此的業界同行也是相當少數。」受訪者如此地跟我說道。 由於此次的訪談仍然是和敏捷有關，因此在圍繞背景資訊閒聊一陣後，便提到敏捷。讓我意外的是對方表示「所採用的實務做法是否為敏捷，並非他們所在意的。他們只是因為需要解決實際問題，而採用了一些實務做法，重要的是解決問題，而非是否採用了哪個框架或做法。若採用的實務做法恰為敏捷裡的實務做法，那也只是剛好而已。」這樣的說法相較於敏捷到只剩下做法的狀況來說，顯然還算不錯。 敏捷性的追求沒有絕對的套路 敏捷性的追求，不會有絕對要如何遵從的套路，準則抓的對，持續改善漸進改變也是很好的過程，甚至能夠讓敏捷變得更加有效。只不過應該要注意的是實務做法之間往往彼此有相關聯性。單獨採用某個實務做法，有時並不能最大化實務做法帶來的好處，還是要回到目的、資源和風險三方面來了解自己最適合的方式是什麼。 接近訪談的尾聲時，意外地聽到了受訪者的另一個焦慮，那就是該如何進行規模化的敏捷。對於一個並不矜持於敏捷，只追求務實解決問題的組織來說，到底他們正面對怎樣的狀況，而使得所提的疑問有種越級打怪的感覺，或許是因為受訪者正在面對一個更加緊迫的市場環境，使得他們不得不思考如何讓專案和產品能夠更好的面對市場變化，從而達到降本增效的效果。 關注實務做法間的連動關係 面對此次的訪談，不得不說面對危機和競爭，敏捷是企業會想到的好解方，但敏捷的落地需要更為系統性的規劃才能夠獲得明確的效益。受訪者應該思考的是： 此次對於規模化敏捷的企求想達成的目的是什麼？ 過往較為嚴格且緊迫的時間管理方式，是否會讓面對改變的組織成員難以消化“規模化敏捷”的好處？ 盤點當前的作法和敏捷之間的關聯性來了解自己的情境和落差，以便知道“規模化敏捷”的內容與方向。 工程所體現的系統性，並非單純地展現在單一實務做法上。相同目標而在不同面相上的實務做法往往會有互相連動的關係，進而成為一種解決目標的系統性作法。當期望將此類做法導入企業，尤其是全面導入時，更應該關注既有做法、想解決的問題和想導入的做法彼此之間的關係，並且階段性的導入，畢竟羅馬不是一天造成的。 – 如果你也正在思考如何規模化敏捷並且為組織帶來改變，CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

隨著當前經濟情勢越來越有挑戰，企業就會希望能夠讓資源更能花在刀口上。這次相談所的對象是來自金融體系的受訪者。 金融行業的複雜 IT 系統和對於系統穩定和正確性的強烈要求是不難想像的背景狀況。此次受訪者是來自金融行業內的大數據處理部門，他們被要求能夠有效地提供業務必要資料，以便能夠即時地反應市場的樣貌，讓業務部門能夠採取正確的行動，然而面對研發大量外包且系統各自獨立的狀況，時常導致行內成員和外包成員的工作負載，不僅增加成本也降低了工作滿意度，大家總是叫苦連天😫 為了能夠改善此一狀況，該團隊透過看板視覺化所有成員的工作和變更動態、採用固定迭代週期來約束需求方的需求和口語化的任務描述來破除外包商彼此間的穀倉，降低因為相依需求而造成的變更衝突，最終讓工作負載回歸正常，也讓交付變得更加準時。 視覺化能夠讓團隊了解當前的工作動態和促進討論，從而降低開發風險。對於因為需求衝突和變更而導致無法準時交付的苦命團隊來說，視覺化和看板絕對是好的起點。 – 如果你也正在思考如何提升效率或看板，CPHT 的豐富經驗和能力將會是你最好的選擇！ 👉 了解更多: https://www.cpht.pro

有多少次... 我們在各自的觀點與理解下，一起錯過了該有的機會？！ 明明是再簡單不過的功能需求，卻無法實現？! 投影片中，Mary 洞悉市場了解領域知識，Peter 熟於管理需求的實現，John 則是有著豐沛經驗的工程師。良好的機會本應帶來甜美的果實，但最終卻是以 Mary 痛哭流涕作結。到底是什麼問題導致了這樣讓人遺憾的結果？ 需求的缺損！ 市場驅動需求的產生，接著我們會探索需求並且描述需求的樣貌，然後透過工程與管理進而實現需求，並且交付需求。過程中，具備不同職能的專家會依照自己的觀點與理解來傳達資訊，一些隱含在需求中的情境資訊，免不了會在傳遞過程中遺失。然而，只有完整的需求才能創造真正的價值。因此，改善需求傳遞時，情境缺損所造成的需求缺損是一個直觀且重要的議題。此外，不同角色對於軟體產生的過程也有不同的關注點。銷售人員關注的是產品是否實現需求，管理人員關注的是如何調控過程，然而工程人員關注的是如何交付需求。不同的關注點會造成對於需求價值的認知不同，進而影響需求的流動。 BizDevOps 正是為了解決上述的問題而存在，所以 BizDevOps 就是： 在原汁原味的產品需求理解下，讓商業人員、管理人員和工程人員能夠有共同認知並且協作達成商業目的 實現 BizDevOps 該處理的第一件事：需求理解問題 如上述，需求傳遞免不了因為情境和領域知識的不夠，而使得不同的人對於需求有不同程度的理解。為了能夠解決這樣的問題，組建一個完整的團隊對於解決理解需求是相當重要的事情。 完整的團隊存在著具有不同技能的成員。為了讓團隊能夠盡量有能力獨立實現需求，團隊中的成員需要不排斥擁抱跨職能，跨職能不是只意味著一人多用，或者是取代誰的工作，更重要的是讓團隊成員能夠在需要的時候互相幫忙，並且可以擁有共通的知識讓溝通和理解更加順利。常見的團隊人數為 8~12 人，然而最佳的人數還是得回到實際開發的需求。根據 Dunbar’s number 可以知道團隊人數在 15 人以內時，成員之間可以建立深厚的信賴關係，所以在組建團隊時別忘了考量人數規模。人不是多就好，多人就會提高溝通與管理的成本。

DevOps 是一種跨團隊協作，以便讓整個軟體服務交付過程的浪費能夠降到最低，並且最大化想要提供的客戶價值。 話雖如此，DevOps 最大的挑戰仍然是團隊的協作與溝通1，而讓人最快聯想到的是自動化與工具鏈。DevOps 一路發展過來，不乏疾呼文化的倡議者，也曾討論過 DevOps 是否是一種職稱。但不管討論過程內容如何，回到產業落地的現場，DevOps 變成了一種職稱或一種團隊的名稱，而這類職能主要提供工具的建構與發展，來支應團隊能夠以大家所想像的 DevOps 方式，把軟體交付到使用者手上。 從去年年底開始 Platform Engineering 突然躍到檯面上。 從 Google 趨勢分析工具可以發現 2021 年底，Platform Engineering 便已經來到一個新的熱度水平，而到了今年，它又再一次跳躍。目前網路上，已經不乏對它的討論。一下子說它將取代 DevOps，一下子又說它能助力 DevOps。那麼到底它扮演著怎樣的角色呢？ 首先如前文所述，DevOps 發展至今，實際的現況是：

Gartner： 直至 2022 年，75% DevOps 未能達到預期的成果 DevOps 透過促進協作與去除浪費，來加速整體價值的流動，但從研究1上可以發現溝通與協作、咎責文化、與系統性地融合新舊做法仍是目前組織落實 DevOps 的重要挑戰。我們或許會直覺地聯想到這一切都與組織的文化有關，我們需要文化上的改變。不過，文化如此抽象，我們又該如何改變文化呢？是不是只能盼著等著文化發生改變，而無法有任何積極的作為呢？ 組織基於商業目的形塑組織的價值、並且與外部環境共同創造出組織成員的工作情境，而這些價值與情境則影響了我們所建構的隱性與顯性行為規則。最終，這些行為規則透過組織成員的一舉一動展現出來，進而造就了組織文化。 任何的轉變都會深刻地影響著組織中的每一位成員，並且最終讓組織文化有所改變。我們可以透過領導力與同理心支持組織成員渡過轉變，然而除此之外，我們要如何有系統且明確地推動文化轉變呢？ 答案就在顯性行為規則，而具體影響顯性行為規則的便是治理。治理定義了結構、流程與互動關係，來確保目標的達成。 治理幾乎無所不在，舉凡組織架構、政策、專案進行方式等都在治理的範疇裡。當我們採用 DevOps 或者引入外部的最佳實務做法或技術工具時，將會衝擊治理所含括的其他面向，進而產生衝突。以 DevOps 轉型來說，具體的衝突會以難以左移、難以驅動自主性、與價值流不效率等方式展現出來。治理並非洪水猛獸，也不是創新的限制，更不會是達成商業目的的阻礙。 治理關注目的與價值，且是保護組織持續成功營運的護欄。 為了平衡治理的需要與團隊授權的必要，組織應該考量最小可行治理。透過盤點與量化組織的必要政策與必要作為，並且容許團隊基於各自目的進行調整，來達成有序地自主。此外，治理並非不可調整的一套僵固政策，透過回饋持續地改善與調整，才是企業面對 VUCA 環境的重要關鍵。 以下為 2022 DevOpsDays 分享的重點摘要：

早在 2020 年，歐盟便提出數位服務法(Digital Services Act)，而在今年四月，歐盟議會與成員國對該法達成一致1。台灣也在今年跟進了這個法案，並且提出了數位中介服務法的草案。頓時，「言論自由受到箝制、影響國際競爭力、扼殺產業」等聳動的標題與質疑躍於媒體之上。然而對於使用者的我們來說，該如何看待此事？ 大家還記得嗎？一年多前的美國總統大選，關於社交平台的輿論操弄與控制一事吵得不可開交。還記得嗎？每逢台灣選舉或者各種特殊事件時，社交平台便會出現所謂的水軍與帶風向。另外，大家是否曾經擔心受怕自己經營許久的臉書2、IG3、Youtube4、Twitter5等社交平台上的內容被無故停權，甚至被消失嗎？在此類的事件裡，可曾想過如果有誰能夠幫忙你要求平台業者給予你更好的回應，那該有多好嗎？ 而這個誰能是誰？是平台業者？是某個正義的勇士？還是只有你安身立命所在國家的政府呢？此外，在這些虛擬資產上，政府是怎樣的角色呢？ 數位轉型的風也吹了好些年，而政府為了數位發展甚至成立了數發部。所謂的數位轉型是透過數位的力量，形塑新的商業價值。政府向來對於實體財產有較完善的管理法規，但對於數位服務與虛擬資產來說，則甚少有很好的著力點。政府開始關注虛擬資產，試著為人民提供必要的價值，是否對於政府來說才是該有的數位轉型呢？以此而言，數位中介法便是個很好的著力點。 歐盟為此法提供了一個很好的先例，但實際上要如何訂立規則，才能面對演變迅速的虛擬世界與所處的國情呢？我想並沒有一個很好的最佳實務做法，但可以想見的是抨擊與疑慮肯定會與 GDPR 公佈時一樣沸沸揚揚。這些疑慮大致上不外乎兩種，一種是言論自由，而另一種則是影響產業發展。近幾年，花了大量的時間研究個資與隱私保護和一些國際法規的演變與發展之後，每次看著「言論自由」這個詞彙，總會不禁想起一個問題： 當資訊不對等且受到操弄時，我們所做出的判斷與言論，還能稱得上自由地表達了想法嗎？ 進一步地翻開草案的總說明文件6，可以發現法案的初衷： ...民眾已普遍透過個別要求，使用藉由電子方式遠距提供之數位格式之服務。其中,尤其是線上平臺服務，已不再只是單純利用各項服務，而是得以一同參與、互動、形塑服務內容之提供；因此民眾使用數位中介服務，已為日常生活的組成部分，同時也為民眾個人及社會全體帶來新的風險及挑戰。為適應數位中介服務轉換及創新之驅力，建構安全、可預測及信賴之網路環境，並維護憲法所保障之基本權利... 或許我們不需要法案的特別說明，都能深刻理解與認同這些服務已經走入我們的生活，並且驅動著我們的行為與思考。當我們因為某些傳播開來的訊息而忿忿不平，甚至為此在自己的虛擬空間裡留下足跡時，我們是否想過： 當資訊不對等且受到操弄時，所留下的足跡真的是你我想要保護的資產嗎？ 當服務提供者為你極力地吶喊著自由，或者是任意的第三者為你極力地吶喊著自由時，你是否在一同群情激憤之前，稍微停下來思考一下「這些自由本身與背後意圖是否與你所想像的一致？」還是只是字一樣而已？自由何其珍貴，而真正的自由需要在資訊對等與透明的情況下，以不受外力影響的心智表達自己真正的想法。 因此，我個人對於法案的提出，反而抱持著積極的態度！ 首先，若是台灣率先提出此類法規，礙於市場規模，我認為法規所能發揮的約束力可能相當有限，然而當具有更大市場的歐盟對同類法規達成一致時，台灣便可以有更好的施力點，甚至能讓台灣跟上國際對於此類議題的腳步，而進一步協助產業完善相關機制，走出國門！產業不應以競爭力為由作為反對的訴求，而政府也不應該只是提出法案，更應該協助產業完善自身的管理，或者提供技術與資源上的協助。不過對於法案的內容倒是有一個擔憂之處： 在有限時間裡，法院是否有足夠資源與能力有效地為此法案提供服務，並且做出合理的判定？ 為了讓法院能夠有效地進行判斷，主管機關是否能夠確切且有效地提供足夠且適切的資料來協助法院進行判定，將是極為重要的事情。因此，主管機關應當善盡查證義務，並且盡可能地保持資訊透明與公正。據此，有以下建議： 法規雖然對於裁定結果有揭露的要求，但應該要求主管單位提供更為主動且易於閱讀與理解的資訊。大家不妨想像一下！當社會出現爭議事件時，看著判決書資料庫介面，我們是否有能力可以查到對的資訊？當我們想要從資料中得到關鍵的洞察時，我們是否能夠輕易地匯整出關鍵的資訊？因此，主管單位應當提供簡單易理解的統計資訊儀表板，針對被提起的議題品質與背後成因進行分析，並且揭露。

Nadella微軟執行長： If there’s one trend that has defined the past year, it’s that digital adoption in every industry is being brought forward multiple years.1 數位轉型的發展在疫情的促使下，進展的速度越來越快。企業為了驅動數位轉型，紛紛大舉投資新穎科技與工具。根據統計，全球相關的花費在 2022 年達到 1.8 兆美元，且預估 2025 年會來到 2.

一些統計的數字… CloudBolt2 針對公司員工數大於 1000 人的組織進行了 DevOps 的現況調查，並且釋出了相關的統計數據3。DevOps 近幾年打得火熱，尤其在疫情期間對企業的自動化、流程改善、團隊運作起到了相當大的幫助。整份報告著重在自動化的調查，數字的確發人省思。以下為摘要： 只有 4% 企業認為自己在 CI/CD 的使用與實踐達到專家級別; 只有 5% 企業有能力單日數次發佈服務變更，然而 85% 企業發佈服務變更需要數天、數周或者更久; 只有 11% 企業認為自己的 CI/CD 流水線環境是可靠且受控; 有 88% 的企業表示正在考慮或已經使用 Terraform 作為基礎設施的發佈工具，然而卻只有 5% 的企業對於使用後感到滿意。 關於 Terraform 與 Infrastructure as Code Infrastructure as Code (基礎設施即程式碼) 的概念已經有 25 個年頭，而 2015 年 Terraform 甫一出現就吸引大家目光。

敏捷在疫情中，為企業帶來了什麼實質的影響? 從麥肯錫2的兩項調查統計來看 在客戶滿意度、員工參與度、與營運績效來看，在同一企業內，敏捷程度較高的部門表現顯然優於敏捷程度較低的部門。 基於亞洲與歐洲電信運營商的組織應變速度來看，敏捷成熟度最高的組織較成熟度最低的組織有著近兩倍的差異。 不可諱言地在疫情前，轉變對於組織來說，並不必然是極為迫切的事情。因為市場變化雖然強勁，但壓迫力卻並非立即性地逼得企業喘不過氣來。疫情來臨時，交付管道的失效、聯繫方式的失效、工作空間的失效等等問題，讓供需兩方彼此交互增強對於變動的需求。敏捷基本上是想找尋一個系統性的方式來解決最終結果的不確定性。畢竟，商業環境唯一不變的真理就是改變。 從疫情中過渡到後疫情 對於組織來說，什麼才是所謂「系統性」的方式? 這就得同時從團隊層級與企業層級兩個不同層級來探討，畢竟敏捷並不是組織內某個單位的事情，而所謂的文化改變，也不可能忽略組織的營運與治理。但不管哪一個層級，以敏捷的角度來看有兩件事是重要的： 1. 貼近於現實的可調適能力； 2. 可視性。 透過看板、電子協作工具，以及基於上述工具的指標儀板，組織才能在霧濛濛的不確定性市場中具備視覺能力。有了這些視覺能力，組織才能夠以更為全面的視角，客觀地衡量現況，進而調整自己的步伐。具備了這項基礎的能力後，才能讓調整步伐的能力有效展現。這就會回到了「如何實際地讓自己具有貼近於現實的可調適能力」這件事上。具體作法不外乎是 企業層級能夠盡快響應市場變化，調整方針與重要項目；團隊層級能夠基於這些改變的方針與實際場景的差異，具體地進行微調，來達成目標。 為了能夠做到這些事情，企業必須要思考的不會是如何帶入別人成功的套路，而是要去反思當前的營運模式、流程與治理方法。 企業作為一個法人，正如同自然人一般。面對外部刺激的反應，可以從大腦下達指令，然後產生相關反應，也可以在一些「特定條件」下，「授權」各部位直接採取行動。不管是從大腦下達，抑或是特定條件下的授權行為，為了能夠更有效率且無誤地發生效果。需要的不只是應急措施，更重要的是能夠重複的「成功規則」。因此，在得益於敏捷的實務作法，而在此次疫情中獲益的組織，在疫情之後，應該要去思考的是： 1. 疫情中採取了哪些應該持續下去的改變，還有哪些問題並未被解決； 2. 匯整經驗，融入日常營運，並且強化與擴大這些經驗的成熟度與覆蓋度。 後記 敏捷不僅是一種方法，也是一種能力。面對疫情所帶來的紛亂，提升企業的敏捷能力，便是提升企業韌性的最好策略。 1. Photo by Elena Mozhvilo on Unsplash 2.

安全的運行環境對於雲端服務來說，是個重要的議題，而對於使用者來說更為重要。 因此，對實體或虛擬主機進行弱點檢查與監測，能為雲端服務提供一個安全的基礎，也能滿足組織對於資安的基本要求。然而，安全威脅多樣，且各式作業系統的組態設定又各有巧妙，要如何才能有效率地完成這個工作，對於維運人員來說是相當令人頭疼的事情。 SCAP2 (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST3)所維護與制定的協定，主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。 OpenScap4 則是基於 SCAP 的具體實作，它主要透過使用 SCAP 裡的 XCCDF5(Extensible Configuration Checklist Description)與 OVAL6(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時，應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查，也可能來自 OVAL 所識別的弱點測試。

COVID-19 的疫情進一步地加速了全球數位轉型的腳步，按微軟 CEO Satya Nadella 所述1「當前兩個月所獲得的數位轉型進展是過去需要兩年才能達到的成果」。數位轉型透過數位的力量為客戶帶來更好的使用經驗，提升企業競爭力的同時，也進一步地擴大了可被攻擊的接觸面積，根據 Ponemon2 的 2020 研究報告指出，受訪者中有 82% 表示其數位轉型項目至少經歷一次資料外洩的問題。另外，為了能夠更了解客戶，提供更完善的服務，資料的收集與應用更是當前商業競爭的重中之重，然而隨著日漸提升的資料隱私保護意識，與相關規範的建立與落實，資訊安全已然無法視為NICE TO HAVE的選項，而是MUST TO HAVE的因子。因此，在考慮數位轉型策略的同時，將安全納入考量，並且雙軌併行，才是當前企業所應該考量的作法。 鑑於此，筆者認為企業把資訊安全融入數位轉型中，有五個關鍵步驟！ 1. 了解組織的資訊安全能力 唯有了解自身當前的狀況，才能知道與需求之間的落差! 在規劃數位轉型計畫的同時，誠實地面對組織當前實施安全的現況與能力，才能夠了解與期待之間的落差，並且建構可行的路徑。所謂可行的路徑，便是逐步地將安全工具、驗證能力、與安全文化逐步地與數位工具與商業服務進行融合。也只有透過一開始便考量安全，才能夠務實地將安全融入數位轉型的過程中。 數位轉型所涉及的層面包含了工具採用、文化和流程變更、與人才培養，過程必然對組織裡的每個人產生衝擊。如果將安全作為轉型成功後，才進一步加強的目標。可以想見的是安全將永遠會是拖慢並且減損轉型成果的障礙！ 2. 將所屬產業的安全需求納入規劃 企業經營自然無法自外於當地法規對於所屬產業的要求，也無法無視消費者對於企業的期待。因此，數位轉型絕非暫緩合規要求的理由，相反的是一開始便將合規需要納入轉型中，才是事半功倍的最佳途徑。試想當組織內的成員好不容易適應新作法後，卻要立即地面對加入額外要素的作法變更。調適與落實所產生的成本將會是企業無法承受之重。 對於並無具體法規規範的產業來說，基於自動化工具所採用的安全規範與指引，將會是比較直覺且成本較低的選擇，比方說 NIST 與 OWASP。

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

作為基礎設施的編撰工具，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.

去年底公佈 CentOS Stream 來替代 CentOS1，也就是說原先的 CentOS 的發佈版本終於迎來它的終焉之時。 簡言之，CentOS 原先作為 RHEL 釋出後的開源版本，如今將重新定位在 Fedora 與 RHEL 釋出之間，成為 RHEL 釋出前的版本，也因為這樣的位置重置，讓原先 CentOS 的用戶立馬就吵翻了天。 不開心! 為何? 先不論是否背叛了開源社群，或者是因為誰而促使這樣的狀況發生。造成這樣的不適感，筆者認為最大的原因有二： 已如理所當然的長期免費資源，如今不再這樣可口。 除 CentOS 6 與 CentOS 7 仍按照原先生命週期外，CentOS 8 並不會按照原先預期的約定，直接改止於 2021 年底。這讓已經投入 CentOS 8 轉換且以此展開產品發展計劃的個人或企業，直接面對這突如其來的變化，反應可想而知不會太好。 關於第二點，雖說按目前軟體發展的模式，尤其紅帽這類大型公司，在持續測試整合上的能力已經相當成熟，不管是相容性與主次版本的相關測試案例，應該都能提供對應的保障，但是一聽到是先於企業版本的發展版本時，誰又願意進一步嘗試或者是相信呢？CentOS Stream 並非突然在 2020 拔地而出，而是在 2019 年時便已經問世，開源使用者固然有關注的義務，然而突如其然的轉換聲明，使用者溝通上顯然不足。不過說到此處，基於第一點，說實在很難找到兩全的方法。或許紅帽能為一些先於RHEL釋出的新功能，提供一些開關，讓使用者對於過新的變化至少有個簡便濾除能力。

General Electric (奇異公司,以下會統一使用GE2來稱呼) 為一個跨國且跨不同產業領域的產業巨擘，2008 年，在 Jeff Immelt3 的支持下開始了轉型之旅，期間各種閃耀的成果與報導不斷，是討論轉型時不能錯過的案例，尤其在討論仍處於熱潮的工業 4.0 時，更應該看看他們的歷程與故事。或許屬於 GE 的最終烏托邦尚未浮現，然而它們的故事仍會繼續，並且探索新的價值。 紀事 2013 年, GE 開始使用自家所打造的工業物聯資料分析平台,Predix，來分析運行於實際場域的機器。 2014 年, GE 聲稱透過 Predix 平台實現了超過 10 億美元利潤4，並且在同年，Jeff 於推特上的一則發文，開始了它們更加積極的數位轉型之旅。 "If you went to bed last night as an industrial company you're going to wake up a software & analytics company.

微服務所帶來的彈性，以及它與CI/CD，與敏捷等所帶來的效率，讓你心動不已嗎？ 微服務和容器、CI/CD、Kubernetes、敏捷等概念有著互相增強彼此所帶來效益的能力。這幾年伴隨著各類技術的發展，台灣自然也沒少了這股熱潮，而這樣的趨勢仍然還在沸騰中。身為一個技術工作者，或許早已看不慣公司裡陳年的大系統，正想一展長才，響應潮流，而管理者或許因為數位轉型與創新的壓力，開始希望從這熱潮中，找尋成功的方程式。 微服務並不是去年才出來的概念，而自家的系統也不是今天才開始運行。先想想「值得嗎？」 微服務是首要之務嗎？ 重構系統將其微服務化是一件極大的工程。相信大家對於微服務所帶來的好處朗朗上口，然而分散式系統的管理複雜度和資源的額外開支，在朗朗上口之餘，也必須認真對待。另外，在過程中可能帶來的業務穩定性衝擊與業務發展資源不足的問題。更重要的是，它所帶來的效益不見得如你所想像的!這幾年穿梭在各類系統架構中，常常必須苦惱不已地進行抉擇，分享幾個思考點，或許能夠在大家踏上旅程前，先想想是否已經可以無悔走上重構： 原先系統的狀態 向原先系統磨刀霍霍之前，先想想「目前原先系統修改的需求高，修改頻繁的發生嗎？」、「大多數新的實作是否仍然增加在原先系統，還是其他服務裡？」如果，原先系統已經處在維護狀態，或者是新的實作大都與原先系統無關，那麼或許更重要的是在流程或其他面向上的優化。 系統已經可預期或已出現容量瓶頸 原先的設計已經限制住系統本身處理當前或者是未來的使用量。如果時常進行尖峰調度，而且調度應變困難，抑或者調度也很難再處理使用量的增長。那麼首要之務，找出瓶頸的服務接口與對應功能類別。作為之後，首要改善之所。 工程資源 任何的改善變更都需要人。如果工程人員已經吃緊，而又另外增加重構改善等任務，那麼下場很可能是不減反增的技術債、業務進展發生開發瓶頸、與惡化的勞動條件。人永遠不是資源，而是企業成長的夥伴！持續性地超支所衍生的代價，恐怕會降低重構的成功機率，以及削減重構所帶來的效益。 原始設計是否良善 單體式(Monolith)架構其實也沒什麼罪惡。如果原始設計已經維持著良好結構，也能正確體現低耦合與高凝聚等特性。那麼它的後續維護其實不見得比較難。難以維護往往是因為求快的實作，導致軟體內部設計耦合度過高，牽一髮動全身，發生問題還無處找之類的狀況。因此，不管在任何時候都好好設計軟體，會讓自己後顧之憂少許多。一個隨便實作的微服務，其實也沒比良善實作單體服務高明到哪？更甚而是不僅要面對可怕的設計外，還要負擔分散式管理的複雜，恐怕問題只是雪上加霜。 如果面對一個既有系統時，已經發生容量問題，設計又差，時常又要新增功能，往往耗損在應對，而非新發展，那麼或許重構是幾乎是你首選了，盤點一下人力狀況和工作配比，為自己重構之路爭取一些支援，反而是你現在該煩惱的，而非是要重構或不重構了。 然而，世事總是讓人陷入兩難，大多數情況都是有點糟，但不是太糟，那麼？

追求獲利與永續是企業的基本訴求，而數位轉型則是企業希望能夠達成訴求的手段。如果將數位轉型比喻成一支箭，那麼箭頭代表著解決客戶需求的產品、服務、與解決方案，而企業的技術、工具、與能力則代表著箭桿，至於箭羽則是價值、信念、與原則！ 箭桿是箭的主要組成，它的各種特質(撓度、長度等)影響著與弓的適配和行徑，左右了搭弓和飛行，然而缺乏對於目標的理解，搭配錯誤的箭頭，則會降低箭的破壞力。正如數位轉型，目標的確立是一切的開始，這樣才能使用正確的箭頭，正中客戶的口味，實現客戶價值。技術、工具、以及組織各項能力，相對於客戶來說，則如同箭桿一樣，具有各種特質，卻是單一而統整的存在。它構成箭的基礎，需要的是各項特質恰到好處的配合。 不要在鋪陳了！到底什麼時候要講箭羽？ 還有轉型最愛提的組織文化呢？ 箭羽的最主要功能是 — 為飛行的箭提供穩定度。風為箭的飛行增加了不確定性，影響箭是否能夠準確地射中目標，而箭羽能夠透過重量與羽毛(或類似羽毛的構造)，在多變的風中，穩定箭的飛行，而對比到企業，則與企業的核心價值、信念、與原則所帶來的功能一致。 轉型 vs. 組織文化 討論數位轉型時，不免會提到「端到端的價值」。這邊的價值更準確地說是客戶價值，然而能夠 正確且有效地 傳遞客戶價值，靠的則是企業的核心價值。核心價值說來抽象，讓我們換個角度，試著用問句來思考一下！ "這個產品的主要解決了什麼問題？" "這個產品與其他產品的差異是什麼？重點是什麼？" 我想上面的問題應該一點也不陌生，它的核心議題是目標、願景、解決的問題等。讓我們再想想其他的問句… "哪些要素持續激勵著目標的達成？" "哪些事情讓我們更容易成功？" "有哪些考量，是交付時不能夠妥協的？" 這些問題所勾勒的價值，便是企業的核心價值。因此，除了「客戶價值」之外，核心價值則扮演著穩定的要素。說到這邊，不免惹人疑問的是，核心價值高高掛，但可能說比做更好聽… 「信念」根據維基百科的解釋2 — 信念是反應個人見識正確與否的思想意識。相比於核心價值，信念是關於人根據過往經驗對於現況環境的假設，它更多是反應感性方面與經驗的累積。 抽象而顯性的價值與具體卻難以清楚解釋的信念，構成企業內做事的原則，而原則左右著做事的方式。 文化是透過組織成員基於組織內成文與不成文原則下，通過行為而具體可見(註3)。 文化很抽象，但透過拆解，可以由核心價值、信念、與原則來更進一步地了解它。回到轉型議題上，當討論轉型，不免立馬想到一些最佳實踐，比方說 SCRUM、SAFe 等。這些實踐都很好，不過更多時候應該作為發想的起點與參考，而不是單純的照單全收。因為實踐最直接的對應是「做事的方式」，具體的作法或許能夠帶來顯著的變化，然而卻會讓「實踐者」忽略了這些實踐背後所體現的價值與信念。當改變後「做事的方式」與原來的「價值和信念」發生不一致時，轉型成果則更傾向曇花一現，甚至是失敗作收。

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

人工智慧對數位轉型產生莫大衝擊以及推力。我想很少人會對這句話產生質疑… 人工智慧在圍棋上打敗人類後，想像空間與可能性便在不同領域持續發酵，彷彿電影內的情節就要活脫脫地呈現在日常生活中。根據市場的調查與推估，以亞太區為範圍的市場規模1 (含括硬體、軟體與服務) 就高達 624 億美元！這樣的趨勢仍以類似指數的曲線往上增長，預期 2027 年的亞太區規模將來到 7337 億美元。不管從個人發展或者從企業發展來看，這是多麼夢幻的成長空間呀！但不管多麼的夢幻，以實際的角度來看，更重要的是 — 你是否在這夢幻樂園內，並且實際從中獲得好處了嗎？ 預測與落地 按 Gartner2 所做出的預測，到 2022 年，只有 20% 左右的資料專案產生實際商業價值，而八成失敗的人工智慧專案有 96%3 的原因來自於資料品質、標記、模型建置。另外，再從 VentureBeat AI4 進一步可以發現 87% 所謂資料科學專案並未走進最後的正式環境，投入使用。

在自動化建置靜態網站基礎設施之一中，我們介紹了如何全面使用 Google 來打造靜態網站的基礎設施，但以一個單純作為靜態網站來說，起初的用戶量與使用情節必然是不太複雜，但全面使用 GCP 的解決方案也就代表了採用負載均衡與 CDN 等相關服務元件，而採用這些元件由於服務水準匹配的原因，也很難降低相關元件(e.g. 負載均衡)的等級，因此，即便流量再小，也必須支付一個月約莫 2x 美元的費用。因此，本文章將介紹利用 Cloudflare 來取代 GCP 的負載均衡與 CDN 相關服務，由於 Cloudflare 有提供免費級別的用量，這對於單純的初期靜態網站來說，應該十分夠用了！接下來，我們就來看看如何用 GCP + Cloudflare，並且基於 Pulumi 打造一個零元的靜態網站基礎設施吧！ 在開始之前 擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$ 建立一個具有合適權限的服務帳號 安裝 Google Cloud SDK，並且確認已經設定好 application-default Python 為 3.

議程總是與會議內容不符？ 會議冗長，重要的卻沒談到？ 參加的人很多，意見卻少的可憐？ 開到意識脫離？ Lean Coffee 是由 Jim Benson 和 Jeremy Lightsmith 所發想，而發想後的最初實踐空間的確就在一間咖啡廳內！Lean Coffee 的議程安排是由參與者所共同決定，所以會議前，相關議題並不明確，但唯一明確的是聚集在一起的人，有共同的目標與興趣，也具備此目標下的相關討論背景知識。雖說議題是由會議進行過程決定，但議程的推進過程卻十足具有結構，並且能有效地針對提出的議題，產生結論與後續行動。 整個開會的基礎概念是基於敏捷、看板與 Lean ，並且以人為優先來考量整個會議的安排，民主式地抉擇討論，並且提高參與感和個人的貢獻，以便形塑真實的共識。 環境與工具 便於走動與張貼的環境，可以善用團隊常用的戰情室； 白報紙一張或白板一個； 建議人數 <= 10 人/組； 白板筆 x 三種顏色 ； 便利貼一包 x 兩種顏色； 點點貼紙 >= 30 點/組； 計時器； 安全可開放討論的氛圍。 流程 利用 3 ~ 5 分鐘的時間，讓參與者透過腦力激盪將感興趣的議題寫在便條紙上； 輪流到白板前，用一至兩句簡短的描述自己的主題； 將相同或者相似的主題進行整合； 一人三點進行議題投票； 將看板 (e.

一聽到治理(Governance)，大多數的第一反應肯定是流程、簽核、惱人等待與時程拖延等那些讓人提不起勁的事兒，但偏偏這些要求都是來自天上避也避不了，只能無奈含著淚，進行著說不上認同的流程:vomiting_face: 組織在面對治理的時候，常會陷入頭痛醫頭腳痛醫腳的狀況，在遭遇外部事件或內部事件後，就逐漸增加治理活動，先不論員工是否喜歡，對組織最大的影響就是價值交付的能力，而這也是組織競爭力的基礎。治理是企業內進行任何活動都無法免去的要素，畢竟它確保著組織的願景與目標，但如何有效地運用治理達成企業目標，同時又能讓創新與響應變化保持彈性，而不是迎頭痛擊成長的機會呢？考慮一下最小可行治理 (MVG, Minimum Viable Governance)，相信這個概念一定能為您帶來啟發與裨益。 首先! 什麼是好的治理呢？ 好的治理就是讓公司內的生產活動(包括專案、產品等)能夠在組織應允的人力、物力等資源情況下，被成功的交付，達成預期的設定。治理的目標是保證公司利害關係人的權益，確保組織有效地利用資源，達成所設定的願景與策略。治理活動通常是由公司內的XX委員會或PMO等團體進行，而主要的管理點則由公司內的高管們來進行授權，以便讓整個治理能實質落地。另外，治理相關的資訊都應該被充分地描述與解釋，並且文件化，以便讓員工取得一致的共識。 因此，在考慮治理又希望能夠降低治理成本時，應該要思考的是 — 所進行的產品與專案需要滿足組織相關利害關係人哪些需求，而這些需求又重要到讓您深刻地銘記在心，值得日以繼夜地為它苦惱! 以下條列一些思考治理時的一些關鍵要素。 治理的關鍵要素 1. 願景一致 這邊的所謂願景一致，有幾個面向。 第一個面向，產品與專案的主要負責人，需要確保產品與專案的願景與公司原本的治理目標相符，並且能夠循著被預期的治理活動進行，進一步讓所有利害關係人買單。 第二個面向，願景如何落到團隊中每個成員上時，而且是否體現結果上的一致。 第三個面向，更高階的管理人員由於能觀察到公司內所有的生產活動，因此必須確保所有專案與產品與公司策略方向一致。這邊的重點是方向上的指引與關注，但並不是進行微管理！因為其結果一方面會降低團隊的自主性，另一方面則會讓整體生產活動效率低落。組織內不同角色有不同的關注要項，多給組織內的專才一些信任，往往好處會大於專案失敗或遲延所帶來的懲罰。 2. 理解不確定性 大部分的組織對於預算的審定與安排大多按年，或者是按專案初期規劃，一次性的配置預算。根據 2019 Gartner Research，有 89% 的專案是採用傳統的預算編列方式，但根據 PMI Research，2019 年的專案中，也僅有 20% 的專案真的在錢與時間上準確。實務上，不管是因為怎樣的理由，我們很難看見因為採用敏捷，在專案上的預算編列就有所調適，最終您仍要落到鉅細靡遺的前期計畫，然後期待一切都對。

對於形象與分享用途的網站來說，靜態網站可以說是首選。各大公雲都有對應的支持做法和文件。Pulumi 作為基礎設施即程式碼工具的新秀，相關範例與分享還是比較少，但 Pulumi 所提供的一般程式開發體驗，卻是讓我無法捨棄它。目前所瀏覽的網站建置也是基於 Pulumi 完成並且進行管理的。鑒於目前網路上的資源稀缺，身為知識愛好者的我來說，當然要毫不猶豫地將這過程分享出來！:triumph: **在開始之前 擁有一個 GCP 的帳號，更重要的是，它必須設定好如何付 $$ 建立一個具有合適權限的服務帳號 安裝 Google Cloud SDK，並且確認已經設定好 application-default Python 為 3.x <== 這非常重要!! 準備好 DNS (本網站是使用Google Domain) 架構說明 如同此篇文章的開頭圖片一般，整體結構極為簡潔。就是在 Google Cloud Storage 前，設定導流規則的負載均衡器，並且搭配 CDN。如此一來，一方面可以直接選擇使用 us-west1、us-central1、或 us-east1 的免費額度，也能兼顧用戶從不同地區存取網站的速度。 開始著手實作 Pulumi 程式 1.