[[339491]]

有時候突然會把幾件不搭邊的事情聯系起來，竟然能夠找到一些共通的地方。我在琢磨最近的幾件事情的時候，腦海里不由得浮現出幾個字：“半成品”

我是蠻反感工作中的半成品的，說有吧，使用效果一般，說沒有吧，也投入了一些時間，概括一下就是投入和產出嚴重不成正比。

另外一類情況更偏于主觀，做任務的人感覺一切都妥當了，但是驗收的時候，發現不是設計理念的問題就是任務的精細度上面比較粗糙，如果本著差不多就行的態度其實也能過去，但是顯然以后的事情誰能說的了，真要用到的時候，代碼邏輯都忘差不多了，重新調試改動，這個工作如果前期能稍微充分難一些，也不會有很多返工。

所以在這件事情上面，我發現以前對自己，對團隊成員的要求有些松散，以至于稍微帶點要求和質量標準，就會感到大家有些吃力，其實對于職業發展來說是有害的，從0到1的構建主要為了效率和快速迭代，可能在一些質量標準上面可以打折扣，過度要求會有些刻薄，但是守江山更難，技術維護也是，都希望時間的邊際成本能夠越來越低，在已有的基礎上構建和改進，那得下真功夫。

我舉一個最近和半成品對抗的小例子，也是鞭策自己能夠繼續按照既定的想法往前走。

這是數據庫軟件的安裝部署的例子，按理說這是很簡單的一件事情了，如果要摳命令，基本都是個位數的命令，但是有一些需要額外補充的地方。

1)不同版本的參數文件，比如環境有5.5,5.6,5.7,8.0等，如何更好的支持多個版本

2)初始化用戶和權限，根據業務特點有些預置的用戶需要創建，配置相應的權限，不同版本下的語法格式都有差異，還有密碼插件相關影響。

3)安裝部署通常是和監控報警，備份恢復相關的，這些工作是不是可以作為可選項

4)單機多實例和service部署模式還是有一定的差別，如何平滑適配

5) 新增數據庫版本支持，已有的接口和部署方式如何適配

MySQL 8.0已經推出了幾年，也在內部做了一些測試和總結，而且早期我們直接入主MySQL 5.7版本，也算是積累了3年多的經驗，所以果斷決定新業務都按照MySQL 8.0的基線來推廣。

已有的腳本都好幾年沒動過了，經過一番需求分析，發現這是一個半成品，主要原因如下：

1)腳本目前直接使用的場景很少，去年團隊下大功夫開發的一鍵部署，因為流程長而顯得比較脆弱，已經和這個功能有了很大的差別

2)腳本執行不穩定，因為之前的腳本設計中采用了很多分散的腳本，也就意味著是腳本調腳本的思路，邏輯相對比較龐大，混雜

3)新增8.0的功能，腳本需要整體改動，涉及的面比較大

4)目前腳本里面也存在一些細小的問題，一直沒有修復

對于這些問題，我做了如下的一些事情。

1)備份腳本內容后，我開始刪除一些過時的邏輯檢查代碼，去掉一些沒有使用場景的邏輯和相關腳本

2)將多個腳本整合為1個，重新組織了腳本關聯依賴

3)將依賴的參數文件模板和腳本模板都上傳到配置中心里面，在腳本里面會用命令方式提取

4)把原來文件夾的腳本結構重構為一個單一的腳本

5)修改前端的配置，去掉冗余無效的配置項，修改調用邏輯

6)團隊內部做了簡單演示，團隊提了一些改進建議，修正后發布

這些工作經過了很多的測試和整理之后，在不同版本中也做了相關的測試和驗證。也算是讓原本半成品的狀態變為可用，而且是最新版本，接下來要做幾件更細致的事情。

1)安裝部署的時間目前在30秒以內，涉及數據字典的初始化，目前使用了一刀切的邏輯，后臺sleep 20秒，保證這個過程的初始化時間足夠，其實可以更加動態友好一些，做動態監測

2)考慮使用基于自制yum的配置方式，把一些固化的參數，命令等方式重新打包構建，這樣后續就可以使用yum的方式快速部署了。

3)把軟件安裝和部署整合起來，提供多版本的軟件支持和安裝，比如8.0.19,8.0.20

4)使用基于壓縮鏡像的模式，可以把一個數據庫壓縮到極小容量，需要時直接解壓啟動即可，經過之前的測試，一個可用的數據庫鏡像大概在2M左右，解壓后在2G~3G左右(涉及ibdata，reod等文件的容量)

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