導入DevOps需考慮的六大面向

當提到導入 DevOps 的時候，你會先想到哪些議題呢？是某個熱門工具？某個軟體開發的最佳實務做法？運用某新技術的系統架構改善？某種提升協作能力的團隊結構改造？還是其他？不管先想到的是哪個議題，隨著導入的過程就會發現上述的議題都將是需要面對的問題，尤其是當你從 DevOps 導入中獲得成果，而進一步想要擴大效益時，這些議題就會上升到你不能忽視的狀態。

那是不是能遇到再討論呢？或是等有問題再說？很多時候會因為沒有看到問題而很難進行討論或是預先想到解決方案，但這和了解事情的全貌並且為可能的風險做準備（至少是心理準備）不衝突。DevOps 的影響會循著產出的價值流向前向後地擴大，並且進一步地影響週遭的人事物，如果在導入的時候對這些可能產生的漣漪掉以輕心，那很可能會遭遇導入阻礙，或是在導入成功時引發更大的問題，比方說維運事故或客服品質下降和衝突等。

POWERS 是一種思考的工具，它可以協助推動者有效地從「達成導入」這個目標，對組織各個角度進行討論，以便獲得事情的全貌，並且意識風險和注意如何讓做法的設計能適合未來進一步擴展。

POWERS模型　（圖片來源／博碩文化）

什麼是POWERS？

POWERS是一種用於觀察和規劃的思考模型，它所包含的每個字母分別代表導入新做法、新工具或新技術時，應該考慮的六大面向。

1. 流程（Process）：通常至少會有以下要素：● 流程的目的　● 流程使用的時機　● 流程中的步驟　● 執行流程的角色　● 輔助的工具　● 預期所需的資料和產出。

2. 目標（Objective）：在討論導入DevOps時，大部分的情況都會以工具或是交付相關的實務做法作為目標。這樣的想法並無不可，但需要注意兩件事情：

先射箭再畫靶：科技新聞、競業表現和技術發展往往會產生強大誘因，讓人開始產生許多聯想，但回到實際場域，推動者應該要去思考這些工具、技術或做法能解決哪些問題、產生哪些成果，以及是否有其他替代方案，再得出屬於自己團隊或組織的目標，才能夠讓這些誘人的事物發揮真正的效果。

相依性：不管是工具或是實務做法往往都會和解決整件事的某個部分有關，比方說，GitLab CI/CD工具能夠提供自動化交付的能力，但有意義的自動化交付是建設在好的測試和持續整合實務做法之上。若只是專注在工具上，那或許就只能得到速度這個好處，但這個好處也可能只是快一點產出有問題的變更而已，又或者會因為分支、提交和合併等問題造成自動化效益大幅減損。

3. 影響窗口（Window）：與目標相關聯的人事時地物邊界（條件）。就像窗戶有邊有框一樣，不同的目標和做法所產生的影響範圍也會有邊界，而且邊界本身也會對目標或做法產生影響。分析和規劃影響的邊界，主要的用意在於降低風險、調配必要資源和找尋切入機會，因此了解邊界可以：● 找出變革實施的條件　● 掌握調適與採取行動的依據　● 獲得思考風險應對的線索。

4. 評估（Evaluation）：與目標相關的觀察點，用來了解效益、追蹤進展和發現問題。評估此一面向主要是為了提供系統裡的觀察點和客觀依據，以便了解狀況並且做出適當的調整，所以在這個面向上需要思考三個問題：● 需要收集哪些資料？● 哪些指標能指出進展或問題？● 如何根據指標進行調整？

5. 互動關係（Relation）：為了實現與保護目標，針對人與人和人與環境之間所建立的機制。

POWERS裡的互動關係可以用來協助推動者思考在變革過程中如何管理與贊助者、與組織成員和受影響成員與組織政策之間的互動關係和應對措施。在這個面向上有三個要點需要思考：

行動護欄：新實務做法對於組織成員來說，意味著改變、混亂和不確定性，甚至對於推動者來說也無法預料到所有可能的影響，為這些可能的不確定性構築護欄可以確保我們在改變的路上不至於跌落山坡。

