團隊的技術方案設計模板

不管我們是做業務開發，還是做基礎建設，雖然產品訴求千差萬別，但是我們必然需要做好方案設計，然後還需要進行方案設計評審。

之前我們團隊的一些成員，甚至有些 T9 級別的同學，竟然都寫不好一個技術方案設計文件。究其根本，主要還是沒有形成自己的方法論，從我個人工作這麼多年的經驗來看，技術方案設計是可以總結出一套方法論或者說框架套路來的。為此，我總結出了一套通用的技術方案設計模板（提綱），然後在我們團隊內部進行了統一，後面還推廣到了整個中心，大家按照這個模板來寫方案設計，絕對讓你的領導滿意。

大家參考我這個方案設計模板(提綱)和相關介紹來做自己的方案設計的時候，可以根據自己的實際業務情況和背景做相關目錄的刪減，最後得出自己最終的方案設計，然後再去進行方案評審。

精簡版-技術方案設計模板（提綱）

精簡版的模板如下，一般的方案設計，大家都可以參考這個提綱來寫：

詳細版-技術方案設計模板（提綱）

相對詳細和複雜的版本如下：

下面是技術方案設計模板在每一章節的簡單說明，用來幫助你理清每個章節大概要寫什麼內容

一，現狀

現狀，主要是用來描述當前這個業務(專案)的一些基本情況介紹和相關的背景。你的方案設計出來之後，是需要給你的 leader 或者團隊其他成員進行評審或者檢視，甚至是要給更高階別的人來評審。但是別人不可能都和你一樣清楚你的專案，因此首先，你要把你專案的基本情況和背景都說清楚，讓大家達成一個共識，站在同一個起點上，才能進行後面的方案評審和討論。

業務背景

業務背景就是你這個業務（專案）的基本介紹，包括但不限於：

• • 專案名稱

• • 業務描述

技術背景

技術背景就是你這個業務是基於什麼樣的技術背景下來構建的，我們的技術方案可能是從 0 到 1 來構建，也能是基於現有的方案來最佳化，但是不管是什麼場景，一定都會存在相關的技術背景，因此包括但不限於：

• • 現有技術積澱

• • 現有架構描述

• • 現有系統的整體容量

二，需求

需求，很重要！技術人員千萬不要忽略需求，因為不管你的技術有多牛逼，都一定為需求服務的，不管這個需求是技術需求，還是業務需求，一定都是要為需求服務。而需求，就是你這個技術方案的起點，技術方案一切都是圍繞需求來設計，當然，這個需求可以是當下的需求，也可以包含未來潛在的需求。

只有把需求介紹清楚之後，大家才能知道你方案設計裡面的所有設計和對應的折中點是否可行，也才能比較好的去評審你的方案。

業務需求

業務需求就是你這個業務具體要做的事情，包括但不限於：

• • 要改造的內容

• • 要實現的新需求

業務痛點

• • 涉及到的業務痛點有哪些

效能需求

我們做需求的時候，對於技術人員，不能只看業務需求，業務需求可能是專案管理人員，也可能是產品人員提出來的，他們只會重點關注業務的可行性，只會關注業務的邏輯。但是技術人員，要從這個業務需求裡面考慮清楚我們滿足這個業務之下的效能需求點，比如我做一個秒殺活動，如果你不考慮效能，可能活動一上來，服務就掛掉了。效能需求包括但不限於：

• • 預估系統平均容量

• • 預估系統峰值容量

• • 可伸縮性

• • 其他的一些效能要求點，比如安全性等

三，方案描述

前面把現狀和需求說清楚後，終於到了我們的重頭戲，方案描述這裡了。一般我們做方案，可能會有幾個可選的方案，但是你不清楚哪個方案最合適，因此你需要把相關可能的方案都描述清楚，然後給出你認為的最合適的方案，然後讓大家來評審和決策，看是否同意你的意見或者有其他更好的意見。

如果沒有方案對比，那麼可以省略掉這一章節

方案1

概述

