來源：騰訊技術(shù)工程微信號
作者：騰訊技術(shù)工程

前言

隨著公司自研上云戰(zhàn)略如火如荼地進行，IEG-增值服務(wù)部作為較早一批響應(yīng)的團隊，截止目前自研上云已完成1/3的流量切換，日PV超百億。切云的服務(wù)大量采用了云原生的應(yīng)用與技術(shù)架構(gòu)，作為公司第一批面臨云原生環(huán)境的業(yè)務(wù)運維，深切感受到云原生給運維工作帶來的機遇與挑戰(zhàn)，運維模式的轉(zhuǎn)型已經(jīng)迫在眉睫，此篇文章最大的價值在于將我們的轉(zhuǎn)型思路、方法與實踐，提供給后面更多面臨同樣挑戰(zhàn)的團隊借鑒與參考。下面我將從業(yè)務(wù)場景、運維轉(zhuǎn)型之道、云端收益等幾個方面來跟大家一起來探討。

一、業(yè)務(wù)服務(wù)場景介紹

DataMore是IEG增值服務(wù)部為游戲項目組提供的一站式智能游戲運營方案平臺，基于游戲日志數(shù)據(jù)，利用實時與離線計算打造數(shù)據(jù)營銷能力，為業(yè)務(wù)提供以解決運營問題為目標(biāo)的數(shù)據(jù)運營服務(wù)方案。與傳統(tǒng)的游戲運營體系不同，DataMore游戲數(shù)據(jù)運營平臺具有脫離游戲版本，對研發(fā)側(cè)依賴小，計算能力與精細(xì)化運營能力強的特點，可以為游戲業(yè)務(wù)帶來更低成本、更快速高效的精細(xì)化運營，并提供豐富的游戲運營方案。DataMore在各個生命周期，多種游戲品類上沉淀了許多運營方案以及工程化的運營系統(tǒng)，覆蓋新進、活躍、流失、留存、付費和傳播等多個階段，包括邀請好友、任務(wù)中心、砍價拼團、低活躍干預(yù)、流失召回等多種數(shù)據(jù)運營方案，使得游戲業(yè)務(wù)可以快捷的找到適合自身游戲階段、針對特定運營問題的解決方案。部分方案截圖：

DataMore在技術(shù)架構(gòu)上采用了微服務(wù)設(shè)計的理念，采用服務(wù)型開發(fā)架構(gòu)，將數(shù)據(jù)營銷服務(wù)拆分成獨立、通用的服務(wù)能力，同時構(gòu)建了應(yīng)用和服務(wù)中臺，能夠通過組合這些通用服務(wù)快速而輕松的構(gòu)建專屬應(yīng)用服務(wù)。DataMore活動覆蓋了互娛幾乎所有的游戲，落地場景非常多，每天都有新活動上線，而且周期短，節(jié)奏快，活動周期一般只持續(xù)一兩周，日PV超過200億，QPS峰值超過20+萬，落地場景覆蓋王者榮耀、和平精英在內(nèi)的所有游戲及周邊應(yīng)用（如助手、微信游戲中心等）。

二、基于云原生環(huán)境開發(fā)者平臺

相信大家對云原生的概念已經(jīng)不陌生，但很難精準(zhǔn)地去解釋云原生具體是個什么東西，原因是云原生沒有很確切的定義，且不斷在發(fā)展演變當(dāng)中。Pivotal 公司的 Matt Stine 于2013年首次提出云原生（CloudNative）的概念，旨在說明云原生是一種構(gòu)建和運行應(yīng)用程序的方法，是一套技術(shù)體系和方法論。2015年云原生計算基金會（CNCF），對云原生的定義為：“云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運行可彈性擴展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格（Service Mesh）、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段，云原生技術(shù)使工程師能夠輕松地對系統(tǒng)作出頻繁和可預(yù)測的重大變更。”。目前形成云原生理解上的最大共識概括為4個核心要點：DevOps+持續(xù)交付+微服務(wù)+容器，即基于這"4件套"構(gòu)建的應(yīng)用我們暫且認(rèn)為就是云原生應(yīng)用了。同時可以享受到云端極為豐富的PaaS組件，如業(yè)務(wù)后續(xù)使用到的數(shù)據(jù)庫、緩存、中間件、存儲、CDN等等，并且具備無縫在不同云廠商間透明遷移的能力。

為適配云原生環(huán)境的數(shù)據(jù)營銷服務(wù)的需求，部門推出了奇點（ODP）平臺（基于騰訊游戲數(shù)據(jù)&營銷服務(wù)能力，以微服務(wù)架構(gòu)為基礎(chǔ)，構(gòu)建的集代碼管理、服務(wù)開發(fā)、運維發(fā)布、服務(wù)運營為一體的一站式開發(fā)運營平臺）實現(xiàn)了真正意義上的DevOps服務(wù)閉環(huán)，貫穿了服務(wù)交付的CI、CD、CO環(huán)節(jié)，得益于公司內(nèi)外部更多優(yōu)秀組件的集成，包括TKE、藍盾、QCI、Envoy等。

