作者簡介：

劉亞丹   YY 互動娛樂事業部運維經理

負責YY互娛事業部的基礎運維平臺建設管理工作，8年網際網路運維從業經驗、經歷伺服器從數百到數千的規模，走過從手工運維到自動化平臺化運維方式轉變，積極擁抱雲端計算大潮，推行 Web 類業務邁向虛擬化雲化的基礎設施，致力於 PaaS運維平臺的 ITIL理念與 DevOps 理念融合、對雲形態下的網際網路企業運維平臺建設管理有較深理解和實戰經驗。

前言

雲端計算從2006年 AWS 推出 EC2開始，至今已經10年，從最開始多數人不清楚雲端計算為何物，到如今，大到 BAT等網際網路公司,傳統金融、證券、製造業企業，小到初創企業，都在積極推進雲端計算戰略，以此加快業務交付效率，降低成本、提升競爭力。雲端計算的首要目的是將底層硬體抽象化，向上提供計算資源，儲存資源，網路資源。

其關鍵核心是提高了IT業務交付效率，使企業花費更少的錢，辦更多的事情，同時滿足質量，安全的需求。在雲端計算大潮下，企業內IT部門，需結合自身的業務特點，思考提供怎樣的雲端計算基礎設施服務（IaaS）,以及基於 IaaS又提供怎樣的 PaaS ，才能滿足企業對於質量，效率，成本，安全四元組合的最佳要求，是擺在每一個運維從業者面前的問題。

YY 互娛基於 DevOps 理念，並結合 ITIL 最佳實踐理念，從13年開始推出自己的IaaS，基於自身條件，推出一套符合企業內部要求的私有 PaaS 運維平臺，並在實踐中不斷的改進完善IaaS，PaaS。本文將系統的從4個方面，分享YY互娛運維團隊對於 PaaS 運維平臺實踐經驗及未來展望，希望對大家有一些參考意義。

一、 運維價值體系

說到運維，還得從運維的價值體系說起。運維的價值體系，從四個維度來概括，即質量，效率，成本，安全。這體現的是一個經濟問題，是運維部門總結工作時，公司高層能聽得懂的語言。我們從事一切運維工作，大到公司運維平臺體系構建，小到某項具體運維工作，最終將從這4個維度的資料來衡量，因此，運維工作應該以提高業務的質量，效率為出發點，在成本和安全中尋求最佳平衡點。在雲端計算的形式下，應當以自動化，服務化等技術手段為依託，資料化，視覺化體現運維的價值輸出。

二、 運維平臺化方式

縱觀整個運維技術的發展歷程，運維平臺化體系建設，我們認為主要有以下3種形式。

1. 面向流程

提供獨立的工具子系統，再將工具 API 化，向上提供整合能力。

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

假如一個 Web 業務需要上線，需要伺服器資源，需求人（開發或者業務運維）需要到 CMDB 檢視是否有空閒資源，若有，則到“伺服器申請”流程裡面提一個工單，經過一個審批流程（至少3個審批節點），拿到伺服器。

同樣，業務上線還需要資料庫，需要快取，需要 DNS 解析，需要開通許可權，需要新增監控等等，需求人都必須到相應的系統提單，才能完成需求。這樣的流程體系下，對於需求的管理方是比較好的，各類需求，資源都可以較好的記錄以及控制。

但對於核心的業務上線，變更、即面向使用者的價值交付，效率很低，業務上線週期長，人力成本高。

ITIL 最佳實踐中總共包括六大操作流程五大服務支援流程，流程都包括五大要點：流程目標、基本概念、主要活動、好處與風險，以及關鍵績效指標與報表。以流程為導向建設運維體系，在網際網路時代本身變化極快，不斷試錯，追求敏捷高效的目標衝突越來越大。

ITIL 面向流程的運維體系亟需改進，而改進的方向，即面向業務的服務化方向改進。

2. 面向服務

基礎元件API 化（IaaS化），向上提供整合能力,再做面向運維的集中資訊管理,配置管理，變更管理等。

