《[YY互娛]基于 DevOps 理念的私有 PaaS 平臺實踐》要點：
本文介紹了[YY互娛]基于 DevOps 理念的私有 PaaS 平臺實踐，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者簡介：

劉亞丹 ? YY 互動娛樂事業(yè)部運維經(jīng)理

負(fù)責(zé)YY互娛事業(yè)部的基礎(chǔ)運維平臺建設(shè)管理工作,8年互聯(lián)網(wǎng)運維從業(yè)經(jīng)驗、經(jīng)歷服務(wù)器從數(shù)百到數(shù)千的規(guī)模,走過從手工運維到自動化平臺化運維方式轉(zhuǎn)變,積極擁抱云計算大潮,推行 Web 類業(yè)務(wù)邁向虛擬化云化的基礎(chǔ)設(shè)施,致力于 PaaS運維平臺的 ITIL理念與 DevOps 理念融合、對云形態(tài)下的互聯(lián)網(wǎng)企業(yè)運維平臺建設(shè)管理有較深理解和實戰(zhàn)經(jīng)驗.

前言

云計算從2006年 AWS 推出 EC2開始,至今已經(jīng)10年,從最開始多數(shù)人不清楚云計算為何物,到如今,大到 BAT等互聯(lián)網(wǎng)公司,傳統(tǒng)金融、證券、制造業(yè)企業(yè),小到初創(chuàng)企業(yè),都在積極推進云計算戰(zhàn)略,以此加快業(yè)務(wù)交付效率,降低成本、提升競爭力.云計算的首要目的是將底層硬件抽象化,向上提供計算資源,存儲資源,網(wǎng)絡(luò)資源.

其關(guān)鍵核心是提高了IT業(yè)務(wù)交付效率,使企業(yè)花費更少的錢,辦更多的事情,同時滿足質(zhì)量,安全的需求.在云計算大潮下,企業(yè)內(nèi)IT部門,需結(jié)合自身的業(yè)務(wù)特點,思考提供怎樣的云計算基礎(chǔ)設(shè)施服務(wù)(IaaS),以及基于 IaaS又提供怎樣的 PaaS ,才能滿足企業(yè)對于質(zhì)量,效率,成本,安全四元組合的最佳要求,是擺在每一個運維從業(yè)者面前的問題.

YY 互娛基于 DevOps 理念,并結(jié)合 ITIL 最佳實踐理念,從13年開始推出自己的IaaS,基于自身條件,推出一套符合企業(yè)內(nèi)部要求的私有 PaaS 運維平臺,并在實踐中不斷的改進完善IaaS,PaaS.本文將系統(tǒng)的從4個方面,分享YY互娛運維團隊對于 PaaS 運維平臺實踐經(jīng)驗及未來展望,希望對大家有一些參考意義.

一、 運維價值體系

說到運維,還得從運維的價值體系說起.運維的價值體系,從四個維度來概括,即質(zhì)量,效率,成本,安全.這體現(xiàn)的是一個經(jīng)濟問題,是運維部門總結(jié)工作時,公司高層能聽得懂的語言.我們從事一切運維工作,大到公司運維平臺體系構(gòu)建,小到某項具體運維工作,最終將從這4個維度的數(shù)據(jù)來衡量,因此,運維工作應(yīng)該以提高業(yè)務(wù)的質(zhì)量,效率為出發(fā)點,在成本和安全中尋求最佳平衡點.在云計算的形式下,應(yīng)當(dāng)以自動化,服務(wù)化等技術(shù)手段為依托,數(shù)據(jù)化,可視化體現(xiàn)運維的價值輸出.

二、 運維平臺化方式

縱觀整個運維技術(shù)的發(fā)展歷程,運維平臺化體系建設(shè),我們認(rèn)為主要有以下3種形式.

1. 面向流程

提供獨立的工具子系統(tǒng),再將工具 API 化,向上提供整合能力.

上面這種運維平臺模式,是典型的以 ITIL 最佳實踐為參考的運維體系建設(shè).我們從一個常見的業(yè)務(wù)上線場景說起,來看看這種模式的特點.

假如一個 Web 業(yè)務(wù)需要上線,需要服務(wù)器資源,需求人(開發(fā)或者業(yè)務(wù)運維)需要到 CMDB 查看是否有空閑資源,若有,則到“服務(wù)器申請”流程里面提一個工單,經(jīng)過一個審批流程(至少3個審批節(jié)點),拿到服務(wù)器.

同樣,業(yè)務(wù)上線還需要數(shù)據(jù)庫,需要緩存,需要 DNS 解析,需要開通權(quán)限,需要添加監(jiān)控等等,需求人都必須到相應(yīng)的系統(tǒng)提單,才能完成需求.這樣的流程體系下,對于需求的管理方是比較好的,各類需求,資源都可以較好的記錄以及控制.