三、云原生運維轉(zhuǎn)型、挑戰(zhàn)、目標(biāo)與實踐

1、云原生運維轉(zhuǎn)型思維

這幾年運維界聽到最多的幾句話：“云計算會淘汰掉運維！整個運維行業(yè)可能被干掉！再不轉(zhuǎn)換運維就要丟飯碗”，諸如此類。那真相到底是什么？行業(yè)有一個共識，即運維工作本身交付的是一種服務(wù)，下面舉一個可能不太恰當(dāng)?shù)睦樱蛘呖梢詭椭蠹艺业酱鸢浮?/p>

云計算時代好比組裝一輛汽車，根據(jù)客戶的需要，通過PaaS能力選擇匹配的引擎、車輪、離合器、 懸架、車控制系統(tǒng)等進行拼裝?？蛻舨挥藐P(guān)心汽車各元部件的實現(xiàn)原理，最終獲得是一輛滿足自身要求的汽車。光有了汽車是玩不轉(zhuǎn)的。還需要有修路、加油站、交通控制等服務(wù)體系，運維就是承擔(dān)這個角色。相比傳統(tǒng)運維，確實是少了自己采購元組與組裝的工作。到了后云計算時代（云原生），出現(xiàn)了一個DevOps公司，引入新技術(shù)與理念，聲稱已經(jīng)將修路、加油站、交通控制等環(huán)節(jié)都打通了，形成了一體化服務(wù)能力，并邀請運維哥一起加入創(chuàng)業(yè)。在這個階段，運維哥出去單干，大概率會翻車。但加入DevOps公司，運維的價值到底還有什么呢？因此，升級與轉(zhuǎn)型是必然的，例如將普通國道升級成高速公路；實現(xiàn)客戶在高速路上不停車換輪胎；貼近并理解客戶，規(guī)劃行程中所需的服務(wù)來提升客戶體驗；通過提升智能化水平，連接交通管制，縮短航程，避開損壞路段等等。相信大家心中已經(jīng)有自己答案了?；氐皆c的靈魂拷問：“云原生背景下，運維不做轉(zhuǎn)型會不會死？”，”運維要如何快速自救和升級？“。

我的觀點：

1）不會死，但未來整條價值交付鏈沒有你什么事了；

2）轉(zhuǎn)型SRE是一種選擇。

接下來介紹我們運維體系是如何進行轉(zhuǎn)型升級的，首先我們的轉(zhuǎn)型理論基礎(chǔ)來源于DevOps框架，從中抽取出符合現(xiàn)階段服務(wù)場景要求的模型，從文化與技術(shù)兩大方向反復(fù)去實踐與論證，也獲取了非常好的效果。下圖是Gartner于2015年發(fā)布的DevOps實踐模型，放在2020年的今天來看，確實具有很強的前瞻性，不少觀點經(jīng)過我們的驗證是正確的，例如：Feature Teams(特性團隊)、Developer Self-Service(開發(fā)者自助服務(wù))、Infrastructure as Code(基礎(chǔ)設(shè)施即代碼)、Integrated Tool Chains(集成工具鏈,CI-CT-CO)、One-Step Build, Test, Deploy(一鍵程序構(gòu)建，測試，部署)等等。下面從文化與技術(shù)兩個層面來剖析：

1）文化層面

以下幾點是我們中心內(nèi)部實行的幾個機制，供作參考，因不同團隊間存在一定差異，此處不展開說明。

• 開發(fā)與運維成立FT虛擬團隊，實現(xiàn)組織上的融合；
• 開發(fā)或運維側(cè)的例會、技術(shù)分享、事件復(fù)盤，F(xiàn)T成員全程參與；
• 項目立項時，運維接口人需要做“左移”，即提前參與技術(shù)架構(gòu)討論，有助于運維的問題提前在方案討論或開發(fā)階段提前暴露，有效做好防范與規(guī)避；
• 建立收集各方反饋問題與建議的機制與渠道，有效將好的想法影響至平臺下個版本的迭代中，實現(xiàn)持續(xù)改進與優(yōu)化。

2）技術(shù)層面

下圖是個人繪制的傳統(tǒng)運維到云原生運維的價值過渡，很明顯的一個特性是往更高階領(lǐng)域去涉足，傳統(tǒng)運維投入將大幅度減弱。目標(biāo)意指將更貼近業(yè)務(wù)、理解業(yè)務(wù)、通過數(shù)據(jù)與AI的能力，提升業(yè)務(wù)持續(xù)服務(wù)的能力及用戶體驗，同時確保整個價值交付鏈的暢通與高效。

在云原生背景下，我們對運維體系進行了升級，在原有基礎(chǔ)運維能力之上確定了以下幾個目標(biāo)：