如上圖所示，我們仍舊以一個 Web 業務上線的場景，來進行說明。

面向服務的運維平臺，首先需要構建底層資源的 IaaS 化，API 化。有了 IaaS化，我們就具備了提供一個一站式的運維平臺的基礎能力。在這樣的運維平臺上，業務上線需要資料庫資源，平臺提供對應的例項配置套餐，一鍵建立並返回給使用者。

同樣，制定一套標準的釋出規範，實現自動化部署，業務在釋出的時候，從 IaaS 資源池自動分配伺服器。其他的資源，如 CDN，域名解析等，同樣可以在平臺上自助完成。

這樣，業務上線的流程，全部以自動化，自助的方式完成。再往前，平臺與持續整合，自動化測試平臺進行對接，即可完成自動化測試，並根據自動化測試結果來決定是否進行釋出。

這裡面主要是以 DevOps 的理念來構建運維平臺，這個方式也是我們的實踐方式，後續內容將詳細描述。

3. “拿來主義”

1. 公有云平臺公有云平臺提供了完備的基礎資源和強大的功能特性，且具體完善的 API，一般創業公司完全可以基於公有云平臺進行運維平臺化管理，無需自己再去開發一套運維管理平臺，也沒有能力去開發。不過一旦公司做大，考慮到單一供應商的風險，勢必考慮至少兩家雲平臺的資源，甚至可能還存在自有資料中心，這樣就面臨著混合雲管理需求。
2. ITSM 商業軟體
   在雲端計算和 DevOps 驅動下，當前也有商業的ITSM 管理軟體，提供一站式運維管理平臺軟體或者服務，而不是提供離散的 ITSM 管理套件。這類軟體，在網際網路+的時代，對於傳統行業的 IT 部門轉型升級會非常有幫助。

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

業務場景

YY 互娛在這幾年處於高速發展的過程，即要穩固拓展 PC 端的市場，又需要在移動端尋求突破，業務場景：

1. 快速試錯

網際網路時代競爭激烈，特別是移動網際網路時代，誰能快速推出產品，快速迭代，誰就能在市場上佔得先機。快速試錯是一種常見的競爭手段。PaaS 平臺的業務交付執行模式，最大特點就是效率高，成本低，可以很好的滿足快速試錯的業務需求。

2. 人力不足

長期以來，網際網路企業在運維方面的人力投入是不夠的，很多時候是扮演的救火員的角色，PaaS 在平臺層面提供一站式運維服務，高可用架構質量保障，減少業務上線對運維人員的依賴，在不需要運維人員介入，開發人員自己就可以上線業務，並持續迭代。

基於 IaaS 的 PaaS 平臺，將硬體環境與軟體環境進行了解耦，也降低了硬體故障對線上業務的影響，釋放了運維自身的壓力。

3. 成本壓力

業務上線需求多，如果按傳統的方式提供物理資源，對資源的需求量極大，而業務的訪問量，生命週期不可預測，造成硬體資源利用率低。很多時候通過混合部署業務，提高硬體資源利用率，造成後期維護成本非常高。

平臺理念

基於上面的業務場景，以及雲端計算的大背景，YY 互娛技術團隊基於 OpenStack ，推出自己的 IaaS平臺，主要面向遊戲業務的雲端計算平臺。基於 IaaS能力，逐步構建自己的PaaS平臺。

我們的平臺理念是：運維技術服務化，轉化為生產力。平臺提供高可用高效能高質量的基礎架構服務，滿足業務的快速交付。平臺提供一系列的工具，元件，來支撐開發人員自助式運維。

開發人員只要使用平臺，無需找到運維人員，就能應用運維的能力，如高可用，彈性伸縮，配置管理，容災備份等能力，達到 NoOps 的目的，減少開發、運維不必要的溝通成本，使開發人員專注於業務開發。

執行 DeoOps 理念，平臺將開發、測試，運維流程自動化打通，將持續整合，自動化測試的能力以服務化的方式輸出到平臺。最終，將業務價值交付涉及的各種能力，通過平臺輸出到業務，達到技術服務轉化為生產力的目標。

