【職場總結】由「 遊戲正式上線」產生的思考

第一段職業經歷裡，我追求「上線經驗」而不得，但是又不太在意「上線經驗」。

那時我認知簡單，ego也很大，認為自己做的東西透過了思想實驗，只是缺了一個線上大使用者量驗證邊界作為收尾。

第二段職業經歷裡，我沒有「上線經驗」，而身邊的同學幾乎個個都有。

我發現我們在認知上確實存在「gap」，在推行一些技術決策的時候也遇到了阻力。因此我在對自己工作內容的安排上希望更貼近「線上」的狀態，關注「上線驅動」會給我的做事心態帶來怎麼樣的變化。

在幾年前精品化的大背景下，不得不說 ——

• 能上線的大型專案是少數，死於一次次內部評審的專案是大多數
• 上線後吸到大使用者量的遊戲專案是少數，吸不到量的遊戲專案是大多數
• 吸到大使用者量的遊戲專案中，成功的遊戲專案更是少之又少，不那麼成功的遊戲專案是大多數
  

有幸幾乎完整參與了一款雖然不那麼成功，但是使用者量規模還不錯的專案。

去年一年，專案先後在港澳臺、日本、中國大陸上線，並穩定運維一年有餘。

中國大陸上線當天接近百萬玩家線上，也成了我個人商業遊戲開發職業生涯的高光時刻。

被業務牽引著緊趕慢趕了四年，最近終於可以稍微空下來沉澱一下幾年來的一些思考。

每每有階段性的思考成果，我還會約業內的朋友進行一些深入的交流。

每一次深入交流，也讓我對「上線經驗」的意義本身產生了更多新的認知。

借本文這個機會，我嘗試結構化地組織一下自己的思考 ——

關於如何認知「上線經驗」，以及這次上線的經歷帶給我的，分享給大家。

「上線經驗」的意義

個人層面，「上線經驗」需要能轉化為知識或技巧的一部分，夯實能力；

團隊層面，具備「上線經驗」的個人能力補齊團隊缺失的部分，進而給業務和專案帶來收益。

大型專案、大使用者量檢驗的「上線經驗」，可以或多或少在以下幾個方面給團隊帶來收益：

• 經過大型專案驗證的生產流程與技術建設能力
• 經過大規模DAU/PCU驗證過的穩定上線運維能力
• 線上問題的判斷與應急處理
• 更完整的技術視野、上線驅動的技術規劃與推進落地能力
  

具體到對技術細節的影響，我用兩個關鍵詞來展開描述：

• 「規模」
• 「穩定」
  

「規模」

大部分技術方案只有暴露在真實使用者的量級與行為下，才能驗證正確性；

在正確性的基礎之上，進而繼續基於線上表現判斷投入產出比及改進的方向。

「規模」既包括直接檢驗系統設計正確性的併發規模，還包括間接檢驗流程高效運轉的資料規模（例如各類跟使用者數量有關的離線流程與操作）。

在一定規模之上，所有的「簡單事務」都會乘以一個跟使用者規模有關的大系數，變成一個「複雜問題」。

從幾個簡單、具體的例子來看如何在前置設計中應對「規模」問題：

單點

• 例如遊戲中常見的做頂號處理的中心管理節點，驅動邏輯的中心節點等
• 提升預設分片的重視程度。設計階段就要妥善處理所有跟活躍賬號量級有關的資料規模如何做分片
• 關注長非同步鏈路中的單點卡點。系統設計之初就儘量避免或留好hook
  

動靜分離

• 靜態檔案的分發交給CDN。一個簡單的熱更下發，就可以在1w PCU線上時打爆LB流量上限
  

低階、常見的程式碼邏輯錯誤，觸發機率和後果都會被規模放大

• 在做防禦式程式設計的時候，更多留一些餘地給未來的自己遇到錯誤從容處理的空間，包括邏輯的臨時修復與線上影響資料的修復
  

配置的人肉介入程度

• 以遊戲服務端通用的supervisor程序管理為例，過於簡單的程序啟動引數設計，如果導致不同程序的啟動命令出現顯著區別，上線後會帶來無法承受的技術方案切換成本以及運維人力
• 運維編排流程的設計上，從簡單的伺服器選擇、針對各角色的複雜流程、配置檢查、更新等各方各面提前考慮各類線上規模龐大後可能會出現的意想不到的問題
  

