文章來自微信公眾號：高效運維

作者簡介：

樑定安
騰訊織雲負責人，目前就職於騰訊社交網路運營部，開放運維聯盟委員，騰訊雲佈道師，騰訊學院講師，EXIN DevOps Master講師，鳳凰專案沙盤教練，復旦大學客座講師。

前言

運維自動化是我們所渴望獲得的，但是我們在一味強調自動化能力時，卻忽略了影響自動化落地的一個關鍵因素。那便是跟運維朝夕相處，讓人又愛又恨的業務架構。

因為業務架構是決定運維效率和質量的關鍵因素之一，所以我想跟大家一起聊一下怎麼樣的架構設計是對運維友好的。結合這些年在騰訊遇到的業務架構和做運維規劃時對業務非功能規範的思考，我們可以把面向運維的架構設計分成六大設計要點。

要點一：架構獨立

任何架構的產生都是為了滿足特定的業務訴求，如果我們在滿足業務要求的同時，能夠兼顧運維對架構管理的非功能性要求。那麼我們有理由認為這樣的架構是對運維友好的。

站在運維的角度，所訴求的架構獨立包含四個方面：獨立部署，獨立測試，元件化和技術解耦。

① 獨立部署

指的是一份原始碼，可以按照便於運維的管理要求去部署、升級、伸縮等，可通過配置來區分地域分佈。服務間相互呼叫通過介面請求實現，部署獨立性也是運維獨立性的前提。

② 獨立測試

運維能夠通過一些便捷的測試用例或者工具，驗證該業務架構或服務的可用性。具備該能力的業務架構或服務讓運維具備了獨立上線的能力，而不需要每次釋出或變更都需要開發或測試人員的參與。

③ 元件規範

指的是在同一個公司內對相關的技術能有很好的框架支援，從而避免不同的開發團隊使用不同的技術棧或者元件，造成公司內部的技術架構失控。

這種做法能夠限制運維物件的無序增加，讓運維對生產環境始終保持著掌控。同時也能夠讓運維保持更多的精力投入，來圍繞著標準組件做更多的效率與質量的建設工作。

④ 技術解耦

指的是降低服務和服務之間相互依賴的關係，也包含了降低程式碼對配置檔案的依賴。這也是實現微服務的基礎，實現獨立部署、獨立測試、元件化的基礎。

要點二：部署友好

DevOps 中有大量的篇幅講述持續交付的技術實踐，希望從端到端打通開發、測試、運維的所有技術環節，以實現快速部署和交付價值的目標。可見，部署是運維日常工作很重要的組成部分，是屬於計劃內的工作，重複度高，必須提升效率

實現高效可靠的部署能力，要做好全域性規劃，以保證部署以及運營階段的全方位運維掌控。有五個緯度的內容是與部署友好相關的：

① CMDB配置

在每次部署操作前，運維需要清晰的掌握該應用與架構、與業務的關係，為了更好的全域性理解和評估工作量和潛在風險。

在織雲自動化運維平臺中，我們習慣於將業務關係、叢集管理、運營狀態、重要級別、架構層等配置資訊作為運維的管理物件納管於CMDB配置管理資料庫中。這種管理辦法的好處很明顯，集中儲存運維物件的配置資訊，對日後涉及的運維操作、監控和告警等自動化能力建設，將提供大量的配置資料支撐和決策輔助的功效。

② 環境配置

在運維標準化程度不高的企業中，阻礙部署交付效率的原罪之一便是環境配置，這也是容器化技術主要希望解決的運維痛點之一。

騰訊的運維實踐中，對開發、測試、生產三大主要環境的標準化管理，通過列舉納管與環境相關的資源集合與運維操作，結合自動初始化工具以實現標準環境管理的落地。

③ 依賴管理

解決應用軟體對庫、運營環境等依賴關係的管理。在織雲實踐經驗中，我們利用包管理，將依賴的庫檔案或環境的配置，通過整體打包和前後置執行指令碼的方案，解決應用軟體在不同環境部署的難題。業界還有更輕量的容器化交付方法，也是不錯的選擇。

④ 部署方式

持續交付原則提到要打造可靠可重複的交付流水線，對應用軟體的部署操作，我們也強烈按此目標來規劃。業界有很多案例可以參考，如Docker的Build、Ship、Run，如織雲的通過配置描述、標準化流程的一鍵部署等等。

⑤ 釋出自測

釋出自測包含兩部分：

1. 應用的輕量級測試；
2. 釋出/變更內容的校對。

建設這兩種能力以應對不同的運維場景需求，如在增量釋出時，使用釋出內容的校對能力，運維人員可快速的獲取變更檔案md5，或對相關的程序和埠的配置資訊進行檢查比對，確保每次釋出變更的可靠。

同理，輕量級測試則是滿足釋出時對服務可用性檢測的需求，此步驟可以檢測服務的連通性，也可以跑些主幹的測試用例。

⑥ 灰度上線