實踐歷程

1. 整體架構

PaaS運維平臺的整體架構：

兩種顏色代表兩個檢視，藍色部分代表從業務維度的檢視，即從PaaS平臺使用者的維度看到的架構。灰色部分代表從運維自身的檢視，即運維全域性的檢視。

從業務維度的檢視，大概分為4層，從下而上，面向服務，包括硬體層，IaaS，PaaS和業務層。

從運維自身的檢視，包括全域性資源中心，監控中心，資料來源中心，報表中心，安全體系等。

接下來的篇幅，主要把面向業務的各個核心元件及實踐做介紹。

2. 標準化

標準化是運維自動化的基礎，PaaS 平臺的標準將以系統化，自動化的方式落地。
標準化主要包括這些規範：

• 基礎應用軟體規範（Nginx,Resin,Tomcat等）
• 應用程式打包規範（Java,PHP）
• 應用程式部署規範
• 監控規範
• 其他

以上規範，全部落地到PaaS 平臺的各個子系統，由子系統自動化完成。比如對VM 環境的標準化，通過 VM 映象方式交付。

3. IaaS

我們的 IaaS 層提供了以下服務，來滿足我們的應用上線。

• 計算虛擬化
  計算虛擬化部分，我們這裡使用 VM，將 VM 作為我們容器計算的最小單元。當前使用 OpenStack 開源實現方案，使用 KVM 做 hypervisor。提供各類 VM 套餐滿足不同業務場景。計算能力擴充套件我們採取的 VM 的橫向擴充套件，即 ScalingOut，後面章節會介紹。
• 儲存虛擬化
  考慮到效能問題，我們VM使用了本地儲存。沒有使用 Ceph分散式儲存。
  物件儲存上，對接了公司提供的基礎服務。
• 網路虛擬化
  網路部分，採用了Neutron Provider Network，未實現 VPC 網路隔離。
• 資料來源
  • 資料來源我們提供了3類資料來源，Mysql，Redis，Memcached。這3類資源是平臺上使用最頻繁的元件。我們以單物理機多例項的方式執行，未主動採用 cgroup 進行資源隔離。這些外掛在被建立的時候會自動新增監控，使用者可以在平臺檢視相關監控狀態資訊。
  • 外掛平臺。上述基礎元件以外掛方式與平臺整合，類似於 Heroku 的 Addons服務。

具體業務流程描述如下：

• 外掛註冊：外掛開發者將自己開發的外掛接入外掛平臺。
• 獲取外掛：PaaS 平臺的專案使用者請求外掛平臺，獲取外掛授權資訊。
• 返回授權：外掛平臺將來自 PaaS 平臺的請求轉發到具體的外掛，獲取具體外掛的地址，授權等資訊，並將資訊儲存在外掛平臺然後返回給PaaS 平臺。比如 Mysql 例項，返回域名，埠，賬號，密碼。
• 外掛注入容器： 專案模組釋出的時候，由CloudRouter 從 PaaS 平臺上獲取外掛資訊並將相關資訊註冊到業務容器環境變數。關於 CloudRouter 的功能，後續會詳細描述。
• 容器訪問外掛：業務容器從環境變數中獲取到的外掛資訊，直接請求具體的外掛。外掛平臺的引入，增強了PaaS平臺的開放性和靈活性，專案所需的所有基礎元件，不需要 PaaS 平臺自己提供，可以由公司其他開發同事提供。外掛平臺面向公司內部所有開發人員，設定了一定的運營策略，如貢獻率,引用量，收穫贊等，並與公司的績效積分，技術職級評定做一定關聯。
• 
• 其他資源
  其他基礎服務，我們同時提供了 CDN，訊息佇列等。
  CDN 是使用第三方廠商基礎服務，通過 API對接，實現一鍵建立 CDN 服務。訊息佇列服務底層採用了 RabbitMQ叢集。
  同樣，這些資源也以外掛方式整合到平臺。

4. 持續交付

基於上面的 IaaS 層，我們有了構建 PaaS 的基礎能力，來解決持續交付的問題。我們從以下幾個方面來描述

