架構師，怎樣才能搞定上下游客戶？

架構師，在開展工作的過程中需要對接老闆、產品、項目、開發、測試、安全和運營等各種崗位角色，他們都是架構需要關註和服務的內部客戶，他們的痛點就是架構工作的驅動因素。架構師就是要用專業技能“搞定”這些角色的需求，輸出大家都能接受的解決方案，大家好才是真正的好。為了達成此目的，我們必須知道不同崗位的關註點... ...

本系列前序文章索引：

架構師，在開展工作的過程中需要對接老闆、產品、項目、開發、測試、安全和運營等各種崗位角色，他們都是架構需要關註和服務的內部客戶，他們的痛點就是架構工作的驅動因素。架構師就是要用專業技能“搞定”這些角色的需求，輸出大家都能接受的解決方案，大家好才是真正的好。為了達成此目的，我們必須知道不同崗位的關註點。

老闆產品

老闆的主要職責就是定方向、找人、找錢，他對架構設計的要求就是在給定的預算、時間範圍內研發出軟體系統，推動公司的戰略或戰術得以實現，也就是說架構方案不能過於理想，不能超出預算和截止時間。自從蘋果公司的喬布斯封神之後，現在的互聯網公司都崇尚老闆擔當首席產品官，例如騰訊馬化騰、微信張小龍、百度李彥巨集等等。產品經理需要思考打造什麼樣的產品才能達成公司的戰略或戰術目的，他要綜合考慮產品是否滿足功能、質量和商業等需求，滿足功能需求只能達到及格線，易用性、交互體驗、性能、可靠性等質量需求能否滿足才是產品達到優秀的關鍵，以及從商業角度考慮選擇什麼時機將產品推向市場，有節奏地推動用戶和業務的不斷增長等。

任何技術都是服務於業務的，架構主要是承上啟下的作用，架構設計需要將老闆和產品的戰略戰術規劃跟開發實現銜接起來，例如：公司準備進入某個新領域，但在沒有足夠把握的情況下先推出一款產品試試水，這個階段的架構設計就不能太超前，而是要儘量簡單輕量，以便開發團隊能夠快速將原型產品開發出來，推向市場並收集真實用戶的反饋，驗證想法。如果發現原先的想法過於紙上談兵，那麼接下來就要儘快調整方向了，這時候架構過於複雜反而不利於調整。如果經過試水驗證發現產品找準了市場切入口，用戶和業務都開始快速增長，那這時候就需要考慮做架構升級了，必須預見到後續業務發展趨勢，預留一些提前量，確保技術不會托業務發展的後腿。

2. 項目管理

我們都知道，不管是傳統瀑布式，還是敏捷迭代式，項目管理主要關註範圍、進度和成本鐵三角，以及滿足上述三個維度約束下確保質量。那麼從服務好項目管理這個內部客戶看，架構設計必須要遵從範圍、進度、成本和質量等約束，否則項目組都解散了，再好的架構也無用武之地。

範圍，指需求的範圍。傳統瀑布式項目的周期較長，通常在立項之初就明確全量需求範圍了；敏捷迭代式項目是小步快跑，需求不是一次性確定的，而是增量添加的。針對不同類型的項目，架構設計就需要給出相應的方案，瀑布式項目可以搭配完整超前些的架構，而迭代式項目的架構必須是易於升級演的。
進度，指研發的進度。時間是項目成功的關鍵因素，時也勢也，再好再完美的產品錯過了上市的最佳時機，最終也將被丟棄到垃圾桶當中。架構設計必須考慮採用哪種技術棧才能保障項目進度，最新的技術成熟度和社區支持不夠，或者開發團隊成員還沒有足夠的知識儲備，很容易將項目拖入到無止境的延期當中。
成本，指研發的成本。任何項目都是考慮投入產出比的，架構方案中有沒有引入商業化的中間件產品，如果有就需要預算採購，如果採用開源產品替代，那就需要投入額外人力研究掌握。另外，技術棧難度高低也會影響人力成本，架構方案將決定團隊是否可以並行開發等，架構設計必須在保守和激進間做好權衡。
質量，指產品的質量。假如現在我們在滿足進度、成本等要求的前提下交付了一款功能齊全的產品，但產品存在明顯的質量缺陷，就像銷售到用戶手上的汽車存在安全隱患，那這樣的產品不僅不掙錢，還要賠錢。從架構維度看，我們也可以圍繞質量這個要求調整設計，讓系統變得易於測試、容災容錯性更強、彈性更好等。

