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

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

前言

隨著公司自研上雲戰略如火如荼地進行，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個。