雲原生背景下的運維價值思考與實踐

作者：劉天斯，騰訊遊戲高級工程師

前言

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

一、業務服務場景介紹

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

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

二、基於雲原生環境開發者平臺

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

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

三、雲原生運維轉型、挑戰、目標與實踐

1、雲原生運維轉型思維

這幾年運維界聽到最多的幾句話：「雲計算會淘汰掉運維！整個運維行業可能被幹掉！再不轉換運維就要丟飯碗」，諸如此類。那真相到底是什麼？行業有一個共識，即運維工作本身交付的是一種服務，下面舉一個可能不太恰當的例子，或者可以幫助大家找到答案。

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

我的觀點：

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

2）轉型SRE是一種選擇。

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

1）文化層面

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

開發與運維成立FT虛擬團隊，實現組織上的融合；

開發或運維側的例會、技術分享、事件復盤，FT成員全程參與；

項目立項時，運維接口人需要做「左移」，即提前參與技術架構討論，有助於運維的問題提前在方案討論或開發階段提前暴露，有效做好防範與規避；

建立收集各方反饋問題與建議的機制與渠道，有效將好的想法影響至平臺下個版本的迭代中，實現持續改進與優化。

2）技術層面

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

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

具備服務全鏈路質量監控覆蓋，涵蓋數據域與業務域

具備一定智能化的資源動態調度、伸縮機制

具備一定的故障預警、根因分析、問題定位能力

服務具備在交付不同階段（測試、預發布、運營）抵禦異常的能力

具備資源高效交付的流程機制與快速上線的能力

具備多雲的資源編排與管理的能力

具備業務快速上雲的機制，確保切換過程的高可用性

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

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

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

2.1 雲原生資產管理

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

在資產管理方案調研的過程中，我們發現資產管理需求與元數據管理十分契合，因此，資產管理，作為河圖元數據系統的應用場景落地，通過元數據定義資產管理的模型、屬性、組合關係，玄圖對元數據的加工、應用實現通用的可靈活調整的業務級資產管理。

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

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

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

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

2.2 雲端一切操作皆可編排

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

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

如上圖所示：

雲資源編排，編排對象是各類雲資源，包括公有雲、私有雲等，採用terraform來實現多雲基礎設施的編排，可以覆蓋騰訊雲、阿里雲、AWS、私有雲等等。

kubernetes編排，編排對象是k8s集群資源，採用Helm/YAML進行編排。

作業編排，編排對象主要是主機節點，對應的操作任務編排，調用現有的藍鯨job作業平臺。

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

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

2.3 DataOps助力運維轉型

2.3.1 TKE資源動態調度

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

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

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

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

2.3.2 TBDS資源動態調度

經過統計我們發現騰訊雲TBDS數據倉庫集群CPU的總體使用率僅為55%左右。如下圖所示，藍色線是分配的資源，綠色線是使用的資源，大部分應用組資源池，存在空閒時間段，而且相互錯峰的情況。我們累計有500+個應用組，抽取幾個大應用組統計其繁忙時間段，發現存在明顯的錯峰情況。

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

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

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

2.4 雲原生應用監控

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

我們需要在TKE集群部署Prometheus主動採集workload負載指標和用戶自定義指標，隨著集群規模不斷擴大，Promethues不支持容災部署，不支持分布式，單實例容量瓶頸等問題也凸顯出來，最後我們放棄了原生的Prometheus，轉而使用Thanos（滅霸）實現了分布式、高可用容災部署和數據長期存儲。

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

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

基於Thanos，我們業務平臺實現了高並發、海量的數據採集上報和存儲。首先，因為所有流量都會經過網關，Thanos主動採集網關的這些指標到並將其可視化。如下圖所示，只要服務接入了業務平臺， QPS、耗時、成功率等一目了然，這些指標都無需額外開發即自動獲得，對代碼0侵入，節省了大量的開發成本。

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

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

2.5 雲原生業務全鏈路跟蹤（血緣關係鏈）

隨著業務的不斷縱深發展，技術服務鏈條也隨之拉長，導致出現異常時定位問題困難，且無法快速評估影響面，因此我們通過構建數據血緣和業務血緣的組合來提升發現問題的能力。

數據與業務血緣關係鏈構建過程，覆蓋了數據服務交付的完整生命周期，通過採集每個交付節點的數據流向上下遊關係，最終形成一張完整的血緣關係鏈。在數據交付過程中，主要通過統一血緣上報規範，並與數據開發流程深度集成，做到對數據開發流程無侵入性。在數據服務交付過程中，則主要利用服務網格技術，自動採集微服務之間的服務調用鏈關係。

血緣關係構建好後，可以應用於血緣可視化檢索、影響面評估、故障回溯、根因分析、評估數據價值等很多方面，還可以結合雲原生的其他特性，發揮出更大的作用。如結合雲原生應用監控系統，在血緣關係鏈中疊加壓測指標、服務負載等多維度分析，可以為資源容量評估提供準確的依據，也可以分析出調用鏈上的瓶頸點在哪裡，提供為某些非核心服務配置服務降級策略和限頻限流策略的依據，避免突發流量影響核心服務體驗。

