技術沙龍|京東雲DevOps自動化運維技術實踐

自動化測試體系不完善、缺乏自助式的持續交付平臺、系統間耦合度高服務拆分難度大、成熟的DevOps工程師稀缺，缺乏敏捷文化……這些都是DevOps 在落地過程當中，或多或少會碰到的問題，DevOps發展任重道遠，不斷學習前人經驗完善自身是很好的選擇。

11月23日，京東雲開發者社區和英特爾聯合舉辦的「京東雲DevOps自動化運維技術實踐」沙龍在上海落地，爲開發者們分享京東雲在DevOps上的經驗。

DevOps 自動化運維技術實踐

01京東雲持續交付演化之路

京東雲工具產品研發部副總監 井亮亮

在行業內，每一年DevOps現狀調查報告裏，都會去衡量DevOps對於一個組織的生產活動的影響，定義出「高效的組織？」，會從4個方面去衡量，分別是：部署頻率、軟件交付週期、變動失敗率、平均修復時長。持續交付目標是提高交付效率和確保交付質量，但交付是線上變動，那麼有變動就意味着會有風險，那麼，如何下降軟件交付的失敗率，控制風險，就變成了企業持續交付考覈的一個重要目標。

「我統計了一下，京東雲在今年的線上軟件變動失敗率控制在在 0.46%，但，咱們仍然有4成的故障是由變動操做引發的，實施持續交付，對於確保整個軟件交付質量來講是相當重要的。」井亮亮說。

不少公司在內部實施交付都曾或多或少產生過這樣問題：開發說"我想更快的開發，但構建系統卻頻繁出問題！」，測試說「我須要更快測試，但沒有環境！」、運維說「我有太多環境須要管理！」……京東雲也不例外，那麼持續交付如何解決跨團隊合做的一些問題呢？yy京東雲持續交付之路

2013 年以前是」HumanOps「，經過腳本手工上線，沒法作到自動化；

2014 年到 2016 年是 Jone(京東持續交付平臺) 時期，在 Jone1.0 交付採用Rsysnc的方式進行，上線過程常常會線上排隊；16年啓動了2.0的迭代，Jone採用了ansible做爲發佈的工具。

2017 年京東雲推出京東雲翼，雲翼是一整套的DevOps平臺，不只包含持續交付，還包含了智能監控、智能運維、門神等能力。

如何在企業內部實施持續交付

• 統一的部署規範
• 靈活的部署流水線
• 企業文化策略協助

在部署規範上，部署規範的統一，是企業實施持續交付的基礎，在京東雲內部會要求以下：

1. 咱們有統一的控制系統去操做線上，減小操做的渠道，減小風險，由於咱們的控制系統可作到秒級回滾
2. 會提供統一的基礎鏡像，這樣不會由於操做系統不一致的問題形成的風險，服務都是用統一的帳戶去啓動
3. 會統一部署路徑和日誌路徑，利於排查問題，以及查詢日誌
4. 線上服務的啓停命令，都是咱們提供的統一的模板，防止不一樣人員本身編寫致使的健壯性不夠的故障
5. 禁止手工，全部的構建都必須走系統去把控質量
6. 系統會控制沒有上預發的app是不容許上線的
7. 另外會控制避免上線致使全流量丟失的上線操做

部署流水線能夠幫助解決如何在企業內部推進各個團隊用你的標準規範和平臺，流水線是搭臺子，各個業務能夠在上面進行唱戲。

在作好規範和部署流水線的前提下，企業內部的落地推進，須要企業文化的支撐，持續交付不只僅工具的支持，仍然須要文化的支撐。

雲翼 DevOps 平臺的設計及落地

• 首先第一步要構建了 CMDB 的建設，cmdb的建設，關鍵是cmdb模型的建設，並要確保 CMDB 數據的準確性。
• 利用容器技術提高持續交付的能力，容器要作擴縮容，可提升運維的效率，極大節約了資源的成本。
• 複雜業務場景，需支持編排部署，如一次幾十個應用的發佈，這時就須要編排能力的建設，編排主要分爲3步：模版編寫、設置策略、一健發佈。

 

02數據驅動企業級監控系統設計與落地

京東雲工具產品研發部總監 顏志傑