幾乎所有技術實現上的細節決策，在上線之後，經歷過「使用者規模」的考驗，判斷合理性與不合理性，都可以沉澱為個人能力與技術判斷的一部分。

「穩定」

大部分遊戲產品的性質決定了「上線」是一個關鍵節點。

上線之後，先有「規模」的考驗，接下來是細水長流的「穩定」考驗。

產品開發階段，做技術方案的時候，就要充分考慮將來如何更好地應對「穩定」考驗。

簡單展開以下幾點：

技術驅動的程式碼質量體系保證程式碼庫及交付版本的質量

• 程式碼庫質量。各維度的編碼規範、開發框架的約束、靜態檢查、型別檢查與抽象解釋
• 保證交付版本的質量。在QA的自動化測試之外，透過各種層面上的斷言式測試機制保證正確性
  

把容災恢復機制建設放到高優先順序位置上

正確性

• 流程正確。關注遊戲內的各主流程在容災恢復後的正確性
• 資料正確。包括自動化的容災測試與資料層面的diff正確性校驗
• 邏輯正確。OBT前的生產環境小規模演練，線上環境驗證容災恢復流程等
  

自動化

• 零人工介入。不需要額外的人工發起流程、日誌確認、狀態確認等
• 高恢復效率。透過指標關注各類資料與狀態的快速恢復
  

保證線上無重大技術事故

• 重大技術事故通常有出現前兆，或者由小事故擴大影響產生
• 線上緊急問題的處理與臨時修復時，保持良好心態，避免操作變形
• 技術驅動設計各類SOP，透過預案與規範化流程把臨時問題轉化為標準化問題求解
  

一些新的思考

做了十年遊戲服務端，我關注的事情經歷了三個階段的變化：

• 初入門路。言必稱的是架構、系統設計、容災、去單點、無狀態
• 陷入技術瓶頸。開始關注並提升開發者體驗、深入靜態程式碼分析與動態程式碼生成與注入
• 站在交付的視角上，經歷了線上運維。開始關注服務端成本、穩定可控與運維友好的服務應該是怎麼樣的
  

四年前，前leader面試的時候問了我一個問題：

「你認為遊戲服務端未來應該是怎樣的？」

具體的回答我已經忘了，但是內容大致逃不脫前面兩個階段的關注點。

今天，我對這個「未來」的想象圖景可以描繪得更加清晰。

假如繼續從事遊戲服務端架構工作，我會從三個方面去描繪遊戲服務端的「未來」：

• 極致的資源利用曲線
• 「SLA」的追求
• 「低運維」
  

極致的資源利用曲線

典型的CPU資源佔用率曲線：


可以看出，在資源的利用上非常低效：

• 大部分時間，資源超配，利用率不到30%
• 小部分時間，資源的吃緊程度決定了資源的配額上限
  

服務端技術需要面向這條資源曲線做最佳化，讓它不那麼陡峭：

大時間尺度上，削峰為主

彈性資源容量

• 構建更靈活的擴縮容粒度。基於中低配置機器工作；合理的程序角色與各角色程序數量
• 低成本、分鐘級、無感知、無損的動態擴縮容能力。不滿足這四個條件，都無法稱為「生產環境」級別的擴縮容能力
  

充分利用多核CPU

• 邏輯分執行緒、計算密集操作的非同步化
• 並行化。ECS與並行化native介面，記憶體緊密排布
  

小時間尺度上，填谷為主

充分利用主執行緒閒時CPU

• 儘量基於事件，而不是基於幀去驅動邏輯
• 遊戲業務特有的自驅邏輯放在人最少的時間跑
• 閒時主動GC
  

理想的資源利用曲線不僅需要計算側的削峰填谷，還需要資源側足夠靈活的容量適配。

除此之外，還有以下注意點：

建立效能基準與全鏈路全場景壓測

基於可以量化的指標做好執行時資源管理

• 日誌管理
• 流量管理
• 業務指標
  

記憶體不便宜。不要再拿「記憶體不值錢」作為懶於最佳化的藉口了

• 作為參考，阿里雲32C128G機型比32C64G同CPU機型貴1/3
  

減少每一份額外CPU使用

• 內外網的發包量級
• 程序級的複製次數
  

必要的native層

• 易錯易阻斷易死迴圈的邏輯放在指令碼層
• native層具備可感知到指令碼層錯誤、阻斷、死迴圈的能力，具備打斷能力
• 封閉計算密集邏輯
• 關注非同步死迴圈、合批、分幀
  

