帳單變小之前，我想先知道錢花在哪裡

最近看了理性避難所談沃爾瑪與 Kmart 的影片。有一句話，我在討論 metabiz 成本時又想起來：低價是結果，不是戰略。

影片的解釋，沒有停在誰願意賣得更便宜，而是往後看那個價格怎麼成立。它以配送中心、門店密度與補貨安排為例，說明幾個做法如何互相支撐，逐步改變成本。

影片以配送、門店與補貨的連動說明戰略支點。我最想留下的，不是學沃爾瑪的價格，而是那個順序。

先找出一個能讓其他事情更容易的做法，成本與價格才有可能跟著改變。光先決定要便宜，沒有回答我們要怎麼持續做到。

這剛好接上我們十月初在做的事。

當時，我們要做的事很具體：把 metabiz 的雲端資源逐項核對，找出可以調整的地方，但不能讓仍在使用的服務因此出問題。

哪些服務還在用，哪些資源已經不需要，主機到底忙在什麼地方。也在評估，有些工作能不能放回自己的設備。

我需要的不只是一張較低的費用估算，還需要工程端確認依賴與負載，業務端確認誰還在使用，並把每個調整的驗證結果留下來。只看其中一邊，容易省錯地方。

但我也不能只把清單交出去，請大家先查完再來討論。可以先整理既有帳單、配置與監控，提出候選調整，再請相關的人核對仍不清楚的依賴。沒有監控的地方，也要由我們安排取得必要證據，不能把查不到當成沒人在用。

如果你也在決定要不要縮主機、刪服務或搬回本地，這篇談的，就是下決定之前要先核對的工作。

很容易先問：可以省多少？

這當然是我要知道的事。但越往下看，越發現有些地方，還不能直接從價格開始決定。

這次有一台主機的 CPU 用量很高。從這個數字看，似乎很難把規格縮小。

後來的診斷紀錄卻顯示，相當一部分耗用來自日誌收集與歷史日誌反覆掃描。修正之後，Docker 的短時間取樣耗用明顯下降。

在十月三日的查核紀錄裡，主機還沒有降規。其他服務、記憶體和尖峰負載，仍列為需要繼續觀察的項目。

但這件事已經讓我重新看待那個高 CPU 數字。

我們原本可能以為，是工作需要這麼多資源。往下追才發現，裡面有一部分，是可以避免的反覆處理。

也就是說，在討論換一台比較便宜的機器之前，還有事情可以先做。

放回影片的觀點，我想拿回 metabiz 的，是去看什麼做法能讓我們長期少一些不必要的耗用，而不是要求大家把成本壓到最低。

清掉一個不用的資源，可以省下一筆錢。如果下次部署又把同樣的東西建回來，還是得再清一次。

找到問題、確認修正，再把設定留下來，才有機會讓下一台也少走同樣的路。

這時候，監控、診斷和部署就不只是三件分開的工作。監控幫我們看見，診斷讓我們知道原因，部署則讓修正有機會持續。

影片最後提出的三個自檢，我也想留著。以下是我放回 metabiz 的理解。

第一個，有沒有一個具體的支點？對我們來說，不能只寫降低雲端費用，要能指出先處理哪段耗用、為什麼它會讓後面的配置更容易調整。

第二個，幾件重點行動有沒有互相支撐？如果監控、修復與部署各做各的，修過的問題可能還會回來。這些工作要接得起來。

第三個，方向裡有沒有明確的不做？這次就包括，不因為單次 CPU 低便直接縮機，不因為有備份便認定服務能恢復，也不為了省錢刪掉仍然需要的工作。

這三個問題幫我檢查方向，但實際能省多少，還是得回到配置、負載與帳單核對。

我也不想因此就認定，把服務搬回自己的主機一定更省。

雲端帳單可能變小，但電力、備份、維護和故障時誰來處理，都不會因為沒有出現在那張帳單上，就消失了。還需要一起看。

同樣地，CPU 下降也不等於費用已經下降。要確認工作能正常完成，真的調整配置，再看後面的帳單，才知道省下多少。

回看那次盤點，有些調整已經做了，有些仍待觀察。我希望每一筆節省都能說清楚，是從哪裡來，而不是拿幾個不同時期的估算，加成一個好看的數字。

若客戶來找我們做類似的檢查，我也希望先讓他看見能開始做什麼：先核對哪一段、會交付什麼判斷、還需要哪些授權。不能要求他先找出浪費的原因，我們才接手；但深入到什麼程度、需要多少投入，也應該先約定。

這件事放回產品和專案，也有值得想的地方。

如果每個客戶都要重新整理、重新串接、重新救一次火，報價再低，也只是我們少收了一點。交付本身沒有比較容易。

但如果某一類工作越做越熟，導入、驗收與支援都有可以沿用的基礎，我們才多了一些選擇。可以給客戶更好的價格，也可以把餘裕留在服務與品質上。

我還是想讓帳單變小。

只是我更想知道，那是因為我們少付了什麼，還是因為我們真的把事情做得比較順了。

— Adam｜metabiz 創辦人

延伸參考：理性避難所｜沃爾瑪與 Kmart