[[373933]]

最近在和團隊規劃OKR目標的時候，我們討論了很多問題，我先拋磚引玉，列舉了一些現有的問題，打算按照推導的方式：

1)列舉當前問題

2)問題歸類和總結

3)梳理現有經驗和現有方案

4)結合時間/性價比得到一定時期的預期目標。

整體來看，工作量還是蠻大的，再加上大家對于問題的理解角度不同，所以在容易在很多細節上討論太多，難以聚焦。

所以我想了下，準備按照生命周期的維度來進行考慮，于是整理了一版設計圖，整體是分為四個層面，也就是按照業務從申請資源和權限，到服務上線，服務優化，最后是相關的服務數據遷移和流轉。

整體設計下來，我們會發現很多考慮中不足的地方和遺漏的角度。在多次提煉之后，我把這個設計圖調整為如下的模式：

我來逐個解釋下：

1)規范/選型/規劃：這個階段更強調整體，很多問題如果直接從基礎運維入手，其實就已經晚了，有些服務質量差，交付時間長，本質上還是前期的基礎建設不夠扎實，所以這是一個互惠互利的關系，比如開發規范的設計和落地執行，架構設計(如分布式架構設計)，技術選型(如MySQL 8.0適配的中間件技術調研，ClickHouse技術調研，TiDB技術選型，MyRocks存儲引擎測試分析等)，SQL審核(已有審核服務的升級和改進等)，高可用(重中之重，涉及健康檢查腳本，Consul服務快速切換，數據庫高可用方案預研測試等)，基礎服務(如監控，報警和任務調度等相關服務)，基礎設置(如拋棄CentOS_6等低版本，磁盤配置統一為SATA-SSD等類似的方式)

2)基礎運維：涉及資源交付(包括上下線，資源擴容等)，權限交付(申請賬號，賬號權限變更，賬號回收等)，安裝部署(如數據庫軟件安裝部署，初始化)，基礎配置(基礎配置，如ntp,crontab等)，備份恢復(按照數據備份，數據恢復的基礎維度實現基本備份集，基于時間點的數據恢復)

3)運維優化：對象變更(需要演進為自動化上線模式)，對于大表變更需要集成在線變更工具來實現，此外，重點是做一些相關的優化，如參數優化(如數據庫優化參數，基礎配置適配)，對象優化(數據表優化，索引優化)，SQL優化(執行計劃優化，索引建議等)，配置優化(系統配置，服務配置優化等)

這三個維度做好之后，其實會發現一些還是會恨吃力，那就涉及到數據遷移和數據流轉，數據本身是在不同類型的環境間流轉的，如何保證數據能夠穩定，準確的流轉也是重要的目標。

4)數據遷移和數據流轉，數據遷移主要實現一鍵式數遷移，主要包括兩個個方面：

(1)一鍵式數據庫遷移，從1個服務器遷移到另外一個服務，一鍵實現

(2)數據庫版本升級，如從MySQL 5.5升級到5.7，從5.7升級到8.0等，可以一鍵實現

此外，數據流轉到數據倉庫，大數據，如何高效穩定的支持，如何實現實時的數據流轉機制和多環境間的快速遷移/同步也是重點目標。

對于技術底座而言，首要的目標就是文檔，文檔可以從上面的四個維度拆分為多種文檔,如規范設計文檔，預研文檔，方案設計文檔，操作文檔，案例文檔等。

接下來的服務的交付都應該統一為API的模式，演進可以從腳本到工具，從工具到API的路徑來演進。

底座的兩大分支是云平臺建設和服務建設，云平臺建設覆蓋面更大，提供的是產品化思維的服務交付，對于技術架構和開發效率的要求較高，這部分不能好高騖遠，還是得結合自身情況來提供強大的動力，其中，元數據建設是核心目標，在這個層面元數據要集成，實現流程化管理。

而右側的服務建設更貼近后端服務，從生命周期的角度來進行實例，數據庫，表，字段，索引層面的周期性管理，而提供的輔助服務則是更加貼近運維實際的，比如慢日志優化，巡檢服務和故障自愈，和業務側是一種半透明的開放形式。

本文轉載自微信公眾號「楊建榮的學習筆記」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。