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

京東科技開發者發表於2019-12-04
dev運維
技術沙龍|京東雲DevOps自動化運維技術實踐
自動化測試體系不完善、缺少自助式的持續交付平臺、系統間耦合度高服務拆分難度大、成熟的DevOps工程師稀缺，缺少敏捷文化……這些都是DevOps 在落地過程中，或多或少會碰到的問題，DevOps發展任重道遠，不斷學習前人經驗完善自身是很好的選擇。
11月23日，京東雲開發者社群和英特爾聯合舉辦的「京東雲DevOps自動化運維技術實踐」沙龍在上海落地，為開發者們分享京東雲在DevOps上的經驗。
技術沙龍|京東雲DevOps自動化運維技術實踐

DevOps 自動化運維技術實踐

01京東雲持續交付演化之路
技術沙龍|京東雲DevOps自動化運維技術實踐
京東雲工具產品研發部副總監 井亮亮


在行業內，每年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資料驅動企業級監控系統設計與落地
技術沙龍|京東雲DevOps自動化運維技術實踐
京東雲工具產品研發部總監 顏志傑


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

  1. 資料採集能力，獲取可觀測的資料
  2. 資料能夠方便加工，比如把相關的資料匯聚起來，得到我們需要關注的資料
  3. 對這些關注的資料，做異常檢測，及時產生告警
  4. 收到告警後，透過 Dashbord 查圖定位，專家診斷推薦平臺，加速定位
  5. 定位問題後，透過預案平臺進行快速止損
  6. 整個監控系統需要做到高可用，監控就是為了發現異常，如果由於異常導致自身不可用，肯定是減分的
從資料角度去理解監控系統設計
典型監控系統從功能模組分為採集、計算、儲存、告警、演算法、業務端等。從資料視角去理解，監控系統就是一個資料處理系統，便於我們簡化系統設計以及更好理解監控系統。那麼從資料視角分析監控系統，還需要優先考慮以下這幾個部分：
  • 資料模型先行，不同模型代表著不同的資料描述及處理能力，進而會對監控產品的形態產生影響
  • 監控採集就是資料標準化的過程
  • 監控資料儲存具有讀寫正交、meta 的靈活查詢、最新時間熱點查詢需求，京東雲採用列式儲存 + 倒排 +Gorilla 的方案選型
  • 聚合計算就是對資料進行範圍圈定，進行運算元處理
  • 報警通路做好“質檢員”工作，同時完成通知使用者這件事情
京東雲的監控標準設計
監控需要覆蓋基礎 - 存活 - 效能 - 業務四個層面，從而保證採集資料的全面，進而避免監控遺漏。那麼如何按照監控標準去指導監控產品的落地呢？看京東雲如何從發現問題、定位問題和解決問題三個方面來減少 MTTR：
  1. 在發現問題階段，分別面向管理者和運維人員設定監控系統的打分機制及推薦系統，給予管理者一個直觀的總分和每個維度的細分得分，使得管理人員對整體監控有個量化的指標，另一方面，對於運維人員，則提供配置推薦、一鍵啟用，可以快速地根據標準去完善監控，達到監控變‘全’。
  2. 在定位問題階段京東雲推進了變更視覺化專案，將上線、配置更改、第三方的變更事件，都接入到變更事件中，使用者可以根據時間去查詢時間段的變更，跟報警做關聯，京東雲也會根據一些相關性的演算法推薦，將變更推薦給使用者，加速問題定位過程。
  3. 處理問題階段京東雲可提供預案平臺，對預案進行標準化分類，指導使用者管理預案。
京東雲落地實踐：以監控告警收斂專案為例
在監控告警上，運維人員往往在提升告警手段上做了很多工作，比如說透過發郵件的形式到簡訊、電話的形式等，京東雲每月簡訊傳送量上百萬、電話告警每月上千條，但是運維人員並沒有感受到有這麼多問題，這就說明告警關注度是下降的，所以告警收斂勢在必行，目標就是讓告警關注度提升，那如何落地呢？
這就需要首先資料量化，先統計各個渠道的告警總數，然後分兩步走，對於產品線負責人，需要讓產品線的負責人知道自己部門的情況，另一路出分析資料，拆解產品線傳送多的原因，給運維同學提供資料指導，分析各種有可能導致傳送告警多的原因，如：一條簡訊平均接收人、哪些告警規則傳送較多等。
基於這些統計資料，監控團隊去成立告警收斂專案：在面對接收人過多的情況（一個簡訊原來需要 10 幾個人接收），京東雲推出值班表計劃，在產品設計上保證告警規則設定的合理性，對於一些大規模觸發情況，比如網路故障，京東雲預設會按照規則、應用進行合併，同時為了在合併之後讓使用者能看的更清楚，京東雲也推出了移動端程式。
03質量服務在京東雲的實踐
技術沙龍|京東雲DevOps自動化運維技術實踐
京東雲平臺質量部總監 丁超


