前言
隨著公司自研上云戰(zhàn)略如火如荼地進(jìn)行，IEG-增值服務(wù)部作為較早一批響應(yīng)的團(tuán)隊(duì)，截止目前自研上云已完成1/3的流量切換，日PV超百億。切云的服務(wù)大量采用了云原生的應(yīng)用與技術(shù)架構(gòu)，作為公司第一批面臨云原生環(huán)境的業(yè)務(wù)運(yùn)維，深切感受到云原生給運(yùn)維工作帶來的機(jī)遇與挑戰(zhàn)，運(yùn)維模式的轉(zhuǎn)型已經(jīng)迫在眉睫，此篇文章最大的價(jià)值在于將我們的轉(zhuǎn)型思路、方法與實(shí)踐，提供給后面更多面臨同樣挑戰(zhàn)的團(tuán)隊(duì)借鑒與參考。下面我將從業(yè)務(wù)場(chǎng)景、運(yùn)維轉(zhuǎn)型之道、云端收益等幾個(gè)方面來跟大家一起來探討。
一、業(yè)務(wù)服務(wù)場(chǎng)景介紹
DataMore是IEG增值服務(wù)部為游戲項(xiàng)目組提供的一站式智能游戲運(yùn)營(yíng)方案平臺(tái)，基于游戲日志數(shù)據(jù)，利用實(shí)時(shí)與離線計(jì)算打造數(shù)據(jù)營(yíng)銷能力，為業(yè)務(wù)提供以解決運(yùn)營(yíng)問題為目標(biāo)的數(shù)據(jù)運(yùn)營(yíng)服務(wù)方案。與傳統(tǒng)的游戲運(yùn)營(yíng)體系不同，DataMore游戲數(shù)據(jù)運(yùn)營(yíng)平臺(tái)具有脫離游戲版本，對(duì)研發(fā)側(cè)依賴小，計(jì)算能力與精細(xì)化運(yùn)營(yíng)能力強(qiáng)的特點(diǎn)，可以為游戲業(yè)務(wù)帶來更低成本、更快速高效的精細(xì)化運(yùn)營(yíng)，并提供豐富的游戲運(yùn)營(yíng)方案。DataMore在各個(gè)生命周期，多種游戲品類上沉淀了許多運(yùn)營(yíng)方案以及工程化的運(yùn)營(yíng)系統(tǒng)，覆蓋新進(jìn)、活躍、流失、留存、付費(fèi)和傳播等多個(gè)階段，包括邀請(qǐng)好友、任務(wù)中心、砍價(jià)拼團(tuán)、低活躍干預(yù)、流失召回等多種數(shù)據(jù)運(yùn)營(yíng)方案，使得游戲業(yè)務(wù)可以快捷的找到適合自身游戲階段、針對(duì)特定運(yùn)營(yíng)問題的解決方案。部分方案截圖：
DataMore在技術(shù)架構(gòu)上采用了微服務(wù)設(shè)計(jì)的理念，采用服務(wù)型開發(fā)架構(gòu)，將數(shù)據(jù)營(yíng)銷服務(wù)拆分成獨(dú)立、通用的服務(wù)能力，同時(shí)構(gòu)建了應(yīng)用和服務(wù)中臺(tái)，能夠通過組合這些通用服務(wù)快速而輕松的構(gòu)建專屬應(yīng)用服務(wù)。DataMore活動(dòng)覆蓋了互娛幾乎所有的游戲，落地場(chǎng)景非常多，每天都有新活動(dòng)上線，而且周期短，節(jié)奏快，活動(dòng)周期一般只持續(xù)一兩周，日PV超過200億，QPS峰值超過20+萬，落地場(chǎng)景覆蓋王者榮耀、和平精英在內(nèi)的所有游戲及周邊應(yīng)用（如助手、微信游戲中心等）。
二、基于云原生環(huán)境開發(fā)者平臺(tái)
相信大家對(duì)云原生的概念已經(jīng)不陌生，但很難精準(zhǔn)地去解釋云原生具體是個(gè)什么東西，原因是云原生沒有很確切的定義，且不斷在發(fā)展演變當(dāng)中。Pivotal 公司的 Matt Stine 于2013年首次提出云原生（CloudNative）的概念，旨在說明云原生是一種構(gòu)建和運(yùn)行應(yīng)用程序的方法，是一套技術(shù)體系和方法論。2015年云原生計(jì)算基金會(huì)（CNCF），對(duì)云原生的定義為：“云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格（Service Mesh）、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。這些技術(shù)能夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動(dòng)化手段，云原生技術(shù)使工程師能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測(cè)的重大變更。”。目前形成云原生理解上的最大共識(shí)概括為4個(gè)核心要點(diǎn)：DevOps+持續(xù)交付+微服務(wù)+容器，即基于這"4件套"構(gòu)建的應(yīng)用我們暫且認(rèn)為就是云原生應(yīng)用了。同時(shí)可以享受到云端極為豐富的PaaS組件，如業(yè)務(wù)后續(xù)使用到的數(shù)據(jù)庫、緩存、中間件、存儲(chǔ)、CDN等等，并且具備無縫在不同云廠商間透明遷移的能力。
為適配云原生環(huán)境的數(shù)據(jù)營(yíng)銷服務(wù)的需求，部門推出了奇點(diǎn)（ODP）平臺(tái)（基于騰訊游戲數(shù)據(jù)&營(yíng)銷服務(wù)能力，以微服務(wù)架構(gòu)為基礎(chǔ)，構(gòu)建的集代碼管理、服務(wù)開發(fā)、運(yùn)維發(fā)布、服務(wù)運(yùn)營(yíng)為一體的一站式開發(fā)運(yùn)營(yíng)平臺(tái)）實(shí)現(xiàn)了真正意義上的DevOps服務(wù)閉環(huán)，貫穿了服務(wù)交付的CI、CD、CO環(huán)節(jié)，得益于公司內(nèi)外部更多優(yōu)秀組件的集成，包括TKE、藍(lán)盾、QCI、Envoy等。
三、云原生運(yùn)維轉(zhuǎn)型、挑戰(zhàn)、目標(biāo)與實(shí)踐
1、云原生運(yùn)維轉(zhuǎn)型思維
這幾年運(yùn)維界聽到最多的幾句話：“云計(jì)算會(huì)淘汰掉運(yùn)維！整個(gè)運(yùn)維行業(yè)可能被干掉！再不轉(zhuǎn)換運(yùn)維就要丟飯碗”，諸如此類。那真相到底是什么？行業(yè)有一個(gè)共識(shí)，即運(yùn)維工作本身交付的是一種服務(wù)，下面舉一個(gè)可能不太恰當(dāng)?shù)睦?，或者可以幫助大家找到答案?/p>
云計(jì)算時(shí)代好比組裝一輛汽車，根據(jù)客戶的需要，通過PaaS能力選擇匹配的引擎、車輪、離合器、 懸架、車控制系統(tǒng)等進(jìn)行拼裝?？蛻舨挥藐P(guān)心汽車各元部件的實(shí)現(xiàn)原理，最終獲得是一輛滿足自身要求的汽車。光有了汽車是玩不轉(zhuǎn)的。還需要有修路、加油站、交通控制等服務(wù)體系，運(yùn)維就是承擔(dān)這個(gè)角色。相比傳統(tǒng)運(yùn)維，確實(shí)是少了自己采購(gòu)元組與組裝的工作。到了后云計(jì)算時(shí)代（云原生），出現(xiàn)了一個(gè)DevOps公司，引入新技術(shù)與理念，聲稱已經(jīng)將修路、加油站、交通控制等環(huán)節(jié)都打通了，形成了一體化服務(wù)能力，并邀請(qǐng)運(yùn)維哥一起加入創(chuàng)業(yè)。在這個(gè)階段，運(yùn)維哥出去單干，大概率會(huì)翻車。但加入DevOps公司，運(yùn)維的價(jià)值到底還有什么呢？因此，升級(jí)與轉(zhuǎn)型是必然的，例如將普通國(guó)道升級(jí)成高速公路；實(shí)現(xiàn)客戶在高速路上不停車換輪胎；貼近并理解客戶，規(guī)劃行程中所需的服務(wù)來提升客戶體驗(yàn)；通過提升智能化水平，連接交通管制，縮短航程，避開損壞路段等等。相信大家心中已經(jīng)有自己答案了?；氐皆c(diǎn)的靈魂拷問：“云原生背景下，運(yùn)維不做轉(zhuǎn)型會(huì)不會(huì)死？”，”運(yùn)維要如何快速自救和升級(jí)？“。
我的觀點(diǎn)：
1）不會(huì)死，但未來整條價(jià)值交付鏈沒有你什么事了；
2）轉(zhuǎn)型SRE是一種選擇。
接下來介紹我們運(yùn)維體系是如何進(jìn)行轉(zhuǎn)型升級(jí)的，首先我們的轉(zhuǎn)型理論基礎(chǔ)來源于DevOps框架，從中抽取出符合現(xiàn)階段服務(wù)場(chǎng)景要求的模型，從文化與技術(shù)兩大方向反復(fù)去實(shí)踐與論證，也獲取了非常好的效果。下圖是Gartner于2015年發(fā)布的DevOps實(shí)踐模型，放在2020年的今天來看，確實(shí)具有很強(qiáng)的前瞻性，不少觀點(diǎn)經(jīng)過我們的驗(yàn)證是正確的，例如：Feature Teams(特性團(tuán)隊(duì))、Developer Self-Service(開發(fā)者自助服務(wù))、Infrastructure as Code(基礎(chǔ)設(shè)施即代碼)、Integrated Tool Chains(集成工具鏈,CI-CT-CO)、One-Step Build, Test, Deploy(一鍵程序構(gòu)建，測(cè)試，部署)等等。下面從文化與技術(shù)兩個(gè)層面來剖析：
1）文化層面
以下幾點(diǎn)是我們中心內(nèi)部實(shí)行的幾個(gè)機(jī)制，供作參考，因不同團(tuán)隊(duì)間存在一定差異，此處不展開說明。
開發(fā)與運(yùn)維成立FT虛擬團(tuán)隊(duì)，實(shí)現(xiàn)組織上的融合；
開發(fā)或運(yùn)維側(cè)的例會(huì)、技術(shù)分享、事件復(fù)盤，F(xiàn)T成員全程參與；
項(xiàng)目立項(xiàng)時(shí)，運(yùn)維接口人需要做“左移”，即提前參與技術(shù)架構(gòu)討論，有助于運(yùn)維的問題提前在方案討論或開發(fā)階段提前暴露，有效做好防范與規(guī)避；
建立收集各方反饋問題與建議的機(jī)制與渠道，有效將好的想法影響至平臺(tái)下個(gè)版本的迭代中，實(shí)現(xiàn)持續(xù)改進(jìn)與優(yōu)化。
2）技術(shù)層面
下圖是個(gè)人繪制的傳統(tǒng)運(yùn)維到云原生運(yùn)維的價(jià)值過渡，很明顯的一個(gè)特性是往更高階領(lǐng)域去涉足，傳統(tǒng)運(yùn)維投入將大幅度減弱。目標(biāo)意指將更貼近業(yè)務(wù)、理解業(yè)務(wù)、通過數(shù)據(jù)與AI的能力，提升業(yè)務(wù)持續(xù)服務(wù)的能力及用戶體驗(yàn)，同時(shí)確保整個(gè)價(jià)值交付鏈的暢通與高效。
在云原生背景下，我們對(duì)運(yùn)維體系進(jìn)行了升級(jí)，在原有基礎(chǔ)運(yùn)維能力之上確定了以下幾個(gè)目標(biāo)：
具備服務(wù)全鏈路質(zhì)量監(jiān)控覆蓋，涵蓋數(shù)據(jù)域與業(yè)務(wù)域
具備一定智能化的資源動(dòng)態(tài)調(diào)度、伸縮機(jī)制
具備一定的故障預(yù)警、根因分析、問題定位能力
服務(wù)具備在交付不同階段（測(cè)試、預(yù)發(fā)布、運(yùn)營(yíng)）抵御異常的能力
具備資源高效交付的流程機(jī)制與快速上線的能力
具備多云的資源編排與管理的能力
具備業(yè)務(wù)快速上云的機(jī)制，確保切換過程的高可用性
確定了運(yùn)維能力升級(jí)指導(dǎo)思想：基于運(yùn)維編排的云原生實(shí)例化。廣義而言，運(yùn)維的本質(zhì)就是多個(gè)運(yùn)營(yíng)事件的有機(jī)串聯(lián)，來達(dá)到質(zhì)量、效率、成本、安全多維收益，而編排是實(shí)現(xiàn)有機(jī)串聯(lián)的有效手段，除了可以沉淀運(yùn)維經(jīng)驗(yàn)外，還可以有效實(shí)現(xiàn)共享。
2、云原生運(yùn)維轉(zhuǎn)型平臺(tái)化建設(shè)
在運(yùn)維平臺(tái)化建設(shè)方面，我們?cè)跇?gòu)建原云生運(yùn)維平臺(tái)能力–玄圖。積極擁抱公司開源協(xié)同的機(jī)制，通過集成現(xiàn)有優(yōu)秀平臺(tái)或組件，如有河圖元數(shù)據(jù)管理平臺(tái)（CMDB）、藍(lán)鯨標(biāo)準(zhǔn)運(yùn)維平臺(tái)、PCG-混沌工程實(shí)驗(yàn)平臺(tái)、藍(lán)鯨服務(wù)流程管理平臺(tái)等等，避免重復(fù)性建設(shè)，結(jié)合我們的服務(wù)場(chǎng)景，發(fā)揮平臺(tái)服務(wù)效能最大化。思路上借鑒了“瑞士軍刀”，我們通過微服務(wù)的架構(gòu)，將云資產(chǎn)（CMDB）管理作為底座，也就是“刀把”。再將剪刀、平口刀、開罐器、螺絲起子、鑷子等等集成進(jìn)來，通過定義資源與上層平臺(tái)的總線協(xié)議，將各類平臺(tái)工具進(jìn)行組裝，猶如瑞士軍刀一樣，將輕、快、實(shí)用、因地制宜發(fā)揮到極致。下面將我們的體系能力進(jìn)行介紹：
2.1 云原生資產(chǎn)管理
公有云/私有云的各類云資源管理，我們叫做資產(chǎn)管理（所有的資源/應(yīng)用/數(shù)據(jù)都在資產(chǎn)范疇）。我們知道，傳統(tǒng)的大多數(shù)cmdb只能管理服務(wù)器信息（如ip地址/機(jī)架/機(jī)房等），在云原生環(huán)境下，我們將面對(duì)復(fù)雜多變的、新生的應(yīng)用和場(chǎng)景，隨之會(huì)產(chǎn)生越來越多的管理配置項(xiàng)，這就要求資產(chǎn)管理能夠滿足各種需求的擴(kuò)展和未來業(yè)務(wù)的變化，例如騰訊云的CLB、CDB、COS、Ckafka等等，沒有自定義模型屬性的CMDB難以將這些云產(chǎn)品納入管理范疇。
在資產(chǎn)管理方案調(diào)研的過程中，我們發(fā)現(xiàn)資產(chǎn)管理需求與元數(shù)據(jù)管理十分契合，因此，資產(chǎn)管理，作為河圖元數(shù)據(jù)系統(tǒng)的應(yīng)用場(chǎng)景落地，通過元數(shù)據(jù)定義資產(chǎn)管理的模型、屬性、組合關(guān)系，玄圖對(duì)元數(shù)據(jù)的加工、應(yīng)用實(shí)現(xiàn)通用的可靈活調(diào)整的業(yè)務(wù)級(jí)資產(chǎn)管理。
在我們常見的kafka集群資產(chǎn)管理的場(chǎng)景下，通過河圖元數(shù)據(jù)定義相關(guān)的集群、主機(jī)模型以及屬性，定義他們的組合關(guān)系，達(dá)到資產(chǎn)管理的要求。
模型代表著一類云資源，模型的屬性從各個(gè)方面分別描述這一類云資源，模型的屬性可以根據(jù)場(chǎng)景自由定義和擴(kuò)展。集群模型，當(dāng)前的屬性包括集群名、cc_set等，主機(jī)模型，當(dāng)前的屬性包括ip、類型、區(qū)域等，隨著業(yè)務(wù)不斷發(fā)展變化，我們后續(xù)可能會(huì)對(duì)集群和主機(jī)的信息進(jìn)行不斷的擴(kuò)展，也可能集群下還要管理如CLB等其他類型的云資源信息，采用云資源管理，能很好地適應(yīng)這種變化。
遵循MOF元對(duì)象設(shè)施建設(shè)標(biāo)準(zhǔn)規(guī)范為基礎(chǔ)的云資源管理平臺(tái)，能自由方便地表示所有模型間的關(guān)系，包括組合關(guān)系、依賴關(guān)系和繼承關(guān)系。組合關(guān)系描述了一種組成關(guān)系，代表某個(gè)模型由另外的模型組成，依賴關(guān)系主要用于管理模型之間的依賴，繼承關(guān)系則可以用來表示一種父子關(guān)系。kafka集群和主機(jī)的關(guān)系我們就可以用組合關(guān)系來表示，集群依賴的業(yè)務(wù)可以用依賴關(guān)系來表示，也可 以定義一個(gè)主機(jī)模型的父類，再派生出不同的子類代表不同的主機(jī)類型，但具有父類公共的屬性定義。
資產(chǎn)管理的數(shù)據(jù)將直接存儲(chǔ)在河圖元數(shù)據(jù)系統(tǒng)中，玄圖平臺(tái)在保留元數(shù)據(jù)管理靈活自定義的前提下，簡(jiǎn)化元數(shù)據(jù)操作管理，適配資產(chǎn)管理的需求，提供高效的查詢、檢索、變更的能力，以有效管理云資產(chǎn)。
2.2 云端一切操作皆可編排
云原生環(huán)境下，運(yùn)維面臨各種不同的公有云/私有云環(huán)境和各種跨云/跨平臺(tái)的操作，給運(yùn)維操作管理帶來了巨大挑戰(zhàn)。因此，我們繼續(xù)構(gòu)建云原生環(huán)境的編排能力，即運(yùn)維編排，通過開發(fā)、封裝可編排的組件和插件，提供靈活、可定制、可管理的模板化運(yùn)維能力，覆蓋運(yùn)維任務(wù)的管理、審批、決策、執(zhí)行、通知等功能，最終實(shí)現(xiàn)自動(dòng)化、智能化運(yùn)維。
我們將運(yùn)維編排分為三層，即：基礎(chǔ)設(shè)施層、容器服務(wù)層、應(yīng)用層。
如上圖所示：
云資源編排，編排對(duì)象是各類云資源，包括公有云、私有云等，采用terraform來實(shí)現(xiàn)多云基礎(chǔ)設(shè)施的編排，可以覆蓋騰訊云、阿里云、AWS、私有云等等。
kubernetes編排，編排對(duì)象是k8s集群資源，采用Helm/YAML進(jìn)行編排。
作業(yè)編排，編排對(duì)象主要是主機(jī)節(jié)點(diǎn)，對(duì)應(yīng)的操作任務(wù)編排，調(diào)用現(xiàn)有的藍(lán)鯨job作業(yè)平臺(tái)。
運(yùn)維編排三層之間如何串聯(lián)？我們采用了開源的藍(lán)鯨標(biāo)準(zhǔn)運(yùn)維作為編排引擎，將不同的三層編排串聯(lián)，打破從前跨云、跨平臺(tái)各種割裂的操作界限，提升運(yùn)維效率，一切皆編排，并能將編排任務(wù)沉淀為能力模板傳承交接。
例如上圖的場(chǎng)景，我們需要擴(kuò)容一個(gè)現(xiàn)網(wǎng)的TKE業(yè)務(wù)集群，從基礎(chǔ)設(shè)施層的資源采買，到容器服務(wù)初始化部署，和一些集群特性作業(yè)操作等均一站式運(yùn)維編排完成，操作時(shí)長(zhǎng)從4小時(shí)優(yōu)化到30分鐘內(nèi)，而且集群再次擴(kuò)容只需簡(jiǎn)單修改幾個(gè)編排參數(shù)執(zhí)行，避免了繁瑣重復(fù)的操作。在玄圖平臺(tái)能力中將通過自助開發(fā)可編排的原子（包括操作、接口、算法等），一切操作皆編排。
2.3 DataOps助力運(yùn)維轉(zhuǎn)型
2.3.1 TKE資源動(dòng)態(tài)調(diào)度
K8S的特性是資源一旦分配給工作負(fù)載，就會(huì)被獨(dú)占，即使是空跑狀態(tài)，其他工作負(fù)載也不能復(fù)用。一般來說用戶申請(qǐng)的資源會(huì)遠(yuǎn)超實(shí)際需求，Pod規(guī)格和副本數(shù)設(shè)置很大，或者HPA最小副本數(shù)設(shè)置很高，并且不會(huì)主動(dòng)去釋放資源。這樣會(huì)導(dǎo)致K8S集群存在大量的空閑資源，集群的總體資源使用率不高。為了解決這個(gè)問題，我們需要主動(dòng)對(duì)工作負(fù)載做資源動(dòng)態(tài)調(diào)度。
如下圖所示，預(yù)測(cè)模型通過TKE自帶的hpa-metrics-server拿到workload當(dāng)前使用的CPU核數(shù)并落地DB，通過API-Server拿到workload當(dāng)前分配的CPU核數(shù)。調(diào)度器Scheduler根據(jù)預(yù)測(cè)模型的預(yù)測(cè)值動(dòng)態(tài)調(diào)整workload的副本數(shù)。
動(dòng)態(tài)調(diào)度模型使用過去一個(gè)時(shí)間周期內(nèi)同一時(shí)間點(diǎn)的負(fù)載數(shù)據(jù)擬合得到CPU核數(shù)預(yù)測(cè)值，為了保證資源充足，模型會(huì)根據(jù)當(dāng)前實(shí)際使用的CPU核數(shù)再預(yù)留一倍的冗余，并且至少保留一個(gè)副本，結(jié)合目前已經(jīng)分配的核數(shù)得到最終預(yù)估分配核數(shù)。最后，調(diào)度器根據(jù)模型的預(yù)估分配核數(shù)動(dòng)態(tài)修改workload的副本數(shù)，釋放空閑資源。
執(zhí)行資源動(dòng)態(tài)調(diào)度后收益非常明顯，集群空閑資源被釋放出來，可以承載更多的workload，在總核數(shù)為1萬核的集群實(shí)踐，可以釋放一半的空閑CPU，集群整體CPU利用率從15%提升到28%。
2.3.2 TBDS資源動(dòng)態(tài)調(diào)度
經(jīng)過統(tǒng)計(jì)我們發(fā)現(xiàn)騰訊云TBDS數(shù)據(jù)倉庫集群CPU的總體使用率僅為55%左右。如下圖所示，藍(lán)色線是分配的資源，綠色線是使用的資源，大部分應(yīng)用組資源池，存在空閑時(shí)間段，而且相互錯(cuò)峰的情況。我們累計(jì)有500+個(gè)應(yīng)用組，抽取幾個(gè)大應(yīng)用組統(tǒng)計(jì)其繁忙時(shí)間段，發(fā)現(xiàn)存在明顯的錯(cuò)峰情況。
為了進(jìn)一步提升資源使用率，需要對(duì)資源做動(dòng)態(tài)分配，簡(jiǎn)單的說，當(dāng)資源使用少的時(shí)候，就少分配些，當(dāng)資源使用多的使用，就分配多些，分配使用動(dòng)態(tài)調(diào)整。動(dòng)態(tài)分配算法模型，大體上分兩步，第一步，先計(jì)算出每個(gè)應(yīng)用組的預(yù)估分配核數(shù)。因?yàn)榭偡峙浜藬?shù)一定，所以還需第二步根據(jù)預(yù)估分配核數(shù)的占比情況算實(shí)際分配核數(shù)。
預(yù)估分配核數(shù)怎么算呢？首先，pt0是基線，目前用線性回歸來擬合，但擬合的結(jié)果會(huì)波動(dòng)很大，所以根據(jù)實(shí)際的任務(wù)要求，根據(jù)當(dāng)前的資源使用核數(shù)，給擬合結(jié)果設(shè)置了下限，又根據(jù)應(yīng)用組總資源池不能過大實(shí)際要求，跟擬合值設(shè)置了上限。所以，分配模型的特點(diǎn)有動(dòng)態(tài)的上下限，另外，這里給當(dāng)前的使用值翻倍預(yù)估，目的是當(dāng)任務(wù)需要資源時(shí)，分配的資源可得到快速增長(zhǎng)，從而不會(huì)影響任務(wù)的執(zhí)行，特別是大任務(wù)。
執(zhí)行動(dòng)態(tài)調(diào)度后收益非常明顯，集群資源利用率從55.4%提升到79.5%。從動(dòng)態(tài)分配前后的對(duì)比圖可以看到，總成本降低了1/3。其次是任務(wù)執(zhí)行效率也有提高，經(jīng)過對(duì)4000+個(gè)分析計(jì)算任務(wù)的執(zhí)行統(tǒng)計(jì)，平均執(zhí)行時(shí)間從27.5分鐘降低到18.1分鐘，執(zhí)行效率提升52%。
2.4 云原生應(yīng)用監(jiān)控
服務(wù)正式上線之后，我們需要掌握其運(yùn)營(yíng)狀況，比如QPS、成功率、響應(yīng)延遲、容量負(fù)載水位等指標(biāo)。一般是通過代碼埋點(diǎn)輸出日志，然后統(tǒng)計(jì)日志獲得，或者是程序主動(dòng)上報(bào)網(wǎng)管系統(tǒng)獲得，不管是哪種方式成本都不低。
我們需要在TKE集群部署Prometheus主動(dòng)采集workload負(fù)載指標(biāo)和用戶自定義指標(biāo)，隨著集群規(guī)模不斷擴(kuò)大，Promethues不支持容災(zāi)部署，不支持分布式，單實(shí)例容量瓶頸等問題也凸顯出來，最后我們放棄了原生的Prometheus，轉(zhuǎn)而使用Thanos（滅霸）實(shí)現(xiàn)了分布式、高可用容災(zāi)部署和數(shù)據(jù)長(zhǎng)期存儲(chǔ)。
Thanos Query 可以對(duì)數(shù)據(jù)進(jìn)行聚合與去重，所以可以很輕松實(shí)現(xiàn)高可用：相同的 Prometheus 部署多個(gè)副本(都附帶 Sidecar)，然后 Thanos Query 去所有 Sidecar 查數(shù)據(jù)，即便有一個(gè) Prometheus 實(shí)例掛掉過一段時(shí)間，數(shù)據(jù)聚合與去重后仍然能得到完整數(shù)據(jù)。
Thanos支持將數(shù)據(jù)上傳到各種對(duì)象存儲(chǔ)（比如COS）以供長(zhǎng)期保存 (Prometheus TSDB 數(shù)據(jù)格式)，對(duì)于需要長(zhǎng)期存儲(chǔ)的數(shù)據(jù)，并且使用頻率不那么高，最理想的方式是存進(jìn)對(duì)象存儲(chǔ)，不限制容量，價(jià)格非常便宜。
基于Thanos，我們業(yè)務(wù)平臺(tái)實(shí)現(xiàn)了高并發(fā)、海量的數(shù)據(jù)采集上報(bào)和存儲(chǔ)。首先，因?yàn)樗辛髁慷紩?huì)經(jīng)過網(wǎng)關(guān)，Thanos主動(dòng)采集網(wǎng)關(guān)的這些指標(biāo)到并將其可視化。如下圖所示，只要服務(wù)接入了業(yè)務(wù)平臺(tái)， QPS、耗時(shí)、成功率等一目了然，這些指標(biāo)都無需額外開發(fā)即自動(dòng)獲得，對(duì)代碼0侵入，節(jié)省了大量的開發(fā)成本。
同時(shí)，業(yè)務(wù)平臺(tái)也會(huì)使用Thanos主動(dòng)采集負(fù)載指標(biāo)生成服務(wù)容量負(fù)載水位視圖，包括CPU，內(nèi)存，流量等，如下圖所示。
如果服務(wù)有額外的指標(biāo)也可以通過平臺(tái)的自定義指標(biāo)采集上報(bào)到Thanos，并用Grafana繪制圖表。接入平臺(tái)后，服務(wù)運(yùn)行、負(fù)載等運(yùn)營(yíng)指標(biāo)全部自動(dòng)可視化，節(jié)省了開發(fā)成本，提升了開發(fā)和運(yùn)營(yíng)效率。
2.5 云原生業(yè)務(wù)全鏈路跟蹤（血緣關(guān)系鏈）
隨著業(yè)務(wù)的不斷縱深發(fā)展，技術(shù)服務(wù)鏈條也隨之拉長(zhǎng)，導(dǎo)致出現(xiàn)異常時(shí)定位問題困難，且無法快速評(píng)估影響面，因此我們通過構(gòu)建數(shù)據(jù)血緣和業(yè)務(wù)血緣的組合來提升發(fā)現(xiàn)問題的能力。
數(shù)據(jù)與業(yè)務(wù)血緣關(guān)系鏈構(gòu)建過程，覆蓋了數(shù)據(jù)服務(wù)交付的完整生命周期，通過采集每個(gè)交付節(jié)點(diǎn)的數(shù)據(jù)流向上下游關(guān)系，最終形成一張完整的血緣關(guān)系鏈。在數(shù)據(jù)交付過程中，主要通過統(tǒng)一血緣上報(bào)規(guī)范，并與數(shù)據(jù)開發(fā)流程深度集成，做到對(duì)數(shù)據(jù)開發(fā)流程無侵入性。在數(shù)據(jù)服務(wù)交付過程中，則主要利用服務(wù)網(wǎng)格技術(shù)，自動(dòng)采集微服務(wù)之間的服務(wù)調(diào)用鏈關(guān)系。
血緣關(guān)系構(gòu)建好后，可以應(yīng)用于血緣可視化檢索、影響面評(píng)估、故障回溯、根因分析、評(píng)估數(shù)據(jù)價(jià)值等很多方面，還可以結(jié)合云原生的其他特性，發(fā)揮出更大的作用。如結(jié)合云原生應(yīng)用監(jiān)控系統(tǒng)，在血緣關(guān)系鏈中疊加壓測(cè)指標(biāo)、服務(wù)負(fù)載等多維度分析，可以為資源容量評(píng)估提供準(zhǔn)確的依據(jù)，也可以分析出調(diào)用鏈上的瓶頸點(diǎn)在哪里，提供為某些非核心服務(wù)配置服務(wù)降級(jí)策略和限頻限流策略的依據(jù)，避免突發(fā)流量影響核心服務(wù)體驗(yàn)。
如下圖所示為一個(gè)典型的血緣應(yīng)用場(chǎng)景，當(dāng)運(yùn)營(yíng)人員收到告警馬上可以知曉，故障影響到哪些接口，哪些應(yīng)用，哪些項(xiàng)目，哪些指標(biāo)等。通過精準(zhǔn)的影響面評(píng)估，可以提早與業(yè)務(wù)側(cè)溝通相應(yīng)的應(yīng)急預(yù)案。
2.6 云原生環(huán)境下的混沌工程
混沌工程是一種在軟件或服務(wù)中進(jìn)行各種試驗(yàn)來驗(yàn)證系統(tǒng)穩(wěn)定性和健壯性的實(shí)驗(yàn)方法。Adrian Cockcroft給出了另一個(gè)定義則是：混沌工程是一種確保失敗所帶來的影響能夠被減少的實(shí)驗(yàn)。
在我們的微服務(wù)場(chǎng)景下，相對(duì)于單體應(yīng)用，服務(wù)鏈路更長(zhǎng)更復(fù)雜，任何一點(diǎn)的異常都可能影響全局服務(wù)，如何讓業(yè)務(wù)團(tuán)隊(duì)更加了解系統(tǒng)可靠性，對(duì)服務(wù)更有信心呢？我們需要混沌工程，來進(jìn)行有預(yù)期、有計(jì)劃的故障模擬，驗(yàn)證業(yè)務(wù)服務(wù)的健壯性，提早發(fā)現(xiàn)風(fēng)險(xiǎn)隱患和薄弱之處，并進(jìn)行修復(fù)，避免線上真正故障時(shí)手忙腳亂。當(dāng)然,業(yè)務(wù)集群上存在大量的服務(wù)，沒有目的性的隨意破壞，“爆炸半徑”失控，將影響整個(gè)業(yè)務(wù)集群，因此混沌工程需要經(jīng)過精心設(shè)計(jì)，在可控的環(huán)境中進(jìn)行。
目前我們已加入公司內(nèi)部混沌工程開源協(xié)同OTeam，搭建起第一版的混沌工程實(shí)驗(yàn)平臺(tái)，進(jìn)行實(shí)驗(yàn)設(shè)計(jì)，這里以云服務(wù)平臺(tái)，注入CPU負(fù)載實(shí)驗(yàn)測(cè)試。實(shí)驗(yàn)?zāi)繕?biāo)，可以包括云服務(wù)平臺(tái)和非云服務(wù)。
實(shí)驗(yàn)配置，即設(shè)計(jì)實(shí)驗(yàn)，當(dāng)前的原子包括cpu、內(nèi)存、io、狀態(tài)等，最后監(jiān)控配置，是可選項(xiàng)，我們直接使用集群本身的監(jiān)控視圖觀察。實(shí)驗(yàn)設(shè)計(jì)配置完成后，啟動(dòng)實(shí)驗(yàn)，觀察相關(guān)監(jiān)控視圖。
這里我們TKE集群中的服務(wù)設(shè)計(jì)了CPU負(fù)載注入演習(xí)，啟動(dòng)實(shí)驗(yàn)后，CPU按預(yù)期提升，當(dāng)CPU持續(xù)高負(fù)載時(shí)，服務(wù)正常且觸發(fā)自動(dòng)擴(kuò)容，無請(qǐng)求超時(shí)用戶無感知，符合預(yù)期，加深了團(tuán)隊(duì)對(duì)系統(tǒng)可靠性的理解和認(rèn)知。
2.7 Devops的持續(xù)集成與交付
一個(gè)穩(wěn)定運(yùn)營(yíng)的運(yùn)維體系必然有相應(yīng)的服務(wù)持續(xù)集成與交付方式與之配套，在云原生體系下我們構(gòu)建了基于Kubernets/Docker技術(shù)工具鏈的服務(wù)CI/CD工作流，同時(shí)最大力度支持公司現(xiàn)有CI/CD服務(wù)組件，從而實(shí)現(xiàn)服務(wù)的快速構(gòu)建、高效集成和部署交付。以下是CI/CD的整體流程圖：
2.7.1 數(shù)據(jù)營(yíng)銷開發(fā)者平臺(tái)-奇點(diǎn)（ODP）中CI的設(shè)計(jì)與實(shí)踐經(jīng)驗(yàn)
1）構(gòu)建鏡像
構(gòu)建鏡像是指業(yè)務(wù)代碼打包或者編譯打包所需的環(huán)境，包括編譯工具、編譯命令、編譯參數(shù)等部分，所有的構(gòu)建任務(wù)都是在使用構(gòu)建鏡像的容器內(nèi)完成的。是業(yè)務(wù)代碼變成制品的必須依賴。構(gòu)建的鏡像主要分為以下兩種類型：
·公共鏡像：奇點(diǎn)針對(duì)通用的場(chǎng)景，提供了一系列的公共鏡像，如 tlinux、go、php、nodejs等。
·自定義鏡像：某些業(yè)務(wù)服務(wù)構(gòu)建打包，有特殊的庫依賴或者環(huán)境依賴，已有的公共鏡像滿足不了業(yè)務(wù)需求，此時(shí)可以通過提交自定義構(gòu)建鏡像加入到編譯環(huán)境中選擇。
2）CI流水線引擎
目前支持公司已有的CI流水線引擎來配置流水線和執(zhí)行構(gòu)建任務(wù)(如藍(lán)盾、QCI、Orange CI)，也支持業(yè)界主流工具(如jenkins、Travis CI、jfrog)，通過“模板+參數(shù)化”的方式滿足業(yè)務(wù)服務(wù)編譯的需求場(chǎng)景。
3）CI任務(wù)觸發(fā)方式
目前CI任務(wù)觸發(fā)方式支持“人工觸發(fā)模式”、“自動(dòng)觸發(fā)模式”、“流水線模式”、“快速發(fā)布模式”等多種模式。
人工觸發(fā)模式：使用者可以在奇點(diǎn)的部署列表中選擇分支或tag以及構(gòu)建流水線（奇點(diǎn)支持同一服務(wù)配置多條流水線）自動(dòng)化完成構(gòu)建、部署。該方式可以靈活操作，如未修改代碼時(shí)，調(diào)整編譯命令重新驗(yàn)證可以通過人工觸發(fā)的方式來完成，如下圖所示:
自動(dòng)觸發(fā)模式：奇點(diǎn)服務(wù)創(chuàng)建時(shí)，需要關(guān)聯(lián)git地址或者創(chuàng)建全新的git項(xiàng)目，此時(shí)會(huì)自動(dòng)注冊(cè)webhook，監(jiān)聽push事件自動(dòng)觸發(fā)流水線構(gòu)建、部署或者快速發(fā)布到測(cè)試環(huán)境
流水線模式 ：跟人工觸發(fā)一樣，會(huì)自動(dòng)發(fā)起CI構(gòu)建任務(wù)和自動(dòng)部署測(cè)試環(huán)境
快速發(fā)布模式：快速發(fā)布流程如下圖所示，針對(duì)非編譯型服務(wù)，如PHP或者Python等服務(wù)，修改某個(gè)靜態(tài)文件或者腳本文件，無需重新執(zhí)行一遍流水線，將變更的文件下發(fā)到容器內(nèi)對(duì)應(yīng)位置，最快的速度方便開發(fā)同學(xué)調(diào)試和驗(yàn)證.對(duì)于編譯型的服務(wù)，也支持快速發(fā)布，前提條件是：編譯出的二進(jìn)制文件必須能在linux上運(yùn)行(例如golang的服務(wù)可在windows下交叉編譯為linux可執(zhí)行程序)，并配置好重啟命令即可( 任務(wù)發(fā)布時(shí)會(huì)自動(dòng)打包和下載解壓到容器內(nèi)，并且執(zhí)行指定的重啟命令 )。
2.7.2 奇點(diǎn)(ODP)中的CD設(shè)計(jì)與實(shí)踐經(jīng)驗(yàn)
1）可運(yùn)行多種鏡像
鏡像是服務(wù)運(yùn)行所依賴的環(huán)境，包括第三方庫以及操作系統(tǒng)版本。目前也支持公共運(yùn)行鏡像和業(yè)務(wù)自定義運(yùn)行鏡像，可以在集成配置頁面選擇運(yùn)行鏡像
2）支持修改/增加系統(tǒng)環(huán)境變量
服務(wù)編譯構(gòu)建時(shí)、服務(wù)啟動(dòng)時(shí)，需要根據(jù)當(dāng)前部署版本來做相應(yīng)的參數(shù)配置或者配置加載，此時(shí)需要通過環(huán)境變量來標(biāo)識(shí)。奇點(diǎn)中根據(jù)用戶自定義配置，生成yaml文件時(shí)會(huì)注入到container中;同時(shí)kubernetes自身的部分參數(shù)，也以環(huán)境變量的方式注入到container中，方便業(yè)務(wù)程序獲取pod自身信息，如POD名稱以及當(dāng)前POD的IP信息等。
3）支持自定義啟動(dòng)命令
支持自定義的業(yè)務(wù)進(jìn)程路徑、啟動(dòng)參數(shù)、啟動(dòng)前置處理等命令集合，為兼容啟動(dòng)參數(shù)中的特殊字符，會(huì)把啟動(dòng)命令中寫入到shell腳本然后執(zhí)行。另外，啟動(dòng)命令必須確保拉起的進(jìn)程是常駐進(jìn)程以及前臺(tái)模式。
4）健康檢查
健康檢查對(duì)線上業(yè)務(wù)來說，是保證服務(wù)的正常、穩(wěn)定運(yùn)行的重要手段。Kubernetes提供了以探針為主的健康檢查方式，對(duì)于故障服務(wù)會(huì)被及時(shí)自動(dòng)下線，通過重啟服務(wù)的方式嘗試使服務(wù)自動(dòng)恢復(fù)。目前主要支持以下兩種方式：
Liveness探針：用于判斷Container是否處于運(yùn)行狀態(tài)，非running狀態(tài)，kubelet會(huì)kill掉Container, 然后根據(jù)其設(shè)置的restart policy進(jìn)行相應(yīng)操作。
Readness探針: 用于判斷服務(wù)是否已經(jīng)ready，對(duì)外提供服務(wù)，如果檢測(cè)未通過，服務(wù)所在的Pod的IP地址會(huì)從服務(wù)的endpoints中被移除，不會(huì)接受或響應(yīng)任何請(qǐng)求。
此外，奇點(diǎn)中支持用戶定義健康檢查規(guī)則，這樣會(huì)自動(dòng)生成對(duì)應(yīng)的Liveness和Readness配置。
5）服務(wù)部署
使用CI流水線的方式構(gòu)建和部署，推薦基于tag來部署（可溯源）。
四、業(yè)務(wù)上云收益
從自研上云開始，我們就確定了云原生的上云方案，經(jīng)過持續(xù)迭代，已經(jīng)建立了一套比較完整的云原生運(yùn)維體系，王者榮耀、和平精英等全部游戲的數(shù)據(jù)運(yùn)營(yíng)活動(dòng)已經(jīng)All IN 云原生。云原生的效能優(yōu)勢(shì)和技術(shù)紅利不斷釋放出來，我們實(shí)現(xiàn)了低成本、高效率構(gòu)建支持高并發(fā)場(chǎng)景的在線服務(wù)，又快又穩(wěn)的支撐游戲運(yùn)營(yíng)活動(dòng)。
1、成本方面
騰訊云產(chǎn)品開箱即用，對(duì)于一些創(chuàng)新業(yè)務(wù)想做技術(shù)調(diào)研非常方便，用完即銷毀，成本很低。另外云產(chǎn)品都是免運(yùn)維自行托管在云端，如TKE的Master和etcd都是托管騰訊云，可以節(jié)省人工運(yùn)維成本，讓我們更專注于做核心業(yè)務(wù)。
2、穩(wěn)定性方面
云原生上云后，服務(wù)獲得了快速擴(kuò)容、彈性伸縮的能力，抗壓能力增強(qiáng)，讓我們可以更加從容面對(duì)各種突發(fā)流量，機(jī)器故障后TKE自動(dòng)遷移Pod讓服務(wù)獲得故障自愈的能力。此外，TKE將各類資源定義成描述文件，整個(gè)應(yīng)用環(huán)境通過容器的方式統(tǒng)一，避免了環(huán)境不一致的風(fēng)險(xiǎn)。
3、效率方面
借助跟云產(chǎn)品的深度集成，方便開發(fā)人員完成一站式研發(fā)、運(yùn)維工作。從業(yè)務(wù)需求立項(xiàng)到拉分支開發(fā)，再到測(cè)試環(huán)境功能回歸驗(yàn)證，再部署到預(yù)發(fā)驗(yàn)證及最后上線，整個(gè)持續(xù)集成可以做到分鐘級(jí)。相較于傳統(tǒng)DO分離的運(yùn)營(yíng)模式，發(fā)布耗時(shí)從小時(shí)級(jí)縮短到分鐘級(jí)，效率提升數(shù)倍。日常工作包括擴(kuò)縮容、單機(jī)故障處理、機(jī)房裁撤等被降維簡(jiǎn)化，運(yùn)維變得更加簡(jiǎn)單可信賴。
4、賦能業(yè)務(wù)
云上產(chǎn)品非常多，涵蓋了計(jì)算、存儲(chǔ)、大數(shù)據(jù)等諸多領(lǐng)域，可以節(jié)省業(yè)務(wù)創(chuàng)新帶來的技術(shù)成本。我們?cè)谟玫陌═KE、CFS、COS、CKafka、VOD等20多個(gè)產(chǎn)品都是直接開箱即用，分鐘級(jí)交付，極大的方便了業(yè)務(wù)新需求的調(diào)研和上線。
五、總結(jié)
云原生給運(yùn)維體系帶來的是挑戰(zhàn)更是機(jī)遇，如何在這波云計(jì)算浪潮中，尋找運(yùn)維的定位與價(jià)值，我想是每一位運(yùn)維人應(yīng)該思考的問題。本文是個(gè)人近幾年的所見、所聞、所思做個(gè)小結(jié)，提出的觀點(diǎn)不一定正確，希望能給大家多一個(gè)思考的方向，也歡迎批評(píng)指正。最后，也將我們的轉(zhuǎn)型思路、方法與實(shí)踐分享于此，提供給后面更多面臨同樣挑戰(zhàn)的團(tuán)隊(duì)借鑒與參考。我們的轉(zhuǎn)型之路還在路上，未來我們將繼續(xù)扎根業(yè)務(wù)，深耕云原生環(huán)境運(yùn)維，通過數(shù)據(jù)、編排、DevOps、AiOps等能力，進(jìn)一步提升服務(wù)水平與用戶體驗(yàn)。
作者簡(jiǎn)介：劉天斯，負(fù)責(zé)騰訊游戲大數(shù)據(jù)管理及運(yùn)維工作，從事互聯(lián)網(wǎng)技術(shù)運(yùn)營(yíng)工作近15年，曾榮獲“華章最有價(jià)值作者”、“中國(guó)十大杰出IT博主”、“WOT十大優(yōu)秀講師”、“OpsWorld金牌講師”、“TOP100優(yōu)秀出品人”、 “中國(guó)數(shù)據(jù)質(zhì)量杰出專家獎(jiǎng)（2020）”、“DAMA中國(guó)數(shù)據(jù)治理專家獎(jiǎng)（2020）”，IEEE與DAMA會(huì)員。曾參與國(guó)家《數(shù)據(jù)資產(chǎn)管理實(shí)踐白皮書》、《數(shù)據(jù)標(biāo)準(zhǔn)管理白皮書》等多個(gè)標(biāo)準(zhǔn)的編寫。熱衷開源技術(shù)的研究，包括大數(shù)據(jù)資產(chǎn)管理及云原生等領(lǐng)域，擅長(zhǎng)大數(shù)據(jù)治理，數(shù)據(jù)與業(yè)務(wù)中臺(tái)建設(shè)、海量運(yùn)維與規(guī)劃等工作，曾出版?zhèn)€人著作《python自動(dòng)化運(yùn)維：技術(shù)與實(shí)踐》、《循序漸進(jìn)學(xué)Docker》等，個(gè)人發(fā)明專利10個(gè)。
