Rose Yang

由 FinOps 的權威機構：FinOps 基金會（FinOps Foundation, F2）所訂定的 FinOps 框架在 2024 年迎來了改版，包含更新 FinOps 一詞的定義[1]、擴展參與和關聯的角色等，而最大的變動在於簡化 FinOps 框架中的實踐領域，並更完善各實踐領域下所需具備的執行能力[2]。下圖是 FinOps 基金會官網最新版的框架總覽圖： 資料來源： FinOps 基金會官網：Framework overview 重點更新：FinOps 定義 早期的時候，雲端的財務管理包含了使用 Cloud Cost Management（雲端成本管理）、Cloud Financial Management（雲端財務管理）一詞。 (2021): “FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.

前言 GitLab CI/CD 的 job 如何獲取程式碼庫時提供三種策略，分別為： clone fetch none 在比較這三個策略的差異之前，我們需要先了解 Executor 主要的初始作業與結束作業是怎麼運作的。 Executor 初始作業 我們先以一個基礎的 GitLab CI/CD 範例來看，該範例將會運行一個 build job： stages: - build build: stage: build script: - echo "building.

前言 前陣子在 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 的過程中，必須兼顧速度與品質。

你的企業是否早已有一套施行已久的 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 落地的阻礙：

FinOps 趨勢 近年來，為加速推動數位轉型與 IT 現代化，企業紛紛開始投向雲端的懷抱，期望利用雲端的優勢以提供更快速、更可靠的服務。企業在邁向雲端的初期，通常優先考量應用場景的服務選用、技術的重構與遷移、安全與合規性等議題，但隨著在雲端的業務趨於穩定後，攀升的雲端成本卻帶來了另一項挑戰。 根據 Google 關鍵字搜尋趨勢，從 2021 年的下半年開始，FinOps 熱議度明顯的攀升。在國際上，不論是相關的職缺，或是 DevOps、雲端等調查報告，多指出 FinOps 是 2022 的關注焦點[1][2]，從 CIO 的訪談也不難看出企業正努力應對不斷上漲的雲端成本[3]。我們可以從調查報告[4][5]發現當前企業採用雲端的普遍現象： 雲端成本大幅增加，但大部分的受訪者表示存在著雲端浪費，且浪費的佔比還不低！ 另外值得一提的是，根據 Hashicorp 2021 的調查報告[6]指出，超出預算者多為雲預算較高的企業！ 因此，企業必須進一步思考： 雲預算逐年增加，是否真的來自業務增加？抑或因爲無法識別過去超支的原因，只能不斷地提高預算以持續業務？ 同時，雲端支出所面臨的痛點導致業務、財務、工程團隊產生隔閡。這是因為使用雲端資源的人無法即時性的洞察支出，而事後的帳務報表檢閱者無法識別責任單位。

啊哈！DevOps Handbook 第二版 DevOps Handbook 是 DevOps 領域的經典書籍，同時也是 EXIN DevOps Professional 國際認證的核心教材，不論技術者或管理者，對於任何想學習 DevOps 核心概念與實踐的人來說，這本書就是最好的起點，也是大家書櫃上不能錯過的一本好書。 最近 Nicole Forsgren 博士（另一本 DevOps 經典書籍 «Accelerate» 的作者之一）為本書第二版添加了新的內容，包括： 15 個案例分享 近年來 DORA1、Puppet2 «State of DevOps Report» 的調研結果 «Accelerate» 所提及的關鍵指標 當前適用的技術工具 …等其他有趣的主題 當中，最主要新增的篇幅為 15 個案例分享，而這些案例多是來自企業在 DevOps Enterprise Summit (DOES)3 上精彩的分享。由於篇幅限制與章節分佈，因此有些案例在書中只能呈現部分的內容。我們將這些原始內容的相關資訊作了整理，並且提供十分扼要的註解。讓大家可以很快地找到感興趣的主題，然後前往觀看4 :sunglasses:

前言 隨著企業提升響應市場變化的速度，不管企業的規模為何，抑或屬於哪一種產業，DevOps 儼然成為現代 IT 的重要典範。但在快速迭代的業務發展下，由於傳統的安全治理較為繁瑣，也使企業在導入 DevOps 的過程中，從需求、設計、實作，到後續的監控和改善，較難看見充分的安全實踐，組織亦缺乏在每個流程階段，衡量當前安全的成熟狀況。 什麼是 OWASP DSOMM？ DSOMM 2 的全名為 DevSecOps Maturity Model（DevSecOps 成熟度模型），或許大家較耳熟能詳 OWASP 的另一個軟體安全的成熟度模型 SAMM（Software Assurance Maturity Model，軟體保證成熟度模型），SAMM 針對五個業務功能（治理、設計、實作、驗證、維運）定義了一系列的安全實踐及評量指標，協助組織將安全覆蓋至全軟體開發生命週期。SAMM 為較高層級的規範性模型，而 DSOMM 則為更具體的 DevSecOps 實踐。

在過去帶領 DevOps 團隊的經驗裡，有時會遇到團隊成員對於身為 DevOps 工程師的價值有所疑惑或迷思： 🤔 我們好像只是在做各種工具的整合…是不是要像開發人員一樣寫程式，這樣才比較厲害！？ 🤔 是不是要像開發團隊一樣面對市場客戶的需求，這樣才能產生價值的交付？ 🤔 是不是打造完工具鏈，DevOps 團隊就不需要存在了？ 本文同步刊登於 DZone - Addressing Concerns About Being a DevOps Engineer 認真做好每一樣事物，這才是工程 在工程的世界裡，每個領域絕對都有它專業價值的存在，只是使用的技術、工具及面對的客群不同。雖然各種 IaC 或 XaC 的工具，不像廣為人知的 Java、TypeScript、Python 等程式語言，但在撰寫的過程中，仍然需要基於邏輯地去考量彈性度、模組化等，以及如何透過測試維持品質。有時更因為它是基礎設施或與合規相關，所以相顯之下它所衝擊的範圍也較為龐大，而需更加謹慎。且在五花八門的工具世界裡，選擇一個適合您組織文化、流程、團隊技術線的解決方案，也是個大哉問，不落入貨物崇拜尤為重要。因此，只要保持好奇心、積極的態度，把事情做對，不論背後所採用的技術為何，這就是工程的美妙。

作為基礎設施的工具，Pulumi 主要可以採用以下三種方式進行測試，而除了驗證的範疇外，在程式語言的支援上也有所不同，下方的表格總結了三種方式主要的差異： 表格一：Pulumi 測試方法比較 單元測試 屬性測試 整合測試 實際部署基礎設施 否 是* 是 需要 Pulumi CLI 否 是 是 執行時間 毫秒 秒 分 語言 同 Pulumi 支援的程式語言 Node.

開始接觸 Pulumi 後，發現 GCP + Python 可以參考的資料很少，以建置 GCP HTTP Load Balancer 來說，Pulumi 官方提供了 Typescript 的寫法1，若自行對應相同資源的 Python API 範例，則會在執行時遇到一些小錯誤（稍後會提到）。因此本篇將會分享如何透過 Python 建立 GCP HTTP Load Balancer，完整的實作程式碼請至 GitHub 2查看。 架構說明 透過 HTTP Load Balancer，將請求導流至後端的 Nginx 伺服器，由於 VM 在初始化時，會透過 startup script 從外網抓取相關套件並安裝，因此需要為 VM 配置 Public IP 或 NAT proxy，讓 VM 可以與網際網路進行通訊。但為安全考量，我們只允許來自 Load Balancer 的請求，禁止透過 VM 的 Public IP 來存取服務。