來源：騰訊技術工程微信號
作者：騰訊技術工程

前言

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

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

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

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

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

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

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

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

1、云原生運維轉型思維

這幾年運維界聽到最多的幾句話：“云計算會淘汰掉運維！整個運維行業(yè)可能被干掉！再不轉換運維就要丟飯碗”，諸如此類。那真相到底是什么？行業(yè)有一個共識，即運維工作本身交付的是一種服務，下面舉一個可能不太恰當?shù)睦?，或者可以幫助大家找到答案?/p>

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

我的觀點：

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

2）轉型SRE是一種選擇。

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

1）文化層面

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

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

2）技術層面

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

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

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

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

2、云原生運維轉型平臺化建設

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

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

公有云/私有云的各類云資源管理，我們叫做資產(chǎn)管理（所有的資源/應用/數(shù)據(jù)都在資產(chǎn)范疇）。我們知道，傳統(tǒng)的大多數(shù)cmdb只能管理服務器信息（如ip地址/機架/機房等），在云原生環(huán)境下，我們將面對復雜多變的、新生的應用和場景，隨之會產(chǎn)生越來越多的管理配置項，這就要求資產(chǎn)管理能夠滿足各種需求的擴展和未來業(yè)務的變化，例如騰訊云的CLB、CDB、COS、Ckafka等等，沒有自定義模型屬性的CMDB難以將這些云產(chǎn)品納入管理范疇。

在資產(chǎn)管理方案調研的過程中，我們發(fā)現(xiàn)資產(chǎn)管理需求與元數(shù)據(jù)管理十分契合，因此，資產(chǎn)管理，作為河圖元數(shù)據(jù)系統(tǒng)的應用場景落地，通過元數(shù)據(jù)定義資產(chǎn)管理的模型、屬性、組合關系，玄圖對元數(shù)據(jù)的加工、應用實現(xiàn)通用的可靈活調整的業(yè)務級資產(chǎn)管理。

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

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

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

資產(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ù)構建云原生環(huán)境的編排能力，即運維編排，通過開發(fā)、封裝可編排的組件和插件，提供靈活、可定制、可管理的模板化運維能力，覆蓋運維任務的管理、審批、決策、執(zhí)行、通知等功能，最終實現(xiàn)自動化、智能化運維。

我們將運維編排分為三層，即：基礎設施層、容器服務層、應用層。

如上圖所示：

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

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

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

2.3 DataOps助力運維轉型

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

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

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

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

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

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

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

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

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

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

我們需要在TKE集群部署Prometheus主動采集workload負載指標和用戶自定義指標，隨著集群規(guī)模不斷擴大，Promethues不支持容災部署，不支持分布式，單實例容量瓶頸等問題也凸顯出來，最后我們放棄了原生的Prometheus，轉而使用Thanos（滅霸）實現(xiàn)了分布式、高可用容災部署和數(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è)務平臺實現(xiàn)了高并發(fā)、海量的數(shù)據(jù)采集上報和存儲。首先，因為所有流量都會經(jīng)過網(wǎng)關，Thanos主動采集網(wǎng)關的這些指標到并將其可視化。如下圖所示，只要服務接入了業(yè)務平臺， QPS、耗時、成功率等一目了然，這些指標都無需額外開發(fā)即自動獲得，對代碼0侵入，節(jié)省了大量的開發(fā)成本。

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

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

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

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

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

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

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

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

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

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

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

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

1）構建鏡像

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

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

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

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

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

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

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

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

1）可運行多種鏡像

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

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

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

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

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

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

5）服務部署

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

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

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

1、成本方面

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

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

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

3、效率方面

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

4、賦能業(yè)務

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

五、總結

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

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

推薦閱讀：

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

更多騰訊AI相關技術干貨，請關注專欄騰訊技術工程

審核編輯：符乾江