• 具備服務(wù)全鏈路質(zhì)量監(jiān)控覆蓋，涵蓋數(shù)據(jù)域與業(yè)務(wù)域
• 具備一定智能化的資源動態(tài)調(diào)度、伸縮機制
• 具備一定的故障預(yù)警、根因分析、問題定位能力
• 服務(wù)具備在交付不同階段（測試、預(yù)發(fā)布、運營）抵御異常的能力
• 具備資源高效交付的流程機制與快速上線的能力
• 具備多云的資源編排與管理的能力
• 具備業(yè)務(wù)快速上云的機制，確保切換過程的高可用性

確定了運維能力升級指導(dǎo)思想：基于運維編排的云原生實例化。廣義而言，運維的本質(zhì)就是多個運營事件的有機串聯(lián)，來達到質(zhì)量、效率、成本、安全多維收益，而編排是實現(xiàn)有機串聯(lián)的有效手段，除了可以沉淀運維經(jīng)驗外，還可以有效實現(xiàn)共享。

2、云原生運維轉(zhuǎn)型平臺化建設(shè)

在運維平臺化建設(shè)方面，我們在構(gòu)建原云生運維平臺能力–玄圖。積極擁抱公司開源協(xié)同的機制，通過集成現(xiàn)有優(yōu)秀平臺或組件，如有河圖元數(shù)據(jù)管理平臺（CMDB）、藍鯨標(biāo)準(zhǔn)運維平臺、PCG-混沌工程實驗平臺、藍鯨服務(wù)流程管理平臺等等，避免重復(fù)性建設(shè)，結(jié)合我們的服務(wù)場景，發(fā)揮平臺服務(wù)效能最大化。思路上借鑒了“瑞士軍刀”，我們通過微服務(wù)的架構(gòu)，將云資產(chǎn)（CMDB）管理作為底座，也就是“刀把”。再將剪刀、平口刀、開罐器、螺絲起子、鑷子等等集成進來，通過定義資源與上層平臺的總線協(xié)議，將各類平臺工具進行組裝，猶如瑞士軍刀一樣，將輕、快、實用、因地制宜發(fā)揮到極致。下面將我們的體系能力進行介紹：

2.1 云原生資產(chǎn)管理

公有云/私有云的各類云資源管理，我們叫做資產(chǎn)管理（所有的資源/應(yīng)用/數(shù)據(jù)都在資產(chǎn)范疇）。我們知道，傳統(tǒng)的大多數(shù)cmdb只能管理服務(wù)器信息（如ip地址/機架/機房等），在云原生環(huán)境下，我們將面對復(fù)雜多變的、新生的應(yīng)用和場景，隨之會產(chǎn)生越來越多的管理配置項，這就要求資產(chǎn)管理能夠滿足各種需求的擴展和未來業(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)用場景落地，通過元數(shù)據(jù)定義資產(chǎn)管理的模型、屬性、組合關(guān)系，玄圖對元數(shù)據(jù)的加工、應(yīng)用實現(xiàn)通用的可靈活調(diào)整的業(yè)務(wù)級資產(chǎn)管理。

在我們常見的kafka集群資產(chǎn)管理的場景下，通過河圖元數(shù)據(jù)定義相關(guān)的集群、主機模型以及屬性，定義他們的組合關(guān)系，達到資產(chǎn)管理的要求。

模型代表著一類云資源，模型的屬性從各個方面分別描述這一類云資源，模型的屬性可以根據(jù)場景自由定義和擴展。集群模型，當(dāng)前的屬性包括集群名、cc/_set等，主機模型，當(dāng)前的屬性包括ip、類型、區(qū)域等，隨著業(yè)務(wù)不斷發(fā)展變化，我們后續(xù)可能會對集群和主機的信息進行不斷的擴展，也可能集群下還要管理如CLB等其他類型的云資源信息，采用云資源管理，能很好地適應(yīng)這種變化。

遵循MOF元對象設(shè)施建設(shè)標(biāo)準(zhǔn)規(guī)范為基礎(chǔ)的云資源管理平臺，能自由方便地表示所有模型間的關(guān)系，包括組合關(guān)系、依賴關(guān)系和繼承關(guān)系。組合關(guān)系描述了一種組成關(guān)系，代表某個模型由另外的模型組成，依賴關(guān)系主要用于管理模型之間的依賴，繼承關(guān)系則可以用來表示一種父子關(guān)系。kafka集群和主機的關(guān)系我們就可以用組合關(guān)系來表示，集群依賴的業(yè)務(wù)可以用依賴關(guān)系來表示，也可 以定義一個主機模型的父類，再派生出不同的子類代表不同的主機類型，但具有父類公共的屬性定義。

資產(chǎn)管理的數(shù)據(jù)將直接存儲在河圖元數(shù)據(jù)系統(tǒng)中，玄圖平臺在保留元數(shù)據(jù)管理靈活自定義的前提下，簡化元數(shù)據(jù)操作管理，適配資產(chǎn)管理的需求，提供高效的查詢、檢索、變更的能力，以有效管理云資產(chǎn)。

2.2 云端一切操作皆可編排