但對于核心的業(yè)務(wù)上線,變更、即面向用戶的價值交付,效率很低,業(yè)務(wù)上線周期長,人力成本高.

ITIL 最佳實踐中總共包括六大操作流程五大服務(wù)支持流程,流程都包括五大要點：流程目標(biāo)、基本概念、主要活動、好處與風(fēng)險,以及關(guān)鍵績效指標(biāo)與報表.以流程為導(dǎo)向建設(shè)運維體系,在互聯(lián)網(wǎng)時代本身變化極快,不斷試錯,追求敏捷高效的目標(biāo)沖突越來越大.

ITIL 面向流程的運維體系亟需改進,而改進的方向,即面向業(yè)務(wù)的服務(wù)化方向改進.

2. 面向服務(wù)

基礎(chǔ)組件API 化(IaaS化),向上提供整合能力,再做面向運維的集中信息管理,配置管理,變更管理等.

如上圖所示,我們?nèi)耘f以一個 Web 業(yè)務(wù)上線的場景,來進行說明.

面向服務(wù)的運維平臺,首先需要構(gòu)建底層資源的 IaaS 化,API 化.有了 IaaS化,我們就具備了提供一個一站式的運維平臺的基礎(chǔ)能力.在這樣的運維平臺上,業(yè)務(wù)上線需要數(shù)據(jù)庫資源,平臺提供對應(yīng)的實例配置套餐,一鍵創(chuàng)建并返回給用戶.

同樣,制定一套標(biāo)準(zhǔn)的發(fā)布規(guī)范,實現(xiàn)自動化部署,業(yè)務(wù)在發(fā)布的時候,從 IaaS 資源池自動分配服務(wù)器.其他的資源,如 CDN,域名解析等,同樣可以在平臺上自助完成.

這樣,業(yè)務(wù)上線的流程,全部以自動化,自助的方式完成.再往前,平臺與持續(xù)集成,自動化測試平臺進行對接,即可完成自動化測試,并根據(jù)自動化測試結(jié)果來決定是否進行發(fā)布.

這里面主要是以 DevOps 的理念來構(gòu)建運維平臺,這個方式也是我們的實踐方式,后續(xù)內(nèi)容將詳細(xì)描述.

3. “拿來主義”

1. 公有云平臺公有云平臺提供了完備的基礎(chǔ)資源和強大的功能特性,且具體完善的 API,一般創(chuàng)業(yè)公司完全可以基于公有云平臺進行運維平臺化管理,無需自己再去開發(fā)一套運維管理平臺,也沒有能力去開發(fā).不過一旦公司做大,考慮到單一供應(yīng)商的風(fēng)險,勢必考慮至少兩家云平臺的資源,甚至可能還存在自有數(shù)據(jù)中心,這樣就面臨著混合云管理需求.
2. ITSM 商業(yè)軟件
   在云計算和 DevOps 驅(qū)動下,當(dāng)前也有商業(yè)的ITSM 管理軟件,提供一站式運維管理平臺軟件或者服務(wù),而不是提供離散的 ITSM 管理套件.這類軟件,在互聯(lián)網(wǎng)+的時代,對于傳統(tǒng)行業(yè)的 IT 部門轉(zhuǎn)型升級會非常有幫助.

三、 YY互娛 – PaaS 運維平臺理念和實踐

業(yè)務(wù)場景

YY 互娛在這幾年處于高速發(fā)展的過程,即要穩(wěn)固拓展 PC 端的市場,又需要在移動端尋求突破,業(yè)務(wù)場景：

1. 快速試錯

互聯(lián)網(wǎng)時代競爭激烈,特別是移動互聯(lián)網(wǎng)時代,誰能快速推出產(chǎn)品,快速迭代,誰就能在市場上占得先機.快速試錯是一種常見的競爭手段.PaaS 平臺的業(yè)務(wù)交付運行模式,最大特點就是效率高,成本低,可以很好的滿足快速試錯的業(yè)務(wù)需求.

2. 人力不足

長期以來,互聯(lián)網(wǎng)企業(yè)在運維方面的人力投入是不夠的,很多時候是扮演的救火員的角色,PaaS 在平臺層面提供一站式運維服務(wù),高可用架構(gòu)質(zhì)量保障,減少業(yè)務(wù)上線對運維人員的依賴,在不需要運維人員介入,開發(fā)人員自己就可以上線業(yè)務(wù),并持續(xù)迭代.

基于 IaaS 的 PaaS 平臺,將硬件環(huán)境與軟件環(huán)境進行了解耦,也降低了硬件故障對線上業(yè)務(wù)的影響,釋放了運維自身的壓力.

3. 成本壓力

