FinOps 的核心目標是有效管理雲端成本，而報表設計與管理是達成此目標的關鍵環節。本文從精簡報表數量、提高資料品質出發，探討瞭如何針對不同角色（財務、長官層、工程師）設計專屬報表，並將 FinOps 資料整合到其日常工作流程中。同時也分析了多雲環境下資料擷取和標準化的挑戰，以及如何運用認知心理學原理，例如錨定效應、確認偏見等，設計更易用、更有效的 FinOps 報表，引導團隊做出明智的決策，最終提升雲端效率。
營運報表最佳化：FinOps 實踐的關鍵
在 FinOps 實踐中，報表的設計與管理扮演著至關重要的角色。有效的報表不僅能夠提供精確的資料，還能引導團隊做出明智的決策。Jason Rhoades，Intuit 的開發經理，分享了他們如何最佳化報表以支援分散式團隊的需求。
精簡報表數量與提高資料品質
Jason Rhoades 表示，他們只保留少於十份官方報表，這些報表回答了所有需要圖形報告的問題。資料透過篩選器縮小到特定範圍內，使相關方能夠關注最重要的資訊。這種做法有效地減少了資料雜亂，提高了資料的可信度。
資料民主化的雙面性
資料民主化可以提高團隊的工作效率，但也伴隨著風險。如果資料消費者在構建自定義報告時出現誤解或做出不同的決策，FinOps 團隊可能會陷入解釋資料差異的困境。因此，建立明確的責任界限對於限制 FinOps 團隊的責任至關重要。
報表的分級管理
隨著報表數量的增加，使用者很難區分哪些報表是重要的、最新的和可信的。透過對報表進行分級管理，可以引導使用者正確使用報表。例如，將報表分為低階別和高階別，低階別報表標記為非維護狀態，而高階別報表則是經過嚴格維護和監控的，能夠提供可靠的資料。
臨時報表的管理
臨時報告在 FinOps 過程中非常重要，但應定期清理不再相關或提供價值的舊報告，以避免員工誤用過時的報告做出決策。提供給員工一個更新的生產報告列表，可以減少對 FinOps 團隊的支援負擔。
變更管理的必要性
隨著時間的推移，報表需要根據新的資料和需求進行變更。在變更生產報表時，應事先在測試環境中進行驗證，並提供相關檔案，以確保使用者能夠理解變更的原因和內容。使用 API 或檔案上傳功能來組態和管理報表，可以提高變更的效率和可追溯性。
通用報表的陷阱
許多從業人員試圖將所有 FinOps 資料整合到一個所謂的「通用報表」中。然而，這種做法往往會導致報表過於複雜，難以閱讀和理解。正確的做法是根據資料點之間的關聯和使用者的需求，將報表進行適當的整合或拆分，以提高報表的清晰度和可用性。
設計有效的FinOps報告
在設計新的FinOps報告時，應力求簡潔。只包含必要的資訊，並盡可能進行匯總。你可能有數百列可用的資料，但包含過多的資訊會使報告難以理解。或者，更好的做法是提供互動式報告，讓使用者能夠深入檢視他們需要的資訊，在需要時新增更多背景或連線更多資料點。
這一點在你建立交付給使用者的報告時尤為重要，而不是使用者在需要資料時才載入的報告。交付的報告將在沒有背景的情況下到達使用者手中，因此需要簡短明瞭，以傳達其資訊。如果交付的報告過於複雜，包含過多資訊，使用者可能會將其存檔，等待有更多時間閱讀，當然，這通常不會發生。
“雜亂和混亂是設計的失敗，而不是資訊的屬性。” —— Edward Tufte
透過設定能夠提醒你變化的報告，你可以建立監控報告，用於監測你不希望看到的事情，例如未使用的雲產品成本、未附加的儲存卷或每日成本跳躍超過設定的百分比。這些報告的通知功能意味著你不需要每天檢查其狀態。相反，讓報告為你工作，在需要閱讀時通知你。
報告設計原則
FinOps報告最成功的時候是你識別出員工需要回答的常見問題，並將報告針對這些問題進行設計。問問自己：“我試圖用這個報告回答什麼問題？”並確保報告實作了這一目標。同時，考慮員工需要知道什麼資訊才能使用你的報告。例如，如果他們需要應用程式名稱或成本中心編號，請確保將使用者引導至幫助他們首先獲得該資訊的報告。
將你的報告視為層層疊加的蛋糕，最上層的報告需要最少的資訊來使用，並且只提供足夠的資訊讓他們使用下一層的報告。當你的使用者向下鑽取到更詳細的特定區域時，他們需要的額外細節才會被提供。
無障礙設計
讓你的FinOps報告對所有員工都可存取至關重要。在建立報告時，請考慮你無法向所有使用者解釋報告的內容。如果你的同事在閱讀你的報告時需要你的解釋，那麼你將難以在組織內擴充套件FinOps。
本文提供了一些常用的UI設計，將有助於使你的FinOps報告更加有用。如果你的組織幸運地擁有專業的報告或UI/UX團隊，他們也可能能夠為你提供已經在使用的示例，以進一步幫助你。
顏色使用
在撰寫本文第一版時，我們犯的一個錯誤是在內容中參照了我們所包含的圖表中的顏色。結果這本文將以黑白印刷，圖表現在具有各種灰色陰影，而內容卻說諸如“紅線與藍線”。顏色的移除使我們的許多圖表變得不清楚，我們不得不重新設計它們並重寫參考內容。雖然完全色盲——只能看到黑白——是不常見的，但在較大的組織中，有一些員工患有某種形式的色盲是可能的。因此，你應該努力使用多於僅僅顏色來表示報告中的不同元素。不要只是紅色和藍色的線條，而是使其中一個實線，另一個虛線。不要是具有實體顏色的條形圖，而是選擇一個具有條紋，另一個具有點。如果更改圖表的格式是不可能的，那麼你最好有兩個圖表，而不是一個堆積疊多個專案的圖表。
視覺層次結構
在你的報告和儀錶板中，將相關的內容擺放在一起。在相關內容周圍設定視覺邊界，並在間接相關的內容之間繪製清晰的區分線。考慮如何佈置內容，將使你的報告對觀眾來說更直觀。
你應該考慮這種視覺層次結構，用於報告上的資訊排列，其中摘要資訊通常位於頂部或左側，而更詳細——或不太重要——的資訊位於底部或右側。
可用性和一致性
你的使用者將很快放棄難以互動且速度緩慢的報告和儀錶板——這增加了在組織內實施FinOps的挑戰。
圖表示例
圖表翻譯： 此圖示呈現了一個簡單的流程控制圖，首先開始（A），然後檢查是否出現錯誤（B）。如果是錯誤，則進行錯誤處理（C），之後繼續執行（D）。如果沒有錯誤，直接繼續執行，最後結束（E）。此圖清晰地展示了基本的錯誤處理機制。
重點摘錄
- 簡化FinOps報告，只包含必要資訊。
- 提供互動式報告，讓使用者能夠深入檢視所需資訊。
- 使用視覺層次結構，使相關內容更直觀。
- 避免僅使用顏色區分不同元素，應結合其他視覺元素。
- 確保報告的可存取性，讓所有員工都能理解和使用。
最佳化FinOps報告的設計：易用性與認知心理學的應用
在構建FinOps報告和儀錶板時，保持效能和一致性至關重要。這不僅能讓員工更容易理解如何使用這些工具，還能提升整體的營運效率。本章將探討如何透過應用認知心理學原理來設計更有效的FinOps報告。
語言的一致性
在討論FinOps時，使用統一的術語可以保持報告的一致性。避免在不同報告中變更術語，或使用模糊的詞彙，這可能會導致讀者混淆。例如，在FinOps實踐中，常見的一個不一致之處是對「成本」一詞的使用。正如第4章所述，這個詞可能指未攤銷成本、攤銷成本或完全負擔成本等不同概念。
顏色和視覺表示的一致性
雖然需要使用多於顏色的區別化手段，但這並不排除使用顏色的可能性。應當在顏色和視覺表示的使用上保持一致性。當你在一個圖表中將節省表示為綠色虛線，而在下一個圖表中卻使用實藍線表示節省時，讀者可能無法理解兩者代表相同的概念。更糟糕的是，在不同圖表中對不同的專案使用相同的顏色/線條樣式，這會迫使讀者仔細參考每個圖表的圖例，以確定每個專案的含義。
認知而非回憶
當資料被一起呈現時，使用者可以更容易地認識到不同資訊片段之間的聯絡。如果呈現的資訊需要參考螢幕外或其他報告中的資料，則會迫讓使用者回憶先前呈現的資訊，導致他們在報告之間頻繁切換。這種相關資訊的分離會使讀者難以將其聯絡起來。
「比較必須在視野範圍內強制執行，這是一個基本點，但在實踐中有時會被遺忘。」— Edward Tufte
心理學概念的應用
Dale Carnegie在其經典著作《如何贏得朋友和影響他人》中說：「與人打交道的成功取決於對他人觀點的同情理解。」FinOps在很大程度上是關於在正確的時間以正確的方式提供正確的資訊，以影響和鼓勵他人的行為。
錨定效應
錨定效應是一種認知偏差，指早期呈現給使用者的資訊會影響他們對後續資訊的看法。例如，當一輛汽車與更昂貴的型號（錨點）一起擺放時，人們更有可能購買它。你的本地零售商經常使用這種策略。當你進入一家商店，看到一台價格極高的電視時，這會讓你的腦海中對「昂貴」有一個錨定，從而使你更有可能購買的其他電視看起來像是划算的交易。
考慮一份向工程團隊呈現其服務成本的報告（見圖8-2）。在報告的開頭，你包含了整個組織中最昂貴的前10項服務，這可能會使你的工程師對這些最昂貴的服務的成本產生錨定效應，從而影響他們對自己服務成本的看法。
圖表翻譯： 上述Plantuml圖表展示了錨定效應在不同場景下的應用。左側描述了零售商如何利用昂貴商品使其他商品顯得划算；右側則說明瞭在FinOps報告中，列出最昂貴服務如何影響工程師對自身服務成本的認知。
確認偏見
確認偏見是指使用者尋找和解釋資訊的方式支援他們先前的信念。當使用者從報告中選擇支援其觀點的資訊，而忽略相反的資訊，或將模糊的證據解釋為支援其現有態度時，就會表現出這種偏見。
最佳實踐
- 保持一致性：在術語、顏色和視覺表示上保持一致。
- 減少認知負擔：將相關資訊放在一起，以減少使用者的回憶負擔。
- 避免偏見：注意錨定效應和確認偏見等認知偏差，在設計報告時採取措施減輕其影響。
內容解密：
上述最佳實踐建議瞭如何在FinOps報告設計中應用認知心理學原理。透過保持一致性、減少認知負擔和避免偏見，可以建立更有效、更易用的報告，從而更好地支援決策制定。
透過瞭解和應用這些心理學理論，你可以設計出更有效的FinOps報告，幫助使用者做出更好的決策，並最終提高組織的營運效率。
心理學概念在FinOps報告設計中的應用
在設計FinOps報告時，瞭解相關的心理學理論有助於提高報告的有效性。這些理論可以幫助組織更好地呈現資料，從而引導工程師和決策者做出正確的決定。
避免確認偏見
確認偏見是指人們傾向於關注支援自己觀點的資訊，而忽視與自己觀點相矛盾的資訊。為了避免這種偏見，可以採取以下策略：
- 提供多個不同的報告，讓使用者選擇支援其思考的報告。
- 使用一致性和可識別性來幫助抵消確認偏見。
- 避免使用通用報告設計，因為它可能會提供過多的資料點，讓使用者找到一些「好訊息」來關注。
範例：針對特定問題的報告
與其提供一個包含40,000個計算資源的報告，不如建立一個標題為「[您的團隊]應盡快考慮調整大小的資源」的報告，列出前5或10個節省成本的資源。這樣的報告更具針對性，也更難被駁斥。
馮·雷斯托夫效應（Von Restorff Effect）
馮·雷斯托夫效應，也稱為隔離效應，指出當多個同質刺激被呈現時，與其他刺激不同的那一個更有可能被記住。在FinOps報告中，這意味著：
- 工程師更容易記住最大或最小的專案。
- 使用獨特的顏色或樣式可以使某個圖表在記憶中脫穎而出。
圖表示例
此圖示顯示了服務成本，包括每週差異。透過在報告中包含每月增長量，可以影響工程師記住增長最快的服務。
圖表翻譯： 此圖示呈現了服務成本的不同導向，包括當前每週支出和每月增長量。透過這兩個維度，可以全面瞭解各服務的成本狀況。
希克定律（Hick’s Law）
希克定律描述了人們做出決策所需的時間與可選項數量之間的關係。隨著可選項的增加，決策時間也會增加。在FinOps最佳化報告中：
- 應盡量減少推薦專案的數量，以減少工程師的決策時間。
- 移除無效或高風險的選項，可以提高決策效率。
範例：AWS Compute Optimizer控制檯
AWS Compute Optimizer控制檯限制了推薦專案的數量，並顯示價格差異和效能風險，以幫助工程師做出決定。這種做法減少了工程師需要花費的時間，並提高了生產力。
報告視角
在評估FinOps報告設計時，應考慮以下視角：
人物角色（Personas）
針對不同的角色設計報告，可以提高報告的有效性。例如，將長官者的報告與工程師的報告分開，可以更好地滿足不同角色的需求。
成熟度（Maturity）
隨著FinOps實踐的成熟，需要報告的資訊量會迅速增長。報告應能夠跟蹤新增的能力和成功的衡量指標，並根據雲端服務的使用情況進行調整。
雲端原生服務與多雲環境的成本管理挑戰
隨著企業在雲端運算上的投入日益增加，雲端原生服務的使用也變得更加多樣化，例如函式即服務（FaaS）、機器學習（ML）等更高層級的應用服務。這些新增的服務將引入不同的計費結構，有些按時間計費，如每秒或每月；有些則根據使用量計費，甚至兩者兼而有之。雲端帳單中使用的服務越多，雲端成本報告的任務就變得越複雜。
多雲環境的挑戰
當企業開始大量使用多個雲端供應商時，財務營運（FinOps）團隊可能會從單獨的報告開始，尤其是當選擇使用個別雲端服務供應商的計費工具時。儘管主要雲端供應商使用的許多術語和概念在功能上相似，但命名慣例和服務分類別存在差異，這可能會造成混淆，有些元素甚至是特定雲端供應商所獨有的。有關雲端中標籤和元資料結構之間差異的詳細分析，請參閱第12章。
將不同雲端的資料分開，會迫讓使用者在不同環境之間回憶資訊，並自行連線相似的概念。正如 Edward Tufte 所說，「比較必須在視野範圍內強制執行」。
為了減少與多雲報告相關的努力和混淆，最好將雲端資料合併到一致的報告中，並正確處理連線資訊的複雜性。要實作這一點，您可能需要超越原生的工具，轉而使用內部或外部供應商的工具。
資料擷取和標準化的重要性
資料擷取和標準化是 FinOps 基礎框架的基本能力，以實作其他能力。有效的 FinOps 實踐需要定期存取詳細的使用情況、利用率和成本資料流，這些資料可以被分類別和分析，以推動決策制定。監控平台、安全平台和業務營運應用程式也可以提供有關利用率、位置、價值和使用情況的資料，通常具有相似的資料量和粒度。隨著資料的複雜性和多樣性增加，資料擷取和標準化的挑戰也隨之增長。在決定如何處理自己的資料時，請務必檢視框架中提出的此必要能力的成功衡量標準。
將資料置於每個角色的工作路徑中
FinOps 資料對於最大限度地發揮雲端支出的價值至關重要，但不幸的是，它往往被隱藏在孤立的 FinOps 專用報告和工具中。當這些報告被孤立在日常工作流程之外的儀錶板中時，工程團隊、業務長官者和財務團隊等需要它們的人卻很少利用它們。
為了改變這種情況，請嘗試將資料置於每個角色已建立的工作方式中。
財務部門的資料
第一個看到某種形式的 FinOps 資料的角色通常是財務團隊。這源於共同的利益，因為財務部門希望將雲端支出資料新增到其已建立的財務報告系統中。雲端支出首先與公司的採購訂單相關聯，以幫助將支出分配給正確的預算。將 FinOps 資料納入財務系統，可以使您現有的財務流程與總結的雲端支出協同工作，並減少與財務團隊的摩擦，因為他們有完善的報告和稽核要求，通常不能偏離這些要求。
長官層的資料
長官層和執行報告也應包括 FinOps 資料，以顯示雲端支出與現有業務指標之間的關係。為了讓業務長官者做出決策，請確保在他們習慣消化的其他資料中，包含有關雲端支出、節省和機會的關鍵資訊。將 FinOps 資料與其他業務資料分開，會強化 FinOps 與業務其他部分脫節的錯誤觀念。正如我們將在第26章中討論的那樣，您應該旨在長官層報告中提供單位經濟指標，將雲端支出與業務指標結合起來，以展示雲端使用對業務的價值和影響，而不僅僅是成本。
工程師的資料
最後但同樣重要的是，我們強烈建議您致力於將 FinOps 資料置於工程師的工作路徑中。當您的工程師開始思考 FinOps 時，它不應該與他們已建立的日常慣例有太大差異，也就是說，您不希望他們遠離 DevOps 而花時間做 FinOps。理想情況下，它成為一個整合且必需的過程中的一部分。
我們經常說，成本只是另一個效率指標。工程團隊將會有專注於一系列關鍵指標的儀錶板和儀式。這些儀錶板將監控安全性、效能和可靠性指標，以成功管理其在雲端中執行的服務。請嘗試將關鍵的 FinOps 資料新增到這些現有的位置和系統中。將他們開始考慮雲端支出變化所需的資料——如實際值與預測值以及降低成本的機會——納入他們正在進行的衝刺規劃中。孤立的 FinOps 資料和對話會產生認知負擔，並使工程師遠離他們的主要任務。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title FinOps實踐與雲端成本最佳化
package "系統架構" {
package "前端層" {
component [使用者介面] as ui
component [API 客戶端] as client
}
package "後端層" {
component [API 服務] as api
component [業務邏輯] as logic
component [資料存取] as dao
}
package "資料層" {
database [主資料庫] as db
database [快取] as cache
}
}
ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取
note right of api
RESTful API
或 GraphQL
end note
@enduml圖表翻譯： 此圖示呈現了不同角色（財務部門、長官層、工程師）如何檢視和使用 FinOps 資料，以及這些資料如何被整合到統一的報告中，以支援業務決策和最佳化雲端支出。
內容解密：
此圖表呈現了不同角色對於FinOps資料的需求和使用方式，以及如何將這些資料整合到統一的報告中。其中，財務部門關注雲端支出報告，長官層關注業務指標與雲端支出的關係，而工程師則關注雲端支出的變化與最佳化機會。最終，這些資料都被整合到統一的報告中，以支援業務決策和最佳化雲端支出。
FinOps 使用者介面設計：打破部門壁壘與提升雲端效率
將 FinOps 納入業務流程
在匯入 FinOps 的過程中，最關鍵的是將成本意識融入工程師的日常工作流程中，而非將其視為額外的負擔。當 FinOps 資料在開發生命週期的早期被引入現有的流程時，工程師能夠在設計新架構或改程式式碼的每個步驟中考慮成本。這需要合理分配時間進行 FinOps 活動，以實作企業期望的雲端效率。
與其他業務部門合作
FinOps 團隊應與現有的財務、執行和管理報告團隊合作，將 FinOps 資料整合到他們的報告中。這不僅能促進不同部門之間的溝通，還能確保語言的一致性，並以鼓勵行動的方式呈現資料。現有的團隊通常擅長使用 API 提取和處理複雜資料，將 FinOps 資料融入他們的工作流程，能夠避免中斷現有的工作模式。
資料路徑（Data in the Path）概念
「資料路徑」的理念是將關鍵的 FinOps 資訊帶入現有的報告和工作流程中，而非將整個 FinOps 世界塞進每個人的報告中。這樣可以促進針對性的對話和決策，而不會干擾目前的工作節奏。當出現需要更深入分析和報告的問題時，再將相關人員引導至更詳細的 FinOps 報告。
瞭解與溝通
在面對最佳化建議或效率評分資料時，應避免直接下結論或指責，而是應啟動無責備的對話，先了解相關人員的決策背景，再嘗試影響他們。Target 公司的效率工程總監 Kim Wier 就是這樣做的，她會詢問工程團隊如何定義資源的高效利用，並根據業務目標提供相關的 FinOps 資料。這種方法能夠建立反饋迴圈，使 FinOps 的建議更符合業務需求。
使用者互動的重要性
Intuit 公司的開發經理 Jason Rhoades 分享了他們的經驗：透過引入涉及使用者寫入活動的 FinOps 工作流程，例如審核工作流程或調整資產分配，解決了更多問題。這種互動式和迭代式的報告功能需要 FinOps 團隊具備新的技能，但能夠更全面地解決問題。
下一步：實施 FinOps 生命週期
現在您已經瞭解了 FinOps 的基礎知識，是時候進入更有趣的部分了。本文第二部分將介紹 FinOps 生命週期中的「資訊階段」，詳細闡述成本分配、預測、帳單變化監測和最佳化效能監控等內容。這一階段將推動團隊的責任制，並為未來的改進設定目標。