云原生環(huán)境下，運維面臨各種不同的公有云/私有云環(huán)境和各種跨云/跨平臺的操作，給運維操作管理帶來了巨大挑戰(zhàn)。因此，我們繼續(xù)構(gòu)建云原生環(huán)境的編排能力，即運維編排，通過開發(fā)、封裝可編排的組件和插件，提供靈活、可定制、可管理的模板化運維能力，覆蓋運維任務(wù)的管理、審批、決策、執(zhí)行、通知等功能，最終實現(xiàn)自動化、智能化運維。

我們將運維編排分為三層，即：基礎(chǔ)設(shè)施層、容器服務(wù)層、應(yīng)用層。

如上圖所示：

• 云資源編排，編排對象是各類云資源，包括公有云、私有云等，采用terraform來實現(xiàn)多云基礎(chǔ)設(shè)施的編排，可以覆蓋騰訊云、阿里云、AWS、私有云等等。
• kubernetes編排，編排對象是k8s集群資源，采用Helm/YAML進行編排。
• 作業(yè)編排，編排對象主要是主機節(jié)點，對應(yīng)的操作任務(wù)編排，調(diào)用現(xiàn)有的藍鯨job作業(yè)平臺。

運維編排三層之間如何串聯(lián)？我們采用了開源的藍鯨標(biāo)準(zhǔn)運維作為編排引擎，將不同的三層編排串聯(lián)，打破從前跨云、跨平臺各種割裂的操作界限，提升運維效率，一切皆編排，并能將編排任務(wù)沉淀為能力模板傳承交接。

例如上圖的場景，我們需要擴容一個現(xiàn)網(wǎng)的TKE業(yè)務(wù)集群，從基礎(chǔ)設(shè)施層的資源采買，到容器服務(wù)初始化部署，和一些集群特性作業(yè)操作等均一站式運維編排完成，操作時長從4小時優(yōu)化到30分鐘內(nèi)，而且集群再次擴容只需簡單修改幾個編排參數(shù)執(zhí)行，避免了繁瑣重復(fù)的操作。在玄圖平臺能力中將通過自助開發(fā)可編排的原子（包括操作、接口、算法等），一切操作皆編排。

2.3 DataOps助力運維轉(zhuǎn)型

2.3.1 TKE資源動態(tài)調(diào)度
K8S的特性是資源一旦分配給工作負(fù)載，就會被獨占，即使是空跑狀態(tài)，其他工作負(fù)載也不能復(fù)用。一般來說用戶申請的資源會遠(yuǎn)超實際需求，Pod規(guī)格和副本數(shù)設(shè)置很大，或者HPA最小副本數(shù)設(shè)置很高，并且不會主動去釋放資源。這樣會導(dǎo)致K8S集群存在大量的空閑資源，集群的總體資源使用率不高。為了解決這個問題，我們需要主動對工作負(fù)載做資源動態(tài)調(diào)度。

如下圖所示，預(yù)測模型通過TKE自帶的hpa-metrics-server拿到workload當(dāng)前使用的CPU核數(shù)并落地DB，通過API-Server拿到workload當(dāng)前分配的CPU核數(shù)。調(diào)度器Scheduler根據(jù)預(yù)測模型的預(yù)測值動態(tài)調(diào)整workload的副本數(shù)。

動態(tài)調(diào)度模型使用過去一個時間周期內(nèi)同一時間點的負(fù)載數(shù)據(jù)擬合得到CPU核數(shù)預(yù)測值，為了保證資源充足，模型會根據(jù)當(dāng)前實際使用的CPU核數(shù)再預(yù)留一倍的冗余，并且至少保留一個副本，結(jié)合目前已經(jīng)分配的核數(shù)得到最終預(yù)估分配核數(shù)。最后，調(diào)度器根據(jù)模型的預(yù)估分配核數(shù)動態(tài)修改workload的副本數(shù)，釋放空閑資源。

執(zhí)行資源動態(tài)調(diào)度后收益非常明顯，集群空閑資源被釋放出來，可以承載更多的workload，在總核數(shù)為1萬核的集群實踐，可以釋放一半的空閑CPU，集群整體CPU利用率從15%提升到28%。

2.3.2 TBDS資源動態(tài)調(diào)度
經(jīng)過統(tǒng)計我們發(fā)現(xiàn)騰訊云TBDS數(shù)據(jù)倉庫集群CPU的總體使用率僅為55%左右。如下圖所示，藍色線是分配的資源，綠色線是使用的資源，大部分應(yīng)用組資源池，存在空閑時間段，而且相互錯峰的情況。我們累計有500+個應(yīng)用組，抽取幾個大應(yīng)用組統(tǒng)計其繁忙時間段，發(fā)現(xiàn)存在明顯的錯峰情況。

為了進一步提升資源使用率，需要對資源做動態(tài)分配，簡單的說，當(dāng)資源使用少的時候，就少分配些，當(dāng)資源使用多的使用，就分配多些，分配使用動態(tài)調(diào)整。動態(tài)分配算法模型，大體上分兩步，第一步，先計算出每個應(yīng)用組的預(yù)估分配核數(shù)。因為總分配核數(shù)一定，所以還需第二步根據(jù)預(yù)估分配核數(shù)的占比情況算實際分配核數(shù)。

