多雲的FinOps成熟度
在雲端中，IT管理者會注意系統在雲端中的啟用與其帶來的成本。本文中我們將使用Finops實踐來強化我們在雲端中的財務管理，我們將會討論到多種成熟度模型。
我們將會討論到如何將FinOps原則套用到我們的企業中。但第一步，這需要一個FinOps團隊，才能把此概念融入企業裡。採用始於意識到。因此，我們必須把FinOps原則整合到＂成本意識設計流程＂中，這是為了讓技術人員產生成本一意識。因為他們的每個技術決策與每個資源使用都會為企業帶來雲端成本。不過這是好的，因為技術人員的這些行動同時也帶來業務價值。這才是FinOps所倡議的。
我們將在本文中討論到以下議題：
- 設立一個FinOps團隊
- FinOps成熟度模型
- 成本意識的設計
- FinOps轉型中的陷阱
設立FinOps團隊
FinOps的目的是讓企業能夠利用雲端獲取利潤，而不是只有節省成本，因為哪只是其中一部分。因此，FinOps要能整合企業的業務規劃與隨其而後的架構。不過挑戰險顯而易見，哪就是從前針對IT人員的嚴格設備與軟體採購流程在公有雲的領域已經變得不適用了。學術一點講，IT的費用從CAPEX 變成OPEX。
CAPEX就是傳統的IT軟硬體採購，它們的費用在一開始採購就已經是固定的了。IT人員怎麼在資料中心搞都不會超過這些前期投資。但是OPEX就不一樣了，每天的佈署與維運都會影響著雲端費用。所以OPEX的費用細項遠比CAPEX多得多，也來得更動態。通常，OPEX會被分成團隊執行日常任務所需的較小預算。 在大多數雲端部署中，企業只需為其使用的內容付費。 如果資源閒置，可以將其關閉，成本就會停止。 如果需要的話，個別技術人員可以決定在需要時啟動額外的資源（如果他有權限的話）。
但在雲端，其實還是有CAPEX的模式。像ERP系統，不可能每天開開關關的。它需要長期而穩定的資源，這意味著跟買一台server是一樣的。只是我們把這台server費用(當然有一些折扣，視簽約的期間長度)付給的雲端供應商(以下簡稱CSP)。
因此，企業的雲端之旅將需要財務專業知識。 至少，強烈建議企業這樣做。 這不只是把卡拿出來刷就好：企業需要一個計劃，就像建立地端機房那樣。 雲端是根據正確的業務理由進行投資。 這就是為什麼每個雲端採用框架 (CAF) 都將治理和財務作為重要支柱之一的原因。更多的雲端採用框架介紹可觀看本部落格系列文章。
故，雲端、財務專家與計畫這三者為FinOps的基礎。這還包含了技術人員、財務人員與C-Level的共同協作。技術與財務專家為雲端上的系統運作而努力。但他們需要一個領導者: 這個角色稱為驅動者(Driver)。
驅動者是將所需的學科融合在一起並推動建立 FinOps 實踐的過程的角色。 這一角色由 FinOps 從業者擔任。 主要任務是倡導FinOps原則並發展能力。 這不是 FinOps 實踐者可以單獨完成的事情。 良好的 FinOps 實踐需要一個與產品或開發團隊、IT、財務和業務團隊密切合作的 FinOps 團隊。
FinOps團隊的主要工作如下：
- 建立雲端成本的控制指南
- 不同的CSP需要有不同的指南。團隊需要了解企業業務所使用的雲端平台。
- 針對tagging設定標準
- 設定雲端成本分配標準
- 資源使用的費用必須歸類到正確的單位或團隊。所以需要有charge-back models。
- 預算與實際支出相匹配
- 與開發團隊合作，以達到雲端資源的使用是具效能的，包括採購策略以及正確大小的資源和自動化。
FinOps團隊要對雲端與其技術要有相當的認識，也要包含與CSP的採購的策略談判。除了檢視雲端成本，驗證發票之外，最重要的是建議開發與業務團隊關於雲端資源的優化使用。這樣才能達到雲端＂具成本效益與增加業務價值＂。
FinOps成熟度模型
上述說了哪麼多的FinOps實踐。哪麼，我們怎麼知道FinOps做得好不好呢？這時我們可以使用COBIT中提及的CMM(Capability Maturity Model來自CMMI)，如下圖。
到了成熟度的最高等級則會專注於改進(improvements)，因為專案和管理是明確定義的，流程是受控的，並且成本是可預測和可衡量的。
另外一個模型則是由Gartner所發展出來的(如下圖)。
主要的主題是後見之明(hindsight)、洞察力(insight)和遠見(foresight)，而這正是 FinOps 的目標：通過財務分析提供洞察力並實現遠見。意思是我們需要資料與流程來分析資料。我們需要指標來驗證資料結果並最終預測未來的成本走向。 使用自動化流程，所有在雲端中的行動都在企業的控制中，而這樣則可以控制成本。
後見之明(hindsight)、洞察力(insight)和遠見(foresight)這幾個步驟是被整在下圖中的成熟度模型(由FinOps基金會發展)。這個模型有5個基礎:
- 知識(Knowledge)
- 流程(Process)
- 指標(Metrics)
- 採用(Adoption)
- 自動化(Automation)
知識、流程與指標是財務操作中的基本術語。它同時也是架構師、技術人員、財務專家與管理層共同的溝通語言。因為大家說同樣的語言才有辦法一起工作，才會有共同的目標，FinOps的採用才容易。
採用需要對資料有共同的理解，對業務應如何發展有共同的願景，以及 IT 如何幫助實現這一願景。 接下來的步驟是優化； 就 FinOps 而言，這應該通過自動化流程來實現，例如，使用自動擴展資源機制，使其與資源使用的預算和預測保持一致。哪我們怎麼實行這一方式呢？有興趣的讀者可以參閱本部落格FinOps的生命週期一文。
成本意識的設計
使用過雲端的人都知道，我們需要對雲端的運作具有＂可觀察性＂，這樣才知道雲端服務到底是否做到業務加值的目標。同樣的，這適用在FinOps中。
因此，我們在設計雲端時
- 需要知道成本是多少
- 需要識別風險，因為當風險發生時，風險也會帶來成本。 這些可以是直接成本，也可以是幫助我們減輕風險的成本。
- 在設計和實施解決方案時必須定義預期效益。
成本、風險和效益將有助於TCO和ROI，如下圖所示。
所謂的效益是關於業務成果或是業務價值。例如，效益可能是增加營收或是加速產品上市。如果有看過本部落格CAF系列文章的人應該可以看出來，所有CSP的CAF最後都指出 — 能否達成業務成果才是決定是否採用雲端的原因。但同時這些CAF也指出了採用雲端也會帶來風險與成本。
哪麼甚麼是成本？通常大家都會想到直接成本，就是企業直接從口袋掏錢出來的成本:
- 軟體授權
- 硬體資源或服務 — 如VM/防火牆/gateway等
- 人力 — 企業要花錢請架構師、工程師與其他有的沒有的專家來搞定雲端運算
而間接成本(或稱隱藏成本)，如人員的訓練。
而從風險的角度來看，我們要來看在雲端中一個特別的議題: 軟體授權。
當企業要使用軟體時通常需要付費的。軟體有分為商業版與開源軟體。不同之處在於開源軟體允許修改軟體代碼，並且把修改的代碼送回給開放這個軟體的開發者。商業軟體則不允許這麼做。
但市面上的商業軟體何其多，這在雲端中變得非常複雜。一般的狀況下如果企業對軟體授權的使用量付費不足，被抓到是會是罰款外加有追朔期。而這樣的狀況在雲端中是一樣的。
企業如何知道使用的軟體是否有授權了？ 軟體授權只有幾種類型（但有很多變體），但歸咎其本質，可歸結為以下類別：
- 算人頭的 — 例如微軟的Office 365或google workspace
- 算資源的 — 例如Oracle DB的軟體授權是算該台機器有有多顆CPU。這樣的費用有資源維度與時間維度。
- 買斷的 —這對企業的預算控制最簡單的作法
至於軟體授權有沒有買足，可以使用SAM(software asset management)工具。SAM 工具的作用不僅僅是對公司使用的所有軟體進行盤點：這些解決方案也評估軟體的整個生命週期，從購買到部署，甚至到使用。
其他風險包括成本增加或缺乏技能熟練員工。 兩者都越來越成為企業日常營運中的事實，而不是風險。 許多公司已經面臨技術人員短缺和成本增加的問題。 顯然，風險一旦發生就會嚴重影響業務價值。
為了管理成本與風險，我們需要一個受管控的流程。這就是成本意識設計，如下圖所示。
如同所有CSP的CAF所提到的，一切都從商業案例開始。商業案例靠著進行以下活動協助企業在雲端相關成本控制與投資。我們可以在上圖中看到，所有的活動都會回到商業案例。
- 將雲端費用的資料對應到企業的業務 —
這通常很花時間，但是卻是必須完成的。這個屬於FinOps的crawl階段。老闆可以看到每一塊錢都投資在業務的哪一部分。重要的是組織結構要能夠反映在雲端平台的設計中。
在多雲中，我們必須確保在我們使用的每個平台上都以相同的方式完成此操作。 各個雲端平台建立帳號層級的過程必須相同，否則充值模式(recharging model)將無法發揮作用。 成本將無法準確分配，或者更糟糕的是，模型中完全遺漏成本而未分配。 - 定義標記(tagging)策略 —
這需要良好的執行紀律，否則我們將會看到雲端的財務報告是亂七八糟的。 - 定義一個清楚的showback與chargeback模式 —
關於什麼是showback與chargeback，我們在FinOps系列文章中已講得很清楚。 - 定義預算與預測(forecasts) —
在稍後階段，企業將能夠使用有關雲端費用的資料進行準確的預測，並為我們在成本意識設計的第一步中定義的單位設置預算。
FinOps轉型中的陷阱
FinOps的目標是協助企業賺錢，而不是只有單單節省成本。這是非常大的不同，因為傳統的IT從來被視為成本單位而非營利單位，但雲端時代的到來卻改變了這一切。成本撙節至上的心態會導致花很多冤枉錢的情況發生。
例如，一個中小企業的開發人員不多，沒有辦法像跨國公司一樣進行7x24小時的研發。從這個案例來看，地端機房的設備就會有資源閒置的狀況，而雲端則可以在沒有使用時停止使用資源，進而費用節省。
另一個主要陷阱是購買雲端管理工具而沒有適當的流程和人員。 企業必須採取第一步：讓正確的人上車、設定目標並定義指標。
實施 FinOps 的最重要的教訓可能是不應該用top-down的方法來完成。 它不會導致 FinOps 實踐的採用，企業也不會實現目標：讓在雲端平台中作業的團隊意識到財務後果。 團隊應該對在雲端中使用正確的資源和服務負有重大責任，但也必須具有成本意識。 他們做出的每一個設計決策都會產生財務後果。 這就是意識，也是FinOps採用的開始。
