敏捷與DevOps

前言 前陣子在 DevOpsDays Taipei 2023 參加了一場 OST，該場討論的主題是《DevOps 與資安的平衡（ISO 27001）》，當中聊到了 DevSecOps 成熟度模型（DSOMM）時，有位與會者提到兩年前有人成功運行了 DSOMM，但現在那個方法已經失效，不確定現在組織要怎麼自己架設 DSOMM 的網站… （…突然感受到我該更新兩年前所寫的 DSOMM 文章了…🧐）於是這篇文章就出現啦！ 不過 DSOMM 的概念與組織如何運用與先前的介紹差異不大，所以本篇不會太著墨在 DSOMM 介紹，對於 DSOMM 有興趣的讀者可以先參考之前的介紹文：DEVSECOPS 成熟度模型（DSOMM）。而本篇主要會針對以下幾個變化進行介紹： DevSecOps 的成熟度級別 ISO 27001:2022 的對照 基於團隊的評估 自行架設 DSOMM 網站 一、DevSecOps 的成熟度級別 如同大多數的成熟度模型（例如：CMMI、DMM）將成熟度分為五個級別，今年 DSOMM 亦將成熟度從四個級別重新劃分為五個級別1：

為什麼需要從價值流開始？ 當想到要如何提升交付能力時，迸出腦海的往往是以下的做法： 增加自動化比例 期望工程師學習更多的技能 引入其他生產力“工具”或是增加人力 要達成軟體服務交付，從商業構想到向客戶交付價值需要經歷的一系列的流程活動（價值流），而上述的改善往往只專注在局部優化。這也正是在改善過程中團隊需要先理解流程活動的原因，並基於價值流對照（Value Stream Mapping, VSM）使用關鍵指標來分析目前的狀態，因為這有助於團隊識別價值流裡真正的瓶頸點與浪費，進一步制定改善目標與計畫。 DORA 指標 VSM 來自於精實（Lean）管理，常見於製造業的產線分析與管理。DevOps Research and Assessment（DORA） 團隊進一步以軟體交付與維運為面向，透過五項指標衡量團隊的 DevOps 績效，分別為： 前置時間（Lead Time） 部署頻率（Deployment Frequency） 變更失敗率（Change Failure Rate） 平均復原時間（Mean Time to Recovery, MTTR） 可靠性（Reliability） 這些指標分別針對團隊的產出量（Throughput）[指標 1,2]、服務運行的穩定性（Stability）[指標 3,4]和可靠性[指標 5]進行衡量，這也意味了團隊在實踐 DevOps 的過程中，必須兼顧速度與品質。

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

你的企業是否早已有一套施行已久的 IT 服務管理（IT Service Management, ITSM）流程？ 以目前使用最廣泛的 ISO 27001 國際標準來看，ISO 27001 藉由全面性的指引協助企業建構資訊安全管理系統（Information Security Management System, ISMS），來達成資訊安全的三個主要目標 CIA： ISO 27001 基於 「規劃－執行－檢查－行動」（Plan-Do-Check-Act, PDCA） 循環過程來落地並且持續改善資訊安全管理系統，企業為了因應 IT 服務管理通常會設置專職團隊，並由該團隊推動企業內的資安治理，來確保企業所使用的資訊系統（內部服務）與所提供的資訊服務（外部服務）之安全性。該團隊亦是變更管理、稽核、資安事故的最後一道把關人。 有些經營決策者認為當 IT 邁向 DevOps 轉型時，只要將 DevOps 套上既有系統性的資安管理就可以快速地實現 DevSecOps。然而，傳統資安有幾個顯著 DevSecOps 落地的阻礙：