爲了實現縮短 MTTR 的目標，監控系統應該具備這些能力：

1. 數據採集能力，獲取可觀測的數據
2. 數據可以方便加工，好比把相關的數據匯聚起來，獲得咱們須要關注的數據
3. 對這些關注的數據，作異常檢測，及時產生告警
4. 收到告警後，經過 Dashbord 查圖定位，專家診斷推薦平臺，加速定位
5. 定位問題後，經過預案平臺進行快速止損
6. 整個監控系統須要作到高可用，監控就是爲了發現異常，若是因爲異常致使自身不可用，確定是減分的

從數據角度去理解監控系統設計

典型監控系統從功能模塊分爲採集、計算、存儲、告警、算法、業務端等。從數據視角去理解，監控系統就是一個數據處理系統，便於咱們簡化系統設計以及更好理解監控系統。那麼從數據視角分析監控系統，還須要優先考慮如下這幾個部分：

• 數據模型先行，不一樣模型表明着不一樣的數據描述及處理能力，進而會對監控產品的形態產生影響
• 監控採集就是數據標準化的過程
• 監控數據存儲具備讀寫正交、meta 的靈活查詢、最新時間熱點查詢需求，京東雲採用列式存儲 + 倒排 +Gorilla 的方案選型
• 聚合計算就是對數據進行範圍圈定，進行算子處理
• 報警通路作好「質檢員」工做，同時完成通知用戶這件事情

京東雲的監控標準設計

監控須要覆蓋基礎 - 存活 - 性能 - 業務四個層面，從而保證採集數據的全面，進而避免監控遺漏。那麼如何按照監控標準去指導監控產品的落地呢？看京東雲如何從發現問題、定位問題和解決問題三個方面來減小 MTTR：

1. 在發現問題階段，分別面向管理者和運維人員設置監控系統的打分機制及推薦系統，給予管理者一個直觀的總分和每一個維度的細分得分，使得管理人員對總體監控有個量化的指標，另外一方面，對於運維人員，則提供配置推薦、一鍵啓用，能夠快速地根據標準去完善監控，達到監控變‘全’。
2. 在定位問題階段京東雲推動了變動可視化項目，將上線、配置更改、第三方的變動事件，都接入到變動事件中，用戶能夠根據時間去查詢時間段的變動，跟報警作關聯，京東雲也會根據一些相關性的算法推薦，將變動推薦給用戶，加速問題定位過程。
3. 處理問題階段京東雲可提供預案平臺，對預案進行標準化分類，指導用戶管理預案。

京東雲落地實踐：以監控告警收斂項目爲例

在監控告警上，運維人員每每在提高告警手段上作了不少工做，好比說經過發郵件的形式到短信、電話的形式等，京東雲每個月短信發送量上百萬、電話告警每個月上千條，可是運維人員並無感覺到有這麼多問題，這就說明告警關注度是降低的，因此告警收斂勢在必行，目標就是讓告警關注度提高，那如何落地呢？

這就須要首先數據量化，先統計各個渠道的告警總數，而後分兩步走，對於產品線負責人，須要讓產品線的負責人知道本身部門的狀況，另外一路出分析數據，拆解產品線發送多的緣由，給運維同窗提供數據指導，分析各類有可能致使發送告警多的緣由，如：一條短信平均接收人、哪些告警規則發送較多等。

基於這些統計數據，監控團隊去成立告警收斂項目：在面對接收人過多的狀況（一個短信原來須要 10 幾我的接收），京東雲推出值班表計劃，在產品設計上保證告警規則設置的合理性，對於一些大規模觸發狀況，好比網絡故障，京東雲默認會按照規則、應用進行合併，同時爲了在合併以後讓用戶能看的更清楚，京東雲也推出了移動端程序。

 

03質量服務在京東雲的實踐

京東雲平臺質量部總監 丁超

「質量是一份事業，向作質量的同窗致敬」

在京東雲，質量部門關注什麼？

京東雲的形態包含公有云、專有云、混合雲、多雲形態，基於京東雲產品的特性，質量服務應關注以下 4 個維度的內容：