業(yè)務(wù)上線需求多,如果按傳統(tǒng)的方式提供物理資源,對資源的需求量極大,而業(yè)務(wù)的訪問量,生命周期不可預(yù)測,造成硬件資源利用率低.很多時候通過混合部署業(yè)務(wù),提高硬件資源利用率,造成后期維護成本非常高.

平臺理念

基于上面的業(yè)務(wù)場景,以及云計算的大背景,YY 互娛技術(shù)團隊基于 OpenStack ,推出自己的 IaaS平臺,主要面向游戲業(yè)務(wù)的云計算平臺.基于 IaaS能力,逐步構(gòu)建自己的PaaS平臺.

我們的平臺理念是：運維技術(shù)服務(wù)化,轉(zhuǎn)化為生產(chǎn)力.平臺提供高可用高性能高質(zhì)量的基礎(chǔ)架構(gòu)服務(wù),滿足業(yè)務(wù)的快速交付.平臺提供一系列的工具,組件,來支撐開發(fā)人員自助式運維.

開發(fā)人員只要使用平臺,無需找到運維人員,就能應(yīng)用運維的能力,如高可用,彈性伸縮,配置管理,容災(zāi)備份等能力,達到 NoOps 的目的,減少開發(fā)、運維不必要的溝通成本,使開發(fā)人員專注于業(yè)務(wù)開發(fā).

執(zhí)行 DeoOps 理念,平臺將開發(fā)、測試,運維流程自動化打通,將持續(xù)集成,自動化測試的能力以服務(wù)化的方式輸出到平臺.最終,將業(yè)務(wù)價值交付涉及的各種能力,通過平臺輸出到業(yè)務(wù),達到技術(shù)服務(wù)轉(zhuǎn)化為生產(chǎn)力的目標(biāo).

實踐歷程

1. 整體架構(gòu)

PaaS運維平臺的整體架構(gòu)：

兩種顏色代表兩個視圖,藍色部分代表從業(yè)務(wù)維度的視圖,即從PaaS平臺用戶的維度看到的架構(gòu).灰色部分代表從運維自身的視圖,即運維全局的視圖.

從業(yè)務(wù)維度的視圖,大概分為4層,從下而上,面向服務(wù),包括硬件層,IaaS,PaaS和業(yè)務(wù)層.

從運維自身的視圖,包括全局資源中心,監(jiān)控中心,數(shù)據(jù)源中心,報表中心,安全體系等.

接下來的篇幅,主要把面向業(yè)務(wù)的各個核心組件及實踐做介紹.

2. 標(biāo)準(zhǔn)化

標(biāo)準(zhǔn)化是運維自動化的基礎(chǔ),PaaS 平臺的標(biāo)準(zhǔn)將以系統(tǒng)化,自動化的方式落地.
標(biāo)準(zhǔn)化主要包括這些規(guī)范：

• 基礎(chǔ)應(yīng)用軟件規(guī)范(Nginx,Resin,Tomcat等)
• 應(yīng)用程序打包規(guī)范(Java,PHP)
• 應(yīng)用程序部署規(guī)范
• 監(jiān)控規(guī)范
• 其他

以上規(guī)范,全部落地到PaaS 平臺的各個子系統(tǒng),由子系統(tǒng)自動化完成.比如對VM 環(huán)境的標(biāo)準(zhǔn)化,通過 VM 鏡像方式交付.

3. IaaS

我們的 IaaS 層提供了以下服務(wù),來滿足我們的應(yīng)用上線.

• 計算虛擬化
  計算虛擬化部分,我們這里使用 VM,將 VM 作為我們?nèi)萜饔嬎愕淖钚卧?當(dāng)前使用 OpenStack 開源實現(xiàn)方案,使用 KVM 做 hypervisor.提供各類 VM 套餐滿足不同業(yè)務(wù)場景.計算能力擴展我們采取的 VM 的橫向擴展,即 ScalingOut,后面章節(jié)會介紹.
• 存儲虛擬化
  考慮到性能問題,我們VM使用了本地存儲.沒有使用 Ceph分布式存儲.
  對象存儲上,對接了公司提供的基礎(chǔ)服務(wù).
• 網(wǎng)絡(luò)虛擬化
  網(wǎng)絡(luò)部分,采用了Neutron Provider Network,未實現(xiàn) VPC 網(wǎng)絡(luò)隔離.
• 數(shù)據(jù)源
  • 數(shù)據(jù)源我們提供了3類數(shù)據(jù)源,Mysql,Redis,Memcached.這3類資源是平臺上使用最頻繁的組件.我們以單物理機多實例的方式運行,未主動采用 cgroup 進行資源隔離.這些插件在被創(chuàng)建的時候會自動添加監(jiān)控,用戶可以在平臺查看相關(guān)監(jiān)控狀態(tài)信息.
  • 插件平臺.上述基礎(chǔ)組件以插件方式與平臺整合,類似于 Heroku 的 Addons服務(wù).

