當技術決策變成客戶管理：一個 S3 清理案例的顧問心法
做顧問久了會發現，真正困難的從來不是「技術上能不能做」， 而是「這個決定，會不會站在客戶的立場看起來很不合理。」
這次的 S3 清理案例，看似只是儲存管理問題，實際上卻是一堂完整的同理式客戶管理課。
表面問題是 S3，實際問題是信任
一開始，客戶提出的需求其實很直白：- S3 用量暴增
- 刪除速度異常緩慢
- 成本遲遲降不下來
如果我是客戶，這時候我心裡想的可能只有一件事：
「資料明明不要了，為什麼還一直在付錢？」
如果只站在工程視角，這確實是一個標準的「清資料」問題。
但站在顧問視角，我腦中第一個浮現的問題不是「怎麼刪」，而是：
「如果現在照客戶說的做，他看到帳單會發生什麼反應？」
技術判斷，先從「風險」而不是「效率」開始
深入檢視後，我們發現這個 bucket 同時踩中了三個高風險設計：
大量小型物件集中寫入同一層 prefix
任何逐筆操作，都會放大 API Request 成本。
如果我是客戶，我不會覺得「這是設計問題」，我只會看到一個結果：
「為什麼刪資料也要錢？」
啟用 S3 Versioning，卻沒有清理策略
刪除只是產生 delete marker，實際容量仍在累積。
從客戶角度來看，這是最容易引發不信任的一點：
「你們不是說刪掉了嗎？為什麼帳單和容量都沒有變？」
部分資料已轉入 Glacier 儲存層級
提前刪除或還原，都可能產生額外費用。
如果我是客戶，我不會在意 Glacier 的設計哲學，
我只會在意一句話：
「為什麼清理舊資料，還要再付一筆錢？」
這三件事疊加起來，代表一個顧問必須正視的事實：
「最快的刪除方式，往往是最容易讓客戶情緒失控的方式。」
客戶管理心法一：先替客戶承擔「他還沒想到的後果」
在顧問角色中，有一件事非常重要：
不要只回應客戶的需求，要先替客戶承擔他沒看到的後果。
客戶要的是「資料全部刪除」。
但客戶無法接受的，往往是：
- 刪資料後帳單突然上升
- 成本變化無法解釋
- 「清理」反而變成一個支出事件
所以在這個階段，顧問真正該做的，不是「照做」，而是幫客戶踩煞車。
為什麼我們刻意不選「直接刪」
從技術面來看，用 Console 或 CLI 直接刪除，確實是最直覺、也最快的方式。
但如果我把自己放在客戶的位置，這是一個極度不友善的體驗：
- 大量 LIST / DELETE → 帳單先上升
- Glacier 物件 → 可能被收額外費用
- 清理成果 → 卻要過一段時間才看得到
最後客戶只會記得一句話：
「你們建議的操作，讓我的帳單變貴了。」
而顧問往往就在此時失去信任。
客戶管理心法二：慢，不一定是壞事
在這次案例中，我們選擇了 S3 Lifecycle Policy。
不是因為它最快，而是因為它從客戶角度看起來最合理。
它符合三個關鍵條件：
成本行為可預期
刪除由 S3 服務端執行，不會突然製造大量請求費用。
情緒風險最低
不會出現「今天刪、明天帳單爆掉」的情況。
決策可被解釋
Lifecycle 是 AWS 官方設計的長期機制，而不是臨時補救。
這裡的重點其實不是技術，而是一句話：
「這個選擇，站在客戶立場，聽得懂，也說得出口。」
技術策略，其實是溝通工具
Lifecycle 的設定本身並不複雜，但它在「對客戶說明」時，意義非常大：
- current 與 noncurrent 版本都有處理
- delete marker 與 multipart 殘留會被清掉
- Glacier 物件依保存期限自然過期
這讓顧問可以很清楚地對客戶說：
「我們不是不處理，而是用一個不會讓帳單突然跳升的方式處理。」
客戶管理心法三：顧問的價值，在於幫客戶避免「事後後悔」
很多技術問題，如果只看功能，答案都很簡單。
但顧問的價值，從來不是「會不會做」，而是：
- 什麼時候該做
- 什麼時候不該急著做
- 哪些風險要先被擋下來
在這次 S3 清理中，真正被解決的不是儲存空間，而是一個還沒發生、但很可能爆發的信任危機。
結語：好的技術決策，會讓客戶「沒感覺」
站在客戶角度，最好的結果往往是：
- 沒有帳單暴增
- 不需要緊急解釋
- 也沒有事後追責
甚至只會覺得：
「事情好像就順順地解決了。」
而對顧問來說，這正是真正把客戶放在心裡的證明。
其實，我們只是一直在問同一個最原始的問題
回頭看這整個 S3 清理案例，我們並沒有做什麼特別高深的技術操作。
我們只是反覆問了一個問題：
「如果我是客戶，這個決定在事後看起來，會不會讓我後悔？」
當答案是「可能會」的時候，
即使那個方案在技術上再正確、再有效率， 都不該是當下的選擇。
這其實就是第一性原理在顧問工作中的樣子。
不是從工具出發，也不是從最佳實務出發， 而是從人真正會感受到什麼開始思考。
在這個案例裡，第一性原理不是：
- S3 怎麼刪
- Lifecycle 怎麼設
- Glacier 的行為細節
而是這個再簡單不過的事實：
客戶不在乎你怎麼刪，只在乎帳單為什麼變這樣。
當我們把決策基準回到這個層次，很多看似「慢一點」「保守一點」的選擇， 反而成了最合理、也最負責任的答案。
對顧問來說，真正高階的技術決策，往往不是讓事情「發生得更快」， 而是讓事情發生得讓人不後悔。
而那，正是第一性原理在現實世界中，最實用、也最有人味的樣子。
