《自動化運維之架構設計六要點》要點：
本文介紹了自動化運維之架構設計六要點，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者簡介：

梁定安
騰訊織云負責人,目前就職于騰訊社交網(wǎng)絡運營部,開放運維聯(lián)盟委員,騰訊云布道師,騰訊學院講師,EXIN DevOps Master講師,鳳凰項目沙盤教練,復旦大學客座講師.

前言

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

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

要點一：架構獨立

任何架構的產(chǎn)生都是為了滿足特定的業(yè)務訴求,如果我們在滿足業(yè)務要求的同時,能夠兼顧運維對架構管理的非功能性要求.那么我們有理由認為這樣的架構是對運維友好的.

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

① 獨立部署

指的是一份源代碼,可以按照便于運維的管理要求去部署、升級、伸縮等,可通過配置來區(qū)分地域分布.服務間相互調用通過接口請求實現(xiàn),部署獨立性也是運維獨立性的前提.

② 獨立測試

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

③ 組件規(guī)范

指的是在同一個公司內(nèi)對相關的技術能有很好的框架支持,從而避免不同的開發(fā)團隊使用不同的技術棧或者組件,造成公司內(nèi)部的技術架構失控.

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

④ 技術解耦

指的是降低服務和服務之間相互依賴的關系,也包含了降低代碼對配置文件的依賴.這也是實現(xiàn)微服務的基礎,實現(xiàn)獨立部署、獨立測試、組件化的基礎.

要點二：部署友好

DevOps 中有大量的篇幅講述持續(xù)交付的技術實踐,希望從端到端打通開發(fā)、測試、運維的所有技術環(huán)節(jié),以實現(xiàn)快速部署和交付價值的目標.可見,部署是運維日常工作很重要的組成部分,是屬于計劃內(nèi)的工作,重復度高,必須提升效率.

實現(xiàn)高效可靠的部署能力,要做好全局規(guī)劃,以保證部署以及運營階段的全方位運維掌控.有五個緯度的內(nèi)容是與部署友好相關的：

① CMDB配置

在每次部署操作前,運維需要清晰的掌握該應用與架構、與業(yè)務的關系,為了更好的全局理解和評估工作量和潛在風險.

在織云自動化運維平臺中,我們習慣于將業(yè)務關系、集群管理、運營狀態(tài)、重要級別、架構層等配置信息作為運維的管理對象納管于CMDB配置管理數(shù)據(jù)庫中.這種管理辦法的好處很明顯,集中存儲運維對象的配置信息,對日后涉及的運維操作、監(jiān)控和告警等自動化能力建設,將提供大量的配置數(shù)據(jù)支撐和決策輔助的功效.

② 環(huán)境配置

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

騰訊的運維實踐中,對開發(fā)、測試、生產(chǎn)三大主要環(huán)境的標準化管理,通過枚舉納管與環(huán)境相關的資源集合與運維操作,結合自動初始化工具以實現(xiàn)標準環(huán)境管理的落地.

③ 依賴管理

解決應用軟件對庫、運營環(huán)境等依賴關系的管理.在織云實踐經(jīng)驗中,我們利用包管理,將依賴的庫文件或環(huán)境的配置,通過整體打包和前后置執(zhí)行腳本的方案,解決應用軟件在不同環(huán)境部署的難題.業(yè)界還有更輕量的容器化交付方法,也是不錯的選擇.

④ 部署方式

持續(xù)交付原則提到要打造可靠可重復的交付流水線,對應用軟件的部署操作,我們也強烈按此目標來規(guī)劃.業(yè)界有很多案例可以參考,如Docker的Build、Ship、Run,如織云的通過配置描述、標準化流程的一鍵部署等等.

⑤ 發(fā)布自測

發(fā)布自測包含兩部分：

1. 應用的輕量級測試；
2. 發(fā)布/變更內(nèi)容的校對.