如下圖所示為一個典型的血緣應用場景，當運營人員收到告警馬上可以知曉，故障影響到哪些接口，哪些應用，哪些項目，哪些指標等。通過精準的影響面評估，可以提早與業務側溝通相應的應急預案。

2.6 雲原生環境下的混沌工程

混沌工程是一種在軟體或服務中進行各種試驗來驗證系統穩定性和健壯性的實驗方法。Adrian Cockcroft給出了另一個定義則是：混沌工程是一種確保失敗所帶來的影響能夠被減少的實驗。

在我們的微服務場景下，相對於單體應用，服務鏈路更長更複雜，任何一點的異常都可能影響全局服務，如何讓業務團隊更加了解系統可靠性，對服務更有信心呢？我們需要混沌工程，來進行有預期、有計劃的故障模擬，驗證業務服務的健壯性，提早發現風險隱患和薄弱之處，並進行修復，避免線上真正故障時手忙腳亂。當然,業務集群上存在大量的服務，沒有目的性的隨意破壞，「爆炸半徑」失控，將影響整個業務集群，因此混沌工程需要經過精心設計，在可控的環境中進行。

目前我們已加入公司內部混沌工程開源協同OTeam，搭建起第一版的混沌工程實驗平臺，進行實驗設計，這裡以雲服務平臺，注入CPU負載實驗測試。實驗目標，可以包括雲服務平臺和非雲服務。

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

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

2.7 Devops的持續集成與交付

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

2.7.1 數據營銷開發者平臺-奇點（ODP）中CI的設計與實踐經驗

1）構建鏡像

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

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

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

2）CI流水線引擎

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

3）CI任務觸發方式

目前CI任務觸發方式支持「人工觸發模式」、「自動觸發模式」、「流水線模式」、「快速發布模式」等多種模式。

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

自動觸發模式：奇點服務創建時，需要關聯git地址或者創建全新的git項目，此時會自動註冊webhook，監聽push事件自動觸發流水線構建、部署或者快速發布到測試環境

流水線模式 ：跟人工觸發一樣，會自動發起CI構建任務和自動部署測試環境

快速發布模式：快速發布流程如下圖所示，針對非編譯型服務，如PHP或者Python等服務，修改某個靜態文件或者腳本文件，無需重新執行一遍流水線，將變更的文件下發到容器內對應位置，最快的速度方便開發同學調試和驗證.對於編譯型的服務，也支持快速發布，前提條件是：編譯出的二進位文件必須能在linux上運行(例如golang的服務可在windows下交叉編譯為linux可執行程序)，並配置好重啟命令即可( 任務發布時會自動打包和下載解壓到容器內，並且執行指定的重啟命令 )。

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

1）可運行多種鏡像

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

2）支持修改/增加系統環境變量

服務編譯構建時、服務啟動時，需要根據當前部署版本來做相應的參數配置或者配置加載，此時需要通過環境變量來標識。奇點中根據用戶自定義配置，生成yaml文件時會注入到container中;同時kubernetes自身的部分參數，也以環境變量的方式注入到container中，方便業務程序獲取pod自身信息，如POD名稱以及當前POD的IP信息等。

3）支持自定義啟動命令

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

4）健康檢查

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

Liveness探針：用於判斷Container是否處於運行狀態，非running狀態，kubelet會kill掉Container, 然後根據其設置的restart policy進行相應操作。

Readness探針: 用於判斷服務是否已經ready，對外提供服務，如果檢測未通過，服務所在的Pod的IP位址會從服務的endpoints中被移除，不會接受或響應任何請求。

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

5）服務部署

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

四、業務上雲收益

從自研上雲開始，我們就確定了雲原生的上雲方案，經過持續迭代，已經建立了一套比較完整的雲原生運維體系，王者榮耀、和平精英等全部遊戲的數據運營活動已經All IN 雲原生。雲原生的效能優勢和技術紅利不斷釋放出來，我們實現了低成本、高效率構建支持高並發場景的在線服務，又快又穩的支撐遊戲運營活動。

1、成本方面

騰訊雲產品開箱即用，對於一些創新業務想做技術調研非常方便，用完即銷毀，成本很低。另外雲產品都是免運維自行託管在雲端，如TKE的Master和etcd都是託管騰訊雲，可以節省人工運維成本，讓我們更專注於做核心業務。

2、穩定性方面

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

3、效率方面

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

4、賦能業務

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

五、總結

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

作者簡介：劉天斯，負責騰訊遊戲大數據管理及運維工作，從事網際網路技術運營工作近15年，曾榮獲「華章最有價值作者」、「中國十大傑出IT博主」、「WOT十大優秀講師」、「OpsWorld金牌講師」、「TOP100優秀出品人」、 「中國數據質量傑出專家獎（2020）」、「DAMA中國數據治理專家獎（2020）」，IEEE與DAMA會員。曾參與國家《數據資產管理實踐白皮書》、《數據標準管理白皮書》等多個標準的編寫。熱衷開源技術的研究，包括大數據資產管理及雲原生等領域，擅長大數據治理，數據與業務中臺建設、海量運維與規劃等工作，曾出版個人著作《python自動化運維：技術與實踐》、《循序漸進學Docker》等，個人發明專利10個。