當你寫了太多的數據庫腳本，做了太多的自動化工作時，面對零散的新需求，嘗試自動化時是否需要按使用頻率提高自動化水平。

假如有個常見需求，數據庫裏刪除一個大表裏的部分數據，或者redis刪除一個key

做為運維，需要考慮表有多大，是否要循環刪除，刪除條件是否有索引， redis的數據類型，如果是list,set,zset，需要考慮大小，是否需要循環清理

第一階段，把循環刪除動作寫在一個循環腳本裏。 運行腳本完成這次任務

第二階段，把這個腳本做成通用性，以後再有類似的同樣的需求，可以傳參過來完成

第三階段，判斷各種情況，如,size,索引，類型 等。加上判斷，以適應更多的情況

第四階段，處理異常，加上各種異常時的處理或重試機制

第五階段，做成頁面化，可人性化的工具化，降低使用成本，目標是非dba的其他rd或運維人員可以簡單使用

第六階段，做成服務化，讓目標受眾除dba以外的人可以平滑（甚至無感知的）使用，將多個自動化系統集成到一個工具或一種服務

後面的就不清楚了，回想我記過的n多腳本和工具

10% 停在第一階段

40% 停在第二階段

20% 停在第三，四階體貼

25% 停在第五階段 （沒錯，就是這麽喜歡搞頁面化！）

5% 搞成業務都不知道後面有運維在支撐。

以

談談數據庫運維自動化