FinOps的生命週期 — 知情階段

我們從開始問問題來進行 FinOps 實踐。這就是知情階段的全部內容。當我們找到這些問題的答案時，我們就可以開始評估我們雲端的狀態。在本文中，我們將探討一些我們應該從頭開始的問題，並且我們將了解一些常見功能。所有這些都將幫助我們了解在優化階段的重點。

正如我們知道的，FinOps 不是一個線性過程。但是第一階段的可見性對於我們進入下一階段至關重要。我們將在知情階段花費大部分時間。如果我們過快地進行優化，很容易犯下代價高昂的錯誤。量測會讓我們知道一些資訊，以便我們可以進行變更，然後我們根據維運指標來衡量這些變更，依此類推。換句話說，我們總是會繞回來到知情階段，然後再次進行一次。

我們需要有一些資料以便讓我們知道我們在哪裡。然後，我們將準備好採取對業務有益的行動。

在這個階段，組織和團隊要能夠有以下的能力

• visibility
• allocation
• benchmarking
• budgeting
• forecasting

雲端的on-demand和彈性(elastic)特性，以及協商後的定價和折扣，讓正確且即時的理解這些資訊後產生的決策是有必要的。然而我們也必須認知到單單只有資料是不夠的，我們必須知道整個故事的來龍去脈，也就是整件事的脈絡。為此FinOps成員需要與所有雲端相關的團隊共同合作。

用基於標籤(tags)、帳戶(account)或組織的業務對映到雲端支出的正確費用分配可實現準確的chargeback和showback。 業務和財務利害關係人還希望確保他們在保持預算範圍內並準確預測費用支出的同時提高ROI以期在費用上不會有太大的意外。 進行用團隊的基準測試(Benchmarking)為組織提供了發展高績效團隊的必要指標。

以下是我們可以詢問FinOps自己的問題

• 我們要回報什麼？是成本中心、應用程式、產品、業務單位還是其他？
• 大部分支出來自哪裡，就是來自哪一組服務？
• 我們要chargeback還是要showback嗎？每種方式都有好處，但無論哪種方式都有助於推動問責制。
• 如果我們要集中費率管理，公司的整體利益是優先事項，還是通過chargeback來收回成本更重要？
• 是為了看到趨勢還是為了能夠準確地回收每一塊的投資？早期的資料是關於趨勢走向；而之後它將變得非常細緻化。
• 我們將如何解釋成本中心的變化？一開始，我們可能有一個excel表，但之後我們將在 FinOps 平台中擁有一個分配資料的mater layer，以根據我們的組織不斷變化的結構動態重新對應。
• 我們將如何解釋團隊之間的人員調動？在他們調動部門之後，我們將如何獲得他們現在關心的資訊，因為他們的資料片段會有所不同？
• 我們要如何通知相關人員成本分配結構發生了變化？
• 我們真正需要的標籤是什麼？早期可能只有三個，但後來可能有幾十個。但是，如果我們確實擴展到數十個，則很可能我們有太多標籤，並且未來的生命週期循環可能會看到我們根據維運階段設置的更動目標優化標籤數量。
• 我們是否會從我們的 CCoE 中進行“午餐會報”之類的事情，以定期展示最佳實踐並讓人們興奮不已？

所以在這個階段，我們建立並使用tags/labels、帳戶層次結構和其他分類法來分配所有成本，以便近乎即時地了解我們雲端的當前使用情況

這些問題會隨著我們的運作越來越清晰，但是FinOps是一個循環回饋，就像品質管理大師愛德華茲·戴明提出P.D.C.A一樣，沒有最好，只有更好。但我們也會再自問一些更深層的問題:

• 在爬(Crawl)的階段：哪些團隊正在推動成本？在走( Walk)的階段：他們有效率嗎？ 在跑(Run)的階段：我們能把他們的成本與單位指標關聯起來嗎？
• 在爬(Crawl)的階段：我們是否為每個團隊制定了預算？ 在走( Walk)的階段：我們是否按照這些預算管理團隊？在跑(Run)的階段：我們是否能夠進行基於活動的成本核算？
• 我們的標籤(tag/label)策略的狀態如何？ 在爬(Crawl)的階段：查看哪些標籤已到位以及它們正在回報什麼。 在走( Walk)的階段：查看覆蓋範圍的差距。 在跑(Run)的階段：考慮如何分配無法下標籤或共同成本。
• 我們將如何使我們的分配結構保持同步和最新？ 在爬(Crawl)的階段：excel表。 在走( Walk)的階段：與我們的 CMDB 定期的的同步。在跑(Run)的階段：FinOps 平台和 CMDB 之間的 API 串接。
• 什麼是 RI 或 CUD 策略？ 在爬(Crawl)的階段：有哪些 RI？ 在走( Walk)的階段：它們的使用情況如何？ 它們如何被交換或修改？ 跑(Run)的階段：我們應該買哪些新的？ 然後……刷掉並重複這個過程。

建立FinOp的文化的工作

除了費用支出的資料分析之外，我們還有許多組織和文化工作要做以建立 FinOps 文化。 在健全的 FinOps 實踐的這一階段，我們將專注於：

• 讓C-Level們專注目標和雲端帶來的工作模式變化保持一致
• 幫助工程師了解他們在他們的作業會影響到的組織業務，尤其是要將成本作為要考量為新的效率指標
• 確保我們的團隊具備正確的技能
• 與財務或 IT 部門的同事建立合作關係，這取決於 FinOps 團隊屬於哪一邊
• 通過 FinOps Day 等活動在內部宣傳 FinOps 工作，以幫助分享概念、影響組織內的人並取得早期的勝利
• 通過管理方式盡可能有較多效率優化，與技術團隊保持一致（並幫助他們完成工作）

另外這個階段還需要努力的建立所有人對數字的信任，並提供一致性的報告(雲端成本數據)給所有的團隊，報告重點包含:

• 資料的透明度和回饋方式
• 異常偵測
• 對團隊績效進行效能測試(Benchmarking)
• 預測支出和預算
• 成本分配
• 帳戶、分類、Tags/labels

透明度和回饋方式

在透明度與回饋方面需要注意的事項有:

• 每日（或定期）的Cloud Usage Feedback
• 乾淨、準確、一致的資料，能簡單的呈現
• 通用語言(大家都聽得懂的)和成本指標
• 報告能夠自動化產生與送達
• 並按不同的角色進行不同的報告:
  具有不同需求/重點/範圍的團隊或群體
• 各種資料圖表的報告
  ○ 每月的直接成本（能發票對賬）
  ○ 預付費用（攤銷）
  ○ 特別專案的圖表（按專案、戰略計劃、研發計劃等報告）

在 FinOps 中，一種稱為“普銳斯(Prius)效應” — 在電動或油電混和的汽車中，駕駛在使用的動力是從引擎產生的充電或一般電池電力時會在儀表板上得到即時電力資訊回饋。 但儀表板上沒有顯示“省錢駕駛”的燈號訊息。 一般正常的駕駛會試圖留在綠區，因為這是人類自然的傾向。

這意味著如果雲端使用者沒有一種即時的儀表板資訊開著我們開的哪台車(雲端運算)的即時請況，雲端使用者就無法有一種認知。就是這一台車子的狀況為何，自然也無法好好駕馭這台車了。

所以關鍵是，通過持續的回饋，當我們需要使用我們可以使用的所有動力時，我們可以做出有意識的決定，並且雲端運算可以支援這種行為。 而在正常情況下，對使用者提供持續回饋往往會推動負責任的行為(因為車是你在開的)。

FinOps 團隊應努力為雲端使用者提供持續、簡單、清晰的回饋，以保持他們的省錢駕駛。

異常偵測

