FinOps-資料擷取與正規化能力 Part 1
資料擷取和正規化是一項將首先在了解雲端的＂資源使用和成本＂領域中執行的能力。 組織使用工具來將位於資料湖內的＂成本、資源使用情況、效能、效率或成本分配＂等這一類的資料進行擷取與正規化，這將是一組重要且需要不斷重新檢視的流程。 使用第三方工具或CSP原生工具的組織可能會透過這些工具執行大部分此能力，並且可能需要較少的需求。本文的重點：
- 概述從CSP中取得雲端成本和資源使用資料的流程
- 描述將擷取的資料類型
- 描述組織可能想要進行的標準化活動的類型
- 各種CSP的資料擷取來源和目標的特定範例
資料擷取與正規化的定義
有效的 FinOps 實踐需要定期存取詳細的資源使用、資源利用率和資源成本資料流，可以對這些資料進行分類和分析以推動決策。 與地端機房的世界不同，雲端資源使用情況的資料並不缺乏。 CSP會產生大量非常詳細的資源使用情況和成本資料，作為 FinOps 實踐的基礎。 監控平台、資安平台和業務營運應用程式還可以提供有關資源利用率、位置、價值和資源使用情況的資料，通常具有相似的數量和細緻度等級。
因此，雖然許多地端機房遇到的問題是缺乏詳細資料，但雲端使用者面臨的挑戰往往是資料太多。 有效的資料管理策略應努力為 FinOps 團隊提供來自以下資料來源的正確資料組合：
- 正確的資料來源系統
- 在正確的時間支持決策的節奏
- 以適當的細緻度支持匯總報告和深入調查
- 透過適當的標準化、增強、正規化等
資料擷取的策略將會是由財務報告、成本分配和最佳化報告這一類需求所驅動。 在業務部門層級所做出決策的所需資料將不需要那麼多詳細的資訊。
在資源層級管理或分配成本的 FinOps 團隊可能需要多個資料來源來加料，因為有些資料或資訊是CSP本身不提供的。
隨著資料複雜性和多樣性的增加，資料擷取和正規化的挑戰也隨之增加。 細緻度等級、成本和費率指標的一致性、相似或類似服務之間的不匹配、各種類型折扣的應用、metadata對資源和層次結構的應用，以及CSP的計費和資源使用資料之間的許多其他差異，即使在考慮定期更改和提供的大量資料之前，CSP提供的資料也可能會產生挑戰。
為何此能力是重要的
因為資料多到爆且複雜。如果企業使用多雲，哪資料來源是多個。並且每個CSP的以下資料維度都各有差異。
- Cost Metrics
- Discount and Credits
- Special programs
- Specific service with no physical analog
最麻煩的是資料與格式經常會變。
參與人員
此能力的參與人員根據RACI模型如下:
- R — FinOps Lead, Data Platform Lead
- A — FinOps Lead
- C — 財務、會計、資料等團隊
- I — 所有人，對於資料品質與即時性有關的人
成功的衡量標準
- 擷取時間 — CSP的資料產生後載入資料所需的時間
- ETL 時間 — 處理資料以使其標準化和正規化所需的時間
- 可從一般正規化data schema查詢而來的自多個CSP的成本/資源使用資料的百分比或總計
- 可用於以標準化貨幣進行報告的總體成本的百分比
- 匹配metadata元素的百分比
Crawl階段
- 儘管是個別的報告，但會匹配傳入來源檔案的成本和資源使用資料的細緻度
- 確保應用於層次結構和資源的metadata在CSP和資料來源之間保持一致
- 在這個階段，使用全面的第三方 FinOps 平台非常有用
Walk階段
- 從多個資料來源取得資料，標準化成本指標
- 在此階段，使用第三方 FinOps 平台標準化資料和報告可能非常有用
- 能夠為不同的雲端建立一致性的報告，但可能使用不同的報告
- 績效/利用率資料的整合
Run階段
- 資源的”使用情況、成本、效能、利用率”資料的一致性資料存儲
- 對計費機制、格式、資料對映有很好的理解
- 能夠使用多個雲端、多個資料來源、一致的成本指標
- 能整合地端和公司特定資料
- 可以客製或管理官方使用的資料報告平台
- 進行資料品質評估的能力
最佳實踐
資料來源
成本與資源使用資料
- AWS CUR檔案
- Azure Billing API
- GCP Billing Data
效能資料
- 資源如何使用？
- 資源的較能如何？
使用率資料
- 每種資源的使用量
- CPU/Memory/Data/Network可能需要不同的來源
內部（或專有）資料集
- 尋找有關資源、組織、成本中心代碼的資料
地端機房資料
- 內部私有雲，如Vmware or Openstack等
Receipt的細緻度和排程
- 建構一般或特定存儲庫/資料存儲
- 資料正規化規則
-資料擷取檔案中的哪些欄位與哪些標準化報告欄位相符（與資料分析結合）
-CSP之間的哪些成本指標是相符的（與量測單位成本並列） - 異常
-我們的資料在哪裡？
-資料品質的問題
資料擷取的檢查清單
- 辨識所有資料來源（成本和資源使用情況、效能、使用率、內部、地端）
- 建立可存取所有資料（權限、保留政策等）的Landing Zone
- 設定細緻度、發送頻率，確保所有metadata都包含在資料中
- 記錄並驗證資料正規化規則、欄位、列
- 記錄資料品質的檢查、節奏、流程、責任
- 設定報告以識別資料攫取的異常（儀表板、報告、觸發器、通知）
正規化範例 — AWS
- 包括哪些內容(Core/memory/EBS volumes/Data transfer)
- 多少錢(on-demand cost/ discount due to commitment/ discount due to usage/其他折扣/free tier/ 預付費涵蓋的攤銷)
- 發票和 CUR 與 EC2 的補償不匹配
- 應該使用什麼“類別”metadata來將所有這些收集在一起？ 服務名稱、產品名稱、使用類型、資源 ID？
- 跨雲端的成本是否也類似，或者需要進行調整嗎？
- 不同的量測單位
- 跨實例、期間、成本類型的總和
資料擷取問題
如果有資料沒出現問題?
- 理解資料發送的節奏
- 通常在計費週期結束時發生變化
- 設定自動檢查/報告以接收和成功處理預期資料
- 了解該打給誰或查看什麼來診斷不同類型的錯誤
- 與相關利害關係人設定期望
如果有資料品質問題?
- 計費資料複雜、來源多樣、不斷變動、經常在沒有通知的情況下就給你改
- 報告的查詢始終基於我們所設計報告時所了解的內容
- 儀表板和報告可能是由具有不同技能水平的許多不同人員隨著時間的推移對複雜資料進行數十次查詢的結果
- 建立綜合檢查報告，或依靠第三方平台檢查資料品質
- 隨著使用情況的變化和時間的流逝，不斷重新評估報告/儀表
其他資源
- AWS —
Cloud Intelligence Dashboards 作為工作坊發布，我們可以與我們的團隊或 TAM 一起進行 - AWS —
AWS 成本和資源使用情況報告切分 - Azure —
使用適用於EA的成本管理 Power BI 應用程式分析成本 - GCP —
使用Looker視覺化雲端成本 - GCP —
使用 BigQuery 和 Looker 優化GCP 支出
傳統IT與雲端財務的不同