一句話概括方案的亮點，比如說：高效能、可擴充套件、雙寫、主從分離、分庫分表、擴容等。

詳細說明

詳細說明這裡需要圖文結合，包括但不限於架構圖、流程圖 等。把你整個方案的架構和模組、細節流程都描述清楚

效能目標

效能一般來說可能包含以下部分：

• • 日平均請求：一般來自產品人員的評估；

• • 平均QPS：日平均請求 除以 4w秒得出，為什麼是4w秒呢，24小時化為86400秒，取使用者活躍時間為白天算，除2得4w秒；

• • 峰值QPS：一般可以以QPS的2~4倍計算；

效能評估

給出方案的基準資料，並按效能需求評估需要使用的資源數量。

• • 單機併發量

• • 單機容量

• • 按照預估效能需求，預估資源數量(應用伺服器、快取、儲存、佇列等)

• • 伸縮方式

方案優缺點

列出方案的優缺點，優缺點要具有確定性，最好是透過量化的指標來說明

方案2

可選的另外一種方案，模板和上面一樣。

方案對比

前面給出了多種可選的方案，那麼這裡就是進行一個簡單的對比，然後給出你覺得最優的方案和原因，這就是你的決策。

有了你自己的決策（傾向）的方案後，接下來的設計就應該更多的偏向你傾向的方案去做設計和描述

四，線上方案

線上方案是對上面你更傾向的方案的更為細緻的描述。

架構圖

整體架構是如何，把架構圖畫上

關鍵設計點 和 設計折衷

把幾個關鍵、重點的點的設計思想表述出來，用來確保你的方案的大體方向是 OK 的。

因為沒有一個方案設計是最完美，方案設計都是逐步演進和最佳化的，方案設計是要最符合當前的背景的。因此，一定會有你設計的關鍵點和折衷點，這也就是前面為何要把專案的各種業務背景和技術背景都說清楚的原因。

業務流程

整體流程是如何，弄一個整體流程圖、核心流程圖出來，然後分業務場景把各個業務場景的流程圖也畫出來，並且做好相關介紹

模組劃分

有了業務流程，那麼必然要針對這個業務流程的各個環節來劃分模組，模組的劃分需要考慮我們架構設計的一些原則，比如：架構分層、業務分模組、微服務化、高內聚低耦合 等。然後把每個模組的功能點都說清楚

異常邊界【重要】

異常邊界是比較重要的，一般情況下，大部分人都能考慮到正常的處理流程，對於異常的邊界考慮的比較少，但是線上出問題，大部分都是異常情況導致，因此這裡非常重要！！！

我們可以透過一個 xmind 格式去整理相關的異常邊界，這樣有助於自己在實現的時候有足夠的把控度，也便於別人去 review 你的方案和具體實現（如 coding）

異常邊界需要考慮:

• • 涉及到了哪些模組

• • 涉及到了哪些流程

• • 每個模組、流程出現了各種可能情況的處理是？

• • 系統底層原因導致的異常的處理是 ？

統計、監控

線上執行的專案，一定需要有各種監控，除了公司內部的基建的監控外，我們可能還需要從業務內部實現自定義的一些業務監控和相關技術統計

灰度、回滾策略

• • 如何灰度？

• • 如何回滾？

容災方案

容災就是當出現 IDC 異常的情況下，怎麼容災，這個可以根據實際情況去考慮。

五，部署拓撲

線上部署拓撲如何，上下游是如何

六，風險評估

標識所選方案的風險，提出解決此風險發生時候的應對策略，比如：上線失敗時的回滾策略。

潛在風險

• • 相關的改動有哪些風險點

• • 不相容點？

• • 當前設計方案目前存在哪些問題？

• • 潛在有哪些問題

七，階段規劃【架構演進規劃】

架構怎麼演進

階段如何規劃

每個階段該達成什麼目標

第一階段

第二階段

第三階段

八，工作量評估

工作量評估也是一個重要的環節，這裡需要細化到每個模組、每個介面的設計分別需要多長時間，一定要同時包括開發時間、聯調時間、測試時間。