• 交付模型

交付模型，指在我們的 PaaS 平臺上的業務，構建一個業務的模型。這個模型也是基於我們的應用程式打包規範來做的。這裡再簡單描述下：

• PaaS 平臺業務交付的物件包括：人, 專案，模組。
• 人即專案管理員，一個人可以管理多個專案，一個專案也可能是多個人管理。

專案對應的是一個業務，一個專案又分多個模組，每個模組就是一個獨立的部署單元；模組一般是按功能進行劃分，比如最常見，一個專案有 admin 模組，user 模組。我們的PaaS平臺的部署操作最小單元是專案的模組。以 Java 應用為例，模組的型別有 War和Jar。不同型別對應不同的部署動作。

• 專案管理

專案的管理包括專案的新建，以及使用者許可權管理，屬性管理。需要的基礎資訊包括：專案 程式碼庫地址，專案成員等等。
專案管理中涉及的資訊

• 持續整合
  以Java 專案為列，我們約定在 pom.xml 根據模組名稱打包成對應型別的包。並自動建立對應的專案模組，打好的程式包上傳到分散式檔案系統（DFS）。實現只要將程式碼提交到版本庫，即可一鍵打包釋出。在我們的現實情況中，並沒有對每一個專案要求持續整合，而是選擇性的，其中的原因是：
  • 大部分專案都是小型專案，不涉及多人協同開發，這樣的場景下不涉及到複雜的持續整合場景。
  • 小步快跑。本身專案的迭代速度比較快，整合頻率比較高，一般不會出現持續整合不通過導致需要花費大量精力解決整合失敗的問題。

• 持續測試
  PaaS 平臺與自動化測試平臺進行對接，在基礎資訊上同步共享，包括專案名稱，專案成員，版本庫地址等。持續測試的實踐經驗是：
  • 業務分級。對核心專案進行嚴格的持續測試，包括單元測試，QA 自動化測試。對非核心專案，預設不進行測試。是否測試的許可權交給專案管理員，專案管理員一般都是開發團隊的 Leader。
  • 風險控制。在實際的運作中，測試能發現的問題是有限的，需要考慮一旦出現問題的補救措施。因此，對於核心的業務系統，引入風險監控，降低 bug 的影響範圍。
• 持續部署
  持續部署中，涉及到如下幾個問題，我們的解決方案是：
  • 資料來源。專案所需的資料來源（Mysql，Redis）例項，使用者在平臺上一鍵建立，然後通過環境變數的方式注入到業務容器。具體流程見前面章節“外掛平臺”所描述。
  • 配置管理。包括執行環境的管理，JVM 引數定製，Nginx 引數定製，域名配置，證書配置等，這類配置全部在平臺，由使用者自助或系統自動化完成。
  • 釋出。涉及“包版本”釋出審批，伺服器資源自動分配，“配置管理“中涉及的各項配置應用到相關元件。
  • 回滾。平臺支援包版本快速回滾。
• 持續反饋
  • 基礎資源監控及監控資料展示
  • 執行維護
  • 業務可用性監控和資料展示上述三點在後面的章節詳細說明

5. 高可用架構

平臺架構高可用設計，從最上層的攻擊防禦，到資料持久化層，全部提供高可用方案。業務只要接入平臺，就具備全部的能力。。

• 雲防DDOS，接入公司層安全中心的DDOS 防火牆，保障業務安全。
• GSLB，平臺提供多機房，多鏈路接入的能力。專案域名自動解析到多個機房，提供就近接入的能力。
• OSPF-LVS，四層負載均衡採用OSPF-LVS 架構，具備平滑的水平擴充套件的能力。

