從去年發起里程碑來做自動化平臺的事情到現在，已經幾個月過去了。在這段時間裡，其實我的心態是很焦灼的。
其實從很多維度來說，做運維平臺的事情，從不明朗的需求和定位開始，很難有說服力。
如果用業務價值的一把標尺來衡量，那基本沒戲；如果從做這件事情的難易程度來說，很多人算是從入門到放棄；當然還可以有很多維度。
最直接的一個痛點就是純運維的開發技能不夠好，純開發的運維背景不夠，所以兩者能夠結合起來，算是一種互補，當然做這個事情要投入的精力，還有毅力，你們自己嘗試去推動體驗一下，還是有收穫的。
如果說這個事情的轉變，我覺得雖然慢了很多拍，好歹這個事情算是提上日程了，但是落地的情況雖然差強人意，相比於去年底的時候，已經有了很大轉變。這裡面要做一些工作，從上到下，從下到上。從上到下，就是從一個更高的角度來和領導談這個事情，從意念上達成一個共識，在這個地方我覺得我犯了一個錯誤，那就是如果已經有很多顯而易見的事實，我覺得就不需要去說服別人，說服領導了，但是恰恰在這個點上，我們還是要做一些推動力的，這個時候很可能就是資訊不對稱，我們認為重要，領導認為一般，結果導致了結果有了較大的偏差。
另外從下到上，其實就是事情怎麼去做，算是一些具體的分工和安排了，最糾結的莫過於沒人，沒技術了。其實這個還不算最糟糕的，最糟糕的是大家認為這個事情還不夠重要，先保持現狀吧。這種時候我很焦躁，我們的價值在哪裡。
原來是感覺有很多事情可以做，但是必要性不大，結果有了一些階段性的討論之後，基於各種因素吧，發現事情一旦有了轉機，你就會發現有很多的事情可以做，值得做了。
所以車輪子轉了起來，我覺得好歹就是進步了。
以上的可以理解是牢騷，也可以理解是一個苦逼的心路歷程。對我來說，抱怨不夠，要做解法，所以前期我的投入會很多，以至於我感覺我現在就是做運維開發的了。
運維開發以後怎麼走，我覺得我們可以看看Google的路，運維開發一個很不錯的方向：SRE
SRE的特質有兩條：
1.對重複性，手工性的操作有天然的排斥感
2.有足夠的技術能力快速開發出軟體系統以替代手工操作
SRE的經驗法則
“SRE團隊必須將50%的精力花在真實的開發工作上”。
所以開發了幾個月，平臺搭建起來了，有了初步的系統功能，有了後設資料的基本功能，做了一些基本功能的除錯和使用，我發現事情開始有了變化。
我畫個圖來表達一下。
這可能是我眼中的運維平臺，無論是資料庫運維平臺還是系統運維平臺，大概念就是運維平臺，我希望有樹幹（好的架構），綠葉（支援豐富的功能），果實（有產品的亮點）
結果做著做著發現好像和自己預期的不一樣了。
發現是這樣的情況，其實事實上比這個還要糟糕。
這是什麼，有時候自己都犯嘀咕。對我來說，把以前的工作全盤否定也不太公平，所以，我決定做需求和功能的收斂。期望達到的這樣的一個效果。
這是不是樹，首先可以肯定說是，抓住幾個亮點，有了好的設計，那麼後續的工作要銜接起來就是一個迭代的過程。
所以我希望的結果是這樣的，那些果子可能是一些目前要解決的痛點。
所以在我的腦海裡閃出了一句話，可能聽起來不大好，我決定叫它是“瘋狗一般的執行速度”。
有了前面的思考之後，我發現其實我雖然實現了一些基本功能，但是面對複雜的運維場景的時候還是有些乏力。
我又畫了一個圖，這次是個技術圖。透過這個圖我可以做很多的總結和思考。
假設透過左側的運維機器要訪問資料庫，有很多中路徑可做。
中間的是中控機器，也可以理解是代理伺服器，右上角的是DB伺服器，右下角的是DB伺服器中的資料庫。
比如透過運維機器來訪問資料庫，我們有很多的路徑可選。
如果面對的場景不確定如何能夠做到一種靈活的外掛方式呢。
我計劃分成幾個維度，運維機器-Ops,中控-CM,DB伺服器-host,DB例項-DB
那樣下來就可以拆分，比如ops_to_cm
cm_to_host,host_to_db,ops_to_db,ops_to_host等等
對於每一個路徑或者分支我們可以使用多種技術來實現，到時候串聯起來即可，比如Ops_to_db如果使用程式指令碼邏輯的方式，那麼sql的方式就滿足不了了，我們可以使用ops_to_host,host_to_db,或者加一層中控，ops_to_cm,cm_db來實現，
當然方法有很多種，我們來適配即可。
所以這個地方如果抽象出來，然後單獨實現，我覺得能夠解決一些通用的問題，所以在這裡我把它做概念提取，這就是一個工具管理的功能。
上面的方式其實主要側重點是接入管理，如果我們做針對性的管理，比如系統管理，資料庫管理，其實就可以做很多的細分了，這樣一來，我們拼接出的工具就好比是一個樂高玩具，堆疊出很多的玩法來。
我設計的一個初步的demo是下面這樣的。
說到這裡一定要提一下原型設計的重要性，這個也是我走過的彎路之一。
這是我最近整理的一個運維開發的流程圖。原型設計還是很重要的，如果原型設計沒想明白就開始很具體的資料庫設計，那麼後面要返工的可能會非常高。
這個圖建議大家好好理解一下，可能我的理解有偏差，希望你能夠提出寶貴的建議來。
所以把之前的工作如果再做一層高度的提取，我覺得要做的應該會分為兩大部分，一部分是通用平臺，另一類是業務運維支援。
所以通用模組我的想法應該是能夠普世很多業務場景，我們經過討論，目前補充的會是下面的一些通用模組。
而從基礎運維來說，比如資料庫運維來說，就是一些具體的業務場景了，比如:
-
資料庫一鍵部署
-
資料庫備份模組
-
資料庫恢復模組
-
一鍵搭建從庫模組
-
服務開通模組
基礎打牢了，後面可以做高可用，分散式，SQL稽核等等。
這些工作有些已經做差不多了，有些還沒有開始，所以要繼續我開始說過的，我們需要“瘋狗一般的執行效率”
所以這個里程碑裡我計劃要實現的就是這些基礎的事情。如果這個時候我強調這是一個很重要的轉折點，大家可能就理解了。
通用模組中我比較喜歡的是任務排程，我覺得如果做好，能做太多的事情了，甚至會激發出一些很亮點的功能，當然我現在想的很好，手底下不停使喚，所以我還是會做好規劃，看看能做到什麼程度。
這個月過去，小半年就過去了，如果還是在打口號，在提思想，我覺得就太失敗了。有句話說得好，快就是慢，慢就是快，你太慢了所以覺得哪裡都快，你太快了覺得哪裡都慢，可能就是這個道理吧。我很喜歡做事情主動能拼的同學，我不喜歡追著別人做事情，要達到初步的預期，我覺得有兩點分享下，一個是做事情需要有明確的目標和計劃，比如這個月我要實現基礎的功能，那麼我來拆分，本週，下週，下下週要做的事情。第二就是deadline,做事情沒有截止日期，結果簡直沒法提。
以上就是我的一些基本想法，很多事情聽起來確實泛泛，需要不斷的細化和梳理，要不時間花了，事情沒成，我覺得太不值了。
我的分享就到這裡。謝謝大家。