在《日常運維三十六計》中有這麼一句話：對不可逆的刪除或修改操作，儘量延遲或慢速執行。這便是灰度的思想，無論是從使用者、時間、伺服器等緯度的灰度上線，都是希望儘量降低上線操作的風險，業務架構支援灰度釋出的能力，讓應用部署過程的風險降低，對運維更友好。

要點三：可運維性

運維腦海中最理想的微服務架構，首當其衝的肯定是可運維性強的那類。不具可運維性的應用或架構，對運維團隊帶來的不僅僅是黑鍋，還有對他們職業發展的深深的傷害，因為維護一個沒有可運維性的架構，簡直就是在浪費運維人員的生命。

可運維性按操作規範和管理規範可以被歸納為以下七點：

① 配置管理

在微服務架構管理中，我們提議將應用的二進位制檔案與配置分離管理，以便於實現獨立部署的目的。

被分離出來的應用配置，有三種管理辦法：

1. 檔案模式；
2. 配置項模式；
3. 分散式配置中心模式。

限於篇幅不就以上三種方式的優劣展開討論。不同的企業可選用最適用的配置管理辦法，關鍵是要求各業務使用一致的方案，運維便可以有針對性的建設工具和系統來做好配置管理。

② 版本管理

DevOps持續交付八大原則之一“把所有的東西都納入版本控制”。就運維物件而言，想要管理好它，就必須能夠清晰的描述它。

和原始碼管理的要求類似，運維也需要對日常操作的物件，如包、配置、指令碼等都進行指令碼化管理，以備在運維繫統在完成自動化操作時，能夠準確無誤的選定被操作的物件和版本。

③ 標準操作

運維日常有大量重複度高的工作需要被執行，從精益思想的視角看，這裡存在極大的浪費：學習成本、無價值操作、重複建設的指令碼/工具、人肉執行的風險等等。

倘若能在企業內形成統一的運維操作規範，如檔案傳輸、遠端執行、應用啟動停止等等操作都被規範化、集中化、一鍵化的操作，運維的效率和質量將得以極大的提升。

④ 程序管理

包括應用安裝路徑、目錄結構、規範程序名、規範埠號、啟停方式、監控方案等等，被收納在程序管理的範疇。做好程序管理的全域性規劃，能夠極大的提升自動化運維程度，減少計劃外任務的發生。

⑤ 空間管理

做好磁碟空間使用的管理，是為了保證業務資料的有序存放，也是降低計劃外任務發生的有效手段。

要求提前做好的規劃：備份策略、儲存方案、容量預警、清理策略等，輔以行之有效的工具，讓這些任務不再困擾運維。

⑥ 日誌管理

日誌規範的推行和貫徹需要研發密切配合，在實踐中得出的經驗，運維理想中的日誌規範要包含這些要求：

• 業務資料與日誌分離
• 日誌與業務邏輯解耦
• 日誌格式統一
• 返回碼及註釋清晰
• 可獲取業務指標（請求量/成功率/延時）
• 定義關鍵事件
• 輸出級別
• 管理方案（存放時長、壓縮備份等）

當具體上述條件的日誌規範得以落地，開發、運維和業務都能相應的獲得較好的監控分析能力。

⑦ 集中管控

運維的工作先天就容易被切割成不同的部分，釋出變更、監控分析、故障處理、專案支援、多雲管理等等，我們訴求一站式的運維管理平臺，使得所有的工作資訊能夠銜接起來和傳承經驗，杜絕因為資訊孤島或人工傳遞資訊而造成的運營風險，提升整體運維管控的效率和質量。

要點四：容錯容災

在騰訊技術運營（運維）的四大職責：質量、效率、成本、安全。質量是首要保障的陣地，轉換成架構的視角，運維眼中理想的高可用架構架構設計應該包含以下幾點：

① 負載均衡

無論是軟體或硬體的負責均衡的方案，從運維的角度出發，我們總希望業務架構是無狀態的，路由定址是智慧化的，叢集容錯是自動實現的。

在騰訊多年的路由軟體實踐中，軟體的負載均衡方案被廣泛應用，為業務架構實現高可用立下汗馬功勞。

② 可排程性

在移動網際網路盛行的年代，可排程性是容災容錯的一項極其重要的運維手段。在業務遭遇無法立刻解決的故障時，將使用者或服務調離異常區域，是海量運營實踐中屢試不爽的技巧，也是騰訊QQ和微信保障平臺業務質量的核心運維能力之一。

結合域名、VIP、接入閘道器等技術，讓架構支援排程的能力，豐富運維管理手段，有能力更從容的應對各種故障場景。

③ 異地多活

異地多活是資料高可用的訴求，是可排程性的前提。針對不同的業務場景，技術實現的手段不限。

騰訊社交的實踐可以參考周小軍老師的文章“2億QQ使用者大排程背後的架構設計和高效運營”。

④ 主從切換

在資料庫的高可用方案中，主從切換是最常見的容災容錯方案。通過在業務邏輯中實現讀寫分離，再結合智慧路由選擇實現無人職守的主從切換自動化，無疑是架構設計對DBA最好的饋贈。

⑤ 柔性可用

“先扛住再優化”是騰訊海量運營思想之一，也為我們在做業務架構的高可用設計點明瞭方向。