預(yù)估分配核數(shù)怎么算呢？首先，pt0是基線，目前用線性回歸來擬合，但擬合的結(jié)果會波動很大，所以根據(jù)實際的任務(wù)要求，根據(jù)當(dāng)前的資源使用核數(shù)，給擬合結(jié)果設(shè)置了下限，又根據(jù)應(yīng)用組總資源池不能過大實際要求，跟擬合值設(shè)置了上限。所以，分配模型的特點有動態(tài)的上下限，另外，這里給當(dāng)前的使用值翻倍預(yù)估，目的是當(dāng)任務(wù)需要資源時，分配的資源可得到快速增長，從而不會影響任務(wù)的執(zhí)行，特別是大任務(wù)。

執(zhí)行動態(tài)調(diào)度后收益非常明顯，集群資源利用率從55.4%提升到79.5%。從動態(tài)分配前后的對比圖可以看到，總成本降低了1/3。其次是任務(wù)執(zhí)行效率也有提高，經(jīng)過對4000+個分析計算任務(wù)的執(zhí)行統(tǒng)計，平均執(zhí)行時間從27.5分鐘降低到18.1分鐘，執(zhí)行效率提升52%。

2.4 云原生應(yīng)用監(jiān)控

服務(wù)正式上線之后，我們需要掌握其運營狀況，比如QPS、成功率、響應(yīng)延遲、容量負(fù)載水位等指標(biāo)。一般是通過代碼埋點輸出日志，然后統(tǒng)計日志獲得，或者是程序主動上報網(wǎng)管系統(tǒng)獲得，不管是哪種方式成本都不低。

我們需要在TKE集群部署Prometheus主動采集workload負(fù)載指標(biāo)和用戶自定義指標(biāo)，隨著集群規(guī)模不斷擴大，Promethues不支持容災(zāi)部署，不支持分布式，單實例容量瓶頸等問題也凸顯出來，最后我們放棄了原生的Prometheus，轉(zhuǎn)而使用Thanos（滅霸）實現(xiàn)了分布式、高可用容災(zāi)部署和數(shù)據(jù)長期存儲。

Thanos Query 可以對數(shù)據(jù)進行聚合與去重，所以可以很輕松實現(xiàn)高可用：相同的 Prometheus 部署多個副本(都附帶 Sidecar)，然后 Thanos Query 去所有 Sidecar 查數(shù)據(jù)，即便有一個 Prometheus 實例掛掉過一段時間，數(shù)據(jù)聚合與去重后仍然能得到完整數(shù)據(jù)。

Thanos支持將數(shù)據(jù)上傳到各種對象存儲（比如COS）以供長期保存 (Prometheus TSDB 數(shù)據(jù)格式)，對于需要長期存儲的數(shù)據(jù)，并且使用頻率不那么高，最理想的方式是存進對象存儲，不限制容量，價格非常便宜。

基于Thanos，我們業(yè)務(wù)平臺實現(xiàn)了高并發(fā)、海量的數(shù)據(jù)采集上報和存儲。首先，因為所有流量都會經(jīng)過網(wǎng)關(guān)，Thanos主動采集網(wǎng)關(guān)的這些指標(biāo)到并將其可視化。如下圖所示，只要服務(wù)接入了業(yè)務(wù)平臺， QPS、耗時、成功率等一目了然，這些指標(biāo)都無需額外開發(fā)即自動獲得，對代碼0侵入，節(jié)省了大量的開發(fā)成本。

同時，業(yè)務(wù)平臺也會使用Thanos主動采集負(fù)載指標(biāo)生成服務(wù)容量負(fù)載水位視圖，包括CPU，內(nèi)存，流量等，如下圖所示。

如果服務(wù)有額外的指標(biāo)也可以通過平臺的自定義指標(biāo)采集上報到Thanos，并用Grafana繪制圖表。接入平臺后，服務(wù)運行、負(fù)載等運營指標(biāo)全部自動可視化，節(jié)省了開發(fā)成本，提升了開發(fā)和運營效率。

2.5 云原生業(yè)務(wù)全鏈路跟蹤（血緣關(guān)系鏈）

隨著業(yè)務(wù)的不斷縱深發(fā)展，技術(shù)服務(wù)鏈條也隨之拉長，導(dǎo)致出現(xiàn)異常時定位問題困難，且無法快速評估影響面，因此我們通過構(gòu)建數(shù)據(jù)血緣和業(yè)務(wù)血緣的組合來提升發(fā)現(xiàn)問題的能力。
數(shù)據(jù)與業(yè)務(wù)血緣關(guān)系鏈構(gòu)建過程，覆蓋了數(shù)據(jù)服務(wù)交付的完整生命周期，通過采集每個交付節(jié)點的數(shù)據(jù)流向上下游關(guān)系，最終形成一張完整的血緣關(guān)系鏈。在數(shù)據(jù)交付過程中，主要通過統(tǒng)一血緣上報規(guī)范，并與數(shù)據(jù)開發(fā)流程深度集成，做到對數(shù)據(jù)開發(fā)流程無侵入性。在數(shù)據(jù)服務(wù)交付過程中，則主要利用服務(wù)網(wǎng)格技術(shù)，自動采集微服務(wù)之間的服務(wù)調(diào)用鏈關(guān)系。