建設這兩種能力以應對不同的運維場景需求,如在增量發(fā)布時,使用發(fā)布內(nèi)容的校對能力,運維人員可快速的獲取變更文件md5,或對相關的進程和端口的配置信息進行檢查比對,確保每次發(fā)布變更的可靠.

同理,輕量級測試則是滿足發(fā)布時對服務可用性檢測的需求,此步驟可以檢測服務的連通性,也可以跑些主干的測試用例.

⑥ 灰度上線

在《日常運維三十六計》中有這么一句話：對不可逆的刪除或修改操作,盡量延遲或慢速執(zhí)行.這便是灰度的思想,無論是從用戶、時間、服務器等緯度的灰度上線,都是希望盡量降低上線操作的風險,業(yè)務架構支持灰度發(fā)布的能力,讓應用部署過程的風險降低,對運維更友好.

要點三：可運維性

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

可運維性按操作規(guī)范和管理規(guī)范可以被歸納為以下七點：

① 配置管理

在微服務架構管理中,我們提議將應用的二進制文件與配置分離管理,以便于實現(xiàn)獨立部署的目的.

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

1. 文件模式；
2. 配置項模式；
3. 分布式配置中心模式.

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

② 版本管理

DevOps持續(xù)交付八大原則之一“把所有的東西都納入版本控制”.就運維對象而言,想要管理好它,就必須能夠清晰的描述它.

和源代碼管理的要求類似,運維也需要對日常操作的對象,如包、配置、腳本等都進行腳本化管理,以備在運維系統(tǒng)在完成自動化操作時,能夠準確無誤的選定被操作的對象和版本.

③ 標準操作

運維日常有大量重復度高的工作需要被執(zhí)行,從精益思想的視角看,這里存在極大的浪費：學習成本、無價值操作、重復建設的腳本/工具、人肉執(zhí)行的風險等等.

倘若能在企業(yè)內(nèi)形成統(tǒng)一的運維操作規(guī)范,如文件傳輸、遠程執(zhí)行、應用啟動停止等等操作都被規(guī)范化、集中化、一鍵化的操作,運維的效率和質量將得以極大的提升.

④ 進程管理

包括應用安裝路徑、目錄結構、規(guī)范進程名、規(guī)范端口號、啟停方式、監(jiān)控方案等等,被收納在進程管理的范疇.做好進程管理的全局規(guī)劃,能夠極大的提升自動化運維程度,減少計劃外任務的發(fā)生.

⑤ 空間管理

做好磁盤空間使用的管理,是為了保證業(yè)務數(shù)據(jù)的有序存放,也是降低計劃外任務發(fā)生的有效手段.

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

⑥ 日志管理

日志規(guī)范的推行和貫徹需要研發(fā)密切配合,在實踐中得出的經(jīng)驗,運維理想中的日志規(guī)范要包含這些要求：

• 業(yè)務數(shù)據(jù)與日志分離
• 日志與業(yè)務邏輯解耦
• 日志格式統(tǒng)一
• 返回碼及注釋清晰
• 可獲取業(yè)務指標(請求量/成功率/延時)
• 定義關鍵事件
• 輸出級別
• 管理方案(存放時長、壓縮備份等)

當具體上述條件的日志規(guī)范得以落地,開發(fā)、運維和業(yè)務都能相應的獲得較好的監(jiān)控分析能力.

⑦ 集中管控

運維的工作先天就容易被切割成不同的部分,發(fā)布變更、監(jiān)控分析、故障處理、項目支持、多云管理等等,我們訴求一站式的運維管理平臺,使得所有的工作信息能夠銜接起來和傳承經(jīng)驗,杜絕因為信息孤島或人工傳遞信息而造成的運營風險,提升整體運維管控的效率和質量.

要點四：容錯容災

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

① 負載均衡

無論是軟件或硬件的負責均衡的方案,從運維的角度出發(fā),我們總希望業(yè)務架構是無狀態(tài)的,路由尋址是智能化的,集群容錯是自動實現(xiàn)的.

