嘉賓簡介

劉天斯

從事網際網路運維工作已13年，目前就職於騰訊-互動娛樂部，負責遊戲大資料的運營，曾就職於天涯社群，擔任首席架構師/系統管理員。

熱衷開源技術的研究，包括系統架構、運維開發、負載均衡、快取技術、資料庫、NOSQL、分散式儲存、訊息中介軟體、大資料及雲端計算、Mesos、Docker、DevOps等領域。擅長大規模叢集的運維工作，尤其在自動化運維方面有著非常豐富的經驗。同時熱衷於網際網路前沿技術的研究，活躍在國內社群、業界技術大會，充當一名開源技術的傳播與分享者。

導言

受 Reboot 邀約與大家聊聊運維自動化的議題，與大家一起探討如何基於Python構建一個可擴充套件的運維自動化平臺，也希望能與大家一起交流，共同成長。

此次分享將通過平臺具備功能、架構設計、模組定製、安全審計、C/S結構的實現等幾個方面內容來展開。

為什麼選擇Python？

幾點優勢：預設安裝且跨平臺、可讀性好且開發效率高、豐富的第三方庫（開發框架、各類API、科學計算、GUI等）、社群活躍&眾多開發者。

Python在騰訊的現狀，根據去年內部提交元件語言統計，除去2、3、4前端技術，Python在高階程式語言中排第3位。應用在系統運維、業務邏輯、運營平臺、測試工具、資料探勘等領域，騰訊大名鼎鼎的“藍鯨”運維PAAS平臺就是基於Python語言來構建。

一、平臺介紹

OMServer 一個集中式的Linux叢集管理（基礎）平臺（《

1、平臺截圖：

2、平臺採用到的第三方庫:

Django - 一個開放原始碼的Web應用框架，由Python寫成，採用了MVC的軟體設計模式；

rpyc - 一個 Python 實現的RPC和分散式計算的工具。支援同步和非同步操作、回撥等；

saltstack 、ansible 、func - 基本

Mysql - 是一個非常流行的關係型資料庫管理系統。

二、平臺架構設計

1、OMServer架構圖

大家對這個架構應該不會感到陌生，三層結構也是目前主流的運營平臺架構。

2、架構說明

OMServer平臺為三層架構，分別為WEB互動層、分散式計算層、叢集管理服務層。

1）、第一層：即為WEB互動層，典型的B/S架構，以供管理員操作的互動平臺，也是OMServer的核心，基於Django開發；

2）、第二層：分散式計算層，提供與主控端的連線通道，採用的是rpyc傳輸協議，協議操作流程：前端模組引數->加密傳輸->任務執行->返回結果集->解密輸出。

3）、第三層：叢集管理服務層，整合Python主流的遠端操作元件（支援Saltstack、Anaible、Func），對被控端（業務伺服器叢集）進行管理，其中主控端可以根據不同IDC環境，採用多地多點的管理方式，可提升冗餘度及執行效率。主控端操作模組以不同Python檔案加以區分，便於維護，可靈活定製操作邏輯及橫向擴充套件等特點。

3、平臺架構優勢

1）管理端多機支援，可按不同IDC劃分；

2）安全性高，加密傳輸、定義私有通訊規範（TCP）；

3）支援多種管理客戶端接入（WEB、桌面、移動）；

4）呼叫Python元件的高階特性（Playbook、State）；

5）功能擴充套件效能力強，模組定製化。

4、架構操作流程

上圖將三個層次的互動流程進行串連，可以清晰瞭解OMServer架構的操作流程，結束了傳統式直連APP Server的操作，更加規範我們的操作事件，一定程度可以避誤一些潛在的誤操作。

5、整合遠端操作Python元件

分別兩個步驟：

1、提前配置主控端與被控端的信任關係，一般為證書或SSH 認證；

2、通過OMServer主控端封裝好的任務模組與API介面，實現定製化的任務下發及執行。

三、平臺模組定製

1、任務模組定製的思路

1）任務模組 – 即為一個“操作事件”為顆粒的任務，如過載配置、部署快取服務、停止Nginx服務等原子操作；

2）新增模組的步驟：

