其實到了現在的階段，我開始做了大量的嘗試，也開始去彌補之前欠缺考慮的一些地方，比如對於業務方向的接入，對此我也做了反思。運維工作中幾點深刻的經驗和教訓
我現在做的一個改變就是更多的承接業務，資料庫部署安裝我接過來，服務開通我接過來，然後把資料庫的DDL變更接過來，雖然忙和累，但是我希望讓我通過這種方式能夠深入業務，找到業務的痛點和我的難處，這樣去尋求解決方案的時候，不會有一種高屋建瓴的感覺。所以接入的業務越多，其實我是希望承接更多，能夠解放自己，如果能夠做到這一點，說明我的實踐是值得的。
所以在很多實現方向上其實我是比較焦慮的，比如我們離自動化的還有距離，更不用提外面大火的智慧運維了。雖然我們考慮了很多的實現路徑，但是不可避免的一些基礎路徑是逃不掉的，那就是指令碼化和工具化。尤其是工具化的工作，大家更是容易忽視。
如果要實現這個方向的事情，我馬上做了如下的實踐。
1.部署安裝的過程，使用指令碼模組化的呼叫，逐個測試，把涉及到手工操作的地方都要做到指令碼化，指令碼化做差不多的時候，其實接入到運維平臺就是一個很自然的事情了。
比如資料庫的安裝部署，我需要檢查這臺伺服器上是否已經有服務，是否已經安裝有其他的例項等等，其實通過後設資料層面我就很容易得到，做出判斷，其實指令碼只是做一些純粹的事情，保證一些基礎邏輯的正確，而如果接入到平臺的過程，其實也是一種工具化的過程，我們可以在裡面嵌入豐富的邏輯，使得整個過程更加高效可控，我想著也就是工具化所希望帶來的一些收益吧。
所以對於一個看似簡單的部署介面，我們糅合了更多的業務場景，比如核心引數優化，系統環境配置，監控配置，備份配置，後設資料配置等等，如果這些都是安裝部署流程中的一個環節，那麼整個安裝部署就算是一個完整的流程了。
另外在實踐的粒度上，我覺得一個比較好的方式就是我們能夠從小做起，比如我們做DDL變更的時候，使用PT工具是很不錯的，對於5.5版本尤其是標配。那麼我們接觸一個業務需求，只是新增一個欄位，做一些簡單的配置，如果資料量不大的情況下，其實我還是建議你用工具來做的，倒不是工具多好，而是希望從這些細小的地方鍛鍊自己，500萬的表變更我做好了，我相信翻幾倍的情況下，你做起來也會從容許多，做這個事情不是炫技術，而是越簡單的場景我們越是重視，通過標準化的操作，帶給自己的收益也會更大。如果提前能夠發現更多的小問題，其實是一件好事，如果這個表千萬上億的級別，變更失敗就很尷尬了。
簡單總結下，運維工作中的指令碼化是我們著重入手的一個開始，然後我們可以把整個過程銜接起來，但是模組化，後期去做一些複雜的邏輯校驗的時候，這算是運維平臺的一個優勢和亮點吧。