3. 開發測試

開發測試要基於架構設計做子系統的概要設計、詳細設計、測試方案設計和測試用例編製等，從這項下游工作來看，開發測試就需要關註系統的邏輯劃分，即系統被分解成幾個子系統，每個子系統分別承擔什麼職責，關鍵業務場景的交互流程是怎樣的，子系統之間採用哪種交互機制和通訊協議等。如果缺失這些信息的輸入，我們開發測試的工作就會受到影響，嚴重會導致無法交付合格的產品。

除了承擔部分設計工作之外，開發測試主要職責就是將文檔圖紙上的設計真正落地實現，這就涉及到具體技術棧的選型，也就是我們程式員構建虛擬世界的工具。若以 Web 應用程式開發為例，技術棧的選型主要包含以下幾個方面：

操作系統 OS：主要包括 Linux \ Windows \ Android \ macOS \ iOS \ watchOS \ tvOS 等，不管是伺服器還是客戶端都有多種選擇，我們必須對它們要有概略的瞭解，然後根據需求和自身情況選擇合適的。
運行時 Runtime：主要包括 Java \ C++ \ Python \ Ruby \ PHP \ C# \ JS \ C \ Perl \ Shell \ VB \ AS \ Scala \ R \ Go 等，每種編程語言都各具優勢，例如：Java 生態圈非常強大，Python 特別適合人工智慧領域，Go 常用於構建雲計算基礎設施等。
容器 Web Container：主要包括 Apache \ Tomcat \ Jetty \ GlassFish \ Weblogic \ WebSphere \ JBOSS \ Nginx \ IIS 等，前後端分離、靜動態資源等場景需要不同的容器。

如果項目壓力很大，那麼選擇熟悉的技術棧是合適的，這樣我們就可以聚焦在業務實現上，不用操心技術維度導致的問題。如果項目壓力適中，團隊也希望掌握一些新技術棧，以便後續可以使用新技術開發新系統，那麼選擇次新的、主流的技術棧是最好的，在項目中實踐熟悉新技術，完成團隊研發能力的升級更新。

4. 運維運營

系統在發佈上線之後將會被移交給運營團隊，但運營團隊的關註點跟開發測試不同，他們關註系統能否穩定運行，在處理業務請求時的耗時長短、吞吐量等性能表現，當業務量爆髮式增長時系統是否具備彈性伸縮能力，系統在長時間運行過程中的穩定性、可靠性和魯棒性等。另外，任何對用戶有價值的系統上線之後都要面臨黑客、羊毛黨的攻擊，系統必須要有安全性保障，確保用戶個人信息和業務交易過程的安全。俗話說：百密必有一疏。考慮得再周全，線上仍然會發生出乎你意料的事情，系統必須要有實時檢測、提前預警和事後恢復等機制，運營的職責就是系統能夠提供 7*24 不間斷的服務，不讓系統拖業務發展的後腿。

在傳統業務模式下，我們企業的大部分軟體系統都是用於辦公自動化的，這些系統的用戶數量是相對穩定的，運營團隊只要保障這些系統穩定運行就可以了。但是到了互聯網+時代，企業的核心系統都是面向線上全網客戶的，併發訪問量的波峰波谷是不斷交替出現的，最大峰值流量也很難預測，這時候系統的彈性伸縮能力就顯得特別重要了，運營團隊比較關註系統是否方便擴容或縮容，是否支持跨數據中心部署，是否支持集群的克隆部署等。這些訴求都要納入到架構設計的驅動因素當中，確保最終輸出的架構設計方案能夠滿足上述要求。

收集瞭解上下游客戶的需求是第一步，後續我們還需要做好平衡協調，最終輸出符合各方訴求的方案。今天先分享到這裡，接下來老兵哥還會分享如何評價架構方案。如果你對這個主題感興趣，千萬要記得先關註哦！堅持原創不易，如果你覺得有價值，麻煩動動手指點下文「推薦」按鈕，讓更多小伙伴可以看到，老兵哥會更有動力堅持分享的。另外，我後續還會分享職業規劃、應聘面試、技能提升、影響力打造等經驗，歡迎關註本專欄或微信公眾號「 IT老兵哥」！