溝通協定：在導入新做法時，推動者需要尋求贊助者的支持、利害關係人的回饋和組織成員的接納，甚至是讓各團隊能在新做法下有效運作，都需要靠良善的溝通協定。

期望管理：有時隨著導入成效浮現，總是會讓人禁不住地讓原先的小目標變成巨大的目標，甚至是其它和原先目標無關的目標。變化莫測的導入目標會讓組織成員對變革的信任感下降，進而導致混亂甚至是抵抗，所以推動者在與贊助者和組織成員溝通時，應該思考如何運用客觀的資料來佐證現況，而非主觀判斷。

不過只靠客觀資料仍然是不夠的，如何透過框架來清楚地描繪新做法和導入目標的樣貌、範圍和里程碑也是管理期望的關鍵方式。期望管理的關鍵要素，可以歸結成下面三點：● 清楚且透明　● 運用佐證，讓證據說話　● 為風險提供替代方案。

6. 結構（Structure）：當我們試著導入DevOps或任何相關的實務做法時，便意味著原先穩定的分工方式與職責很可能需要改變，而這些改變讓結構面向的議題成了流程、影響窗口和互動關係這些面向在規劃上的限制。此外，分工方式與職責的變化和導入的需要，也可能對專案或產品結構和資訊系統結構帶來影響。

為了讓新的實務做法落地，推動者在結構面向上有四個需要思考的議題：

職責分工：新的實務做法會帶來職能上的變化，甚至是組織結構上的變化。推動者不只需要根據實際需求來思考原有組織結構是否合適之外，還需要向成員說明變動背後的理由和相關角色分工的細節。

規模化：在推動DevOps時，最常聽到「兩塊披薩」（Two pizza）團隊，但同時也會聽到需要讓團隊負責完整的端到端價值，換言之就是商業價值。這兩個論述都是正確的，但同時也是矛盾的。即便只討論產品交付，一個能夠持續創造商業價值的數位服務需要專案人員、維運人員、安全專家、測試人員、開發人員和商業人員等多種不同角色的完整投入才能夠達成。但考量到團隊人數的限制，小型團隊往往難以形成一個完整的團隊，而使得團隊在實現需求時容易因為任務或職能上的依賴而造成等待與延遲。雖說如此，組織往往會透過多個小團隊並各自分配多個小型服務來進行分工，以便橫向擴展DevOps，進而讓更多人採用新的實務做法。

雙元性：雙元性的概念指出一個成功組織應該同時具備「探索」式創新與「深耕」式創新兩種不同的能力。

「探索」式創新能力代表組織能夠在新技術、新產品、新市場或任何新事物中找出新的價值，從而為組織帶來截然不同的新競爭力。而「深耕」式創新代表組織能夠從既有的事物中找尋更有效率的新穎做法，以便提升組織在既有業務上的競爭能力。

風險與可持續性：分工、專案或產品和資訊系統的結構能為組織的持續營運帶來穩定。當這些結構需要改變時，將會為穩定性帶來不確定性。因此，當需要調整任一種結構時，務必抱持謹慎的心態評估可能引起的風險，尤其是法規和營運持續相關的問題，並且尋求專家（可能是來自組織內、外部）的建議與參與。（本文摘錄整理自《駕馭組織DevOps六面向》，博碩文化提供）

 書名  駕馭組織DevOps六面向：變革、改善與規模化的全局策略

盧建成／著

博碩文化出版

定價：750元

 作者簡介 

盧建成

鑽研軟體工程並且接軌實務經驗二十年，範圍涉及軟體設計、流程、雲計算、人工智慧，並且歷練新產品開發與交付、（跨國）團隊建立、企業營運等種種議題，並且深耕變革管理、DevOps、資訊安全與隱私保護等領域，是一名創業者、審查員、和教育者。

譯有《非監督式學習｜使用Python》、《Python for DevOps｜學習精準有效的自動化》、《AI策略｜人與企業的數位轉型》和《敏捷開發的藝術, 第二版》，以及參與合著《軟體測試實務I》。圖片來源／DevOpsDays Taipei大會網站