取捨有道：看移動雲資料庫自動化運維平臺建設之路
本文根據dbaplus社群第172期線上分享整理而成，文末還有好書送哦~
講師介紹
劉書浩
中國移動DBA
負責“移動雲”業務系統的資料庫運維、標準化等工作；擅長技術領域MySQL，熟悉MySQL複製結構、Cluster等架構及運維優化；具有自動化運維經驗，負責“移動雲”資料庫管理平臺的開發和部署。
一、前言
作為雲服務供應商，“移動雲”發展到現在大約有15萬的在網客戶，提供雲主機、雲端儲存、雲網絡、雲安全、RDS等大約10種產品。
隨著“移動雲”業務的不斷增長以及全國各地資源池的陸續上線，我們管理的資料庫例項較兩年前翻了一倍，但DBA人數基本沒有變化，一方面是因為“移動雲”標準化完成的比較早，另一方面要歸功於自動化運維工作的開展，在不到兩年的時間內，我們從資料庫的標準化、工具化過渡到了自動化和平臺化，未來的目標是希望能進一步做到智慧化和服務化。
本文就將針對我們DBA團隊完成的“EcloudDB資料庫管理平臺”的構建和開發思路做一些簡單介紹，主要分享前期資料庫運維遇到的瓶頸，標準化構建和自動化平臺“模組化”、”輕量化“搭建思路方面的內容。
二、自動化運維演進過程
首先，平臺化的過程並不是一蹴而就的。
在業務上線初期，資料庫管理員每天工作強度都很大，因為很多系統是剛剛上線交維的，變更操作比較頻繁，經常會遇到一些突發故障需要處理。即便是簡單的更改資料庫引數配置的工作，也因為MySQL例項數較多，又涉及不同的業務系統，要耗費較多的時間和精力。
在這樣的情況下，我們開始考慮將重複的工作簡單化，並且把我們的資料庫管理人員解放出來，做一些優化類的工作，從而使系統更加穩定。
早期我們主要從標準化、工具化以及指令碼化三個方面探索自動化運維的可行性，並儲備了一些運維研發技術，像Python語言和一些Web開發技術，可以說是平臺化的前身。
1、標準化
首先，標準化是自動化的重要前提。“移動雲”的標準化制定的比較早，並且從OS標準化到DB層的標準化都有著統一的要求。
OS層標準化
主要包括：作業系統版本、檔案系統型別、磁碟排程演算法（Deadline）、RAID、IPSAN掛載、基礎依賴包、NTP服務、SELinux、NUMA特性、ulimit、vm.swappiness、防火牆和網路策略等。
資料庫標準化
- 目錄結構：程式目錄、配置檔案目錄、資料目錄、日誌目錄、PID/Socket、指令碼目錄、工具目錄、軟連線；
- 使用者許可權：bcrdb：bcrdb 775；
- 引數配置：規定了my.cnf檔案全部引數配置、除個別引數（硬體相關、主機IP）外，其餘保持一致；
- 賬號許可權：統一DB賬號許可權要求：最小許可權原則、限定來源IP範圍、加密措施等；
- 密碼策略：安裝密碼驗證外掛，設定強密碼規則；
- 日誌要求：安裝審計外掛，開啟審計日誌、錯誤日誌、慢日誌、binlog和備份日誌；
- 執行緒池：執行緒池引數設定需考慮伺服器硬體配置和業務系統併發情況；
- 常用工具：安裝percona-xtrabackup 2.2.12備份工具、安裝percona-toolkit 2.2.16工具集用於日誌切分、慢日誌分析、線上改表、資料一致性校驗等功能；
- 計劃任務：在bcrdb使用者下建立計劃任務，用於定期進行資料備份及校驗、呼叫Zabbix監控指令碼等。
其中，目錄結構標準化的好處是，無論誰來處理問題，都能根據標準化路徑到達目的地，找到自己所需的內容，也使得我們可以通過編寫指令碼實現對資料庫的批量操作。
標準化的好處有很多，但在未做到自動化部署之前，MySQL嚴格要做到標準化是比較困難的。
早期我們投入了很多精力做“標準化部署文件”，但效果並不好。因為早期部署階段由工程人員實施，而工程人員的流動性比較大，導致對“標準“的掌握並不到位，部署結果總是跟標準化有偏差，經常要進行標準化整改，使部署週期變的很長。
後來我們總結經驗，從“移動雲”五期部署開始，除了提供“標準化部署文件”外，還提供了標準部署工具包和Ansible playbook檔案，通過Ansible工具自動推送部署。到現在資料庫的部署安裝，慢慢用自動化的方式來實施了，進一步保證了標準化的質量。
自動標準化部署過程
Step 1：根據資料庫的部署規劃和配置要求分配物理機或建立虛擬機器。
Step 2：部署Ansible工具。
Step 3：OS初始化，結合資料庫部署要求。
作業系統版本、檔案系統、磁碟排程演算法Deadline、RAID10、掛載點、基礎依賴包、NTP服務、SELinux、NUMA特性、ulimit、vm.swappiness、防火牆端（服務和節點通訊同步複製埠）、網路策略等。
Step 4：上傳Ansible劇本包、標準bcrdb部署包。
- 採用Ansible roles的方式編寫playbook，實現資料庫的批量推送安裝；
- 上傳ansible劇本包playbook.tar.gz至Ansible伺服器的/apps/components/roles/目錄下並解壓；
- 上傳bcrdb.tar.gz程式包至Ansible伺服器/apps/components/roles/bcrdb/files目錄並解壓；
- 修改檔案使用者、組及許可權。
Step 5：制定初始化引數（編寫Inventory檔案）。
初始化引數：
- 叢集節點引數：node_address、node_name、cluster_address
- 業務和硬體配置相關引數：max_connection、innodb_buffer_pool_size、wait_timeout
開啟hosts.sample中資料庫部署Inventory檔案，替換本次部署安裝的實際引數，生成本次部署安裝用的Inventory檔案：vim/components/hosts。
Step 6：執行推送部署
選擇playbooks目錄下對應的資料庫playbook檔案，使用ansible –playbook命令執行安裝
ansible –playbook –i host playbooks/bcrdb.yml
2、工具化和指令碼化
有了標準化作為基礎，我們開始慢慢引入了一些開源工具，有針對性的解決一些運維中的問題。這個階段引入的工具主要有Zabbix、ELK、Ansible、Percona tookit工具集、Percona xtrabackup備份工具。
- 其中，Zabbix的引入解決了資料庫的監控問題，早期我們運維是非常依賴Zabbix的。它的好處是監控項很全，並且有告警發生會第一時間通知到DBA。Zabbix足夠的輕量化，比較容易部署和配置，在運維起步階段提供的幫助是非常大的。
- ELK可以用於日誌採集和分析。我們同步了現網資料庫的審計日誌、慢日誌和錯誤日誌，通過ELK可以按條件對日誌進行篩選和查詢，對於故障快速定位和故障原因追溯有很大幫助。
- Ansible主要用於資料庫批量標準化部署。
- PT工具集主要用來進行日誌切分、慢日誌分析、線上改表和資料一致性校驗等功能。
- Xtrabackup用於資料庫的線上備份，是最常用的工具之一。
同時DBA也不斷開發和自研一些自動化指令碼，例如：
- 自動化巡檢指令碼，用於定期巡檢並按模板生成巡檢報告；
- 備份和備份有效性校驗的指令碼，用於定期執行備份，並對備份檔案的有效性進行測試驗證；
- 另外，還有資料一致性校驗指令碼、標準化核查指令碼等等，用於輔助DBA日常工作，減輕一些重複性的勞動。
3、平臺化目標
有了運維工具和指令碼，解決了我們早期工作中的一些難點，但是工具解決的大部分是如何發現問題，卻很少涉及如何解決問題，而且工具之間的壁壘也使得整個運維體系顯得零零散散。
另外，大多時候運維人員還是要通過堡壘機ssh登入到資料庫主機，再經手工執行命令或指令碼進行運維操作。因此，一定程度上存在操作不便、效率低、重複工作、安全性較差等問題。
總的來說，工具和指令碼運維，雖然緩解了一部分的工作壓力，但是沒有一個體系化的構建。所以在這樣的背景下，我們也開始尋求更高階的運維方式——運維平臺的建設 。
平臺化的目標是整合已有自動化運維工具和手段，將複雜操作、重複操作程式化，並收口登入資料庫主機的操作行為，提高操作安全性，增加管理和稽核機制，提升運維效率，減少人為故障，解放運維人員。
三、自動化運維平臺
1、構建思路
在平臺的構建模式上：
首先，平臺實現的功能要以實用為主，並且可以滿足快速搭建這兩個特點。開發過程中要避免過度設計，後續再以快速迭代的方式對平臺進行不斷完善。
其次是平臺的擴充套件性要好，為了儘量避免耦合採用前、後端分離的方式。因為平臺不僅面向DBA，還要面向一部分系統運維人員和研發人員，因此需要動態選單。不同許可權，不同業務的人看到的選單是不一樣的。平臺還要記錄操作日誌，登入人員做了哪些操作這些資訊還是需要格外重視的，起到一個安全審計的作用。
最後，在互動實現方面，要做到視覺化、自動化和自助化。通過使用直觀的使用者介面，使DBA、開發人員和管理人員能夠清晰的看到資料庫的總體執行情況，幫助DBA更輕鬆地解決複雜的資料庫問題。
2、技術棧
技術棧的選型主要考慮滿足平臺可擴充套件性和快速搭建這兩個特點。平臺後端採用的是Django框架，前端採用Vue.JS，同時利用了快取Redis和MySQL作為資料儲存，整套系統採用的技術棧較簡單，實現的功能對於目前來說是比較實用的。其中：
- vue屬於前端的架構，平臺採用前後端分離的方式，並沒有採用Django的Jinja2，主要是考慮到未來後端框架的擴充套件性以及伸縮性。後臺和前端的互動，只通過標準的restful介面進行資料傳輸。後臺採用成熟的Django架構，能夠快速搭建一個後臺網站。
- Redis作為資訊快取器，主要儲存一些前端Dashboard以及資料庫的基本資訊，加快前端訪問速度。
- Django-Celery模組用於非同步任務，由於一些資料庫操作（備份、任務排程等）執行的時間較長，沒有辦法立即返回結果，因此需要採用非同步形式完成操作。
- Ansible用於一些批量的資料庫推送、搭建以及批量的資料庫配置。
- 資料連線採用pymysql模組，能夠實現不同種類資料庫連線。
3、平臺架構
平臺的架構體系設計為三層：
- 首先是互動層，主要指使用者對平臺的使用體驗，在一定層次上對使用者的操作行為有一定限制性。主要作用是使使用者可以通過瀏覽器對平臺進行操作處理，包括web UI層及介面層。
- 中間是服務層，主要任務是將互動層使用者提交過來的請求及引數，通過相應的API介面連線到後臺，後臺控制器通過各自API和路由列表匹配到相對應的view，然後進行一系列的邏輯處理。這一系列的邏輯處理我們把它歸類為服務層處理。
- 底層屬於資源層，主要包括：資料服務，為服務層提供資料管理、查詢和資料邏輯處理、資料讀、存取等服務；還包括系統層（主要指主機OS層）為上層提供基本的執行環境保障、基礎元件支撐、和本地檔案路徑等服務；另外還有一些其他資源，為上層資料邏輯處理提供公共元件和日誌輸出等服務。
平臺的訪問流程如下：
- 首先，使用者通過瀏覽器訪問前端頁面，前端頁面將請求傳送到後臺API，後臺經過中介軟體，通過使用者認證後跳轉至主頁。根據平臺使用者許可權不同，會返回相應的頁面給使用者；
- 然後是使用者進行自助操作，平臺根據使用者自助操作選項找到對應的view進行處理，view根據請求是否耗時，判斷要不要採用非同步任務；
- 另外，view還需要根據請求檢視是否牽扯系統層的操作，如果牽扯則需要呼叫Ansible介面工具，對遠端主機進行操作。
4、平臺功能
平臺是分兩個階段進行開發，一階段主要實現的功能有：
- Index展示頁面；
- 平臺使用者管理：管理員設定、訪問使用者設定；
- 備份管理：備份執行、備份恢復、歷史備份、備份策略；
- 資料庫賬號許可權管理：DB賬號許可權概覽、賬號申請、賬號審批、賬號管理；
- 例項管理：一鍵標準化部署、例項管理，建立資料庫、表、儲存過程、觸發器、事件、檢視；
- 巡檢管理：一鍵巡檢、常規巡檢項快速排查、自定義巡檢項；
- SQL稽核。
平臺Index頁面
使用者認證成功後會跳轉到Index頁面，主頁最上面可以展示：各資源池MySQL例項總體執行情況，在這可以直觀看到是否有節點存在異常。
下面可以顯示不同資源池、不同業務系統後端資料庫的健康度、效能指標（TPS、QPS、請求佇列長度、活躍執行緒數等情況）以及各資源池告警資訊展示。有了健康度資訊，DBA就可以直觀的掌握生產環境的執行情況，並且在此基礎上，判斷資料庫的執行狀態，對可能出現的問題進行預測：
另外由於資料備份的重要性，我們也把備份監控放在了首頁上進行展示，頁上可以看到備份的執行時間、執行情況、備份校驗和備份檔案大小等資訊。除了以上主頁，還可以展示平臺使用者的訪問和操作記錄。
使用者管理
管理員可以通過使用者管理模組對平臺已註冊賬號的相關許可權進行修改。普通使用者可以通過如下步驟申請開通資料庫賬號：
首先是使用者填寫HTML表單並提交，此時狀態將更新為等待管理員審批，當管理員登入平臺系統會提示有待辦，點開後可進行處理，如果管理員審批通過，系統會自動建立賬號，並通知使用者建立完成。
管理員待辦頁面普通使用者是看不到的，另外，管理員還可以對現有DB賬號的許可權進行修改，也可以建立和刪除賬號。
備份管理
平臺側可以提供備份執行和備份恢復的功能，這裡的備份功能，更多是用於變更前或故障發生時的臨時備份，並不是日常備份。
“移動雲”的日常備份是利用xtrabackup工具在資料庫本地做物理備份，然後定期拉取到測試機上進行恢復校驗，每次恢復測試並不是全量，而是抽樣對核心的資料庫例項做測試，最後通過日誌記錄測試結果，也會定期使用NBU進行異地備份，以上都是通過計劃任務和備份指令碼實現的。
平臺也提供了備份恢復的功能，可以指定某個時間點的備份檔案對現網資料進行恢復。平臺也提供了在測試環境進行資料恢復的介面，可以將個別業務錶的歷史資料恢復並匯出，用於資料比對和故障排查。
平臺側可以對備份策略進行設定，對日常備份的執行時間、保留週期、備份方式等進行設定或修改，並且提供了對每套資料庫進行策略修改的介面，例如：可以設定OP資料庫每週日凌晨兩點執行全量備份，週一到週六每天凌晨兩點執行增量備份，也可以設定備份檔案的保留週期為一個月或兩週。
巡檢管理
平臺設計了一鍵巡檢功能，用於資料庫的例行巡檢。可以選擇多臺資料庫批量執行巡檢，巡檢結果可以在Web頁面上檢視，DBA可以直接填寫巡檢結論。針對每套資料庫會生成一份標準格式的巡檢報告，報告可以從Web頁面直接下載，這項功能為DBA減少了很多重複工作。
巡檢的專案一共有40多項，涵蓋了主機硬體、作業系統和資料庫三個層面。包括：CPU和記憶體利用率、磁碟空間剩餘情況、磁碟讀寫情況、平均TPS/QPS、業務表主鍵、資料量大小和高水位等情況以及業務壓力、慢查詢和備份等情況。
另外，平臺也提供了快速巡檢功能，用於對一些常規項巡檢進行快速排查。常規巡檢項主要是DBA根據以往故障處理的經驗總結下來的一些常用的排查專案，例如：processlist當前連線情況核查、資料庫阻塞的情況核查、鎖爭用的檢查以及一些臨時表和查詢快取等情況的檢查。
對於DBA來說，一般出問題或者接到告警，通常都要登入到伺服器通過手工執行命令排查故障。
其實這個診斷過程完全可以被自動化掉，日常處理問題的核心原則是“快”，所以平臺必須能提供這樣的能力，出問題時儘量減少 DBA 思考的時間，平臺可以將 DBA 常用的排查命令集都整合到一起。DBA 只需要進行簡單操作，系統就會自動執行所有命令，如：SQL執行計劃分析、慢查詢分析、鎖分析、processlist快照檢視等常見操作。雖然這些功能看似簡單但是卻非常實用，可以提高DBA故障定位的效率。
作為對常規巡檢項的補充，平臺也提供了自定義巡檢項的功能。並且執行SQL語句的時候，結合了語義稽核和轉譯的功能，保證DDL及DML的正確使用，不會造成線上事故。
SQL稽核
為了避免效能比較差的SQL語句進入生產系統影響資料庫效能，平臺也提供了SQL語句稽核的功能。
這個功能並不是完全自主開發的，我們藉助了開源工具YearningSQL，並做了一些擴充套件，加入自定義的一些規則。平臺會自動對要執行的SQL做分析，通過觸碰事先定義好的規則來判斷這個SQL是否可以通過稽核，無法通過自動稽核的SQL再由人工來處理。
例項管理
平臺為例項建立，提供了一鍵部署的功能，進一步簡化了標準化部署的過程。平臺通過呼叫底層Ansible模組可以進行資料庫的批量推送安裝，只需要在Web頁面上選擇要推送的主機，並對一些初始化引數進行定義就可以了。推送完成後平臺會呼叫標準化核查指令碼對部署情況進行核查。
另外，還可以在平臺例項管理模組下面，建立資料庫、表、儲存過程和觸發器等。使用者只需要按照選單提交申請。後臺核實使用者許可權後會自動根據需求進行建立。平臺也會自動記錄建立人和組別等資訊。
此外，平臺也為DBA提供資料庫、表和儲存過程的管理介面，DBA可以在平臺側對資料庫、表字段等內容進行修改。
二階段規劃的功能有：
- 日誌管理
- 慢查詢管理
- 阻塞與鎖衝突分析
- 資訊查詢
- 監控告警
四、總結和建議
最後是一些經驗總結，希望能給大家提供一些幫助。
首先，在設計產品或資料架構上要遵循一個原則，就是化繁為簡，避免過度設計，大到功能的實現，小到一些頁面美觀的細節，不要拘泥於追求完美，最好能做到敏捷開發，通過不斷迭代來完善平臺的功能。
其次是開發過程中要注意需求管理。我們在實際開發過程中有過幾次需求變更。相比於早期的規劃，不斷的提出一些新的功能需求，導致開發週期被拉長。
最後，平臺的穩定性是一切的基礎，在正式上線前一定要經過嚴格測試，保證各項功能的實用性和穩定性，這樣才能最大限度的發揮平臺的效率優勢。
Q & A
Q：請問平臺的建設是否採用敏捷性開發呢？
A：採用，一階段先完成基礎功能，後期二階段每次都交付一個最小可用的產品，不斷的迭代來滿足業務需求，可以讓使用者快速看到已經落地的功能，提升平臺的可用性，避免陷入越做越大、交付週期過長的困局。
直播回放