此階段的一項關鍵能力是偵測雲端費用支出異常的能力。 異常是偏離平均值、隨時間變化的斜率（趨勢）或週期性重複模式（季節性）的支出。 它們是眾所周知的大海撈針，在大多數雲端帳單的複雜性(用得越多越複雜)中很難發現。 但它們也可以真正加總起來。

為此我們需要做到以下的狀況能夠被偵測:

• 這個資源建立沒有經過核可
• 有錯誤發生

而異常檢測對於任何大規模雲端維運都至關重要。除了安全和維運監控之外，成本監控還可以提供重要的預警信號，所以需要:

• 適當的解決方案或工具
• 考慮各種告警方案 — 超過一定$$ 的閾值告警。偏離平均值的告警。特定view/某個服務的告警

並且這些都要能夠被快速告知，如自動化提醒的email/監控系統/工單系統。

基準測試(Benchmarking)

使用衡量團隊績效的計分卡(scorecard)是比較組織內各使用雲端的各團隊最佳方式。 計分卡讓我們可以找到表現最差和支出最高的團隊，還可以讓您深入了解如何與同產業內其他人進行效能測試。

計分卡還應該能顯示針對核心效率指標的改進機會。 我們們應該讓C-Level們了解整個業務（或其中的一部分），以了解每個人的工作情況，並能夠深入到單一團隊以得到可以有下一步行動的資料。 它們是 C Level最好的朋友，也是實現變革的最佳武器。 計分卡應該推動團隊的努力，並統一從事類似工作的不同團隊之間的經驗。 計分卡也幫助團隊相互競爭。

以下是我們在效基準測試可以進行的作業:

1. 制定對每個的團隊有意義的 KPI
   ○ 一致性的回報機制
   ○ 公平的成本分配
   ○ 一致且透明的成本指標
2. 趨勢和差異分析
   ○ 長期績效與數字一樣重要
   ○ 省錢並持續評估行為趨勢
   ○ 衡量 FinOps 團隊、DevOps 團隊、雲端使用整體的績效
3. 團隊之間的基準(benchmark)
   ○ 使用 KPI 持續衡量一段時間
   ○ 進行成本優化的遊戲化的(需要可能性的評估)
4. 與其他雲端使用者進行效能測試
5. 管理面
   ○ 可以得到我們的指標促進的行為
   ○ 需要不斷改進指標
   ○ 良好的中央集權的 FinOps 團隊角色

預測支出和預算

如果我們正在偏離預測趨勢，我們必須問自己：是否需要更改某些事才能讓我們恢復預測(forecast)，或者我們是否需要變更我們的預測？ 因此，我們需要每天追踪實際的雲端費用支出與我們的預測。 雲端費用支出圖表應包含我們的預測，以確定我們是否需要採取任何行動（如下圖）。 然後，我們可以將資訊分解到team level，這樣我們就可以查看誰的行為（如果有的話）不在我們預測之外。 如果是商業因素（合規性、效能等），這意味著我們應該選擇簡單地調整我們的預測。

如果是按月/季度評估預測其實是不夠的。高竿的 FinOps 人員不斷（每天）根據即時資料評估差異，以查看哪些團隊偏離了季度預測，然後相通知他們。這可以讓他們避免越來越大的差異。然後，在超出Forcast之前，可以向管理高層報告預測的變化。管理高層對其業務進行評估，以確定增加的雲端支出所產生的價值（如果有的話）。

隨著逐月的進行，這些持續的評估有助於組織做出更好的決策，同時顯示費用支出可以下降的最快點。預算(budget)不應該是為了防止支出，而應該提供一種工具來識別費用支出何時偏離計劃 — — 這可以促進團隊之間的內部討論。

預測(Forecasting)應該基於機器學習。 人工預測通常與實際值相差 20–70%，即使在人類為分析和預測數據而苦惱了數週之後也是如此。這些結果不值得付出組織的人力。