• AppRouter 應用路由層，Nginx提供七層的路由轉發，同樣具備平滑的水平擴充套件能力。
• Container，應用邏輯層。這一層是專案級別的配置。提供 Nginx+容器（Tomcat，Resin,PHP-FPM）環境。這一層引入 Nginx，是考慮到部分七層業務邏輯控制，交由專案級別的控制，不至於每次專案級別的變更，而影響上一層AppRouter 全域性層面的變更。這一層具備彈性伸縮的能力，後續章節具體講解彈效能力實現方式。
• Cache 層，提供純 Cache 和資料型 Cache。這一層我們主要是使用的 Redis，以域名和埠的方式對外暴露，通過域名切換，具備故障切換的能力。
• DB資料持久化.這一層目前對於所有業務例項，預設提供帶主從的例項對，業務發生故障時，需要根據業務場景對資料一致性要求情況，進行故障切換。這一層當前未引入開源類似 MHA,MMM 等架構，而是通過域名切換的方式來實現，這裡面參考了 AWS 的實現方法。我們的架構一般都是 MM 架構，當主節點發生 Down 機後，域名切換到從例項，Master 恢復後，只要修復主從關係即可。對於高併發訪問量的業務，需要一主多從，或者 Mysql 環形複製場景，這些需要根據業務特性做一些人工介入。

6. 彈性擴充套件

• 彈性
  彈性是 PaaS 平臺的基本能力，彈性技術的好處有：
  • 高效能：在業務訪問規模上去時，伺服器自動增加，保證效能
  • 經濟性：在業務規模降低時，自動收縮伺服器，節省成本
  • 高可用：如果有伺服器宕機，自動進行故障隔離
  • 平滑部署：實現熱部署，不影響現有業務執行彈性伸縮提供包括動態伸縮，熱部署，故障隔離三層含義。彈性示意（圖十四）

我們的彈性技術是由CloudRouter 和 CloudMonitor，資源池3個部分組成。架構：

• CloudRouter是核心元件，是彈性排程的大腦，在使用者的任務，資源分配中間起核心的排程協調的作用。
• CloudMonitor 負責專案伺服器的狀態資料收集，並提供介面供 CloudRouter 查詢狀態。
• 資源池是基於預建立的可用資源緩衝池。這裡主要是指 VM 資源。VM 資源又分為多種配置，對於每種配置的資源，可在後臺配置預先建立一定的數量。一旦服務需要資源，可立刻從池裡獲取。
• 彈性的策略. 當前我們的彈性策略是模組的所有 VM 的負載平均值。當負載平均值大於我們們指定的彈性閥值，則進行擴充套件，可設定每次擴充套件的伺服器數量。同樣，當平均值小於我們指定的閥值，則進行縮減。

在實際的業務場景中，可能有些業務是內部小型專案，不需要進行彈性，是否彈性是一個可選項。另外，還有一些專案，可能無法滿足無狀態的設計要求，不希望每次部署都更換伺服器，我們也提供了在部署的時候，選擇“就地部署”，就地部署的意思就是每次部署都使用同樣的伺服器。彈性排程策略配置：

7. NoOps

• 自主運維

平臺提供一系列日常運維管理工具，包括常見的伺服器效能查詢，日誌查詢，應用分析工具，資料來源相關資訊查詢。大多數場景下，開發人員無需登入伺服器。

• 日誌管理
  日誌管理方面，我們提供了兩種方式
  • 文字日誌。我們在每臺vm上通過 Rsyslog 程序收集業務程序日誌發到集中日誌伺服器。在集中日誌伺服器端，我們按專案名稱儲存，一個專案一個日誌目錄。日誌目錄許可權管理，我們使用Linux 使用者組許可權設定，只有具備PaaS 平臺專案管理許可權的使用者，才能檢視該專案下的日誌。
  • Web 日誌分析。PaaS 平臺對接了公司級的 Web 日誌分析系統，能夠實時展示專案域名的日誌訪問量，頻寬流量，請求狀態等情況。