血緣關(guān)系構(gòu)建好后，可以應(yīng)用于血緣可視化檢索、影響面評估、故障回溯、根因分析、評估數(shù)據(jù)價值等很多方面，還可以結(jié)合云原生的其他特性，發(fā)揮出更大的作用。如結(jié)合云原生應(yīng)用監(jiān)控系統(tǒng)，在血緣關(guān)系鏈中疊加壓測指標(biāo)、服務(wù)負(fù)載等多維度分析，可以為資源容量評估提供準(zhǔn)確的依據(jù)，也可以分析出調(diào)用鏈上的瓶頸點在哪里，提供為某些非核心服務(wù)配置服務(wù)降級策略和限頻限流策略的依據(jù)，避免突發(fā)流量影響核心服務(wù)體驗。
如下圖所示為一個典型的血緣應(yīng)用場景，當(dāng)運營人員收到告警馬上可以知曉，故障影響到哪些接口，哪些應(yīng)用，哪些項目，哪些指標(biāo)等。通過精準(zhǔn)的影響面評估，可以提早與業(yè)務(wù)側(cè)溝通相應(yīng)的應(yīng)急預(yù)案。

2.6 云原生環(huán)境下的混沌工程

混沌工程是一種在軟件或服務(wù)中進行各種試驗來驗證系統(tǒng)穩(wěn)定性和健壯性的實驗方法。Adrian Cockcroft給出了另一個定義則是：混沌工程是一種確保失敗所帶來的影響能夠被減少的實驗。
在我們的微服務(wù)場景下，相對于單體應(yīng)用，服務(wù)鏈路更長更復(fù)雜，任何一點的異常都可能影響全局服務(wù)，如何讓業(yè)務(wù)團隊更加了解系統(tǒng)可靠性，對服務(wù)更有信心呢？我們需要混沌工程，來進行有預(yù)期、有計劃的故障模擬，驗證業(yè)務(wù)服務(wù)的健壯性，提早發(fā)現(xiàn)風(fēng)險隱患和薄弱之處，并進行修復(fù)，避免線上真正故障時手忙腳亂。當(dāng)然,業(yè)務(wù)集群上存在大量的服務(wù)，沒有目的性的隨意破壞，“爆炸半徑”失控，將影響整個業(yè)務(wù)集群，因此混沌工程需要經(jīng)過精心設(shè)計，在可控的環(huán)境中進行。
目前我們已加入公司內(nèi)部混沌工程開源協(xié)同OTeam，搭建起第一版的混沌工程實驗平臺，進行實驗設(shè)計，這里以云服務(wù)平臺，注入CPU負(fù)載實驗測試。實驗?zāi)繕?biāo)，可以包括云服務(wù)平臺和非云服務(wù)。

實驗配置，即設(shè)計實驗，當(dāng)前的原子包括cpu、內(nèi)存、io、狀態(tài)等，最后監(jiān)控配置，是可選項，我們直接使用集群本身的監(jiān)控視圖觀察。實驗設(shè)計配置完成后，啟動實驗，觀察相關(guān)監(jiān)控視圖。

這里我們TKE集群中的服務(wù)設(shè)計了CPU負(fù)載注入演習(xí)，啟動實驗后，CPU按預(yù)期提升，當(dāng)CPU持續(xù)高負(fù)載時，服務(wù)正常且觸發(fā)自動擴容，無請求超時用戶無感知，符合預(yù)期，加深了團隊對系統(tǒng)可靠性的理解和認(rèn)知。

2.7 Devops的持續(xù)集成與交付

一個穩(wěn)定運營的運維體系必然有相應(yīng)的服務(wù)持續(xù)集成與交付方式與之配套，在云原生體系下我們構(gòu)建了基于Kubernets/Docker技術(shù)工具鏈的服務(wù)CI/CD工作流，同時最大力度支持公司現(xiàn)有CI/CD服務(wù)組件，從而實現(xiàn)服務(wù)的快速構(gòu)建、高效集成和部署交付。以下是CI/CD的整體流程圖：

2.7.1 數(shù)據(jù)營銷開發(fā)者平臺-奇點（ODP）中CI的設(shè)計與實踐經(jīng)驗

1）構(gòu)建鏡像

構(gòu)建鏡像是指業(yè)務(wù)代碼打包或者編譯打包所需的環(huán)境，包括編譯工具、編譯命令、編譯參數(shù)等部分，所有的構(gòu)建任務(wù)都是在使用構(gòu)建鏡像的容器內(nèi)完成的。是業(yè)務(wù)代碼變成制品的必須依賴。構(gòu)建的鏡像主要分為以下兩種類型：

·公共鏡像：奇點針對通用的場景，提供了一系列的公共鏡像，如 tlinux、go、php、nodejs等。