機器學習是準確預測費用支出的關鍵。但是單一模型或演算法是不夠的。一些機器學習演算法在有較長久的成本資料下能作的更好，而另一些則能夠處理有限的資料點。我們可能會擁有具有歷史悠久資料的帳號，但是當我們導入新的專案或全新的帳號時，某些機器學習演算法就失準了。將多種演算法整合起來是一種更有效的方法來適應歷史資料可用性的變異。

在進行預測時，我們必須考慮一些重要的考慮因素。我們的預測基於多長時間（支出模式可能與六個月前不同）？我們使用的成本指標是什麼？是否會攤銷包括 RI 在內？是否針對協商後費率進行了調整？團隊之間的一致性是關鍵，因此我們必須確保儘早就成本指標達成一致。

所以就預測支出與預算這一部分，我們在FinOps成熟度(爬，走，跑)應該會是:

• 爬：基於人工估算或去年的資料加上模型的預測
• 走：根據過去在應用程式或環境範圍內的使用情況進行預測
• 跑：通過服務進行精細預測，每日追踪並更新到實際值，包括折扣、攤銷和分攤成本

組織很容易將預算視為具有嚴格限制的控制方式(因為這是傳統的地端機房思維使然)。然而，預算不需要也不應該限制創新。正如我們之前提到的，"FinOps 不是為了省錢，而是為了製造獲利"。在 FinOps 下，預算是關於將我們的投資集中在推動創新而不是阻止創新上。

與技術工程團隊就成本優化進行的討論通常沒有成效。他們傳統上不必考慮成本(因為相關的軟硬體已經買好就位)，而且他們一直承受著交付更多和更快產品/服務的壓力。因此，可以理解的是，他們不願意花費寶貴的時間來優化成本 — — 那是別人的工作。

當 FinOps 成員與雲端架構團隊坐下來討論雲端成本的調查結果時，FinOps 成員經常會遇到建議的阻力，並且偶而只會看到建議的變更已實施。

但是，如果給團隊指定了具體的成本目標或要達到的目標，他們往往會達到目標。來自管理高層的成本節約指令通常有強制性。技術工程團隊會積極參並且尋求在保持速度和品質的同時降低成本的方法。調整規模是因為團隊有明確的目標。成本優化的討論已使他們有這個認知，並讓他們了解如何幫助企業。他們開始明白 FinOps 不是要削減資源，而是要實現速度和創新。

對於許多科技獨角獸來說，預算是個名詞。這是一個必要之惡，它分散了人們試圖在競爭激烈的成長市場中盡可能多地搶占市場份額的注意力。他們沉浸在一場永無止境的軍備競賽中，以提供更大更好的功能、引人入勝的內容或數據科學驅動的建議。有一個毫無根據的前提是預算會減緩一切。

但對於大多數企業來說，預算是啟動專案的必要步驟。在預算獲得批准之前不會開綠燈。但雲端已經徹底改變了預算流程。預算可以通過採購訂單的力量來控制的日子已經一去不復返了，因為這可以防止支付的費用超出計劃。由於雲端費用支出的分佈式和輕度管理的性質，大多數組織 — — 無論大小 — — 都在努力在公共雲中進行準確的預算。

像大多數事情一樣，制定有效的預算是一段旅程。以下是組織通常經歷的四個預算等級：

Level 1 : 根本沒人在做預算
在最近與知名科技獨角獸的一次會議中，該團隊被問及他們如何定義雲端支出的預算。 答案是搖頭：“我們沒有預算。 我們不想限制工程師。” 這家公司也意識到他們的支出比他們想要的要多得多。 該組織已經制定了未來三年每年在雲端上花費多少的計劃，但由於沒有落實到負責消耗雲端資源的各個團隊，所以他們已經完全接受了他們和雲端平台商之間所有的合約內容。

Level 2: 花跟去年一樣的錢
一家知名零售商的預算流程很簡單，就像試圖保持公司去年的支出一樣。 雖然從表面上看，這似乎是一個很好的起點，但它並不是基於對公司支出是否適合其所做的事情的分析。 他們公家單位一樣，它通過鼓勵團隊花費"所有預算"來創造錯誤的激勵方法，這樣明年就不會編不到同樣的預算。

