您好,登錄后才能下訂單哦!
本篇內容介紹了“怎么從生命周期的角度來規劃數據庫運維體系”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
最近在和團隊規劃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的路徑來演進。
底座的兩大分支是云平臺建設和服務建設,云平臺建設覆蓋面更大,提供的是產品化思維的服務交付,對于技術架構和開發效率的要求較高,這部分不能好高騖遠,還是得結合自身情況來提供強大的動力,其中,元數據建設是核心目標,在這個層面元數據要集成,實現流程化管理。
而右側的服務建設更貼近后端服務,從生命周期的角度來進行實例,數據庫,表,字段,索引層面的周期性管理,而提供的輔助服務則是更加貼近運維實際的,比如慢日志優化,巡檢服務和故障自愈,和業務側是一種半透明的開放形式。
“怎么從生命周期的角度來規劃數據庫運維體系”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。