警惕複用的物件

關注沒有與PCU成正比的指標

• 特別是PCU下降時，沒有隨之下降的指標。潛在問題
• 單位PCU峰值CPU核數，資源估算
  

我們經常能聽到一種錯誤的觀點 —— 伺服器的資源成本遠低於遊戲開發中的其他成本。

這背後可能透露出三層資訊：

• 對技術尤其是服務端技術沒有足夠的「敬畏」
• 對服務端技術建設各事項的優先順序評估不準確
• 對穩定運營遊戲的成本條目沒有清晰的認知
  

這個說法充滿了遊戲開發野蠻生長時代的特色，但是在降本增效、精細化運營的大環境下已經不再適用。

讓每一部分成本都有所值是每個技術團隊目標的一部分。

「SLA」的追求

SLA指應用面向使用者承諾的服務級別，同時也是服務端技術團隊面向其他職能承諾的服務級別。

在各類雲環境已經足夠成熟的當下，業務依賴雲環境服務商提供的SLA已經足夠作為面向使用者的承諾下限。但是對於技術來說，需要做的是基於雲商的SLA下限，追求更高標準的SLA。

高標準的SLA達成路徑有三個關鍵點：

• 配置化、靈活完善的服務治理
• 保證正確性、高度自動化的容災恢復機制
• 完善的應用系統可觀測度覆蓋
  

依次展開一下。

1. 服務治理是服務端應用框架的基礎

核心服務治理能力

服務發現

• 基於任意第三方元件實現服務的進入感知
  

服務探活

• 避免探活決策依賴單一的元件。網路原因容易導致預期外的大量服務失活
• 一致性儲存與探活邏輯分離。一致性儲存依賴成熟的外部元件實現；探活藉助叢集內角色實現。gossip protocol是個成熟方案備選
  

可動態調整策略的負載均衡機制

• 線上總會遇到各類異常，需要人工巡檢識別到並介入調整
  

完善的降級、限流、熔斷、自恢復機制

• 粗暴的熔斷容易引起雪崩，需要自恢復或手動恢復機制介入
  

分層服務治理

native層服務治理

• 最小化叢集角色數量。只需要保留必要的native角色，比如gate、game、訊息轉發與db代理
• 同構的應用角色，並在同構的應用角色之上構建業務層的各類異構服務
  

業務框架層服務治理

• 配置化定義服務。透過配置描述服務的能力、分級（可用性保證）、隔離性等
• 預設的分片實現。全域性服務總可以基於玩家id劃分分片例項
• 無狀態不是容災恢復和彈性擴縮容的唯一解
  

2. 容災的正確性保證與自動化恢復

部署方案的穩定性與容災容錯

• 多可用區部署策略
• 依賴的外部服務做好分割槽部署
  

提前應對所有不穩定的要素

雲環境基建的不穩定

VM故障。突然停機、計劃重啟、熱遷移

• 服務恢復機制
• 防雪崩的設計
  

網路環境/ACL的不穩定。閃斷、超時、重連

• 簡化連線拓撲管理
  

外部IO的不穩定

• 核心服務的閃斷、重連
• 突發的高延遲或網路不通
  

服務自身的不穩定

• 服務容災
• 資料容災
  

各類突發事件

• 完備的流程、演練、預案、SOP
  

保證正確性

• 流程正確
• 狀態正確
  

自動化容災恢復

• 去中心化的服務掉線感知
• 去單點的服務重新拉起與恢復
  

3. 系統觀測度覆蓋

• 飽和式的監控、統計、打點、報警、日誌、鏈路追蹤機制建設
• 基於業務側的指標而不是機器層面的指標做決策
• 監控、巡檢、報警，針對各類服務的時延、流量/擁塞、錯誤/異常、負載等關鍵訊號
• 關注執行時各層次的inspect/debug/REPL能力
• 全要素保活機制
  

「低運維」

「運維」是我經歷這次「上線」後最大的認知改變。

對於穩定、長線運營的遊戲服務端來說，「運維」是「持續交付」的基礎。

「運維」相關框架與工作流的設計，從研發早期就需要重點關注。

• 如果介入較晚，很有可能歷經多次測試後，引擎框架陷入「改不動」的窘境，只能將就著上線；
• 如果不經過良好設計，那會線上上運營階段耗費大量人力來彌補基建與流程的不足。
  