具體業(yè)務(wù)流程描述如下：

• 插件注冊：插件開發(fā)者將自己開發(fā)的插件接入插件平臺.
• 獲取插件：PaaS 平臺的項目用戶請求插件平臺,獲取插件授權(quán)信息.
• 返回授權(quán)：插件平臺將來自 PaaS 平臺的請求轉(zhuǎn)發(fā)到具體的插件,獲取具體插件的地址,授權(quán)等信息,并將信息存儲在插件平臺然后返回給PaaS 平臺.比如 Mysql 實例,返回域名,端口,賬號,密碼.
• 插件注入容器： 項目模塊發(fā)布的時候,由CloudRouter 從 PaaS 平臺上獲取插件信息并將相關(guān)信息注冊到業(yè)務(wù)容器環(huán)境變量.關(guān)于 CloudRouter 的功能,后續(xù)會詳細(xì)描述.
• 容器訪問插件：業(yè)務(wù)容器從環(huán)境變量中獲取到的插件信息,直接請求具體的插件.插件平臺的引入,增強了PaaS平臺的開放性和靈活性,項目所需的所有基礎(chǔ)組件,不需要 PaaS 平臺自己提供,可以由公司其他開發(fā)同事提供.插件平臺面向公司內(nèi)部所有開發(fā)人員,設(shè)置了一定的運營策略,如貢獻率,引用量,收獲贊等,并與公司的績效積分,技術(shù)職級評定做一定關(guān)聯(lián).
• 
• 其他資源
  其他基礎(chǔ)服務(wù),我們同時提供了 CDN,消息隊列等.
  CDN 是使用第三方廠商基礎(chǔ)服務(wù),通過 API對接,實現(xiàn)一鍵創(chuàng)建 CDN 服務(wù).消息隊列服務(wù)底層采用了 RabbitMQ集群.
  同樣,這些資源也以插件方式整合到平臺.

4. 持續(xù)交付

基于上面的 IaaS 層,我們有了構(gòu)建 PaaS 的基礎(chǔ)能力,來解決持續(xù)交付的問題.我們從以下幾個方面來描述

• 交付模型

交付模型,指在我們的 PaaS 平臺上的業(yè)務(wù),構(gòu)建一個業(yè)務(wù)的模型.這個模型也是基于我們的應(yīng)用程序打包規(guī)范來做的.這里再簡單描述下：

• PaaS 平臺業(yè)務(wù)交付的對象包括：人, 項目,模塊.
• 人即項目管理員,一個人可以管理多個項目,一個項目也可能是多個人管理.

項目對應(yīng)的是一個業(yè)務(wù),一個項目又分多個模塊,每個模塊就是一個獨立的部署單元；模塊一般是按功能進行劃分,比如最常見,一個項目有 admin 模塊,user 模塊.我們的PaaS平臺的部署操作最小單元是項目的模塊.以 Java 應(yīng)用為例,模塊的類型有 War和Jar.不同類型對應(yīng)不同的部署動作.

• 項目管理

項目的管理包括項目的新建,以及用戶權(quán)限管理,屬性管理.需要的基礎(chǔ)信息包括：項目 代碼庫地址,項目成員等等.
項目管理中涉及的信息

• 持續(xù)集成
  以Java 項目為列,我們約定在 pom.xml 根據(jù)模塊名稱打包成對應(yīng)類型的包.并自動創(chuàng)建對應(yīng)的項目模塊,打好的程序包上傳到分布式文件系統(tǒng)(DFS).實現(xiàn)只要將代碼提交到版本庫,即可一鍵打包發(fā)布.在我們的現(xiàn)實情況中,并沒有對每一個項目要求持續(xù)集成,而是選擇性的,其中的原因是：
  • 大部分項目都是小型項目,不涉及多人協(xié)同開發(fā),這樣的場景下不涉及到復(fù)雜的持續(xù)集成場景.
  • 小步快跑.本身項目的迭代速度比較快,集成頻率比較高,一般不會出現(xiàn)持續(xù)集成不通過導(dǎo)致需要花費大量精力解決集成失敗的問題.

• 持續(xù)測試
  PaaS 平臺與自動化測試平臺進行對接,在基礎(chǔ)信息上同步共享,包括項目名稱,項目成員,版本庫地址等.持續(xù)測試的實踐經(jīng)驗是：
  • 業(yè)務(wù)分級.對核心項目進行嚴(yán)格的持續(xù)測試,包括單元測試,QA 自動化測試.對非核心項目,默認(rèn)不進行測試.是否測試的權(quán)限交給項目管理員,項目管理員一般都是開發(fā)團隊的 Leader.
  • 風(fēng)險控制.在實際的運作中,測試能發(fā)現(xiàn)的問題是有限的,需要考慮一旦出現(xiàn)問題的補救措施.因此,對于核心的業(yè)務(wù)系統(tǒng),引入風(fēng)險監(jiān)控,降低 bug 的影響范圍.
