騰訊雲+社區技術沙龍丨數字經濟大潮推進下的高效智能運維

在數字經濟大潮的推進下，信息化建設以及數字化轉型加速發展，大中型乃至超大型的數據中心不斷產生，但其中成百上千套的 IT 設備與業務系統的正常健康運行爲傳統 IT 運維帶來了嚴峻挑戰，這些都在推進着我國 IT 運維向標準化、自動化、智能化方向升級轉變。

11 月 9 日，由騰訊云云+社區主辦的「高效智能運維」技術沙龍中，來自騰訊雲和嘉爲科技的專家大牛圍繞「運維」展開了一場技術盛宴，從 AIOps、Serverles DevOps、藍鯨 Paas 平臺、K8S 等 分享關於業務運維的技術實踐乾貨，同時帶來騰訊海量業務自研上雲實踐，推進傳統運維向雲運維轉型。

張戎：《騰訊雲智能運維(AIOps)項目實踐》

來自騰訊雲的張戎，分享了關於智能運維(AIOps)方面的一些應用和實踐。本次分享主要包括智能運維場景描述、單維時間序列分析、多維時間系列分析、近期工做和將來的研究方向。

基於機器學習的智能運維分爲幾個方面，基於機器學習的運維也分爲幾個應用場景。但如何在高效或者煩瑣的業務中迅速定位到哪些地方處了問題，是咱們須要關注的地方：

1. 發現問題：包括時間序列的異常檢測、日誌異常分析、服務器性能評估；
2. 分析問題：如何精準的定位日誌、影響到哪些客戶、影響範圍與影響面；
3. 解決問題：經過智能運維將記憶學習運用到運維領域，提高質量、效率、成本。

整個智能運維分爲好幾個階段，第一個是咱們剛剛開始機器學習的能力，而從剛剛開始應用到逐漸可以成熟落地其實這個是有很長的時間段的，一般來講是 1-2 年甚至是更長的時間。

第二個就是咱們各個能力相對完備一點，好比說異常檢測、分析、日誌提取或者是模板分析的內容，作到相對完善的功能。而後這一塊咱們儘可能作到儘可能少的人工參與。

最後會實現一個終極的 AIOPS 的階段，有一個終輸的流程的大腦，咱們能夠在效率、質量、成本三個方面達到一個相對均衡的狀態，讓咱們的系統達到一個相對穩定的過程。

黃宏東：《衝上雲霄-騰訊海量業務上雲實踐》

隨着雲計算的發展，雲的運用愈來愈廣，運維領域也有很大的變革。騰訊在上雲這一塊有不少的業務實踐，它對咱們的業務有很大提高，騰訊雲的黃宏東給你們分享了騰訊在上雲的思考和實踐。

第一，爲何要上雲？

在騰訊作開發是既是幸福的事情也是煩惱的事情。騰訊的業務線很是普遍，每條業務線有本身的運維資源體系、開發體系，也會有本身定製化的方案和架構，這致使咱們每一個系統都不相通。

這也致使了內部的方案不通用、重複造輪子、缺少統一規範。爲此咱們在 2018 年 9 月 30 日作了一個變革，業務線和技術線都作了變革。不只作鏈接人、鏈接數據與服務，還對產業互聯網方向作了升級。第一個是開源協同，第二個是自研業務上雲。

第二，業務上雲的價值。

業務上雲的價值主要從三大塊來看。第一塊是對業務的價值，第二個是對工程師的價值，第三塊是對客戶的價值。

在以前，騰訊沒有本身的雲，只能用 AWS，但以後咱們有了本身的雲，有了海外服務的時候，出海會更加順暢。而且雲的服務和咱們自研的環境是相通的，不少運維體系、運維架構都是兼容的，對業務出海有很是大的幫助。

對於技術人員來說，咱們的研發環境是可以和雲直接相通，咱們的開發、構建、測試、運維整個過程很是高效。

客戶價值這方面，咱們主要是爲行業輸出公有云遷移經驗，更豐富的雲服務和工具提供給客戶。

第三，如何上雲？

咱們總結了兩點，第一個是如何提高上雲的效率，第二個是下降遷移風險。

業務上雲作了這麼長時間，有一些總結。第一個是擁抱雲原生，雲原生在近五年必定是一個最新的趨勢。第二個是借上雲革新研發模式，全面 Devops（CI/CD/CO）。第三個是組件和工具的上雲，服務化主要是如何對業務和客戶服務，工程師文化如何培養，如何將這種技術氛圍給調動起來。

張敏：《藍鯨研發運維技術Paas體系實踐》

第三位嘉賓是來自嘉爲科技的張敏，從藍鯨研發運維技術 PaaS 體系帶來了精彩內容分享。

騰訊藍鯨智雲，簡稱藍鯨，是騰訊互動娛樂事業羣（簡稱 IEG）自用的一套用於構建企業研發運營一體化體系的 PaaS 開發框架，提供了 aPaaS（DevOps 流水線、運行環境託管、先後臺框架）和 iPaaS（持續集成、CMDB、做業平臺、容器管理、數據平臺、AI 等原子平臺）等模塊，幫助企業技術人員快速構建基礎運營 PaaS。