1. 標準化流程建設，及配套的 check 服務。
   流程覆蓋從需求、設計、編碼、測試、發佈、監控到工單。
   以解決需求不明確、設計後期頻繁變動、代碼分支混亂、測試無准入準出標準、發佈無標準、線上運行時數據無觀測等問題。
   丁超建議人工先把事情作起來，先有再深刻，再自動化。
2. 垂直方向上業務能力和場景的建設。
   質量部門更關注產品的能力驗證、能力評測。
   以解決測試目標及內容不明確、無准入標準、準出標準、業務場景的模擬(用戶是怎樣使用產品的)、產品能力及侷限性、對標評測等問題。
3. 橫向視角上的平臺能力建設。
   質量部門須要須要解決的問題是：
   持續集成、效率問題、性能及安全評測能力、資源及環境快速獲取能力。
4. 做爲雲廠，或者做爲企業，如何從雲得到專業服務的能力。

須要解決的問題包括：

• 針對客戶場景的質量解決方案；
• 讓客戶無需分神質量專業性的建設；
• 保證使用門檻低，效果好。

衡量質量的指標，一是看服務可用性 SLA，二是考覈線上的故障數，三是要給用戶交付功能清單，四是有性能測試指標 QPS，五是數據持久性，六是安全性，七是兼容性，根據以上指標，經過4個維度的質量建設，最終須要給用戶交付極致的體驗。

質量模型落地之從單點突破到持續交付

傳統企業中的 CMM 標準，其對質量控制是很是細緻的，若是既想實現互聯網快速迭代，又想要傳統企業中豐富的過程控制，該如何作呢？京東雲用了現代和傳統結合的方法，即持續交付的思想加入打點服務：1. 需求和設計上，採用「模板+人工」的方式，保證事情的發生和效果。2. 編碼環節，提供 JDCCheck 服務， 代碼倉管理、靜態代碼檢查、安全檢查、UT、代碼評審等方面。提供打點服務，該環節經過，才能夠進入測試環節。

在測試環節，京東雲提供 JDCCase 測試管理平臺，包含 Case 庫、測試計劃、測試執行、測試報告等，覆蓋了測試任務的各個方面，保證了測試的准入和準出。同時與 DevOps 團隊合做，發佈 PipeLine 服務，保證測試規範，主要保證如下效果：

• 總體流程清晰
• 子服務作成 plugin，隨需調用卡點
• 用戶使用成本低，無感知接入
• 經過數據度量作改進，關注過程數據，和線上效果

丁超提到：「研發自測不足、推 UT 難、缺少敏捷教練、流程落地難、人力不足、惟快不破（關注快，忽略質量），都使得持續交付在互聯網的落地更難。因此，很是提倡「通用打點」 的方式，求同存異，統一流程和平臺，又給團隊最大的自由。在過程和結果上進行考覈。」

京東雲混沌工程實踐

Netflix《混沌工程》書中說到：在接受「系統越複雜，越脆弱」的事實以後，讓系統在每一次失敗中獲益，而後不斷進化，這是混沌工程的核心思想。即經過模擬故障，來驗證系統的可用性。

對於京東雲來講，作混沌工程困難重重，機器規模大，地域範圍廣，涉及產品多，上下游依賴複雜，涉及人員多，並且擔憂線上出故障影響客戶。可是從平臺層面看問題，須要有人總體把控系統狀況，保證故障的及時恢復，混沌工程又是必需要作的事情。

既然不能在線演練，京東雲另闢蹊徑，最終選擇在隔離區從新搭建一套仿真環境。模擬多Region、多AZ。並在AZ1實現了與線上的 1:1 建設。同時，爲保證該環境與線上版本的一致性，把該仿真環境做爲「預發環境」使用，放在發佈流程中，做爲上線前的系統集成環境。只有經過該預發的集成，驗證變動內容對雲總體無影響，才能夠繼續後續的灰度流程。這樣，還同時解決了平常運維問題。1、混沌工程第一次演練丁超介紹道：「第一次演練大約在 1 年半前，命名爲「AZ故障」。目標是：測量 AZ1總體斷電時，雲服務所有恢復的時間（即所有遷移到 AZ2 恢復可用的耗時）。再重啓AZ1，測量AZ一、AZ2同時恢復流量負載的耗時。以後，針對AZ2 重複如上的步驟。結果光AZ1斷電的場景，就用了數個小時，這其中包括故障定位、執行預案、恢復驗證等。很是直接客觀地代表，在問題發現和定位、預案有效性、系統級驗證方面，都亟待改進。不可貴出結論：破壞性演練，是推進服務治理、架構升級的有效助力！「2、混沌工程改進及發展第一次演練以後，京東雲開始了不斷的迭代改進，包括：