• 持續(xù)部署
  持續(xù)部署中,涉及到如下幾個問題,我們的解決方案是：
  • 數(shù)據(jù)源.項目所需的數(shù)據(jù)源(Mysql,Redis)實例,用戶在平臺上一鍵創(chuàng)建,然后通過環(huán)境變量的方式注入到業(yè)務(wù)容器.具體流程見前面章節(jié)“插件平臺”所描述.
  • 配置管理.包括運行環(huán)境的管理,JVM 參數(shù)定制,Nginx 參數(shù)定制,域名配置,證書配置等,這類配置全部在平臺,由用戶自助或系統(tǒng)自動化完成.
  • 發(fā)布.涉及“包版本”發(fā)布審批,服務(wù)器資源自動分配,“配置管理“中涉及的各項配置應(yīng)用到相關(guān)組件.
  • 回滾.平臺支持包版本快速回滾.
• 持續(xù)反饋
  • 基礎(chǔ)資源監(jiān)控及監(jiān)控數(shù)據(jù)展示
  • 運行維護
  • 業(yè)務(wù)可用性監(jiān)控和數(shù)據(jù)展示上述三點在后面的章節(jié)詳細(xì)說明

5. 高可用架構(gòu)

平臺架構(gòu)高可用設(shè)計,從最上層的攻擊防御,到數(shù)據(jù)持久化層,全部提供高可用方案.業(yè)務(wù)只要接入平臺,就具備全部的能力..

• 云防DDOS,接入公司層安全中心的DDOS 防火墻,保障業(yè)務(wù)安全.
• GSLB,平臺提供多機房,多鏈路接入的能力.項目域名自動解析到多個機房,提供就近接入的能力.
• OSPF-LVS,四層負(fù)載均衡采用OSPF-LVS 架構(gòu),具備平滑的水平擴展的能力.

• AppRouter 應(yīng)用路由層,Nginx提供七層的路由轉(zhuǎn)發(fā),同樣具備平滑的水平擴展能力.
• Container,應(yīng)用邏輯層.這一層是項目級別的配置.提供 Nginx+容器(Tomcat,Resin,PHP-FPM)環(huán)境.這一層引入 Nginx,是考慮到部分七層業(yè)務(wù)邏輯控制,交由項目級別的控制,不至于每次項目級別的變更,而影響上一層AppRouter 全局層面的變更.這一層具備彈性伸縮的能力,后續(xù)章節(jié)具體講解彈性能力實現(xiàn)方式.
• Cache 層,提供純 Cache 和數(shù)據(jù)型 Cache.這一層我們主要是使用的 Redis,以域名和端口的方式對外暴露,通過域名切換,具備故障切換的能力.
• DB數(shù)據(jù)持久化.這一層目前對于所有業(yè)務(wù)實例,默認(rèn)提供帶主從的實例對,業(yè)務(wù)發(fā)生故障時,需要根據(jù)業(yè)務(wù)場景對數(shù)據(jù)一致性要求情況,進行故障切換.這一層當(dāng)前未引入開源類似 MHA,MMM 等架構(gòu),而是通過域名切換的方式來實現(xiàn),這里面參考了 AWS 的實現(xiàn)方法.我們的架構(gòu)一般都是 MM 架構(gòu),當(dāng)主節(jié)點發(fā)生 Down 機后,域名切換到從實例,Master 恢復(fù)后,只要修復(fù)主從關(guān)系即可.對于高并發(fā)訪問量的業(yè)務(wù),需要一主多從,或者 Mysql 環(huán)形復(fù)制場景,這些需要根據(jù)業(yè)務(wù)特性做一些人工介入.

6. 彈性擴展

• 彈性
  彈性是 PaaS 平臺的基本能力,彈性技術(shù)的好處有：
  • 高性能：在業(yè)務(wù)訪問規(guī)模上去時,服務(wù)器自動增加,保證性能
  • 經(jīng)濟性：在業(yè)務(wù)規(guī)模降低時,自動收縮服務(wù)器,節(jié)省成本
  • 高可用：如果有服務(wù)器宕機,自動進行故障隔離
  • 平滑部署：實現(xiàn)熱部署,不影響現(xiàn)有業(yè)務(wù)運行彈性伸縮提供包括動態(tài)伸縮,熱部署,故障隔離三層含義.彈性示意(圖十四)