- 定義任務模組“輸入引數”，採用HTML Form元素，可以為輸入、下拉、單複選框等元素；

- 編寫後臺模組程式碼，其中執行部分由Saltstack或Ansible的Client_API來實現；

  - 任務模組核心程式碼，只需要5行程式碼就可以實現一個SHELL指令碼下發、執行的功能。

3）執行模組的步驟 - 選擇任務模組 & 操作物件 -> 指定輸入引數 -> 執行 -> 返回執行結果。

2、當我們的平臺已經具備可定製、擴充套件操作的能力，運維的核心工作就聚焦以下幾點：

1）平臺功能改進、升級，需要具備DevOps能力；

2）根據業務運營需求，做任務功能模組的編寫的工作；

3）日常工作梳理（標準、流程化建設），更好將原子操作串成流程。

4）系統、業務的調優，服務業務。

四、安全審計的實現

1、安全審計技術架構

安全審計功能模組分兩部分，一部分為操作事件前臺展示，另部分為部署在伺服器側的採集Agent，通過CGI介面上報至資料庫儲存，可對上報的資料作關鍵字監控，發現異常可以觸發告警。

2、Agent上報實現原理

實現原理非常簡單，通過修改Linux系統環境配置檔案/etc/profile，定義history事件相關環境變數，捕捉所有Linux登入使用者會話中的操作事件及指令，實時通過OMAudit_agent.py中的HTTP GET CGI向資料庫寫操作事件流水。

管理前臺頁面通過定時重新整理，獲取最新的操作事件。

五、C/S結構的實現

1、OMServer桌面版截圖

2、OMServer桌面版架構

桌面版OManager基於Wxpython + XRC構建，為兩層結構，一層為桌面客戶端，另一層為叢集管理端，同時相容OMServer管理端，通訊依然採用rpyc協議，與OMServer有以下幾點區別：

3、後續優化

1）整合ansible或saltstack高階功能，如ansibleplaybook；

2）將多個任務模組打包成模板對列，實現原子操作與運維變更流程的結合；

3）引用任務排程Celery，支援更大併發；

4）任務對列支援暫停、中止、重執行功能，實現操作可控。

5）提供與CMDB訪問對接，通用性更強。

Q&A

Q1:個人可以完成運維自動化平臺嗎，需要哪些技術？

當然可以，騰訊內部對運維人員都有一個要求，就是要具備開發能力。Python簡單，容易入手，強烈推薦。

Q2:分享中有提到 CS 架構中安全性高，請問具體高在哪些方面，是什麼原因呢？

一般CS客戶端部署在管理員電腦，通過私有網路、協議與主控端效互，B/S部署在節點與業務叢集同區域，不一樣同網段，另外黑客對WEB層的攻擊遠高於桌面客戶端，網路隔離在這時候顯得尤為重要了。

Q3：自行研發tglog對於海量日誌傳輸是否主要走的udp協議？如果是走的udp協議，怎麼去解決一些資料包傳輸中資料亂序以及資料反序列化問題，或者做了哪些協議層面的優化？

是的，主要走的是UDP協議。tglog同時也是一套資料日誌的規範，約束開發人員打日誌的標準。

目前未碰到資料亂序以及資料反序列化問題，以前面臨一個比較大的問題是丟包情況，尤其在流量高峰期時段更為明顯。

後面在核心、IO優化得到緩解，但無法規避，所以我們對比較重要的日誌採用TCP傳輸。比如玩家消費流水。

Q4：規範化、標準化遇到最大問題是什麼？我們遇到就是無法行政干涉開發如何寫程式碼？有什麼好的方式去引導規範？尤其是開發有很繁重的開發任務.

這已經不是運維層面推動的事情，必須升級到運維及開發的上層領導，開發任務繁重不是理由，上線後出問題一樣得不償失，提前丟擲風險，讓開發人員認真做好上線前的評估。

Q5：運維管理系統安全性這塊有什麼好的思路？

1、網路的隔離，避免直接暴露在公網；

2、辦公電腦需要有一套標準的日常安全規範，尤其是運維辦公機；

3、平臺編碼人員需要有較好的安全意識；

4、多關注業界安全、漏洞事件。

==========================================