• 依賴治理：服務的 RING 級別梳理。將服務按照依賴順序、部署順序進行梳理，同一 RING 上的服務，不能有相互依賴。不一樣 RING 上的服務，有明確的監控項（KEY）狀態呈現，有助於問題的逐層定位。
• 預案自動化：將全部預案收錄到監控系統，實現自動化。觸發方式定義爲：檢測到問題直接觸發，和預警後人工確認觸發。並對每一個預案的生效時間進行嚴格的耗時檢查，不斷精進。
• 數據面要求對用戶無損（即用戶無感知），控制面可適當放寬。
• 服務治理：引入微服務架構和調用鏈治理。
• 觸發及驗證自動化：將故障的觸發和雲功能的驗證，進行平臺化。現已實現無成本的觸發、秒級驗證，這使破壞性演練可平常常態觸發，沒必要大動干戈。

「時至一年半後的今天，咱們已經從單場景故障恢復時間數個小時，下降到了分鐘內，大部分故障場景用戶無感知。微服務化、3AZ 建設等雲的高可用性改造也在持續進行中。對於將來，京東雲更有信心！」丁超老師對混沌工程的迭代有更強的信心。

BoCloud博雲 售前總監 劉欣雨

多雲管理平臺的建設

開篇，劉欣雨分析了中國雲市場現狀提出：中國雲市場規模在逐年增長，增幅領跑全球，呈現特色是愈來愈多用戶願意同時採用公有云和私有云這種多雲管理模式。隨着國內更多雲服務商的參與，爲雲市場提供更好、更完善服務，咱們相信中國的雲市場規模將會更加龐大，那麼多雲管理的需求也將會愈來愈強烈，範圍愈來愈廣，這爲多雲管理服務商提供更大的市場機會。

博雲多雲平臺整體建設思路圍繞「七化」：管理統一化、資產精細化、業務流程化、服務自助化、運營計量化、響應自動化，管理智能化。劉欣雨主要分享了一體化運維管理方案，其中包含的多雲管理方案、自動化運維和金融行業實踐等內容。

關於其一體化運維管理方案，劉欣雨說：「一體化運維包含五個方面，統一納管，統一運維，統一運營，統一服務門戶和統一監控管理，實現異構資源集中納管，統一資源按需分配；支持自動化運維，支持經過服務編排實現不一樣運維場景的自動化服務；提供統一服務門戶，實現自助自主服務門戶，讓業務人員自助獲取本身所須要的服務，咱們的平臺能夠自動執行，爲用戶提供資源，同時提供集中監控管理，實現資源、應用和服務一站式管理」。

同時劉欣雨也提到，對自動化運維場景的支持主要體現資源自動化、應用自動化、網絡自動化和業務場景自動化。包括資源交付、系統安裝，應用上下線、應用變動、補丁管理、網絡配置管理和業務場景管理（如災備切換和跑批業務自動化處理）。劉欣雨提到雲管平臺還須要開放的集成模式，要匹配多服務管理方式，提供開放接口，方便對接客戶現有系統（如多廠商雲平臺、ITSM、CMDB、監控等），這個也是對雲管平臺的要求。

最後劉欣雨分享了博雲在某大型股份制銀行多雲管理平臺項目建設內容，多雲管理平臺幫助該股份制銀行實現了資源統一化、服務標準化、運維自動化和服務智能化的IT管理目標，提升了資源利用率，減輕了運維人員工做量，提高了運維工做效率，保障了運維工做質量，加強了IT服務體驗，節約了IT建設和運營成本。

關注【京東雲開發者社區】，後臺回覆【PPT1123】查看活動PPT

點擊「閱讀」，進入京東雲開發者中心查看沙龍視頻

歡迎點擊「京東雲」瞭解更多精彩