在騰訊多年的路由軟件實踐中,軟件的負載均衡方案被廣泛應用,為業(yè)務架構實現(xiàn)高可用立下汗馬功勞.

② 可調度性

在移動互聯(lián)網(wǎng)盛行的年代,可調度性是容災容錯的一項極其重要的運維手段.在業(yè)務遭遇無法立刻解決的故障時,將用戶或服務調離異常區(qū)域,是海量運營實踐中屢試不爽的技巧,也是騰訊QQ和微信保障平臺業(yè)務質量的核心運維能力之一.

結合域名、VIP、接入網(wǎng)關等技術,讓架構支持調度的能力,豐富運維管理手段,有能力更從容的應對各種故障場景.

③ 異地多活

異地多活是數(shù)據(jù)高可用的訴求,是可調度性的前提.針對不同的業(yè)務場景,技術實現(xiàn)的手段不限.

騰訊社交的實踐可以參考周小軍老師的文章“2億QQ用戶大調度背后的架構設計和高效運營”.

④ 主從切換

在數(shù)據(jù)庫的高可用方案中,主從切換是最常見的容災容錯方案.通過在業(yè)務邏輯中實現(xiàn)讀寫分離,再結合智能路由選擇實現(xiàn)無人職守的主從切換自動化,無疑是架構設計對DBA最好的饋贈.

⑤ 柔性可用

“先扛住再優(yōu)化”是騰訊海量運營思想之一,也為我們在做業(yè)務架構的高可用設計點明了方向.

如何在業(yè)務量突增的情況下,最大程度的保障業(yè)務可用?是做架構規(guī)劃和設計時不可回避的問題.巧妙的設置柔性開關,或者在架構中內(nèi)置自動拒絕超額請求的邏輯,能夠在關鍵時刻保證后端服務不雪崩,確保業(yè)務架構的高可用.

要點五：質量監(jiān)控

保障和提高業(yè)務質量是運維努力追逐的目標,而監(jiān)控能力是我們實現(xiàn)目標的重要技術手段.運維希望架構為質量監(jiān)控提供便利和數(shù)據(jù)支持,要求實現(xiàn)以下幾點：

① 指標度量

每個架構都必須能被指標度量,同時,我們希望的是最好只有唯一的指標度量.對于業(yè)務日趨完善的立體化監(jiān)控,監(jiān)控指標的數(shù)量隨之會成倍增長.因此,架構的指標度量,我們希望的是最好只有唯一的指標度量.

② 基礎監(jiān)控

指的是網(wǎng)絡、專線、主機、系統(tǒng)等低層次的指標能力,這類監(jiān)控點大多屬于非侵入式,很容易實現(xiàn)數(shù)據(jù)的采集.

在自動化運維能力健全的企業(yè),基礎監(jiān)控產(chǎn)生的告警數(shù)據(jù)絕大部分會被收斂掉.同時,這部分監(jiān)控數(shù)據(jù)將為高層次的業(yè)務監(jiān)控提供數(shù)據(jù)支撐和決策依據(jù),或者被包裝成更貼近上層應用場景的業(yè)務監(jiān)控數(shù)據(jù)使用,如容量、多維指標等.

③ 組件監(jiān)控

騰訊習慣把開發(fā)框架、路由服務、中間件等都統(tǒng)稱為組件,這類監(jiān)控介于基礎監(jiān)控和業(yè)務監(jiān)控之間,運維常寄希望于在組件中內(nèi)嵌監(jiān)控邏輯,通過組件的推廣,讓組件監(jiān)控的覆蓋度提高,獲取數(shù)據(jù)的成本屬中等.如利用路由組件的監(jiān)控,運維可以獲得每個路由服務的請求量、延時等狀態(tài)和質量指標.

④ 業(yè)務監(jiān)控