• 監控
  平臺監控主要是基於 Zabbix 做了一些 API 層面的定製開發，我們內部稱之的為“CloudMonitor“。主要包括以下三個方面功能：
  • 基礎監控
    VM:基礎監控包括 CPU,記憶體，磁碟 IOUtils，磁碟空間使用率，網路流量，TCP連結數,程序數等。監控資訊如圖：
    
  • 資料來源：對 Mysql，Redis，Memcached 常規指標做了監控。
    自定義監控。支援 TCP,DNS,PING,HTTP,支援自定義告警條件和策略。如圖：
    
  • 告警。平臺告警由 CloudMonitor 元件負責，支援多種方式告警。CloudMonitor 元件是在Zabbix 的事件介面上，定期獲取事件，按業務維度進行彙總分析傳送給業務開發負責人和運維負責人。做了一定程度的事件聚合，比如宿主機 Down 機，宿主機上的 vm 相關資訊關聯起來，從業務開發負責人看：某 vm Down 機是由於某宿主機引起；從運維層面看，某宿主機 Down，影響了這些 vm，這些 vm 運行了這些業務。
• 工具元件
  在自助運維場景中，開發人員需要對專案 ，域名，IP 資訊進行查詢，平臺提供相應的工具。
• 可用性反饋
  平臺的可用性反饋，主要是對平臺各個層面的服務可用性，進行系統化，自動化評估。這裡主要介紹下我們的業務的可用性度量實踐方法。
  我們稱為“Monitor.X監控規範”具體描述如下：
  • X代表語言。(注：若是 PHP 專案，檔案字尾為 monitor.php；若為 node.js，則檔名為，monitor.js）。
  • 路徑要求：url規則為http://專案域名/monitor/monitor.X）專案域名取配置管理裡面，設定域名框中，去掉 包括 test 字串後的第一個域名。
  • 輸入引數：介面不用輸入引數。
  • 輸出說明：介面輸出只分為兩種，正常和不正常。
  • 正常：狀態碼為200，且輸出包括字串“200”
  • 非正常：狀態碼200或者非200，且輸出字串不包括200。 (可以用作錯誤提示內容)。
  • 對於狀態碼200，同時資訊也包括200字串，但是實際是服務不可用的情況，需要程式設計師特殊處理返回資訊。
  • 介面內部實現要求：要覆蓋系統的核心業務邏輯(業務自身把握)；有多個業務邏輯時，也是統一在一個介面返回(呼叫順序由業務控制)。

業務在PaaS 平臺釋出，平臺將自動加上專案的 Monitor.X 監控，根據 Monitor.X 的狀態，來衡量業務是否可用。可用性反饋如圖：

8. 安全審計

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

對於核心專案的資料變更類的操作，引入運維審批。

9. 平臺運營

雙向反饋
構建平臺使用者反饋溝通群組，第一時間接受響應使用者的需求，重視“客戶滿意度”，並將客戶反饋的問題，由專人進行收集彙總，每週發出平臺質量問題週報，並組織開發運維力量，集中有效解決使用者反饋的問題。這些問題，有技術性的，流程性的和體驗性的，使用者每一個問題的互動過程，通過溝通群傳達給平臺每一個使用者。

體驗優化
長期以來，在面向技術人員的系統 UI設計，使用者體驗是不好的，內部技術平臺首要解決的是可用性問題。PaaS 平臺需重視使用者的體驗，體驗好也才能實現我們的 NoOps 的理念。試想一下，如果我們做了一個自己覺得很厲害的功能，而使用者覺得不好用而棄用，那做的可能就是無用功。

也許有種擔心，我們已經把所有的使用者放在一個群裡面，任何一個細節問題，體驗問題，都會讓所有使用者知曉，平臺維護者比較被動。我們的經驗是，在 DevOps 文化下，平臺的建設者（運維團隊），平臺的使用者（開發團隊），都有面向業務終端使用者價值交付的共同目標，都將以合作，包容的心態，共同推動平臺的進步。

平臺收益

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

• 質量
  基礎元件平臺保障高可用，故障自動隔離。應用容器彈性伸縮，確保在業務變化中得到穩定的服務質量。平臺提供自動化可用性管理方案，對業務質量形成有效反饋。
• 效率
  執行 DevOps 理念，將研發，測試，運維全流程以自動化的方式整合，實現業務的快速交付。提供豐富的自助運維工具，系統，滿足開發自助式運維需求，提高日常維護的效率。
• 安全
  在網路安全和系統安全上，接入公司級安全體系，包括雲防 DDOS,主機基線安全，主機漏洞檢測，應用層引入公司的 WAF模組。在資料安全和 D/O 許可權分離上，平臺隔離開發人員登陸生產環境和生產資料庫的許可權，所有許可權全部收攏在平臺上，變更類操作自動引入工單，由運維介入審批。所有操作記錄可跟蹤。
• 成本
  通過 IaaS 層的計算虛擬化，資源池，彈性伸縮等技術手段，提高系統資源利用率，減少硬體資源採購。通過自動化的技術手段，減少人力資源的投入一站式的運維管理服務平臺，大大減少人員流動導致專案的交接成本，降低人力成本。

平臺風險

PaaS 平臺的風險，如圖所示

    1. 容量管理

PaaS 平臺的資源交付是完全自助的，不需要運維人員介入審批，IaaS 層的資源容量是有限的，因此，從接入層，應用層，IaaS 層，構建全面的自動化容量評估系統，顯得尤為重要。需要關注幾個點：

• 資源排程
  IaaS 層的資源排程器，一般都是靜態的排程策略，是基於資源建立時間點來選取一臺最優的節點進行資源新增。一般來說，我們的排程策略都會有一定的超額比例。但隨著業務的發展，某些節點的負載會比較高，甚至出現資源不足導致系統宕機。
  對於計算節點，我們有彈性擴充套件來保證業務可用性。但對於資料庫如 Mysql，如果出現宕機，對業務影響非常大，一個 Mysql 宿主機，可能執行10個以上的例項，一次宕機影響幾十個業務。
• 容量預警
  對各類資源設定一個預警閥值是非常重要的。比如對於 Mysql 資料來源，我們主要關注的是記憶體的分配，那麼預警閥值=(已經分配記憶體)/總的可分配記憶體*100%，這個閥值隨著資源池越大，可以調得越大。
• 容量預測
  定期釋出容量預測報告。如對計算資源來說，定期自動預測不同型別的套餐可建立的數量。同時，還需構建基於一段時間的趨勢預測，以便及時發現平臺資源容量突變情況。

    2. 隔離性

• 資源隔離
  私有 PaaS平臺，對 IaaS層資源，一般都是沒有做資源隔離的。比如，像 Mysql 這種多執行緒的應用，單機跑多個例項，可能一個業務異常 SQL，就會耗盡宿主機的所有CPU資源而影響其他業務。因此，對於業務例項的質量分析，主動發現例項的質量變化，並及早介入優化，顯得尤為中重要。

從我們的經驗看，大部分的 SQL，只需簡單的索引即可得到明顯優化。而這些 SQL 優化，只要能及時讓開發人員知道，他們就有能力去優化，或者更近一步，質量分析平臺能自動生成優化的 SQL，自動推送給開發人員進行優化，或者再近一步，把優化的 SQL 應用到資料例項，並通知使用者執行結果。

• 網路隔離
  當前我們的IaaS 層未實現 VPC 網路，網路上不具備隔離性。這是我們當前正在改進的方面。

YY互娛- PaaS 運維平臺未來規化

1. 面向業務/運維的一站式平臺

增強平臺的一站式運維管理的能力，包括容量評估，管理，預測，質量分析，成本分析，容災切換等。如圖所示

2. 多語言支援
支援 Task，Node.JS，Python等語言。
支援資源編排。

  3. 自動化、資料化、視覺化、產品化

進一步提升自動化，包括IT運營分析，容量評估預測，容災備份切換等。
將運維的各項能力資料化，並進一步可視化出來。
產品化，提升使用者體驗。
如圖所示：

 4. 業務運行於VDC

YY 互娛技術團隊當前推出自主研發實現 SDN，SDC，SDS 的雲端計算平臺， 初步具備了SDDC 的能力，我們把 SDDC，稱之為 VDC(Vistual Data Center)。

在 SDN上採取軟硬結合的方案，在硬體交換機上實現了基於 VxLAN技術的VPC網路資料包的封裝和解封。下一步，我們將構建基於VPC的 PaaS 運維平臺。