FinOps-導入工作負載的能力
- 為什麼 FinOps 團隊參與將工作負載導入雲端很重要
- 將工作負載導入雲端與將工作負載導入地端機房有何不同
- 確定構成良好導入流程的關鍵活動
- 將工作負載導入雲端的最佳實踐
- 描述在 FinOps 成熟度的各個階段，良好的工作負載導入流程是什麼樣子，以及如何衡量成功
在 FinOps 框架內，可以在雲端資源使用優化領域中找到導入工作負載能力，因為工作負載導入到雲端的方式將影響運行它所需的主要雲端資源和支援雲端資源的成本和使用情況。
與此能力的相關FinOps能力
定義
導入工作負載功能旨在建立於雲端中遷移和開發應用程式的流程。 FinOps 處於管理遷移（Brownfield）和新的Cloud First應用程式開發（Greenfield）的上游團隊的交叉點。
參與角色
FinOps 的核心焦點是驅動價值。 參與早期的導入工作負載的浪潮將有助於優先考慮雲端價值並使組織受益。 在導入工作負載一開始就與架構師、DevOps 工程師和資安團隊合作，可以培養成本調查的早期採用者，並將有助於在這些技術團隊中推廣 FinOps 思維和文化。 隨著 FinOps 實踐的成熟，這將非常有利於組織內 FinOps 的採用。
此外，在導入工作負載時，避免浪費比管理浪費好得多。 在早期「上游」階段所做的決策將對以後的 FinOps 工作產生深遠的影響。 這很重要，我們為提高導入工作負載效率和提高使用率而投入的精力將使後續工作變得更加容易。
當 FinOps 專業人員參與導入工作負載時，我們可以從一開始就提高可見性和意識，以實現要導入工作負載的目標和目的。
相關活動
在執行此能力期間會發生許多不同的活動。 這些活動需要在規模上、跨多雲、user friendly（而不是控制點）方面保持效能，並在整個工作負載導入過程中提供專家支援和指導。 身為 FinOps 專業人員，我們將在整個導入工作負載流程中參與、推動和支援這些活動。
- 參與SOW/專案/計畫/遷移
- 與架構團隊的介面
- 檢視架構圖
- 與平台團隊的整合
- 產生或檢視所預估的事物
- 確認負責人、成本中心與預算核可
- 教育產品負責人與技術團隊
- 了解專案時程和進度審查
參與SOW/專案/計畫/遷移的角色
此活動的參與人員根據RACI模型如下:
- R — 專案經理/遷移主管
- A — 產品經理
- C — FinOps、技術、資安
- I — 財務
在此活動期間，應定義並記錄新增或遷移工作負載的初始範圍。 FinOps 團隊應討論範圍內和範圍外的內容，並記錄期望、限制、資源和時程表。 產品負責人和工程師將確定工作負載遷移範圍並準備商業論證。 在此期間，他們將就成本管理和治理考量因素正式或非正式地諮詢 FinOps 人員。 在理想狀態下，FinOps 將就"如何、何時以及在何處"計算遷移的工作負載成本進而提供建議。
與架構團隊的介面
此活動的參與人員根據RACI模型如下:
- R — 技術
- A — 產品經理
- C — FinOps、資安
- I — 財務
在此活動中，FinOps 團隊支援架構團隊了解在為業務設計新解決方案時如何將成本效率適當地納入決策過程。 這將有助於最大化業務價值。 交付成功的雲端架構已經涵蓋了許多不同的議題 — — 安全性、量能、韌性和業務需求的適用性。 價值和成本效率必須成為與其他領域並列的主要因素。
檢視架構圖
此活動的參與人員根據RACI模型如下:
- R — 技術
- A — 產品經理
- C — FinOps、資安
- I — 財務
在此活動期間，應檢視解決方案架構的適當性。 技術團隊負責在資安團隊的協助下將業務需求轉化為解決方案架構，以確保與組織的資安原則保持一致。 FinOps 團隊應透過效率視角積極檢視架構，以確保其不會帶來不必要的複雜性和浪費，並在適當的情況下為相關成本節約措施提供指導（例如電源管理、reserved/spot instance、storage tiers）。
與平台團隊的整合
此活動的參與人員根據RACI模型如下:
- R — 技術
- A — 產品經理
- C — FinOps、資安
- I — 財務
在此活動中，FinOps 團隊必須與平台團隊密切合作，以整體交付高效的 FinOps 成果。 最終，平台團隊往往才是真正花錢的地方。 這些是實施架構規範的個別團隊（並且經常做出決定以使該規範適應現實世界）。 這些團隊每天都會做出雲端支出的選擇。 這些平台團隊必須認知到其行動的直接成本結果，這一點至關重要。 FinOps 專業人員可以支援使用所有權、協作以及及時、清晰的報告原則，以確保每個人都有權透過所做的每項決策創造價值。
產生或檢視所預估的事物
此活動的參與人員根據RACI模型如下:
- R — FinOps
- A — 產品經理
- C — 財務
- I — 技術、資安
在此活動期間，應以明智的方式估計整個生命週期的成本。 FinOps 團隊應該利用現有的資訊和指標，擁有可用的工具來預先估計已加入工作負載的成本。 這不僅包括運行與工作負載直接相關的資源的成本，還可能包括共享成本。 也希望了解整個生命週期的成本，這可能會考慮資源部署的時間、未來服務的擴展和支援成本。 這可以透過定期成本檢視或自動預測來實現。
確認負責人、成本中心與預算核可
此活動的參與人員根據RACI模型如下:
- R — 產品負責人、產品經理
- A — 財務
- C — FinOps、技術
- I — 高階管理層、資安
在此活動期間，可以對所有共享和非共享成本進行適當核算和分配。 在導入工作負載時，無論是透過遷移還是新專案，發展商業論證並獲得批准和贊助仍然很重要。 產品負責人和專案經理將負責這項活動，其中不可避免地包括批准預期成本以及最終由誰來支付費用。 為了追蹤這些成本，FinOps 和技術部門必須提供輸入，以確保服務正確放置在帳號層次結構中，並且存在用於成本追蹤和分配的必要metadata。
教育產品負責人與技術團隊
此活動的參與人員根據RACI模型如下:
- R — FinOps
- A — 高階管理層
- C — 全部
- I — 全部
在此活動期間，資訊以開放且可用的方式提供，以便每個人都在同一個共識中。 FinOps 團隊的主要職能之一是推動組織內的 FinOps 文化和最佳實踐。 實現這一目標的最佳方式是開放成本分配和共享方式、制定政策和架構模式，團隊可以將這些政策和架構模式用作導入工作負載時的指導工件。 此外，許多 FinOps 團隊都有產品負責人入職訓練，以引導他們了解雲端道路的規則。
了解專案時程和進度審查
此活動的參與人員根據RACI模型如下:
- R — 專案經理
- A — 產品經理
- C — FinOps、技術、資安
- I — 財務、高階管理層
在此活動期間，專案時程表與預算和其他組織活動保持一致。 作為專案商業論證的一部分，專案經理需要了解專案活動何時啟動以及這些活動對組織其他領域和 FinOps 領域的影響。 例如：
- 其他團隊應該什麼時候參與？
- 這些架構是否支援 FinOps 功能？
- 新加入的工作負載將如何影響預算/預測/異常偵測？
FinOps 團隊需要在生產環境的工作負載上線後重新參與，以製定優化調整建議和承諾決策。 FinOps 與專案時程表以及任何可能影響架構權衡和預測/預算的範圍蔓延保持一致至關重要。
成功的衡量因素
我們如何衡量雲端功能中的導入工作負載是否成功？
- 遷移規劃
FinOps 團隊是否參與工作說明書 (SOW) 準備和(或)遷移決策？
這種參與是什麼樣的？ - 上游成本估算
估計的營運成本在多大程度上包含在工作負載導入的討論中，並在製定架構決策時予以考慮？ - 上游最佳化
有多少比例的已上線的工作負載在放入雲端時已經針對業務價值進行了最佳化？ - 成本差異
實際工作負載營運成本與最初估算有何差異？
差異的大小是多少？ - 未來的工作負載管理
部署到雲端後所需的 FinOps 工作等級（工作負載管理、規模調整、雲端帳號變更）？
Crawl階段
- 遷移規劃
FinOps 在遷移前的討論中沒有代表。
在實際部署工作負載之前，FinOps不會參與其中。 - 上游成本估算
此階段的工作負載導入期間沒有上游成本估算。 - 上游最佳化
此階段的工作負載導入期間沒有上游最佳化。 - 成本差異
如果在導入前沒有做出良好的估計，則可能會出現很高的成本差異。 - 未來的工作負載管理
由於工作負載被標記為最佳化（rehosting、 refactoring、rightsizing等），未來的工作負載管理負擔可能會很高。
Walk階段
- 遷移規劃
FinOps 團隊應參與其中，並需得到架構師、DevOps 和安全代表的接受。 - 上游成本估算
架構師、DevOps 和資安團隊歡迎經過充分準備的估計，並在工作負載導入決策中考量到業務價值。 - 上游最佳化
有些工作負載從一開始就是為了優化成本和業務價值而設計的。 - 成本差異
優化工作負載的成本差異相對較低，其他工作負載的成本差異相對較高，並且可能會針對預算超支產生一些告警。 - 未來的工作負載管理
最佳化的工作負載可能需要 FinOps 團隊進行最少的部署後作業，而其他工作負載可能需要大量的作業。
Run階段
- 遷移規劃
FinOps 團隊應定期參與遷移前的討論。
這是組織政策的一部分。預設情況下，工作負載旨在優化導入流程中的成本和業務價值。 - 上游成本估算
所有導入討論都會考慮營運成本估算和預期業務價值。 - 上游最佳化
組織政策將包括一個規則，用於根據過去的經驗評估哪些工作負載應考慮遷移或建構在雲端。 - 成本差異
全面的成本差異相對較低。 差異會被預測出來並透過例外情況進行管理。 - 未來的工作負載管理
未來使用最佳化（即工作負載管理和自動化、資源使用率和效率）所需的 FinOps 作業量將大幅減少。
成功衡量標準和 KPI
成功的衡量標準在雲端成本的背景脈絡下呈現，可能包括一個或多個KPI，以OKR描述目標 ，並宣告定義異常值或與預測趨勢的可接受差異的閾值。
- 透過節省基礎設施、遷移和支援成本來衡量成本效率
- 提高服務品質和安全風險態勢的營運韌性
- 透過加快產品和服務交付的流動性來縮短上市時間
- 打造快速實驗文化，推動創新與雲端轉型
- 在整個組織中融入真正的環境和社會永續性
- 為應內建或遷移到雲端的工作負載建立組織範圍的政策或規則
投入
有助於實現上述成功衡量標準的資訊分為以下幾類：
- 成本效率 — 基礎設施成本、支援成本、遷移/實行成本
- 韌性 — 服務品質、安全態勢、維運穩定度
- 速度 — 開發人員的生產力、發布頻率、業務敏捷性
- 創新 — ROI、員工體驗、客戶滿意度
- 永續性 — 碳足跡、能源效能、循環經濟
最佳實踐
- 為設計團隊進行上游最佳化教育
- 建立政策、程序和模式
- 制定最佳導入策略的協作
- 根據估算和 KPI 定期檢視工作負載
- 在將工作負載導入到雲端之前建立Rollback計劃
為設計團隊進行上游最佳化教育
在組織中注入上游最佳化的一種方法是將導入工作負載納入所有相關的 FinOps 訓練計畫中。 開發此訓練內容時，請包含工作負載導入如何影響組織的總體成本。 在談論上游最佳化時，我們還可以將組織的策略優先事項納入工作負載導入選項和建議中。 這將有助於在調整更大的組織優先事項時獲得利害關係人的支持。 最後，為了吸引設計團隊成員的關注，找到可以傳播雲端工作負載上游優化訊息的「擁護者」。
建立政策、程序和模式
身為 FinOps 專業人員，協助建立明確的導入工作負載的政策、程序和模式非常重要。 這將有助於促進多個團隊採用一致的方法。 然後，團隊就可以獨立作業來處理工作負載。 這將透過了解哪些模式最有效、在團隊之間有機地採用它們並將其正式化為政策來促進整個組織的成熟度提升。 提前完成這項作業將在以後減少差異，但可能為時已晚。 建立這些政策、程序、模式甚至作業流程的主要領域是：審查 SOW、估算成本、調整架構以及尋求預算所有者和批准。
制定最佳導入策略的協作
FinOps 專業人員的職責之一是關係發展和協作。 確保與技術和設計團隊建立積極的協作關係。 這將有助於在談判中佔據一席之地，特別是在儘早參與 SOW 討論時。 在討論最佳導入訓練時，請認識到適用於工作負載入導入訓練策略的限制並採用務實的方法。 一次性進行多項變更可能很誘人，但更確切地說，目標是透過 FinOps 生命週期（Inform、Optimize、Operate）建立穩定、迭代的改進。
根據估算和 KPI 定期檢視工作負載
當新的工作負載加入雲端時，甚至在加入之前的過程中，將這些工作負載採用到組織現有的追蹤流程中。 一旦工作負載啟動，就可以允許一段時間的穩定，以便工作負載可以穩定下來。 此後，FinOps 專業人員應根據一組一致的指標或 KPI 定期檢視已加入的工作負載。 FinOps的職責是建立一個流程來檢視使用率、效率和架構選項，並標記潛在的改進。 FinOps 專業人員還需要與利害關係人合作，驗證成本估算與實際運作成本。
在將工作負載導入到雲端之前建立Rollback計劃
雲端本質上是敏捷的，因此即使在工作負載導入之前進行了所有規劃和測試，事情也可能不會按預期進行。 雲端的靈活性允許快速做出決策，並且可能對財務影響最小（「快速失敗」）。 專案團隊應該在工作負載啟動之前製定rollback計劃，而不是事後才建立計劃。 這個計劃可能就像終止所有資源一樣簡單。 該計劃也可以更加複雜，並且可能包括針對更複雜的工作負載的詳細記錄的流程。