我們的彈性技術(shù)是由CloudRouter 和 CloudMonitor,資源池3個部分組成.架構(gòu)：

• CloudRouter是核心組件,是彈性調(diào)度的大腦,在用戶的任務(wù),資源分配中間起核心的調(diào)度協(xié)調(diào)的作用.
• CloudMonitor 負(fù)責(zé)項目服務(wù)器的狀態(tài)數(shù)據(jù)收集,并提供接口供 CloudRouter 查詢狀態(tài).
• 資源池是基于預(yù)創(chuàng)建的可用資源緩沖池.這里主要是指 VM 資源.VM 資源又分為多種配置,對于每種配置的資源,可在后臺配置預(yù)先創(chuàng)建一定的數(shù)量.一旦服務(wù)需要資源,可立刻從池里獲取.
• 彈性的策略. 當(dāng)前我們的彈性策略是模塊的所有 VM 的負(fù)載平均值.當(dāng)負(fù)載平均值大于我們們指定的彈性閥值,則進行擴展,可設(shè)置每次擴展的服務(wù)器數(shù)量.同樣,當(dāng)平均值小于我們指定的閥值,則進行縮減.

在實際的業(yè)務(wù)場景中,可能有些業(yè)務(wù)是內(nèi)部小型項目,不需要進行彈性,是否彈性是一個可選項.另外,還有一些項目,可能無法滿足無狀態(tài)的設(shè)計要求,不希望每次部署都更換服務(wù)器,我們也提供了在部署的時候,選擇“就地部署”,就地部署的意思就是每次部署都使用同樣的服務(wù)器.彈性調(diào)度策略配置：

7. NoOps

• 自主運維

平臺提供一系列日常運維管理工具,包括常見的服務(wù)器性能查詢,日志查詢,應(yīng)用分析工具,數(shù)據(jù)源相關(guān)信息查詢.大多數(shù)場景下,開發(fā)人員無需登錄服務(wù)器.

• 日志管理
  日志管理方面,我們提供了兩種方式
  • 文本日志.我們在每臺vm上通過 Rsyslog 進程收集業(yè)務(wù)進程日志發(fā)到集中日志服務(wù)器.在集中日志服務(wù)器端,我們按項目名稱存儲,一個項目一個日志目錄.日志目錄權(quán)限管理,我們使用Linux 用戶組權(quán)限設(shè)置,只有具備PaaS 平臺項目管理權(quán)限的用戶,才能查看該項目下的日志.
  • Web 日志分析.PaaS 平臺對接了公司級的 Web 日志分析系統(tǒng),能夠?qū)崟r展示項目域名的日志訪問量,帶寬流量,請求狀態(tài)等情況.
• 監(jiān)控
  平臺監(jiān)控主要是基于 Zabbix 做了一些 API 層面的定制開發(fā),我們內(nèi)部稱之的為“CloudMonitor“.主要包括以下三個方面功能：
  • 基礎(chǔ)監(jiān)控
    VM:基礎(chǔ)監(jiān)控包括 CPU,內(nèi)存,磁盤 IOUtils,磁盤空間使用率,網(wǎng)絡(luò)流量,TCP鏈接數(shù),進程數(shù)等.監(jiān)控信息如圖：
    
  • 數(shù)據(jù)源：對 Mysql,Redis,Memcached 常規(guī)指標(biāo)做了監(jiān)控.
    自定義監(jiān)控.支持 TCP,DNS,PING,HTTP,支持自定義告警條件和策略.如圖：
    
  • 告警.平臺告警由 CloudMonitor 組件負(fù)責(zé),支持多種方式告警.CloudMonitor 組件是在Zabbix 的事件接口上,定期獲取事件,按業(yè)務(wù)維度進行匯總分析發(fā)送給業(yè)務(wù)開發(fā)負(fù)責(zé)人和運維負(fù)責(zé)人.做了一定程度的事件聚合,比如宿主機 Down 機,宿主機上的 vm 相關(guān)信息關(guān)聯(lián)起來,從業(yè)務(wù)開發(fā)負(fù)責(zé)人看：某 vm Down 機是由于某宿主機引起；從運維層面看,某宿主機 Down,影響了這些 vm,這些 vm 運行了這些業(yè)務(wù).
• 工具組件
  在自助運維場景中,開發(fā)人員需要對項目 ,域名,IP 信息進行查詢,平臺提供相應(yīng)的工具.