·自定義鏡像：某些業(yè)務(wù)服務(wù)構(gòu)建打包，有特殊的庫依賴或者環(huán)境依賴，已有的公共鏡像滿足不了業(yè)務(wù)需求，此時可以通過提交自定義構(gòu)建鏡像加入到編譯環(huán)境中選擇。

2）CI流水線引擎
目前支持公司已有的CI流水線引擎來配置流水線和執(zhí)行構(gòu)建任務(wù)(如藍盾、QCI、Orange CI)，也支持業(yè)界主流工具(如jenkins、Travis CI、jfrog)，通過“模板+參數(shù)化”的方式滿足業(yè)務(wù)服務(wù)編譯的需求場景。

3）CI任務(wù)觸發(fā)方式
目前CI任務(wù)觸發(fā)方式支持“人工觸發(fā)模式”、“自動觸發(fā)模式”、“流水線模式”、“快速發(fā)布模式”等多種模式。

• 人工觸發(fā)模式：使用者可以在奇點的部署列表中選擇分支或tag以及構(gòu)建流水線（奇點支持同一服務(wù)配置多條流水線）自動化完成構(gòu)建、部署。該方式可以靈活操作，如未修改代碼時，調(diào)整編譯命令重新驗證可以通過人工觸發(fā)的方式來完成，如下圖所示:

• 自動觸發(fā)模式：奇點服務(wù)創(chuàng)建時，需要關(guān)聯(lián)git地址或者創(chuàng)建全新的git項目，此時會自動注冊webhook，監(jiān)聽push事件自動觸發(fā)流水線構(gòu)建、部署或者快速發(fā)布到測試環(huán)境
• 流水線模式 ：跟人工觸發(fā)一樣，會自動發(fā)起CI構(gòu)建任務(wù)和自動部署測試環(huán)境
• 快速發(fā)布模式：快速發(fā)布流程如下圖所示，針對非編譯型服務(wù)，如PHP或者Python等服務(wù)，修改某個靜態(tài)文件或者腳本文件，無需重新執(zhí)行一遍流水線，將變更的文件下發(fā)到容器內(nèi)對應(yīng)位置，最快的速度方便開發(fā)同學(xué)調(diào)試和驗證.對于編譯型的服務(wù)，也支持快速發(fā)布，前提條件是：編譯出的二進制文件必須能在linux上運行(例如golang的服務(wù)可在windows下交叉編譯為linux可執(zhí)行程序)，并配置好重啟命令即可( 任務(wù)發(fā)布時會自動打包和下載解壓到容器內(nèi)，并且執(zhí)行指定的重啟命令 )。

2.7.2 奇點(ODP)中的CD設(shè)計與實踐經(jīng)驗

1）可運行多種鏡像

鏡像是服務(wù)運行所依賴的環(huán)境，包括第三方庫以及操作系統(tǒng)版本。目前也支持公共運行鏡像和業(yè)務(wù)自定義運行鏡像，可以在集成配置頁面選擇運行鏡像

2）支持修改/增加系統(tǒng)環(huán)境變量
服務(wù)編譯構(gòu)建時、服務(wù)啟動時，需要根據(jù)當(dāng)前部署版本來做相應(yīng)的參數(shù)配置或者配置加載，此時需要通過環(huán)境變量來標(biāo)識。奇點中根據(jù)用戶自定義配置，生成yaml文件時會注入到container中;同時kubernetes自身的部分參數(shù)，也以環(huán)境變量的方式注入到container中，方便業(yè)務(wù)程序獲取pod自身信息，如POD名稱以及當(dāng)前POD的IP信息等。

3）支持自定義啟動命令
支持自定義的業(yè)務(wù)進程路徑、啟動參數(shù)、啟動前置處理等命令集合，為兼容啟動參數(shù)中的特殊字符，會把啟動命令中寫入到shell腳本然后執(zhí)行。另外，啟動命令必須確保拉起的進程是常駐進程以及前臺模式。

4）健康檢查
健康檢查對線上業(yè)務(wù)來說，是保證服務(wù)的正常、穩(wěn)定運行的重要手段。Kubernetes提供了以探針為主的健康檢查方式，對于故障服務(wù)會被及時自動下線，通過重啟服務(wù)的方式嘗試使服務(wù)自動恢復(fù)。目前主要支持以下兩種方式：

• Liveness探針：用于判斷Container是否處于運行狀態(tài)，非running狀態(tài)，kubelet會kill掉Container, 然后根據(jù)其設(shè)置的restart policy進行相應(yīng)操作。
• Readness探針: 用于判斷服務(wù)是否已經(jīng)ready，對外提供服務(wù)，如果檢測未通過，服務(wù)所在的Pod的IP地址會從服務(wù)的endpoints中被移除，不會接受或響應(yīng)任何請求。

此外，奇點中支持用戶定義健康檢查規(guī)則，這樣會自動生成對應(yīng)的Liveness和Readness配置。

5）服務(wù)部署

使用CI流水線的方式構(gòu)建和部署，推薦基于tag來部署（可溯源）。

四、業(yè)務(wù)上云收益