除了線上運維工作流之外，「低運維」關注如何在研發階段就從基建與框架上構建低成本運維的遊戲服服務端。

展開看下「低」如何理解：

「低」環境認知與部署成本

透過「統一」降低心智成本

• 統一的機器/VM規格
• 統一的隔離環境
• 開發、測試、預釋出、小流量、生產，部署釋出統一
  

透過「統一」減少不一致風險

• 統一的服務執行環境與依賴
• 統一的靜態配置與注入配置
  

「低」運維投入

研發設計運維流程

• 釋出、外放、更新、維護的運維流程編排
• 設計具備產品意識的流程。把其他技術當作使用者
  

減少協作成本損耗

• 複雜且不靈活的配置方案，會帶來極高的運維風險及人力成本投
• 儘早評估在龐大叢集規模下的潛在問題與風險
• VM粒度、組粒度、叢集粒度的配置項設計，動靜分離，與整體架構息息相關
• 配置的維護與協作方式，不是簡單的一句「SA來搞定就好了」，所有的配置都需要研發兜底
• 研發需要深度介入設計，關注落地
• 考慮幾百上千組伺服器，配置檔案透過自動流程渲染下發，仍然會有出錯的可能，需要比較深度的介入人肉校驗
  

「低」業務感知

維護無感知，對業務的影響降到最小

• 臨時的擴縮容維護、臨時停服維護、常規更新維護等
  

配置的重要性

• 足夠多的、覆蓋全面的應用配置
• 業務無感知的、流程化變更的動態管理。配置源變更到業務感知到的鏈路，保證足夠短且風險可控
  

「技術建設總是短期內被低估成本，長期內被低估收益」。

遊戲行業的「專案制」屬性決定了，我們經常在做重複的「專案」層面的業務實現，而少有超越「專案」的「技術建設」。

在構建想象圖景的過程中，我們看到了一些細節，比如：

• 靈活的動態擴縮容
• 完善的服務治理、容災與自動化恢復
• 低運維甚至無運維，精細釋出與持續交付
  

等等，都指向了一個關鍵詞 —— 「雲原生」。

遊戲服務端的「雲原生」適配，就是一個典型的容易被低估成本，且容易被低估收益的「技術建設」。

對於遊戲服務端來說，「雲原生」不是一個虛無縹緲的概念，確實會帶來實實在在的好處。

接下來我透過兩個方面分享一下對遊戲服務端「雲原生」的思考：

• 標準化服務單元
• DevOps
  

標準化服務單元

標準化的服務單元，對遊戲服務端的架構提出了兩點要求：

• 面向「服務單元」做抽象
• 基於「標準化執行環境」開發、構建、部署、交付
  

「服務單元」，可以簡單理解為將整體系統在不同層面上，劃分為松耦合、可獨立釋出部署、可獨立橫向擴縮容的單元為使用者提供服務。

「雲原生」解決方案中，「服務單元」通常會對映為「微服務」。但是對於遊戲服務端來說，微服務不是雲原生的唯一解。

以前，我糾結於有狀態與無狀態，糾結於遊戲的伺服器形態上的劃分。過去一段經歷中，有幸參與並實踐了遊戲的微服務化，產生了一些新的思考：

• 遊戲的後端，不適合按無狀態服務去實現，更不能粗暴地劃分為有狀態服務
• 當作一個native元件叢集，更適合遊戲服務端的屬性
• 不需要盲目追求遊戲服務端的微服務架構 —— 與通常的理解不同，其實發展到目前的遊戲伺服器，或多或少已經不再算是單體應用
  

「服務單元」更多是從交付與部署的粒度上去拆解整體服務，並不特指微服務。劃分粒度決定了開發與交付的速度，以及對線上服務的影響範圍。

• 交付粒度上，需要考慮針對單個「服務單元」如何做版本控制
• 部署粒度上，需要考慮如何漸進式釋出與部署，讓使用者及其他系統感知最小
  

基於同構的native應用角色層，構建異構的業務「服務單元」，在我看來，是比「微服務」更適用於遊戲服務端的解。

異構的業務「服務單元」，初階可以實現為共享主執行緒的邏輯實體形式，進階可以實現為更高度抽象的actor形式。

接下來看標準化的執行環境。

需要明確的是，技術團隊交付的是解決方案而不是一個個孤立的版本。

