歸因是監控的地基

有了歸因，成本才從一個總數變成一張可查詢的報表。雲端的成本分攤工具（AWS Cost Explorer、Cost Allocation Tags、GCP 的 billing label）用標籤當分群維度，於是「team-payments 這個月花多少」「staging 環境占總成本幾成」變成一次查詢、而不是一場翻帳的會議。這套 tag schema 與啟用機制由 infra 鋪好，成本管理直接用它的產出——不重複鋪地基，聚焦在「有了歸因之後做什麼」。

歸因裡最關鍵的一個維度是擁有者。一個沒有擁有者標記的資源，出事時沒人認領、要不要關掉沒人能決定，就變成孤兒資源長期計費。擁有者標記讓每個資源都有一個「出事找誰」的答案，這也是後面告警能自動路由到對的團隊的前提。

異常告警：抓突增，然後定位

成本監控要主動、不能等月底帳單。做法是設異常告警——日均花費超過基線某個幅度就通知，把「這個月怎麼這麼貴」的驚訝提前到花費突增的當天。雲端提供成本異常偵測（如 AWS 的 anomaly monitor，可設每日頻率、超過某個絕對影響就發通知），這套 IaC 也由 infra 的治理地基提供，成本管理引用它、聚焦在告警觸發後的處置。

告警的價值在於它配上歸因能立刻定位。成本突增的三個常見來源都很具體：開發者開了大型機器測完忘了關、自動擴縮的上限設太高在尖峰長出一堆機器、NAT gateway 的出站流量灌爆帳單。告警響的時候，因為資源都有標記，可以馬上看出是哪個團隊的哪類資源在漲，而不是對著一個總數乾瞪眼。抓到之後的處置就接回前面幾章：忘了關的關掉、規格過大的做 right-sizing、可中斷的批次轉 spot。

Showback 還是 chargeback

歸因鋪好之後，有一個制度選擇決定成本控制的力度：showback 還是 chargeback。showback 是純展示——把每個團隊的花費算出來、給大家看，靠透明度促成節約，但不實際扣任何人的預算。chargeback 是實扣——每個團隊的雲端花費真的從它自己的預算裡出，成本變成團隊要對自己負責的數字。

兩者的取捨是「效果 vs 組織複雜度」。chargeback 的節約效果強得多——當花費真的從自己的預算出，團隊自然會在意 right-sizing、會記得關測試機；但它需要組織上把預算真的下放到團隊、需要一套公認公平的分攤規則，複雜度高。showback 複雜度低、阻力小，適合起步或組織還沒準備好下放預算的階段。很多團隊從 showback 開始（先讓大家看到自己花多少），等文化成熟、分攤規則穩定，再進到 chargeback。細緻的 chargeback 報表不必第一天就做——歸因的地基要早（day-1 就把 tag 立好），但制度化的分攤可以等成本真的成為議題時再上。

成本 review 併進容量 review

成本監控最有效的做法是把它併進既有的容量檢討，而不是當成一個獨立的活動。每個月的成本 review 跟容量 review 一起做：看預算對實際的差距、找出前幾名的成本驅動、追月度趨勢裡的異常、跟容量團隊一起討論哪些資源該 right-sizing。成本跟容量本來就是一體兩面——容量規劃決定要開多少資源，成本管理決定這些資源花得值不值得，兩者放在同一個檢討裡，right-sizing 的決策才有容量數據支撐。

下一步路由

• tag schema、成本分攤標籤啟用、anomaly monitor 的 IaC 地基 → infra 治理好習慣
• 告警抓到過度配置之後怎麼調規格 → Right-sizing
• 非 production 環境的成本怎麼系統性壓下去 → 開發環境成本控制
• 成本 review 對應的容量檢討 → 模組五 容量規劃