咱們常常談組織轉型，運維轉運維開發，但如何落地？它必定要一個平臺或者是一個框架下降你轉運維開發的技術門檻。而下降這個技術門檻，就是剛纔講的藍鯨 Paas 體系提供的能力，你基於它的框架，惟一要作的是將你之前寫運維的腳本嵌到這個框架裏面，少許的代碼量，便可完成一個自定義的運維工具或運營系統的構建，這個時候纔可能達成成功的轉型。

組織轉型帶來的成效會體如今企業運營工具文化中，工具文化通俗點理解：就是一個團隊裏面，任何兩我的若是運維工做上的這種溝通和協做，還要經過口頭和電子流的方式進行，效率就很低；而工具文化就是一旦有這樣的痛點，就能夠快速地構建一個工具來解決這個痛點。慢慢落地工具文化，就造成了一個史無前例的運維建設模式。

總結來說技術運營 PaaS 就是這樣一個演進的過程，從煙囪治理到 PaaS 技術框架，到組織轉型，再到企業工具文化，基於 PaaS 框架，實現 CI/CD/CO 的研發、運維、運營全覆蓋。這就是目前藍鯨對外的一個總體方案了。

孔令飛：《ServerlesDevOps 最佳實踐》

最近兩年 Serverless 技術很火，Serverless 翻譯過來就是無服務器，其實 Serverless 並非真的不須要服務器，只不過把服務器交給雲廠商來進行維護。同時國內外的 Serverless 平臺也都會對平臺上部署的業務提供開箱即用的業務運維能力。也就是說 Serverless 會影響到業務運維和系統運維 2 個方面。但願經過此次分享可以讓你們瞭解什麼是 Serverless，Serverless 可以提供的運維能力，還會經過對比讓你們瞭解 Serverless 相比傳統的運維方式有什麼樣的效率提高。最後會介紹下在 Serverless 下是如何進行運維的。

莊鵬銳：《騰訊雲Kubernetes集羣提高資源利用率的實踐》

接下來，來自騰訊雲的莊鵬銳，帶來了對 K8S 的改造，關於如何提升資源業務方面的技術乾貨。

爲何咱們的集羣資源利用率不夠高？其中大概會概括爲幾個方向，第一個是 Node 節點資源的碎片；第二點，大部分業務在建立 Pod 的時候，對 resource 設置不合理，這每每會設很大從而形成資源的浪費；第三點，很多用戶難以準確評估 workload 副本數；第四點，業務的空閒時間。

爲了解決這個問題，咱們作了一些優化。

第一個是對 Pod 的壓縮。Pod 壓縮是爲了不建立時 requests 設置不合理。當 kube-apiserver 收到 Pod add 請求時，根據其處理流程中的 mutatingadmissionwebhook 機制，kube-apiserver 會將請求轉發到咱們寫的 webhook，而後按照 webhook 設計的 ratio 和 limits 的值對 Pod 的 requests 進行壓縮。

第二個是 Node 超賣。Node 超賣是爲了讓利用率低的 Node 能夠建立更的的 Pod。超賣包含兩個部分， 一個是經過根據 Node 歷史使用數據和 Node 的資源分配狀況來計算出超賣比率；另一部分是 Node 週期性發生 patch 請求更新其狀態數據，同樣經過 mutatingadmissionwebhook 機制，經過上述計算出來的超賣比例來動態調整 Node 的可分配資源。

第三個是 HPAplus。HPAPlus 解決了用戶設置 workload 合理副本數的困擾。HPAplus 是一個單獨的 controller，其除了具有原 HPA 功能特性外，還支持如 CronHPA、支持多種數據源、動態調整 minRepliacs、更好性能等特性。爲何將它抽出來而不是直接修改 controller-manager 呢？主要緣由在咱們並不想去大規模改動 kubernetes 的代碼，避免之後和社區方向誤差愈來愈大，很差升級。

最後一個是 VPAPlus。VPAPlus 根據監控數據，動態熱更新 Pod 的資源配置。社區版本的 VPA，是經過驅逐 Pod 的方式來動態調整 Pod 的配置，這種方式須要通過較長的時間重建 Pod 來恢復服務，而且可能會對服務形成影響。這就跟 VPA 快速調整 Pod 配置的目的相違背。所以咱們經過修改 kube-apiserver 和 kubelet 的代碼，來達到熱更新 Pod 資源配置的目的。此外咱們從新寫了 vpa-updaet 組件，在性能上和響應時間上作了優化，併爲 VPA/Pod 對象添加了多種個性化配置。

此外，還作了動態調度、碎片處理等來進一步提升集羣資源利用率。

本期雲+社區技術沙龍吸引了衆多運維技術開發者前來學習交流，經過一個簡短的下午時間讓開發者對運維技術有了更深刻的理解。愈來愈多的開發者經過雲+社區組織舉辦的技術沙龍瞭解騰訊雲技術和產品，在這裏碰撞出知識的火花。