解決方案理應可以部署在任何環境，包括各類開發環境，各類私有云、公有云或混合雲環境等等。

在行業發展的當前階段，基於容器和容器編排設計應用已經成為事實上的標準化解決方案。

回顧一下容器和容器編排能帶給我們什麼：

• 資源抽象。基於OS、VM及各類雲環境做抽象，只需要關注應用交付而不用關注基建、機器環境、網路訪問規則與配置以及雲環境特定的資源等
• 叢集層面，網路拓撲，內部拓撲，外網
• 執行時隔離。提供比程序粒度更粗，比VM粒度更細的隔離抽象
• 規定交付標準。基於容器，進行整體釋出而不是隻交付一個二進位制版本包
• 跨環境的釋出與部署。架構適配各類雲環境，可部署、可執行，並不限定為某個公司內部平臺整套技術棧與基礎設施
  

為什麼需要基於容器和容器編排做構建釋出？

• 基於容器的應用釋出始終是完整的，基於VM釋出則會把整體流程拆分為機器初始化與版本釋出。基於容器構建應用版本可以進行更敏捷的釋出、部署與回退
• 構建與釋出結合在一起，全流程運維環境統一。不再需要傳統意義上的打包上傳階段，內外網環境的構建釋出可以做到真正統一
• 構建可觀測系統時，可以聚焦於應用層的指標，忽略機器層面的指標
• 實現資源的隔離與最大化利用
  

DevOps

「DevOps」的前提之一是「CI/CD」。

CI，持續整合

基於成熟的Jenkins和gitlab，大部分團隊都很容易認知，也很容易實現

CD，持續交付與持續部署

遊戲行業大部分公司和專案仍然處於「DO分離」的研發運維合作模式，難以達到「CD」的狀態


如之前所說，技術交付的不僅是一個可執行檔案包，而是一整套持續開發迭代、持續整合、持續交付的解決方案。

什麼是「持續」？一個版本從開發完畢，涉及最少的人，以最快的速度和對外部最小的影響上線到生產環境。

接下來從遊戲服務端受DevOps理念影響最大的兩個方面，來看看如何在架構設計時進行DevOps適配：

• 部署
• 更新
  

部署

常規的部署流程包括運維資源的規劃部署與籌備，具體的事務包括開服與線上擴縮容。

部署流程上，遊戲行業經歷了三個階段：

DO分離

• DevOps的反面，SA是業務研發的工具人
• 研發發起需求，SA執行需求
• 極高的溝通成本
  

DO合作

相比於DO分離，在兩個切面上有所提升：

• 研發流程編排由研發與SA協同設計流程，研發執行流程並確認流程引數
• 資源籌備與部署研發深度介入並對結果負責，而不是交付一個版本
  

研發與運維仍然有各自的職責邊界

DevOps

研發自運維

我們可以從以下方面審視自己的工作流所處的階段：

• 涉及內外網公共服的流程誰設計，誰發起，引數如何確認
• 開發環境、預釋出環境與生產環境的差異度
• 遊戲伺服器「更新」都有哪些技術職能介入
  

這三個階段的演化，是「版本交付」與「部署」的職能邊界從清晰到模糊的過程。

設計部署與擴縮容友好的應用架構需要在以下方面做好適配：

做好程序角色規劃

• 確定的native程序角色，最小角色數量，明確的角色職責
• 同角色各例項在靜態配置層面等價
  

角色適配通用的服務概念

提供服務即暴露埠

• 叢集理應暴露埠的量級需要是可控的
  

連線發起方向需要謹慎設計

• 角色互連線的連線方向考慮容災場景
• 考慮角色的相對動態性與相對靜態性，偏動態的角色總是主動感知偏靜態的角色併發起維護連線
  

部署和擴容單元最小化與標準化

• 統一部署和擴容層面的最小單元。避免出現按叢集部署，按節點擴容的設計
• 擴縮容的最小單元，不能有獨立的靜態配置。否則擴縮容時的配置變更本身會帶來極大風險
• 面相生產環境設計與驗證橫向擴縮容。開發環境的擴縮容與生產環境的擴縮容是兩個維度的問題
• 降低業務和使用者側對擴縮容的感知
  

更新

遊戲作為一種網際網路應用，「更新」的理想形態是「漸進式」的、是「持續性」的。

但是至今，仍然有大量的新專案在計劃用「stop-the-world」的機制應對每一次常規更新。技術決策的依據也令人相當哭笑不得 —— 一款幾年前上線的「頭部專案」就是這麼做的。