這種類型的預算 — — 一種“第一時間止血”的方法 — — 實際上在阻止失控的雲端支出方面相當有效。 但這不會帶來省錢或任何有意義的與業務目標相關的雲端支出衡量標準。 這類似於在資本支出(CapEx)為重的傳統的地端機房採購設備的方式一樣來進行預算。 我們查看了我們當時擁有的設備以及剩餘的容量，但我們對所使用設備的實際效率一無所知。

Level 3:用成本帶出目標
成本帶出目標會查看我們在上個期間的支出，然後將其減少規定的金額。 它們可以為團隊提供正確的激勵措施，但它們通常是隨便定的，並且與任何特定的業務成果無關。 一家電商的目標是減少整個組織的支出，並為其每個團隊設定了降低 20% 的成本支出目標。 這個目標很容易實現，因為這是團隊給出的第一個優化目標。 畢竟，“被衡量的東西會得到改進。” 正在運行的機器可以完全停掉，未使用的存儲空間到處都是，並且有很多機會來調整資源大小和購買 RI。

Level 4 : 單位經濟績效指標
在這裡，公司開始將雲端支出與實際業務成果聯關聯起來。 如果組織的業務正在成長並且我們正在雲端中擴展資源，那麼我們花更多的錢不一定是壞事。 如果我們知道服務客戶的成本是甚麼並且能不斷降低成本，則尤其如此。 如我們所知，將費用支出指標與業務指標關聯起來是實現 FinOps 旅程的關鍵步驟。 任何人都可以看到單位成本是上升還是下降，但他們不知道為什麼，所以他們不能告訴你為什麼。 為了真正使分佈式團隊能夠影響他們的支出，基於組織業務活動的雲端成本是最後一步。

成本分配

成本分配有以下三種方式:

集中付款或合併付款
○ 採購單位為共同服務、RI 預付款、雲端基礎設施等付費。
○ 開發團隊只需支付直接的雲端成本，並套用任何折扣（RI /CUD等）
○ 發票可以按帳號拆分

Showback
○ 單一開發團隊可以看到他們的直接的雲端成本
○ 出於預算目的，向開發團隊顯示他們在共同成本、基礎設施和攤銷 RI 成本中所佔的份額

Chargeback
○ 除了直接雲端成本外的共同服務、基礎設施成本、RI 預付款和所有其他費用，要分攤給開發團隊
○ 帳號、攤銷計劃、標籤和其他工具的組合可用於產生chargeback report

chargeback通常不會在傳統的地端機房發生，就算有，大都是算人頭的(各業務單位的員工數)。而那樣對業務單位不公平也不準確。而在地端機房的效率報告中，沉沒成本很少被計算或追踪。雲端運算則沒有這樣的問題，雲端成本可以更輕鬆地變更和追蹤，並且每天進行管理。理想情況下，所有直接和間接成本都可以分配到成本中心為其編制預算。

而在成本分配中，FinOps的成熟等級為:

爬：拆分發票
走：產生包含 RI/CUD 攤銷的直接成本報告
跑：直接成本和共同成本，與每項成本的業務成果與攤銷是可以掛鉤的

但我們還是有一些特別的狀況需要處理，例如:

• 網路成本
• 雲端監控與管理工具或方案的成本
• 雲端的Marketplace費用
• 稅（按服務，包括Marketplace？）
• 技術支援費用(雲端平台商與代理商)
• 預付費用
• 折扣和credit(所謂credit就是雲端平台送錢到雲端計費系統)

另外雲端的支持者經常把從CapEx到OpEx的變化作為一種好處。 但情況總是這樣嗎？

• 使用 Opex 而不是 Capex 來建立新的應用程式？
• 增加OpEx？
• 減少CapEx？
• 用傳統的Capex 換Opex？

而以下的商業情況也不一定能適用從CapEx轉換到OpEx