從自研上云開始，我們就確定了云原生的上云方案，經(jīng)過持續(xù)迭代，已經(jīng)建立了一套比較完整的云原生運維體系，王者榮耀、和平精英等全部游戲的數(shù)據(jù)運營活動已經(jīng)All IN 云原生。云原生的效能優(yōu)勢和技術(shù)紅利不斷釋放出來，我們實現(xiàn)了低成本、高效率構(gòu)建支持高并發(fā)場景的在線服務(wù)，又快又穩(wěn)的支撐游戲運營活動。

1、成本方面

騰訊云產(chǎn)品開箱即用，對于一些創(chuàng)新業(yè)務(wù)想做技術(shù)調(diào)研非常方便，用完即銷毀，成本很低。另外云產(chǎn)品都是免運維自行托管在云端，如TKE的Master和etcd都是托管騰訊云，可以節(jié)省人工運維成本，讓我們更專注于做核心業(yè)務(wù)。

2、穩(wěn)定性方面

云原生上云后，服務(wù)獲得了快速擴容、彈性伸縮的能力，抗壓能力增強，讓我們可以更加從容面對各種突發(fā)流量，機器故障后TKE自動遷移Pod讓服務(wù)獲得故障自愈的能力。此外，TKE將各類資源定義成描述文件，整個應(yīng)用環(huán)境通過容器的方式統(tǒng)一，避免了環(huán)境不一致的風(fēng)險。

3、效率方面

借助跟云產(chǎn)品的深度集成，方便開發(fā)人員完成一站式研發(fā)、運維工作。從業(yè)務(wù)需求立項到拉分支開發(fā)，再到測試環(huán)境功能回歸驗證，再部署到預(yù)發(fā)驗證及最后上線，整個持續(xù)集成可以做到分鐘級。相較于傳統(tǒng)DO分離的運營模式，發(fā)布耗時從小時級縮短到分鐘級，效率提升數(shù)倍。日常工作包括擴縮容、單機故障處理、機房裁撤等被降維簡化，運維變得更加簡單可信賴。

4、賦能業(yè)務(wù)

云上產(chǎn)品非常多，涵蓋了計算、存儲、大數(shù)據(jù)等諸多領(lǐng)域，可以節(jié)省業(yè)務(wù)創(chuàng)新帶來的技術(shù)成本。我們在用的包括TKE、CFS、COS、CKafka、VOD等20多個產(chǎn)品都是直接開箱即用，分鐘級交付，極大的方便了業(yè)務(wù)新需求的調(diào)研和上線。

五、總結(jié)

云原生給運維體系帶來的是挑戰(zhàn)更是機遇，如何在這波云計算浪潮中，尋找運維的定位與價值，我想是每一位運維人應(yīng)該思考的問題。本文是個人近幾年的所見、所聞、所思做個小結(jié)，提出的觀點不一定正確，希望能給大家多一個思考的方向，也歡迎批評指正。最后，也將我們的轉(zhuǎn)型思路、方法與實踐分享于此，提供給后面更多面臨同樣挑戰(zhàn)的團隊借鑒與參考。我們的轉(zhuǎn)型之路還在路上，未來我們將繼續(xù)扎根業(yè)務(wù)，深耕云原生環(huán)境運維，通過數(shù)據(jù)、編排、DevOps、AiOps等能力，進一步提升服務(wù)水平與用戶體驗。

作者簡介：劉天斯，負(fù)責(zé)騰訊游戲大數(shù)據(jù)管理及運維工作，從事互聯(lián)網(wǎng)技術(shù)運營工作近15年，曾榮獲“華章最有價值作者”、“中國十大杰出IT博主”、“WOT十大優(yōu)秀講師”、“OpsWorld金牌講師”、“TOP100優(yōu)秀出品人”、 “中國數(shù)據(jù)質(zhì)量杰出專家獎（2020）”、“DAMA中國數(shù)據(jù)治理專家獎（2020）”，IEEE與DAMA會員。曾參與國家《數(shù)據(jù)資產(chǎn)管理實踐白皮書》、《數(shù)據(jù)標(biāo)準(zhǔn)管理白皮書》等多個標(biāo)準(zhǔn)的編寫。熱衷開源技術(shù)的研究，包括大數(shù)據(jù)資產(chǎn)管理及云原生等領(lǐng)域，擅長大數(shù)據(jù)治理，數(shù)據(jù)與業(yè)務(wù)中臺建設(shè)、海量運維與規(guī)劃等工作，曾出版?zhèn)€人著作《python自動化運維：技術(shù)與實踐》、《循序漸進學(xué)Docker》等，個人發(fā)明專利10個。

推薦閱讀：

• 騰訊絕悟AI完全體限時開放體驗，研究登上國際頂會與頂刊
• Linux I/O 原理和 Zero-copy 技術(shù)全面揭秘
• 用萬字長文聊一聊 Embedding 技術(shù)

更多騰訊AI相關(guān)技術(shù)干貨，請關(guān)注專欄騰訊技術(shù)工程

審核編輯：符乾江