從去年發起里程碑來做自動化平臺的事情到現在,已經幾個月過去了。在這段時間裡,其實我的心態是很焦灼的。
其實從很多維度來說,做運維平臺的事情,從不明朗的需求和定位開始,很難有說服力。
如果用業務價值的一把標尺來衡量,那基本沒戲;如果從做這件事情的難易程度來說,很多人算是從入門到放棄;當然還可以有很多維度。
最直接的一個痛點就是純運維的開發技能不夠好,純開發的運維背景不夠,所以兩者能夠結合起來,算是一種互補,當然做這個事情要投入的精力,還有毅力,你們自己嘗試去推動體驗一下,還是有收穫的。
如果說這個事情的轉變,我覺得雖然慢了很多拍,好歹這個事情算是提上日程了,但是落地的情況雖然差強人意,相比於去年底的時候,已經有了很大轉變。這裡面要做一些工作,從上到下,從下到上。從上到下,就是從一個更高的角度來和領導談這個事情,從意念上達成一個共識,在這個地方我覺得我犯了一個錯誤,那就是如果已經有很多顯而易見的事實,我覺得就不需要去說服別人,說服領導了,但是恰恰在這個點上,我們還是要做一些推動力的,這個時候很可能就是資訊不對稱,我們認為重要,領導認為一般,結果導致了結果有了較大的偏差。
另外從下到上,其實就是事情怎麼去做,算是一些具體的分工和安排了,最糾結的莫過於沒人,沒技術了。其實這個還不算最糟糕的,最糟糕的是大家認為這個事情還不夠重要,先保持現狀吧。這種時候我很焦躁,我們的價值在哪裡。
原來是感覺有很多事情可以做,但是必要性不大,結果有了一些階段性的討論之後,基於各種因素吧,發現事情一旦有了轉機,你就會發現有很多的事情可以做,值得做了。
所以車輪子轉了起來,我覺得好歹就是進步了。
以上的可以理解是牢騷,也可以理解是一個苦逼的心路歷程。對我來說,抱怨不夠,要做解法,所以前期我的投入會很多,以至於我感覺我現在就是做運維開發的了。
運維開發以後怎麼走,我覺得我們可以看看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,做事情沒有截止日期,結果簡直沒法提。
以上就是我的一些基本想法,很多事情聽起來確實泛泛,需要不斷的細化和梳理,要不時間花了,事情沒成,我覺得太不值了。
我的分享就到這裡。謝謝大家。