“質量是一份事業，向做質量的同學致敬”

在京東雲，質量部門關注什麼？
京東雲的形態包含公有云、專有云、混合雲、多雲形態，基於京東雲產品的特性，質量服務應關注如下 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，測量AZ1、AZ2同時恢復流量負載的耗時。之後，針對AZ2 重複如上的步驟。結果光AZ1斷電的場景，就用了數個小時，這其中包括故障定位、執行預案、恢復驗證等。非常直接客觀地表明，在問題發現和定位、預案有效性、系統級驗證方面，都亟待改進。不難得出結論：破壞性演練，是推動服務治理、架構升級的有效助力！“ 2、混沌工程改進及發展第一次演練之後，京東雲開始了不斷的迭代改進，包括：
  • 依賴治理：服務的 RING 級別梳理。將服務按照依賴順序、部署順序進行梳理，同一 RING 上的服務，不能有相互依賴。不同 RING 上的服務，有明確的監控項（KEY）狀態呈現，有助於問題的逐層定位。
  • 預案自動化：將所有預案收錄到監控系統，實現自動化。觸發方式定義為：檢測到問題直接觸發，和預警後人工確認觸發。並對每個預案的生效時間進行嚴格的耗時檢查，不斷精進。
  • 資料面要求對使用者無損（即使用者無感知），控制面可適當放寬。
  • 服務治理：引入微服務架構和呼叫鏈治理。
  • 觸發及驗證自動化：將故障的觸發和雲功能的驗證，進行平臺化。現已實現無成本的觸發、秒級驗證，這使破壞性演練可日常常態觸發，不必大動干戈。
“時至一年半後的今天，我們已經從單場景故障恢復時間數個小時，降低到了分鐘內，大部分故障場景使用者無感知。微服務化、3AZ 建設等雲的高可用性改造也在持續進行中。對於未來，京東雲更有信心！”丁超老師對混沌工程的迭代有更強的信心。
技術沙龍|京東雲DevOps自動化運維技術實踐
BoCloud博雲 售前總監 劉欣雨


多雲管理平臺的建設

開篇，劉欣雨分析了中國雲市場現狀提出：中國雲市場規模在逐年增加，增幅領跑全球，呈現特點是越來越多使用者願意同時採用公有云和私有云這種多雲管理模式。隨著國內更多雲服務商的參與，為雲市場提供更好、更完善服務，我們相信中國的雲市場規模將會更加龐大，那麼多雲管理的需求也將會越來越強烈，範圍越來越廣，這為多雲管理服務商提供更大的市場機會。
博雲多雲平臺總體建設思路圍繞“七化”：管理統一化、資產精細化、業務流程化、服務自助化、運營計量化、響應自動化，管理智慧化。劉欣雨主要分享了一體化運維管理方案，其中包含的多雲管理方案、自動化運維和金融行業實踐等內容。
關於其一體化運維管理方案，劉欣雨說：“一體化運維包含五個方面，統一納管，統一運維，統一運營，統一服務門戶和統一監控管理，實現異構資源集中納管，統一資源按需分配；支援自動化運維，支援透過服務編排實現不同運維場景的自動化服務；提供統一服務門戶，實現自助自主服務門戶，讓業務人員自助獲取自己所需要的服務，我們的平臺可以自動執行，為使用者提供資源，同時提供集中監控管理，實現資源、應用和服務一站式管理”。
同時劉欣雨也提到，對自動化運維場景的支援主要體現資源自動化、應用自動化、網路自動化和業務場景自動化。包括資源交付、系統安裝，應用上下線、應用變更、補丁管理、網路配置管理和業務場景管理（如災備切換和跑批業務自動化處理）。劉欣雨提到雲管平臺還需要開放的整合模式，要匹配多服務管理方式，提供開放介面，方便對接客戶現有系統（如多廠商雲平臺、ITSM、CMDB、監控等），這個也是對雲管平臺的要求。
最後劉欣雨分享了博雲在某大型股份制銀行多雲管理平臺專案建設內容，多雲管理平臺幫助該股份制銀行實現了資源統一化、服務標準化、運維自動化和服務智慧化的IT管理目標，提高了資源利用率，減輕了運維人員工作量，提升了運維工作效率，保障了運維工作質量，增強了IT服務體驗，節約了IT建設和運營成本。
關注【京東雲開發者社群】，後臺回覆【PPT1123】檢視活動PPT
點選“ 閱讀 ”，進入京東雲開發者中心檢視沙龍影片
歡迎點選“ 京東雲 ”瞭解更多精彩
技術沙龍|京東雲DevOps自動化運維技術實踐
技術沙龍|京東雲DevOps自動化運維技術實踐


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912185/viewspace-2666821/，如需轉載，請註明出處，否則將追究法律責任。

相關文章