梁定安
騰訊織云負責(zé)人，目前就職于騰訊社交網(wǎng)絡(luò)運營部，開放運維聯(lián)盟委員，騰訊云布道師，騰訊學(xué)院講師，EXIN DevOps Master講師，鳳凰項目沙盤教練，復(fù)旦大學(xué)客座講師。
運維自動化是我們所渴望獲得的，但是我們在一味強調(diào)自動化能力時，卻忽略了影響自動化落地的一個關(guān)鍵因素。那便是跟運維朝夕相處，讓人又愛又恨的業(yè)務(wù)架構(gòu)。
因為業(yè)務(wù)架構(gòu)是決定運維效率和質(zhì)量的關(guān)鍵因素之一，所以我想跟大家一起聊一下怎么樣的架構(gòu)設(shè)計是對運維友好的。結(jié)合這些年在騰訊遇到的業(yè)務(wù)架構(gòu)和做運維規(guī)劃時對業(yè)務(wù)非功能規(guī)范的思考，我們可以把面向運維的架構(gòu)設(shè)計分成六大設(shè)計要點。
任何架構(gòu)的產(chǎn)生都是為了滿足特定的業(yè)務(wù)訴求，如果我們在滿足業(yè)務(wù)要求的同時，能夠兼顧運維對架構(gòu)管理的非功能性要求。那么我們有理由認為這樣的架構(gòu)是對運維友好的。
站在運維的角度，所訴求的架構(gòu)獨立包含四個方面：獨立部署，獨立測試，組件化和技術(shù)解耦。
① 獨立部署
指的是一份源代碼，可以按照便于運維的管理要求去部署、升級、伸縮等，可通過配置來區(qū)分地域分布。服務(wù)間相互調(diào)用通過接口請求實現(xiàn)，部署獨立性也是運維獨立性的前提。
② 獨立測試
運維能夠通過一些便捷的測試用例或者工具，驗證該業(yè)務(wù)架構(gòu)或服務(wù)的可用性。具備該能力的業(yè)務(wù)架構(gòu)或服務(wù)讓運維具備了獨立上線的能力，而不需要每次發(fā)布或變更都需要開發(fā)或測試人員的參與。
③ 組件規(guī)范
指的是在同一個公司內(nèi)對相關(guān)的技術(shù)能有很好的框架支持，從而避免不同的開發(fā)團隊使用不同的技術(shù)?；蛘呓M件，造成公司內(nèi)部的技術(shù)架構(gòu)失控。
這種做法能夠限制運維對象的無序增加，讓運維對生產(chǎn)環(huán)境始終保持著掌控。同時也能夠讓運維保持更多的精力投入，來圍繞著標準組件做更多的效率與質(zhì)量的建設(shè)工作。
④ 技術(shù)解耦
指的是降低服務(wù)和服務(wù)之間相互依賴的關(guān)系，也包含了降低代碼對配置文件的依賴。這也是實現(xiàn)微服務(wù)的基礎(chǔ)，實現(xiàn)獨立部署、獨立測試、組件化的基礎(chǔ)。
DevOps 中有大量的篇幅講述持續(xù)交付的技術(shù)實踐，希望從端到端打通開發(fā)、測試、運維的所有技術(shù)環(huán)節(jié)，以實現(xiàn)快速部署和交付價值的目標?？梢?，部署是運維日常工作很重要的組成部分，是屬于計劃內(nèi)的工作，重復(fù)度高，必須提升效率。
實現(xiàn)高效可靠的部署能力，要做好全局規(guī)劃，以保證部署以及運營階段的全方位運維掌控。有五個緯度的內(nèi)容是與部署友好相關(guān)的：
① CMDB配置
在每次部署操作前，運維需要清晰的掌握該應(yīng)用與架構(gòu)、與業(yè)務(wù)的關(guān)系，為了更好的全局理解和評估工作量和潛在風(fēng)險。
在織云自動化運維平臺中，我們習(xí)慣于將業(yè)務(wù)關(guān)系、集群管理、運營狀態(tài)、重要級別、架構(gòu)層等配置信息作為運維的管理對象納管于CMDB配置管理數(shù)據(jù)庫中。這種管理辦法的好處很明顯，集中存儲運維對象的配置信息，對日后涉及的運維操作、監(jiān)控和告警等自動化能力建設(shè)，將提供大量的配置數(shù)據(jù)支撐和決策輔助的功效。
② 環(huán)境配置
在運維標準化程度不高的企業(yè)中，阻礙部署交付效率的原罪之一便是環(huán)境配置，這也是容器化技術(shù)主要希望解決的運維痛點之一。
騰訊的運維實踐中，對開發(fā)、測試、生產(chǎn)三大主要環(huán)境的標準化管理，通過枚舉納管與環(huán)境相關(guān)的資源集合與運維操作，結(jié)合自動初始化工具以實現(xiàn)標準環(huán)境管理的落地。
③ 依賴管理
解決應(yīng)用軟件對庫、運營環(huán)境等依賴關(guān)系的管理。在織云實踐經(jīng)驗中，我們利用包管理，將依賴的庫文件或環(huán)境的配置，通過整體打包和前后置執(zhí)行腳本的方案，解決應(yīng)用軟件在不同環(huán)境部署的難題。業(yè)界還有更輕量的容器化交付方法，也是不錯的選擇。
④ 部署方式
持續(xù)交付原則提到要打造可靠可重復(fù)的交付流水線，對應(yīng)用軟件的部署操作，我們也強烈按此目標來規(guī)劃。業(yè)界有很多案例可以參考，如Docker的Build、Ship、Run，如織云的通過配置描述、標準化流程的一鍵部署等等。
⑤ 發(fā)布自測
發(fā)布自測包含兩部分：
- 應(yīng)用的輕量級測試；
- 發(fā)布/變更內(nèi)容的校對。
建設(shè)這兩種能力以應(yīng)對不同的運維場景需求，如在增量發(fā)布時，使用發(fā)布內(nèi)容的校對能力，運維人員可快速的獲取變更文件md5，或?qū)ο嚓P(guān)的進程和端口的配置信息進行檢查比對，確保每次發(fā)布變更的可靠。
同理，輕量級測試則是滿足發(fā)布時對服務(wù)可用性檢測的需求，此步驟可以檢測服務(wù)的連通性，也可以跑些主干的測試用例。
⑥ 灰度上線
在《日常運維三十六計》中有這么一句話：對不可逆的刪除或修改操作，盡量延遲或慢速執(zhí)行。這便是灰度的思想，無論是從用戶、時間、服務(wù)器等緯度的灰度上線，都是希望盡量降低上線操作的風(fēng)險，業(yè)務(wù)架構(gòu)支持灰度發(fā)布的能力，讓應(yīng)用部署過程的風(fēng)險降低，對運維更友好。
運維腦海中最理想的微服務(wù)架構(gòu)，首當其沖的肯定是可運維性強的那類。不具可運維性的應(yīng)用或架構(gòu)，對運維團隊帶來的不僅僅是黑鍋，還有對他們職業(yè)發(fā)展的深深的傷害，因為維護一個沒有可運維性的架構(gòu)，簡直就是在浪費運維人員的生命。
可運維性按操作規(guī)范和管理規(guī)范可以被歸納為以下七點：
① 配置管理
在微服務(wù)架構(gòu)管理中，我們提議將應(yīng)用的二進制文件與配置分離管理，以便于實現(xiàn)獨立部署的目的。
被分離出來的應(yīng)用配置，有三種管理辦法：
- 文件模式；
- 配置項模式；
- 分布式配置中心模式。
限于篇幅不就以上三種方式的優(yōu)劣展開討論。不同的企業(yè)可選用最適用的配置管理辦法，關(guān)鍵是要求各業(yè)務(wù)使用一致的方案，運維便可以有針對性的建設(shè)工具和系統(tǒng)來做好配置管理。
② 版本管理
DevOps持續(xù)交付八大原則之一“把所有的東西都納入版本控制”。就運維對象而言，想要管理好它，就必須能夠清晰的描述它。
和源代碼管理的要求類似，運維也需要對日常操作的對象，如包、配置、腳本等都進行腳本化管理，以備在運維系統(tǒng)在完成自動化操作時，能夠準確無誤的選定被操作的對象和版本。
③ 標準操作
運維日常有大量重復(fù)度高的工作需要被執(zhí)行，從精益思想的視角看，這里存在極大的浪費：學(xué)習(xí)成本、無價值操作、重復(fù)建設(shè)的腳本/工具、人肉執(zhí)行的風(fēng)險等等。
倘若能在企業(yè)內(nèi)形成統(tǒng)一的運維操作規(guī)范，如文件傳輸、遠程執(zhí)行、應(yīng)用啟動停止等等操作都被規(guī)范化、集中化、一鍵化的操作，運維的效率和質(zhì)量將得以極大的提升。
④ 進程管理
包括應(yīng)用安裝路徑、目錄結(jié)構(gòu)、規(guī)范進程名、規(guī)范端口號、啟停方式、監(jiān)控方案等等，被收納在進程管理的范疇。做好進程管理的全局規(guī)劃，能夠極大的提升自動化運維程度，減少計劃外任務(wù)的發(fā)生。
⑤ 空間管理
做好磁盤空間使用的管理，是為了保證業(yè)務(wù)數(shù)據(jù)的有序存放，也是降低計劃外任務(wù)發(fā)生的有效手段。
要求提前做好的規(guī)劃：備份策略、存儲方案、容量預(yù)警、清理策略等，輔以行之有效的工具，讓這些任務(wù)不再困擾運維。
⑥ 日志管理
日志規(guī)范的推行和貫徹需要研發(fā)密切配合，在實踐中得出的經(jīng)驗，運維理想中的日志規(guī)范要包含這些要求：
- 業(yè)務(wù)數(shù)據(jù)與日志分離
- 日志與業(yè)務(wù)邏輯解耦
- 日志格式統(tǒng)一
- 返回碼及注釋清晰
- 可獲取業(yè)務(wù)指標（請求量/成功率/延時）
- 定義關(guān)鍵事件
- 輸出級別
- 管理方案（存放時長、壓縮備份等）
當具體上述條件的日志規(guī)范得以落地，開發(fā)、運維和業(yè)務(wù)都能相應(yīng)的獲得較好的監(jiān)控分析能力。
⑦ 集中管控
運維的工作先天就容易被切割成不同的部分，發(fā)布變更、監(jiān)控分析、故障處理、項目支持、多云管理等等，我們訴求一站式的運維管理平臺，使得所有的工作信息能夠銜接起來和傳承經(jīng)驗，杜絕因為信息孤島或人工傳遞信息而造成的運營風(fēng)險，提升整體運維管控的效率和質(zhì)量。
在騰訊技術(shù)運營（運維）的四大職責(zé)：質(zhì)量、效率、成本、安全。質(zhì)量是首要保障的陣地，轉(zhuǎn)換成架構(gòu)的視角，運維眼中理想的高可用架構(gòu)架構(gòu)設(shè)計應(yīng)該包含以下幾點：
① 負載均衡
無論是軟件或硬件的負責(zé)均衡的方案，從運維的角度出發(fā)，我們總希望業(yè)務(wù)架構(gòu)是無狀態(tài)的，路由尋址是智能化的，集群容錯是自動實現(xiàn)的。
在騰訊多年的路由軟件實踐中，軟件的負載均衡方案被廣泛應(yīng)用，為業(yè)務(wù)架構(gòu)實現(xiàn)高可用立下汗馬功勞。
② 可調(diào)度性
在移動互聯(lián)網(wǎng)盛行的年代，可調(diào)度性是容災(zāi)容錯的一項極其重要的運維手段。在業(yè)務(wù)遭遇無法立刻解決的故障時，將用戶或服務(wù)調(diào)離異常區(qū)域，是海量運營實踐中屢試不爽的技巧，也是騰訊QQ和微信保障平臺業(yè)務(wù)質(zhì)量的核心運維能力之一。
結(jié)合域名、VIP、接入網(wǎng)關(guān)等技術(shù)，讓架構(gòu)支持調(diào)度的能力，豐富運維管理手段，有能力更從容的應(yīng)對各種故障場景。
③ 異地多活
異地多活是數(shù)據(jù)高可用的訴求，是可調(diào)度性的前提。針對不同的業(yè)務(wù)場景，技術(shù)實現(xiàn)的手段不限。
騰訊社交的實踐可以參考周小軍老師的文章“2億QQ用戶大調(diào)度背后的架構(gòu)設(shè)計和高效運營”。
④ 主從切換
在數(shù)據(jù)庫的高可用方案中，主從切換是最常見的容災(zāi)容錯方案。通過在業(yè)務(wù)邏輯中實現(xiàn)讀寫分離，再結(jié)合智能路由選擇實現(xiàn)無人職守的主從切換自動化，無疑是架構(gòu)設(shè)計對DBA最好的饋贈。
⑤ 柔性可用
“先扛住再優(yōu)化”是騰訊海量運營思想之一，也為我們在做業(yè)務(wù)架構(gòu)的高可用設(shè)計點明了方向。
如何在業(yè)務(wù)量突增的情況下，最大程度的保障業(yè)務(wù)可用？是做架構(gòu)規(guī)劃和設(shè)計時不可回避的問題。巧妙的設(shè)置柔性開關(guān)，或者在架構(gòu)中內(nèi)置自動拒絕超額請求的邏輯，能夠在關(guān)鍵時刻保證后端服務(wù)不雪崩，確保業(yè)務(wù)架構(gòu)的高可用。
保障和提高業(yè)務(wù)質(zhì)量是運維努力追逐的目標，而監(jiān)控能力是我們實現(xiàn)目標的重要技術(shù)手段。運維希望架構(gòu)為質(zhì)量監(jiān)控提供便利和數(shù)據(jù)支持，要求實現(xiàn)以下幾點：
① 指標度量
每個架構(gòu)都必須能被指標度量，同時，我們希望的是最好只有唯一的指標度量。對于業(yè)務(wù)日趨完善的立體化監(jiān)控，監(jiān)控指標的數(shù)量隨之會成倍增長。因此，架構(gòu)的指標度量，我們希望的是最好只有唯一的指標度量。
② 基礎(chǔ)監(jiān)控
指的是網(wǎng)絡(luò)、專線、主機、系統(tǒng)等低層次的指標能力，這類監(jiān)控點大多屬于非侵入式，很容易實現(xiàn)數(shù)據(jù)的采集。
在自動化運維能力健全的企業(yè)，基礎(chǔ)監(jiān)控產(chǎn)生的告警數(shù)據(jù)絕大部分會被收斂掉。同時，這部分監(jiān)控數(shù)據(jù)將為高層次的業(yè)務(wù)監(jiān)控提供數(shù)據(jù)支撐和決策依據(jù)，或者被包裝成更貼近上層應(yīng)用場景的業(yè)務(wù)監(jiān)控數(shù)據(jù)使用，如容量、多維指標等。
③ 組件監(jiān)控
騰訊習(xí)慣把開發(fā)框架、路由服務(wù)、中間件等都統(tǒng)稱為組件，這類監(jiān)控介于基礎(chǔ)監(jiān)控和業(yè)務(wù)監(jiān)控之間，運維常寄希望于在組件中內(nèi)嵌監(jiān)控邏輯，通過組件的推廣，讓組件監(jiān)控的覆蓋度提高，獲取數(shù)據(jù)的成本屬中等。如利用路由組件的監(jiān)控，運維可以獲得每個路由服務(wù)的請求量、延時等狀態(tài)和質(zhì)量指標。
④ 業(yè)務(wù)監(jiān)控
業(yè)務(wù)監(jiān)控的實現(xiàn)方法分主動和被動的監(jiān)控，即可侵入式實現(xiàn)，又能以旁路的方式達到目的。這類監(jiān)控方案要求開發(fā)的配合，與編碼和架構(gòu)相關(guān)。
通常業(yè)務(wù)監(jiān)控的指標都能歸納為請求量、成功率、延時3種指標。實現(xiàn)手段很多，有日志監(jiān)控、流數(shù)據(jù)監(jiān)控、波測等等，業(yè)務(wù)監(jiān)控屬于高層次的監(jiān)控，往往能直接反饋業(yè)務(wù)問題，但倘若要深入分析出問題的根源，就必須結(jié)合必要的運維監(jiān)控管理規(guī)范，如返回碼定義、日志協(xié)議等。需要業(yè)務(wù)架構(gòu)在設(shè)計時，前置考慮運維監(jiān)控管理的訴求，全局規(guī)劃好的范疇。
⑤ 全鏈路監(jiān)控
基礎(chǔ)、組件、業(yè)務(wù)的監(jiān)控手段更多的是聚焦于點的監(jiān)控，在分布式架構(gòu)的業(yè)務(wù)場景中，要做好監(jiān)控，我們必須要考慮到服務(wù)請求鏈路的監(jiān)控。
基于唯一的交易ID或RPC的調(diào)用關(guān)系，通過技術(shù)手段還原調(diào)用關(guān)系鏈，再通過模型或事件觸發(fā)監(jiān)控告警，來反饋服務(wù)鏈路的狀態(tài)和質(zhì)量。該監(jiān)控手段屬于監(jiān)控的高階應(yīng)用，同樣需要業(yè)務(wù)架構(gòu)規(guī)劃時做好前置規(guī)劃和代碼埋點。。
⑥ 質(zhì)量考核
任何監(jiān)控能力的推進，質(zhì)量的優(yōu)化，都需要有管理的閉環(huán)，考核是一個不錯的手段，從監(jiān)控覆蓋率、指標全面性、事件管理機制到報表考核打分，運維和開發(fā)可以攜手打造一個持續(xù)反饋的質(zhì)量管理閉環(huán)，讓業(yè)務(wù)架構(gòu)能夠不斷進化提升。
在騰訊，所有的技術(shù)運營人員都肩負著一個重要的職能，就是要確保業(yè)務(wù)運營成本的合理。為此，我們必須對應(yīng)用吞吐性能、業(yè)務(wù)容量規(guī)劃和運營成本都要有相應(yīng)的管理辦法。
① 吞吐性能
DevOps持續(xù)交付方法論中，在測試階段進行的非功能需求測試，其中很重要一點便是對架構(gòu)吞吐性能的壓測，并以此確保應(yīng)用上線后業(yè)務(wù)容量的健康。
在騰訊的實踐中，不僅限于測試階段會做性能壓測，我們會結(jié)合路由組件的功能，對業(yè)務(wù)模塊、業(yè)務(wù)SET進行真實請求的壓測，以此建立業(yè)務(wù)容量模型的基準。也從側(cè)面提供數(shù)據(jù)論證該業(yè)務(wù)架構(gòu)的吞吐性能是否達到成本考核的要求，利用不同業(yè)務(wù)間性能數(shù)據(jù)的對比，來推動架構(gòu)性能的不斷提高。
② 容量規(guī)劃
英文capacity一詞可以翻譯成：應(yīng)用性能、服務(wù)容量、業(yè)務(wù)總請求量，運維的容量規(guī)劃是指在應(yīng)用性能達標的前提下，基于業(yè)務(wù)總請求量的合理的服務(wù)容量規(guī)劃。對容量規(guī)劃與優(yōu)化的手段，可參考“運維如何為公司節(jié)省一個億？”。
③ 運營成本
減少運營成本，是為公司減少現(xiàn)金流的投入，對企業(yè)的價值絲毫不弱于質(zhì)量與效率的提升。
騰訊以社交、UGC、云計算、游戲、視頻等富媒體業(yè)務(wù)為主，每年消耗在帶寬、設(shè)備等運營成本的金額十分巨大。運維想要優(yōu)化運營成本，常常會涉及到產(chǎn)品功能和業(yè)務(wù)架構(gòu)的優(yōu)化。因此，運維理想的業(yè)務(wù)架構(gòu)設(shè)計需要有足夠的成本意識，
騰訊的成本優(yōu)化措施，可參考“榨干運營成本：一億之后再省兩億”。
本文純屬個人以運維視角整理的對微服務(wù)架構(gòu)設(shè)計的一些愚見，要實現(xiàn)運維價值最大化，要確保業(yè)務(wù)質(zhì)量、效率、成本的全面提高，業(yè)務(wù)架構(gòu)這塊硬骨頭是不得不啃的。
運維人需要有架構(gòu)意識，能站在不同角度對業(yè)務(wù)架構(gòu)提出建議或需求，這也是DevOps 精神所提倡的，開發(fā)和運維聯(lián)手，持續(xù)優(yōu)化出最好的業(yè)務(wù)架構(gòu)。
聯(lián)系客服