• 可用性反饋
  平臺的可用性反饋,主要是對平臺各個層面的服務(wù)可用性,進行系統(tǒng)化,自動化評估.這里主要介紹下我們的業(yè)務(wù)的可用性度量實踐方法.
  我們稱為“Monitor.X監(jiān)控規(guī)范”具體描述如下：
  • X代表語言.(注：若是 PHP 項目,文件后綴為 monitor.php；若為 node.js,則文件名為,monitor.js).
  • 路徑要求：url規(guī)則為http://項目域名/monitor/monitor.X)項目域名取配置管理里面,設(shè)置域名框中,去掉 包括 test 字符串后的第一個域名.
  • 輸入?yún)?shù)：接口不用輸入?yún)?shù).
  • 輸出說明：接口輸出只分為兩種,正常和不正常.
  • 正常：狀態(tài)碼為200,且輸出包括字符串“200”
  • 非正常：狀態(tài)碼200或者非200,且輸出字符串不包括200. (可以用作錯誤提示內(nèi)容).
  • 對于狀態(tài)碼200,同時信息也包括200字符串,但是實際是服務(wù)不可用的情況,需要程序員特殊處理返回信息.
  • 接口內(nèi)部實現(xiàn)要求：要覆蓋系統(tǒng)的核心業(yè)務(wù)邏輯(業(yè)務(wù)自身把握)；有多個業(yè)務(wù)邏輯時,也是統(tǒng)一在一個接口返回(調(diào)用順序由業(yè)務(wù)控制).

業(yè)務(wù)在PaaS 平臺發(fā)布,平臺將自動加上項目的 Monitor.X 監(jiān)控,根據(jù) Monitor.X 的狀態(tài),來衡量業(yè)務(wù)是否可用.可用性反饋如圖：

8. 安全審計

所有操作包括打包,配置,部署,日常運維等操作全部收攏在PaaS平臺上,每一個用戶在平臺的的所有操作都有記錄,可追蹤.

對于核心項目的數(shù)據(jù)變更類的操作,引入運維審批.

9. 平臺運營

雙向反饋
構(gòu)建平臺用戶反饋溝通群組,第一時間接受響應(yīng)用戶的需求,重視“客戶滿意度”,并將客戶反饋的問題,由專人進行收集匯總,每周發(fā)出平臺質(zhì)量問題周報,并組織開發(fā)運維力量,集中有效解決用戶反饋的問題.這些問題,有技術(shù)性的,流程性的和體驗性的,用戶每一個問題的交互過程,通過溝通群傳達給平臺每一個用戶.

體驗優(yōu)化
長期以來,在面向技術(shù)人員的系統(tǒng) UI設(shè)計,用戶體驗是不好的,內(nèi)部技術(shù)平臺首要解決的是可用性問題.PaaS 平臺需重視用戶的體驗,體驗好也才能實現(xiàn)我們的 NoOps 的理念.試想一下,如果我們做了一個自己覺得很厲害的功能,而用戶覺得不好用而棄用,那做的可能就是無用功.

也許有種擔(dān)心,我們已經(jīng)把所有的用戶放在一個群里面,任何一個細(xì)節(jié)問題,體驗問題,都會讓所有用戶知曉,平臺維護者比較被動.我們的經(jīng)驗是,在 DevOps 文化下,平臺的建設(shè)者(運維團隊),平臺的使用者(開發(fā)團隊),都有面向業(yè)務(wù)最終用戶價值交付的共同目標(biāo),都將以合作,包容的心態(tài),共同推動平臺的進步.

平臺收益

平臺收益情況,從四個方面表述,如圖所示

• 質(zhì)量
  基礎(chǔ)組件平臺保障高可用,故障自動隔離.應(yīng)用容器彈性伸縮,確保在業(yè)務(wù)變化中得到穩(wěn)定的服務(wù)質(zhì)量.平臺提供自動化可用性管理方案,對業(yè)務(wù)質(zhì)量形成有效反饋.
• 效率
  執(zhí)行 DevOps 理念,將研發(fā),測試,運維全流程以自動化的方式整合,實現(xiàn)業(yè)務(wù)的快速交付.提供豐富的自助運維工具,系統(tǒng),滿足開發(fā)自助式運維需求,提高日常維護的效率.
• 安全
  在網(wǎng)絡(luò)安全和系統(tǒng)安全上,接入公司級安全體系,包括云防 DDOS,主機基線安全,主機漏洞檢測,應(yīng)用層引入公司的 WAF模塊.在數(shù)據(jù)安全和 D/O 權(quán)限分離上,平臺隔離開發(fā)人員登陸生產(chǎn)環(huán)境和生產(chǎn)數(shù)據(jù)庫的權(quán)限,所有權(quán)限全部收攏在平臺上,變更類操作自動引入工單,由運維介入審批.所有操作記錄可跟蹤.
• 成本
  通過 IaaS 層的計算虛擬化,資源池,彈性伸縮等技術(shù)手段,提高系統(tǒng)資源利用率,減少硬件資源采購.通過自動化的技術(shù)手段,減少人力資源的投入一站式的運維管理服務(wù)平臺,大大減少人員流動導(dǎo)致項目的交接成本,降低人力成本.