業(yè)務監(jiān)控的實現(xiàn)方法分主動和被動的監(jiān)控,即可侵入式實現(xiàn),又能以旁路的方式達到目的.這類監(jiān)控方案要求開發(fā)的配合,與編碼和架構相關.

通常業(yè)務監(jiān)控的指標都能歸納為請求量、成功率、延時3種指標.實現(xiàn)手段很多,有日志監(jiān)控、流數(shù)據(jù)監(jiān)控、波測等等,業(yè)務監(jiān)控屬于高層次的監(jiān)控,往往能直接反饋業(yè)務問題,但倘若要深入分析出問題的根源,就必須結合必要的運維監(jiān)控管理規(guī)范,如返回碼定義、日志協(xié)議等.需要業(yè)務架構在設計時,前置考慮運維監(jiān)控管理的訴求,全局規(guī)劃好的范疇.

⑤ 全鏈路監(jiān)控

基礎、組件、業(yè)務的監(jiān)控手段更多的是聚焦于點的監(jiān)控,在分布式架構的業(yè)務場景中,要做好監(jiān)控,我們必須要考慮到服務請求鏈路的監(jiān)控.

基于唯一的交易ID或RPC的調用關系,通過技術手段還原調用關系鏈,再通過模型或事件觸發(fā)監(jiān)控告警,來反饋服務鏈路的狀態(tài)和質量.該監(jiān)控手段屬于監(jiān)控的高階應用,同樣需要業(yè)務架構規(guī)劃時做好前置規(guī)劃和代碼埋點..

⑥ 質量考核

任何監(jiān)控能力的推進,質量的優(yōu)化,都需要有管理的閉環(huán),考核是一個不錯的手段,從監(jiān)控覆蓋率、指標全面性、事件管理機制到報表考核打分,運維和開發(fā)可以攜手打造一個持續(xù)反饋的質量管理閉環(huán),讓業(yè)務架構能夠不斷進化提升.

要點六：性能成本

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

① 吞吐性能

DevOps持續(xù)交付方法論中,在測試階段進行的非功能需求測試,其中很重要一點便是對架構吞吐性能的壓測,并以此確保應用上線后業(yè)務容量的健康.

在騰訊的實踐中,不僅限于測試階段會做性能壓測,我們會結合路由組件的功能,對業(yè)務模塊、業(yè)務SET進行真實請求的壓測,以此建立業(yè)務容量模型的基準.也從側面提供數(shù)據(jù)論證該業(yè)務架構的吞吐性能是否達到成本考核的要求,利用不同業(yè)務間性能數(shù)據(jù)的對比,來推動架構性能的不斷提高.

② 容量規(guī)劃

英文capacity一詞可以翻譯成：應用性能、服務容量、業(yè)務總請求量,運維的容量規(guī)劃是指在應用性能達標的前提下,基于業(yè)務總請求量的合理的服務容量規(guī)劃.對容量規(guī)劃與優(yōu)化的手段,可參考“運維如何為公司節(jié)省一個億?”.

③ 運營成本

減少運營成本,是為公司減少現(xiàn)金流的投入,對企業(yè)的價值絲毫不弱于質量與效率的提升.

騰訊以社交、UGC、云計算、游戲、視頻等富媒體業(yè)務為主,每年消耗在帶寬、設備等運營成本的金額十分巨大.運維想要優(yōu)化運營成本,常常會涉及到產(chǎn)品功能和業(yè)務架構的優(yōu)化.因此,運維理想的業(yè)務架構設計需要有足夠的成本意識,

騰訊的成本優(yōu)化措施,可參考“榨干運營成本：一億之后再省兩億”.

小結

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

運維人需要有架構意識,能站在不同角度對業(yè)務架構提出建議或需求,這也是DevOps 精神所提倡的,開發(fā)和運維聯(lián)手,持續(xù)優(yōu)化出最好的業(yè)務架構.

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

轉載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/2362.html