• 內部資本成本和公司整體資本結構
• 公家單位與私人企業
• 指標報告和審計合規性
• 組織的競爭格局
• 規劃、預算和會計流程

帳號、分類、Tags/labels

而關於這三件事則有以下的事項需要注意

● 帳號

• 測試環境、開發環境、生產環境各一個？
• 還是一個包含 測試環境、開發環境、生產環境的帳號？
• AWS、Azure 和 GCP 是否一樣作法？

● 分類

• 用部門/業務單位/投資組合
• 用成本中心/專案代碼/專案 ID
• 或用其他正在使用中的成本分類法（例如 TBM）

● Tags、Labels

• 資源標籤
• 帳號 / 群組標籤
• 業務規則/綜合標籤

資源標籤是在雲端平台商的環境中分配。理想情況下在建立時在腳本中，或通過 SDK/CLI，或通過第三方工具，在建立資源時同時建立標籤。

而帳戶/群組標籤是在 雲端平台商或 第三方工具中分配給帳號/訂閱/資源群組/專案。理想情況下這類的標籤是作為帳號建立過程的一部分，或通過其他方式。

業務規則/綜合標籤是由第三方工具或成本管理應用程式用業務邏輯來下標籤。這適用於更複雜的使用/成本子集(subset)或需要邏輯樹來確定正確的標籤，可能通過查找表、CMDB 或其他帳號圖表的自動化。

而對於標籤的管理我們也需要注意以下的議題:

• 下標籤下太少有問題，太多也有問題
• 某些標籤對於了解費用支出不是必要的
• 考慮要下標籤的工作量（對工程師/FinOps 團隊/平台工程師）
• 考量無法下標籤的事物
• 標籤的治理政策

所以在FinOps中，對於標籤也有成熟度等級

• 爬：在資源/資源組的等級下標籤
• 走：標記資源和帳號的等級以擷取無法下標籤的成本
• 跑：跨不同雲端平台的標籤，跨帳號，能自動下標籤，根據自定義的業務邏輯建立標籤

最終願景

成為高績效者是沒有捷徑可走。 鍛鍊組織的肌肉可能需要數年時間。 當然，我們可以做一些事情來幫助加快這個過程，但最終我們需要經歷一系列的學習過程。 組織內的這種教育和文化發展需要時間。 事實上，我們可以直接嘗試跑(跳過爬跟走的階段)來損害組織的業務。 它不可避免地導致錯誤，從而帶來意想不到的成本。

高績效者能夠快速詢問和回答有關其費用支出和預測的複雜問題，他們對不斷變化的部署情景進行假設分析，並且他們了解這些變化對其"單位經濟"的影響。 由於雲端支出的精細度的可見性和分配性，他們知道需要做什麼來優化其維運指標。

這種高水準的能力使企業能夠通過創新速度提高競爭力，讓管理高層和團隊更好的理解成本和 COGS，也能更深入理解雲端的服務定價。

結論

FinOps 生命週期的告知階段是靜止的狀態。在這一階段，我們了解雲端財務管理的當前狀態，這將有助於我們在下一階段進行優化和維運改進。

總結一下：

• 根據我們的雲端財務資料建立整個故事脈絡來回答我們的問題。
• 使用資料監控費用支出並制定優化和效率計劃。
• 預測(Forecast)和預算的應用是在於於及早發現導致雲端支出偏離預期的問題。
• 預算是必要的，與單位經濟績效指標是掛鉤的。

爬/走/跑 模型很重要。隨著成熟度的每一次發展，我們都會回過頭來，這讓我們能夠回答有關組織在使用雲端的更複雜問題。

我們已經確定了問題，但沒有將雲端費用支出劃分為成本中心的解決方案，只能回答總體問題。我們需要一種方法來確定哪些成本屬於哪個成本中心，以便逐個團隊進行預算和預測。然後，我們可以對團隊進行效能測試(benchmarking)並相互比較。