對遊戲服務端「更新」的思考，在我看來可以簡單分為四個階段：

1. 對「更新」的認知侷限在「stop-the-world」，並對新的更新形式產生「畏懼」。


2. 理解、認知並以實踐新技術的心態落地「不停服更新」，最簡單的形式是藍綠部署

3. 透過實際運維經驗，反思「不停服更新」的成本與業務需求的適配度

4. 從雲原生開發部署一體化的視角去重新設計並實踐「持續更新」

在網路遊戲單機化的趨勢下，之前我認為適配「持續更新」的業務需求是減少了。但是經過思考之後，我認為反而增加了。

「持續更新」帶來的基準提升是讓玩家感知不到遊戲的維護與更新。

從業務視角來說，單機化網路遊戲一個典型的更新策略是大版本更新前會招募測試玩家。並且：

• 測試服與正式服同時開放，多版本同時運營
• 測試玩家在測試服與正式服的資料互通
  

「持續更新」可以應對這兩點業務需求帶來的挑戰。

簡單聊聊落地路徑。

所有的維護與釋出策略，技術層面都可以簡化為：

• 同一服務同時部署了新舊兩個版本
• 在一段時間視窗內，新舊兩個版本的服務同時面向玩家
• 生產環境流量逐步從全量舊版本過渡到部分小流量新版本，最終過渡到全量新版本
  

要做到適配雲原生的「持續更新」，需要從架構設計之初就深度定製：

確定的、與業務無關的叢集角色劃分

前文提到的服務治理能力

各角色本身「必須」具備橫向擴容能力

同一服務新舊版本同時部署釋出的必備機制

外接與叢集內建的流量管理機制

生產環境流量在新舊服務間的切換

不同版本間實現互相相容

包括協議層面的相容與資料層面的相容

透過一定的策略標記流量只要經過了新版本就無法會退

業務框架與上層系統的適配

無法處理的系統在「持續更新」期間關閉即可

寫在最後

「上線經驗」對於個人來說，有遞進的四層意義：

• 履歷，成為簡歷中可以寫出來的一段專案經歷
• 路徑，增加了可以依賴的依據與技術儲備，在做方案的時候可以有更多的技術自信
• 思考，獲得從研發到上線到穩定運維多視角深度思考沉澱的契機
• 認知，可以梳理並完善各類上線前技術決策的預估收益與上線後實際收益的偏差模型，可以基於這個模型繼續做新的技術探索
  

沒「上線經驗」的時候，我喜歡在技術方案review的時候說，不要過於依賴上線經驗；

有「上線經驗」了之後，我發現我確實沒辦法做到預設信任沒有經過線上驗證的技術方案。

這不是屁股決定腦袋，是認知發生了變化。

不過，這也不是絕對。

技術方案的選擇具備時空屬性 —— 在特定時間特定場合下，技術方案的決策是有意義、可參考的；過了時效，不具備可參考價值。

在做全新的技術方案時，「上線經驗」不是權威，不應該成為技術判斷與決策的絆腳石，一切以事實為依據。

我們經常聽到的一個說法 ——

「某個方案上線驗證了那就一定要這麼做」

更合適的說法是：某個方案是這麼做的且上線驗證了，把其中有意義的點和沒有意義的點透過線上驗證的結果拆出來，並且提出更合理的需要改進的點，綜合起來，才是「上線經驗」的意義。

「上線經驗」對於行業來說，同樣意義重大。

對工業界來說，將「上線經驗」與背後的知識快速鋪開，是整個行業進入工業化的意義。

以好萊塢為例，早期一部大型工業級影視作品的誕生，中間各環節各流程的關鍵角色在行業內開枝散葉，快速生產出類似體量的一部又一部更優秀的影視作品，這是行業維度看工業化的意義所在。

具體到專案與業務來說，以有限、確定的成本，減少試錯，把資源投在需要試錯與探索的方向上，無疑會增加專案的成功率。

敬畏「上線經驗」。

祝大家的專案都可以順利上線。

祝大家都能從上線中收穫新的思考，提升認知。

經歷一次又一次的專案開發與「上線」歷練，不論是做業務系統，還是基建或框架，還是架構設計，都要沉澱屬於自己的「設計語言」與「技術審美」。

共勉！


來源：說給開發遊戲的你