降本增效是今年的主旋律，對于技術團隊來說，最大的成本除了人力成本，就是我們的技術成本。這里的技術成本包括各種 CDN、網絡帶寬、服務器、存儲、云計算服務等。
如果你是一個運維總監，或者是技術負責人，需要在技術成本上節流提效，這篇文章應該對你有一些幫助。
今天所講的策略是當我們面對一個已有的技術基建和系統，如何有計劃地針對技術成本做優化，如何持續運營，讓成本降下來，讓錢花得有理有據。
整體分為兩個階段，成本優化和精細化運營。
1 成本優化
成本優化是一個「止血」的過程，如果之前沒有刻意關注過技術成本，可能存在較多的浪費或者不合理，特別是當業務在高速野蠻發展的時期，一不留神就會出現你想象不到的成本浪費。
我們做成本優化一般有如下幾步：
1.1 組建團隊
一件事情要想做得比較好，得先有一個團隊。對于技術成本優化這種可能會跨團隊，跨業務的事情，更需要有一個合適的團隊。
在項目成立時，我們可以成立專項小組，小組由以下成員角色組成：
- Owner(組長/負責人) ：負責整個項目的規劃、計劃安排、人員協調以及對外溝通匯報等，為整個項目負責；
- 運維的負責人（運維總監/ SRE 負責人）：負責整體技術成本的評估、公共技術成本的評估、優化，以及云服務商上相關操作的評估，規劃和人員安排， Owner 和運維的負責人可以是同一個人；
- 業務側的技術負責人（各業務的技術總監/技術經理）：負責各業務側技術成本的評估、優化落地；
- 財務的負責人（財務總監/財務經理）：負責組織安排技術成本資金的確認、核對以及預決算等。
以上為主要小組成員，一般各負責人還會拉上具體操作的核心同學一起參加，這些同學由以上的負責人自行安排協調。
1.2 現狀分析
技術成本之所以浪費，大概率是不知道錢花在哪里了，賬有點糊涂，或者說沒有人去關注里面的細節，是一個大大的黑盒子?？赡艽蠹叶家乐鴳T性往前跑，有業務要申請資源，直接上操作臺或系統買了分配完事，沒有考慮這些投入的價值在哪里。
現狀分析主要的作用是把這個黑盒子打開，把里面的東西一個個拿出來，把數點清楚，把每個云產品、去服務使用的情況摸清楚。
在做現狀分析時，我們建議先定量分析，再定性分析。
這里的定量分析并非嚴謹的科學實驗中的定量分析，而是以云產品為項，分析其成本金額、實例數等的情況，再在此基礎上確認優化的策略。
咱們的定量分析有兩個維度，一個是基于時間維度，看每個月的成本，年度成本，對成本有一個大的概覽；另一個是基于當月各個云產品的使用情況，看有哪些優化的空間。
如果沒有比較好的報表支撐，并且存在多賬號，多云服務商等情況，建議直接拉一個 Excel 表格，表結構大概如下：
| 月份 | 云廠商 1 成本 | …… | 合計 |
|---|---|---|---|
| 2021-01 | 阿里云 | …… | 合計 |
在以上數據表的基礎上，以總的趨勢圖和餅圖等較直觀的方式展示出來，趨勢圖能看到漲跌的情況，餅圖能看到組成部分，可以以云產品為維度，也可以自行分類查看，此處建議使用飛書的多維表格，生成儀表盤，當然，如果你 Excel 操作很強，那隨意。
通過以上的表格，能大致了解整體成本的情況，對于后續成本的優化評估，年底預算等都會有一個較為直觀的印象，以后續決策打下基礎。
了解了整體成本的情況，接下來就是要打開盒子，在不明確業務歸屬的情況下，我們先從云產品的維度來梳理整個成本的情況，對此，我們的定量分析有一個簡單的模型表格，如下：
| 云廠商 | 云產品 | 當月成本 | 優化策略 | 優化預計收益 | 操作難度 | 業務風險 | 優先級 |
|---|---|---|---|---|---|---|---|
| 阿里云 | OSS | 108萬 | XXX bucket 轉低頻 | 10 萬 | 低 | 中 | 高 |
基于以上的模型表格，我們可以快速地確認能「止血」的部分，我們對其做一些定性的分析，如分類。
一般技術成本優化大概有如下的一些情況：
1.2.1 折扣和計費方式
折扣是一個很明顯的優化點，當你在某個云廠商消費到一定的金額，應該是有對應的折扣，具體的折扣情況需要和你對接的商務來聊，不同的區域，不同的人，聊的結果不同，但是一定是有空間的；而且不同的產品可以折扣不同，如果你某個產品的消費金額特別高，可以單獨申請很低的折扣，很低很低。
不同的計費方式在不同的量級，成本不同，需要根據業務評估，或者是一些續費的方式，不同的續費方式成本也是不同的，如按年或按月的價格差異也蠻大的。
1.2.2 存儲
現在的存儲大家基本都會用云存儲，而不是自己來搭一套。每個業務都往存儲里面存東西，基本上沒有人太去管。而實際上這里的浪費往往較多，常見的情況有：
- 歷史存儲，沒有人維護，如一些臨時性的文件、過期的文件、用戶不要的內容等等；
- 無用存儲，原來是給業務使用，但是業務新申請一個 Bucket，舊的沒有刪；
- 冷熱存儲，用戶的一些文件，但是很久沒有訪問了，屬于冷數據了，但是這些冷數據還在存在標準存儲中，而在云廠商的邏輯中，除了標準存儲，還有低頻存儲，歸檔存儲，冷歸檔存儲等，建議根據實際的使用場景規劃使用哪種存儲，以及使用哪種存儲過期策略；
- 日志存儲，特別是鏈路跟蹤的日志存儲，鏈路跟蹤數據的價值是隨著時間的推移急速降低的。從我們實際的生產情況看，但凡你發生一個線上的調用異常，如果是真正的問題，我們在半小時以內發現解決，甚至幾分鐘之內就處理掉。幾天后，它就變成了一個無關緊要的異常，也就沒有什么價值了。但是如果我們對這些鏈路跟蹤的數據不做處理，其存儲量隨著時間推移會越來越大，成本也就越來越高。所以我們可以把過去一小時或兩小時以外的數據進行采樣、清洗最終只保留有價值的數據，實行差異化的鏈路跟蹤數據存儲，從而降低存儲成本；
- 存儲帶寬，像阿里云的 OSS 提供外網直接訪問服務，如果開放了外網直接訪問，建議評估一下，是否走 CDN + 回源更合理，或者有沒有本來可以走內網的，卻去了外網訪問；
- 存儲計算，有些存儲帶有一些圖片處理等的計算能力，這些能力也是單獨收費的，如果此處費用較高，建議評估以空間成本換計算成本，或者從業務上考慮減少計算量。
1.2.3 機器
主要指我們常見的云服務器，數據庫等，其常見的優化點：
- 沒人用的機器，這個特別常見，比如某個業務想跑一個定時任務，一段時間后不跑了，也沒有知會運維同學，機器就會一直在那里花錢，但是啥價值也沒有；
- 線上負載低的機器，一些線上的服務配置超高，如最開始評估容量是 100，但是實際只用到了 10 或者 10 都不到，但是并沒有把機器降配，畢竟對于使用方來說，在不考慮成本的情況下，配置高更好一些，特別對于一些 GPU 的機器，特別貴，如果只是偶爾用用，考慮是否直接在內網本地部署；又或者一些小業務在獨占某個實例，此時可以合并這些小業務到一個實例，釋放其它的實例；
- 非線上環境閑置的機器，一些開發測試環境配置了非常好的機器，或者多個業務各有一套，但是實際使用頻次很低的情況；
- 數據庫存儲浪費，有些存儲的數據因為版本升級或遷移等原因，一直留著，沒有刪除，也沒有地方用上，或者是一些沒有用的數據也一直存在數據庫中，此時可以溝通后刪除，釋放空間，降低配置。
1.2.4 流量帶寬
主要指 SLB、一些網絡網關等的流量，常見的優化點：
- 內外網錯亂，比如一些請求可以走內網，卻走了外網
- 計費方式，流量有按帶寬和按流量，根據歷史數據測算，哪種更劃算一些，可能前期用流量劃算，到后期量大了后用帶寬更劃算一些，這里就需要具體問題具體分析。
1.2.5 CDN
- CDN 帶寬，帶寬優化最常見的就是壓縮了，看 CDN 的壓縮機制開了沒，特別是對一些圖片的壓縮，有些甚至可以省一半的帶寬；
- CDN 的其它計算成本，如 HTTPS 的費用，不同的云廠商不一樣，有些沒有這個成本，可以考慮多談談折扣。
1.2.6 云服務
像一些安全服務，如 WAF、DDoS，或者云計算之類的服務基本都是云廠商提供的，我們常見的情況：
- 服務共用，像 DDoS 是按實例收費，如果是多業務，可以考慮共用一個實例以減少成本；
- 服務空轉，比如像一些治理類的服務，可能當時確實需要，或者試了一把，最后沒有用起來，導致云服務還在繼續跑，而沒有人在用；又或者某些云的數據庫各種附加功能，有些是默認開啟的，其實可能用不上，一直開著一直浪費成本，如此種種；
- 服務版本，有些服務，不同的版本其價格不同，比如阿里云的 DMS，新版的價格和舊版的價格就不一樣；
- 服務超配，服務有其不同的檔位，可能是一些歷史原因，或者一些奇怪的需求，導致申請了比較高配置的服務，后面沒有調下來，一直在消耗成本，沒有物盡其用，和業務方溝通后把配置降下來；
- 多服務商對比，如內容安全審核，短信服務等等超公共的業務，可以選擇多家云廠商，一個是災備，另一個是成本控制，像內容安全審核，網易易盾的價格就和阿里云 CDI 價格差距挺大的。
1.3 項目計劃和里程碑
基于上面的現狀分析，我們大概清楚了我們能做什么，以及做了這些后可以得到的收益。根據收益的大小、操作的難易度、風險的大小來評估優先級，對于收益大的，操作簡單，風險小的先快速落地；對于收益小，復雜且風險高的往后放放。
根據優先級，我們下一步是制定詳細的計劃表和里程碑。
大的里程碑可以分為三個：
- 止血，第一批快速落地里程碑，盡量控制在當月底，快速把通過運維部門操作能優化的點做了，解決明顯的浪費和不合理使用的情況，快速見效；
- 業務優化，一些需要業務側優化的高收益的優化，一些需要和云廠商重新簽合同等依賴于第三方的操作，屬于有些難度的止血療傷操作，此時需要業務側一起參與進來評估，優化，見效時間為一到三個月；
- 精細化運營，建立技術成本控制體系，對技術成本進行精細化運營，解決業務演化過程中成本出現的變化，應對突發事件產生的成本增加；
在里程碑的基礎上，列出每一個里程碑中的詳細計劃跟進表，大概如下：
| 業務 | 優化專項/措施 | 解決的問題描述 | 預計節省成本 | 當前狀態 | 計劃完成時間 | 負責人 | 相關文檔 |
|---|---|---|---|---|---|---|---|
| 基建 | SLB 計費方式梳理及調整 | 解決當前 SLB 計費方式不合理的問題 | 5000 | 計劃中 | 2022-11-10 | 張三 | 文檔XXX |
1.4 溝通和匯報
在我們執行成本優化過程中，需要和業務方打交道、需要和財務交互打款，核對消費金額，需要和老板們匯報項目進展，基于此，我們需要構建針對本項目的溝通和匯報渠道。
我們可以通過報告/文檔，以及月度會議的方式溝通和匯報。
文檔包括以下幾種：
- 月度分析報告，主要是在月度賬單出來后，按月分析上個月的成本花費情況，回顧上月計劃執行情況，成本優化目標達成情況，如果沒有達成，分析原因并做出對應的解釋和應對計劃，同時對比上上個月的的成本情況，按云產品比對，發現增長了的云產品，以及減少未達標的項，比如 11 月 5 號出 10 月的分析報告，對比 9 月的情況。
- 業務技術成本分析報告，與上一個報告的不同點在于增加了業務維度的，不同的業務其在云產品的消耗不同，能看出業務側云產品的漲跌，為后續精細化運營的業務分攤做準備分析；
- 財務分析報表，基于財務的角度對技術成本分析，這個報告是由財務同學輸出，以一個非技術同學的角度看技術成本事項，可能會列更關注成本花在哪里，以及各種維度的漲跌。
在準備了這些文檔后，我們按月召開技術成本優化月度會議，與會人員為上面我們所列的小組成員。會議主題主要是同步月度成本情況，以及協調資源做業務成本的優化。這里可能逐漸要形成各業務自己為自己的成本負責的邏輯和意識。
每個月所有以上的報告，會議完成后，和小組各成員確認了結果，可以整理文檔和說明，郵件或 IM 將相關結果發送給與本項目相關的老板們，如 CTO、CFO 等。
技術成本的優化基本在 3 個月到半年內完結，再接下來就是針對技術成本的精細化運營，在已優化好的成本水位的基礎上，保持水位的不增/隨業務體量正常增加，或者減少。
1.5 其它原則和注意事項
- 以不影響公司業務為前提；
- 在激進的方案中，可以少量影響一些工作的效率；
- 先止血，再優化，即把能快速節省成本的操作先做了，如空閑或負載低的服務器，用得少的云服務，不合理的折扣等，對于報表建設，需要改動線上代碼的優化往后排一些；
- 部分優化的生效具有滯后性，即某些優化當月操作后，需要下個月才能生效，因為有很多云服務的計費項是按月收取的，如 CDN 帶寬；
- 分清主次，看業務的主要成本在哪里，優先處理可節省成本高的部分，比如存儲的費用多，可能一點小優化就抵其它的全部成本；
- 掰開了，揉碎了去優化，把每項的成本都列出來，評估每項成本的合理性和必要性；
- 把業務方和財務拉到一起來搞，部分壓力傳導給業務方，一些成本項的責任人放到業務方，讓財務加入，是想通過財務的溝道，把成本優化透明化出來，讓公司更快的知道，同時從財務的角度看成本優化的問題；
- 多廠商對比，優先選擇大廠商，他們的客戶多，遇到的問題多，當下你所難解決的問題，可能他們在其他客戶那里就已經解決過了，你只需要接入使用就可以了。比如短信服務，被攻擊的情況很多，不停的對抗，在大的云廠商已經在海量客戶和用戶的基礎上形成了很強的安全策略；
- 從一個云廠商 A 遷移到另一個云廠商 B，建議找云廠商 B 分攤一些遷移成本，比如你有 5 個 PB 的數據遷移，這個過程中會產生機器成本，流量成本以及過渡階段的存儲成本等，就這體量算是一個大單了，可以要求 B 搞定遷移成本。從云廠商的角度看，這個成本算是拉新的成本，如果能在未來掙回來，大概率是會愿意掏這個錢的。但是，這個操作盡量在遷移之前搞定，否則當你遷移完后再提這茬，就會有點被動，但是也不至于完全不行，只是難度會大一些，如商務同學和他們內部的產品同學去聊的時候，邏輯是不一樣的，有點像男女朋友最開始選擇是否在一起的時候樣子，求而不得才是議價選擇權最高之時 。
2.精細化運營
精細化運營和前面講的成本優化不一樣，成本優化考慮的是短期效益，為的是解決歷史的問題，而精細化運營是一個長期的邏輯，解決的是未來的持續發展的問題。
精細化運營分為三個層面，組織分工，流程機制，系統支撐。
2.1 組織分工
2.1.1 按業務分攤成本
前面短期的成本優化大多數以運維部門為主，少部分需要修改業務方配合，為了快速見效，這里需要有一個強有力的集權性質的組織，讓整個項目快速成功。
當成本優化到一定階段，沒有那種短平快的措施后，我們需要結合業務來做深度的優化，整個分工邏輯會有所變化。
原來是運維部門為成本負責，主導成本優化，業務側以配合為主，當需要修改業務時由業務側配合修改上線，運維部門來驗收確認。
在新的邏輯里面，成本由各業務側來承接，業務側的技術負責人為自己業務的成本負責，技術成本優化小組為整個公司的技術成本負責，技術成本優化小組和各業務、財務、運維等部門對于成本分攤邏輯達成一致，認可自己的成本有多少。在此基礎上，根據業務的情況，技術成本優化小組可以提出優化建議，各業務側自行評估或者推動成本優化達成目標。
2.1.2 基于業務的成本優化策略
之所以要把成本分攤給業務側，是一個「屁股決定腦袋」的問題，是一個責權利對等的問題。
當我們的成本優化進入持續運營階段，一些優化需要深入到業務才能達成，以及在業務擴張或者有新業務時，只有業務方才能評估成本是否合理，是否是有價值的。
舉兩個例子：
一個是微信收藏功能的例子，在微信里面我們發的消息，如視頻這些是沒有永久存儲在服務器，而只是臨時存儲了三天，當你把消息收藏后，這條消息就會永久收藏。
這個功能用得人不多，但是卻耗費了很多存儲空間，并且用戶在收藏后很少去看收藏的內容。但是這塊的成本又非常高，在 2016 年那個 2TB 是主流存儲的年份里面已經有 7PB+ 的數據，相當于至少要用 1000 多臺服務器來存放這些內容。
這里有明顯的業務優化空間，于是騰訊的成本優化團隊和微信團隊一起對其產品邏輯和播放邏輯做出了優化，減少幾百臺服務器的量。
到現在，收藏功能對于每個用戶都有一個存儲上限，當到達上限后就無法收藏內容，這也是通過產品策略來減少技術成本的一個方面。
另一個是某網盤的例子，某網盤是一個臨時性網盤，用戶可以臨時傳一個文件分享給朋友，朋友拿到分享鏈接后直接下載，上傳的內容七天有效；除此之外，用戶還可以上傳文件，永久保存，隨著用戶的增多，成本急劇上升。
深入業務后發現，網盤系統做了全局唯一的存儲，以實現秒傳功能，所有上傳的文件都會存下來，不管是不是臨時的。
成本優化團隊和業務側討論后做了兩個優化，臨時文件過期刪除，永久存儲的文件一個月后從標準存儲轉為低頻存儲，六個月后轉為歸檔存儲并提供解凍功能，此舉節省了將近一半的存儲成本。
2.2 流程機制
成本要長效地得到控制，需要有對應流程的保證。在成本的流程中，核心是要控制成本的顯性增加，以及在過程中監控并檢查成本的變化趨勢，以快速應對成本的變化。
2.2.1 資源申請流程
資源申請流程主要是通過資源申請的集中管控來控制成本的無序擴張。
各公司對于流程的落地實現不同，有些的有流程系統，有些的直接在釘釘等應用中直接使用其 OA 流程，也有用類似于 Jira 等系統走任務處理流程的，所有的這些都只是咱們流程的落地實現方式。
資源申請流程的核心點有兩個：
- 資源申請模板，以模板的方式承載資源申請的考量因素。模板中至少要包含資源申請原因、使用業務方、規格、容量估算、成本估算等；
- 流程中必須包含技術成本小組的審批，以評估成本是否超出預算，以及評估成本的合理性，如果成本的業務方過多，考慮多級架構。
對于緊急情況或者沒有人能及時審批的場景，可以走緊急流程，先處理，后續再走確認成本變化。
2.2.2 成本預核算機制
在一年結束的時候，我們會對來年的成本做預算。在成本預算的時候我們需要先進行預測，即通過歷史數據、業務目標預測來年的成本，從而做成預算。
無論是從成本控制的角度，還是從技術運營的角度，我們所使用的設備、帶寬、流量、存儲，必須要預核算管控。
如果公司已經有現成的預核算系統或流程，直接走現成的即可，如果沒有系統化的做預核的邏輯，可以以相對「土」的方式實現預核算管控。這里所說的「土」的方式，可以是一個EXCEL 或一個文檔，說明指標體系和預測模型。
預測的技術成本等于預測的固定成本和變動成本。
固定成本是指不會隨著業務的增長，用戶的增長而有一定趨勢增長的成本，如一些管理系統、安全基礎設施等。
變動成本是指會隨著業務增長而增長的成本，如機器、帶寬、流量，存儲等等。我們這里要做的預測工作主要是圍繞變動成本來做。
變動成本的預測需要先有預測指標。預測指標是指在技術成本中和在我們做預測的時候，需要先有預測指標，即技術成本是如何隨著業務的變化而變化的，如 CDN 帶寬可能和日活強相關，存儲和存量用戶數相關等等。常見的指標如下：
- 每用戶存儲成本 = 存儲成本 / 總用戶數
- 每活躍用戶 CDN 帶寬成本 = CDN 月成本 / DAU(如果有明顯活躍周期，可以用活躍周期的 DAU，如活躍日 DAU，因為 CDN 一般是按 95 峰值計費)
- 每活躍用戶接入帶寬成本 = 接入帶寬月成本 / DAU(如果有明顯活躍周期，可以用活躍周期的 DAU，如活躍日 DAU)
- 每活躍用戶機器成本 = 當月機器成本 / DAU ，機器成本包括ECS、K8S、各種數據存儲、數據傳輸、消息隊列等等，DAU 邏輯同上，月使用的上限決定機器的成本
- 每活躍用戶流量成本 = （月 CDN 流量成本 + 回源成本 + 負載均衡流量成本 + 網絡流量成本）/ MAU（流量成本一般是按流量計費，用多少算多少，所以用 MAU 來算更準確一些）
除此之外，還可以有數據存儲，日志存儲，網絡帶寬、媒體計算、大數據成本等等，根據實際的業務情況拆分。不過也不用太細，按大的分類就行。
在確定了預測指標后，根據業務目標估算指標中的 DAU、MAU、用戶數等等分母的值，求和或加權求和得出預測值。
得出預測值后，根據公司流程走完預算邏輯。
在持續運營的過程中，每個月持續地迭代預算，當遇到不可抗力時，可以考慮申請預算滾動，即重新調整預算。
比如公司戰略在年中有調整，需要新增業務線，又或者業務調整，某塊業務不做了等等。
在每個月初，通過系統的方式，復盤核算上個月的總成本情況，各云產品的成本情況，各業務的成本成本情況，得出下個月的重點關注點和行動事項，持續迭代，保證年度成本預算不超。
2.3 系統支撐
在項目早期，不用著急著上系統，一些事情可以手動先搞，如一些報表，數據統計，信息同步等。
在持續運營的時候，系統就成了一個必選項，通過系統支撐前段時間我們的手動邏輯，可能包括如下一些內容：
- 各云，各產品，各業務的成本日報，月報，周報；
- 月度小結報表，增加了多少，減少了多少，每個產品的變化趨勢，各業務的變化趨勢，總成本；
- 自動形成報表，郵件或 IM 消息發送；
- 定時報表，產品報表，部門報表。
基于業務情況，成本情況，對當月，當年的成本預測等等
除了成本以外，我們在系統中還需要包含資源利用率，純粹從技術出發，查看資源的使用情況，如機器的使用率，內存/CPU 的使用率，將資源利用率和成本關聯上，以更好地控制成本。
我們通過系統，提供成本的透明度以支持成本優化。
提高透明度的目的是想知道發生了什么，將要發生什么。
系統支撐除了報表等透明化邏輯，還有監控提醒邏輯，通過對業務的監控和成本的監控，快速知道成本的變化和過程中的問題，以快速解決這些問題。
3 寫在最后
技術成本優化是一個持續的工作，以精細化運營的方式，責任到人，把成本管控起來。
技術成本運營沒有終點，成本優化和精細化運營只是其中的一個環節，需要持續迭代和優化，不斷地升級。
從現在的階段來看，我們還可以朝統一可視化，自動化，智能化等方向再迭代迭代。
你好，我是潘錦，超過 10 年的研發管理和技術架構經歷，出過書，創過業，帶過百人團隊，也在騰訊，A 股上市公司呆過一些年頭，現在在一家 C 輪的公司負責一些技術方面的管理工作。早年做過 NOI 和 ACM，對前端架構、跨端、后端架構、云原生、DevOps 等技術始終保持著濃厚的興趣，平時喜歡讀書、思考，終身學習實踐者，歡迎一起交流學習。微信公眾號：架構和遠方，博客： www.phppan.com
本文由mdnice多平臺發布