平臺風(fēng)險

PaaS 平臺的風(fēng)險,如圖所示

????1. 容量管理

PaaS 平臺的資源交付是完全自助的,不需要運維人員介入審批,IaaS 層的資源容量是有限的,因此,從接入層,應(yīng)用層,IaaS 層,構(gòu)建全面的自動化容量評估系統(tǒng),顯得尤為重要.需要關(guān)注幾個點：

• 資源調(diào)度
  IaaS 層的資源調(diào)度器,一般都是靜態(tài)的調(diào)度策略,是基于資源創(chuàng)建時間點來選取一臺最優(yōu)的節(jié)點進行資源新增.一般來說,我們的調(diào)度策略都會有一定的超額比例.但隨著業(yè)務(wù)的發(fā)展,某些節(jié)點的負(fù)載會比較高,甚至出現(xiàn)資源不足導(dǎo)致系統(tǒng)宕機.
  對于計算節(jié)點,我們有彈性擴展來保證業(yè)務(wù)可用性.但對于數(shù)據(jù)庫如 Mysql,如果出現(xiàn)宕機,對業(yè)務(wù)影響非常大,一個 Mysql 宿主機,可能運行10個以上的實例,一次宕機影響幾十個業(yè)務(wù).
• 容量預(yù)警
  對各類資源設(shè)置一個預(yù)警閥值是非常重要的.比如對于 Mysql 數(shù)據(jù)源,我們主要關(guān)注的是內(nèi)存的分配,那么預(yù)警閥值=(已經(jīng)分配內(nèi)存)/總的可分配內(nèi)存*100%,這個閥值隨著資源池越大,可以調(diào)得越大.
• 容量預(yù)測
  定期發(fā)布容量預(yù)測報告.如對計算資源來說,定期自動預(yù)測不同類型的套餐可創(chuàng)建的數(shù)量.同時,還需構(gòu)建基于一段時間的趨勢預(yù)測,以便及時發(fā)現(xiàn)平臺資源容量突變情況.

????2. 隔離性

• 資源隔離
  私有 PaaS平臺,對 IaaS層資源,一般都是沒有做資源隔離的.比如,像 Mysql 這種多線程的應(yīng)用,單機跑多個實例,可能一個業(yè)務(wù)異常 SQL,就會耗盡宿主機的所有CPU資源而影響其他業(yè)務(wù).因此,對于業(yè)務(wù)實例的質(zhì)量分析,主動發(fā)現(xiàn)實例的質(zhì)量變化,并及早介入優(yōu)化,顯得尤為中重要.

從我們的經(jīng)驗看,大部分的 SQL,只需簡單的索引即可得到明顯優(yōu)化.而這些 SQL 優(yōu)化,只要能及時讓開發(fā)人員知道,他們就有能力去優(yōu)化,或者更近一步,質(zhì)量分析平臺能自動生成優(yōu)化的 SQL,自動推送給開發(fā)人員進行優(yōu)化,或者再近一步,把優(yōu)化的 SQL 應(yīng)用到數(shù)據(jù)實例,并通知用戶執(zhí)行結(jié)果.

• 網(wǎng)絡(luò)隔離
  當(dāng)前我們的IaaS 層未實現(xiàn) VPC 網(wǎng)絡(luò),網(wǎng)絡(luò)上不具備隔離性.這是我們當(dāng)前正在改進的方面.

YY互娛- PaaS 運維平臺未來規(guī)化

1. 面向業(yè)務(wù)/運維的一站式平臺

增強平臺的一站式運維管理的能力,包括容量評估,管理,預(yù)測,質(zhì)量分析,成本分析,容災(zāi)切換等.如圖所示

2. 多語言支持
支持 Task,Node.JS,Python等語言.
支持資源編排.

??3. 自動化、數(shù)據(jù)化、可視化、產(chǎn)品化

進一步提升自動化,包括IT運營分析,容量評估預(yù)測,容災(zāi)備份切換等.
將運維的各項能力數(shù)據(jù)化,并進一步可視化出來.
產(chǎn)品化,提升用戶體驗.
如圖所示：

?4. 業(yè)務(wù)運行于VDC

YY 互娛技術(shù)團隊當(dāng)前推出自主研發(fā)實現(xiàn) SDN,SDC,SDS 的云計算平臺, 初步具備了SDDC 的能力,我們把 SDDC,稱之為 VDC(Vistual Data Center).

在 SDN上采取軟硬結(jié)合的方案,在硬件交換機上實現(xiàn)了基于 VxLAN技術(shù)的VPC網(wǎng)絡(luò)數(shù)據(jù)包的封裝和解封.下一步,我們將構(gòu)建基于VPC的 PaaS 運維平臺.

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4356.html