如何在業務量突增的情況下，最大程度的保障業務可用？是做架構規劃和設計時不可迴避的問題。巧妙的設定柔性開關，或者在架構中內建自動拒絕超額請求的邏輯，能夠在關鍵時刻保證後端服務不雪崩，確保業務架構的高可用。

要點五：質量監控

保障和提高業務質量是運維努力追逐的目標，而監控能力是我們實現目標的重要技術手段。運維希望架構為質量監控提供便利和資料支援，要求實現以下幾點：

① 指標度量

每個架構都必須能被指標度量，同時，我們希望的是最好只有唯一的指標度量。對於業務日趨完善的立體化監控，監控指標的數量隨之會成倍增長。因此，架構的指標度量，我們希望的是最好只有唯一的指標度量。

② 基礎監控

指的是網路、專線、主機、系統等低層次的指標能力，這類監控點大多屬於非侵入式，很容易實現資料的採集。

在自動化運維能力健全的企業，基礎監控產生的告警資料絕大部分會被收斂掉。同時，這部分監控資料將為高層次的業務監控提供資料支撐和決策依據，或者被包裝成更貼近上層應用場景的業務監控資料使用，如容量、多維指標等。

③ 元件監控

騰訊習慣把開發框架、路由服務、中介軟體等都統稱為元件，這類監控介於基礎監控和業務監控之間，運維常寄希望於在元件中內嵌監控邏輯，通過元件的推廣，讓元件監控的覆蓋度提高，獲取資料的成本屬中等。如利用路由元件的監控，運維可以獲得每個路由服務的請求量、延時等狀態和質量指標。

④ 業務監控

業務監控的實現方法分主動和被動的監控，即可侵入式實現，又能以旁路的方式達到目的。這類監控方案要求開發的配合，與編碼和架構相關。

通常業務監控的指標都能歸納為請求量、成功率、延時3種指標。實現手段很多，有日誌監控、流資料監控、波測等等，業務監控屬於高層次的監控，往往能直接反饋業務問題，但倘若要深入分析出問題的根源，就必須結合必要的運維監控管理規範，如返回碼定義、日誌協議等。需要業務架構在設計時，前置考慮運維監控管理的訴求，全域性規劃好的範疇。

⑤ 全鏈路監控

基礎、元件、業務的監控手段更多的是聚焦於點的監控，在分散式架構的業務場景中，要做好監控，我們必須要考慮到服務請求鏈路的監控。

基於唯一的交易ID或RPC的呼叫關係，通過技術手段還原呼叫關係鏈，再通過模型或事件觸發監控告警，來反饋服務鏈路的狀態和質量。該監控手段屬於監控的高階應用，同樣需要業務架構規劃時做好前置規劃和程式碼埋點。。

⑥ 質量考核

任何監控能力的推進，質量的優化，都需要有管理的閉環，考核是一個不錯的手段，從監控覆蓋率、指標全面性、事件管理機制到報表考核打分，運維和開發可以攜手打造一個持續反饋的質量管理閉環，讓業務架構能夠不斷進化提升。

要點六：效能成本

在騰訊，所有的技術運營人員都肩負著一個重要的職能，就是要確保業務運營成本的合理。為此，我們必須對應用吞吐效能、業務容量規劃和運營成本都要有相應的管理辦法。

① 吞吐效能

DevOps持續交付方法論中，在測試階段進行的非功能需求測試，其中很重要一點便是對架構吞吐效能的壓測，並以此確保應用上線後業務容量的健康。

在騰訊的實踐中，不僅限於測試階段會做效能壓測，我們會結合路由元件的功能，對業務模組、業務SET進行真實請求的壓測，以此建立業務容量模型的基準。也從側面提供資料論證該業務架構的吞吐效能是否達到成本考核的要求，利用不同業務間效能資料的對比，來推動架構效能的不斷提高。

② 容量規劃

英文capacity一詞可以翻譯成：應用效能、服務容量、業務總請求量，運維的容量規劃是指在應用效能達標的前提下，基於業務總請求量的合理的服務容量規劃。對容量規劃與優化的手段，可參考“運維如何為公司節省一個億？”。

③ 運營成本

減少運營成本，是為公司減少現金流的投入，對企業的價值絲毫不弱於質量與效率的提升。

騰訊以社交、UGC、雲端計算、遊戲、視訊等富媒體業務為主，每年消耗在頻寬、裝置等運營成本的金額十分巨大。運維想要優化運營成本，常常會涉及到產品功能和業務架構的優化。因此，運維理想的業務架構設計需要有足夠的成本意識，

騰訊的成本優化措施，可參考“榨乾運營成本：一億之後再省兩億”。

小結

本文純屬個人以運維視角整理的對微服務架構設計的一些愚見，要實現運維價值最大化，要確保業務質量、效率、成本的全面提高，業務架構這塊硬骨頭是不得不啃的。

運維人需要有架構意識，能站在不同角度對業務架構提出建議或需求，這也是DevOps 精神所提倡的，開發和運維聯手，持續優化出最好的業務架構。