自動化運維群第三個里程碑總結
自己發起了一個自動化運維群,也寫了好幾期的介紹和想法,今天來給第三期的工作做一個總結。畢竟發起和結束都需要有一個儀式感。我現在深刻的發現,原來不主動發起,不推動,很多事情一直都是縹緲狀態。
大家可以多反饋提問,就當是一次聊天。
我的分享的脈絡分享以下幾個層面:
- 為什麼設定這個里程碑
- 我的困境
- 運維的困境
- 運維的一個突破口
- 第一個里程碑的情況
- 第二個里程碑的情況
- 第三個里程碑的情況
- 分享公益化的想法
- 年後的計劃
至於為什麼設定這個里程碑,可能對於新入群的同學來說,都是帶著問號的,何況對於群裡的很多同學來說,說實話,也是在無視這個里程碑。看起來儘管如此的尷尬的里程碑到底有什麼意義,或者說這個里程碑對大家來說有沒有可操作性。我認為是有的。
從我發起這個事情到現在,我們經歷了3個里程碑,前兩個分別是1個月,這次是2周,這是第3個里程碑的總結,里程碑的時間短了些,但是看起來基本的預期是達到了。
我先來說說我的預期和想法,然後大家自己對話入座。我做的這個事情不能嚴格的說是從0開始,但是實際上和從0開始差不多。
我的困境
實際上,我之前也很少寫python程式碼,基本熟悉Java,會一點shell和SQL,總體來說開發的東西很多是相通的,所以自動化平臺的事情從提出來到開始做,我發現這個事情比想象的要難。
主要難在哪裡,就是在理念上,如果目前的工作能夠滿足目前的需求,那麼不改進,走進舒適區是很自然的,但是如果你深刻知道下一步會遇到哪些瓶頸,會碰到哪些通用問題,如果快速提高團隊的技術能力和理念,對於我來說,比單純去承接業務要意義更大。
所以早期的時候,公司的想法也是沒有讓我去承接現有的業務,而是從自己的理解和想法入手,看看哪些事情需要改善,哪些事情可以做。
做一件具體的事情和做一件事情,差別是很大的,所以前期的時候還是有些懵的,不是在技術能力上,而是在工作方式上,或者說是在公司文化的理解上。
所以前期的時候,瞭解問題的時候會發現一連串的問題,發現的問題越多,感覺可做的事情越多,但是深入瞭解下去,很多不合理,甚至奇葩的現象都是有一定的原因,那句話就很合適了,存在即合理,所以逐步的瞭解,逐步的理解,發現很多事情似乎也有一定的道理,但是這樣一來,感覺離自己的預期也開始有差距。
所以我逐步發現需要做的事情很多,有些時候發現比自己想的要難一些。自動化平臺的事情從我入職之前就提出來要搞,但是一直到年底才開始落實要搞,到現在逐步被領導重視,我覺得雖然心裡也累,身體也累,也算是看到了一個明確的方向。
年底前打算做這個自動化平臺的事情,瓶頸很明顯,缺人,缺資源。 這種方式大家應該很容易理解,也是公司裡的普遍現象,如果一個平臺由純開發去做,做出來的可能和實際業務還是有差距,而如果讓業務參與主導,可能技術實現上有瓶頸,說得直白點,介面做的會比較醜。
運維的困境
所以人的事情,比想的要難一些。結合目前的情況可以分為兩類,一個是招人實在是難,第二個是運維的職業發展本身也很難。
而且實際上這條路會越來越難,如果你仔細觀察你會發現現在的公司招聘,很多運維的JD已經開始明確要開發技能,還有些會要求更高,比如架構,或者多棧的技術能力。落實到我的想法,就是招一個會開發又懂資料庫的人才是我們的需要,這個也是明確提給公司的JD要求,第二個就是我們需要自身提高自己的水平,而不是完全依賴外來力量。
《摔跤吧,爸爸》裡的阿米爾汗對他侄子說:你會做飯嗎,侄子說,不會,阿米爾汗簡單回了一句:那就學啊,馬上。
對於很多還在糾結要不要開發的同學來說,我的回答也是,不會就學啊。我們其實都希望手把手,但是現實工作中基本沒有這種情況。
所以我現在對於團隊的新人員需求其實主要還是看態度,沒有學不成的事情,主要還是看態度行不行。我對接過很多公司的招聘,所以大概瞭解一些潛規則,所以我們的壓力非常大,我也經常自己給自己敲警鐘。
有些現實環境是很殘酷的,我之前深入交流的一個公司,全公司就一個DBA,全公司都上雲了。基本不需要關注備份恢復和高可用的事情,甚至連分散式的很多方案都有現成的,所以他們更加關注優化,我去交流,講優化他們格外合拍,講死鎖之類的大家積極性很高。
還有我的一個同事,他現在是一個公司的總監,公司目前是沒有運維的,而且後期的一些工作是打算要通過外包的方式來對接,也是全面雲化。還有我身邊的朋友,做測試工作的,現在出去找一些職位,稍微有點規模的公司都是要求開發能力,現在基本都是叫開發測試了。
所以大家的壓力還是蠻大的,我不是完全看空運維,而是覺得我們需要做很多思維,理念的轉變,覺得這個事情可能不會發生在自己身上。但是恰恰相反,至少時間的問題。
運維的一個突破口
人員的事情是個難題,但是方向很明顯,是奔著SRE的目標去的。Google的那本SRE的書很不錯,也推薦大家看看。
所以年前講這些,看起來說的遠了些,但是也希望大家藉著這個時間,別光喝酒聚會,也想想自己的未來和發展。技術發展會越來越成熟,單純拼技術能力,90後從精力和技術成熟度上已經相比80後有很大的優勢了。
說了些我的擔心,我來說說我的一些想法,做自動化平臺的事情只是我們成長路上的一個步驟,但是絕對不是全部,這個事情就好比要打一場攻堅戰,達成之後還有其他的戰役要打。如果連解決問題(攻堅戰)的需求都沒有,就如同《芳華》裡的文工團,說散就散了。
我的一個大體思路是,平臺的這個事情需要明確,需要上下兩邊的支援,領導支援,同事支援,缺了哪一邊都很難,如果缺少領導支援,就好像打游擊,大家都會比較累,如果缺同事支援,心裡會更累,整天忙哪些有啥用估計是自己最怕聽到的,一旦大家參與進來,這個事情就裡面有點味道了。
前戲有點長,我來說說這個群裡的事情。
第一個里程碑的情況
所以一直提倡,要求,最後大家都支援,但是都行動不起來,你的抱怨也會多起來,但是沒鳥用。前兩期的里程碑,我就算是自立了一個牌坊,我要做這個事情。
群裡的人也不都是做平臺的,但是從需求來說,都差不了太多。
從最開始大家天馬星空的想一些問題,討論自動化平臺裡的一些點線面的問題,到最後逐步討論,看別人的一些實現,逐步有了一個體系和思路,我想這個過程是很難得的。我也從這個過程裡收穫頗豐,也瞭解到很多運維兄弟的不容易。
所以第一期的時候,大家主要是分享一些比較散,但是可能很多問題沒有結論,這樣一個狀態不怕,我給自己的初步目標是,我在里程碑要看到這個平臺能跑起來,沒有Django基礎,web技術都快忘光,python基礎不紮實的情況下,就開始匆匆上路了。
結果就是第一個里程碑,有了一個計劃,不多不少,就是在最後一天我把OpsManage的平臺做了改造,重新跑起來了。
第二個里程碑的情況
然後第二個里程碑就開始夯實一些基礎功能,我的關注點最多是在許可權和通用功能上,所以動態選單,許可權的粒度細化這些就是我主要解決的問題,這個階段的最大收穫除了完成功能外,一大收穫就是對於ORM有了一層深入的理解,我現在不會完全糾結於ORM的實現細節和瓶頸了,而是對ORM層的使用做了裁剪,可以靈活的支援。這個主要是理念層面的進步。
能做出一個基本的資訊管理,能做出幾個還能看過去的頁面,我覺得對團隊來說也會有一些動力。因為大家談論的不再說一個虛擬的事情。而是滑鼠能夠點選到的這樣一個平臺。
第三個里程碑的情況
同事做了模板機,配置了gitlab,我們準備開搞了,因為時間和工作的安排,這些事情還是由我來主導去做,所以第3個里程碑的時間我做了一些前置,因為快過年了,最後一週大家都應該在節日的氛圍裡了,我就敲定先提前結束里程碑。
里程碑的事情就是這麼個考慮,有的同學可能和我合拍了,有的就是進來看看,還有其他的原因,總之最低的門檻就是參與進來
按照這個思路,別說一週或者一個月分享一下,如果你確實在做這個或者認真參與了,一週分享一次應該是輕輕鬆鬆,所以群裡的同學,大家還需要努力,我設定的群規只是最低的要求。
分享公益化的想法
分享的意義,這個問題是很多人入群之後的一個常見問題。
最開始是希望大家都參與,群主是輪值的方式,大家找了6位同學來做,第一個里程碑,幾個輪值群主的壓力蠻大的,每週都要分享,明顯到第二個里程碑就會感覺到累了。
所以第二個里程碑我們又邀請了幾位同學參與進來,算是緩解輪值群主的壓力,畢竟這又不是一個嚴格以上的工作。
第三個里程碑的輪值群主更多。但是如果你仔細觀察就會發現,前兩個里程碑的主題大家會越提越多,最後可能提出了50個,但是達成的只有20個左右,第三個里程碑裡的我們不斷的改進,截止目前,所有的任務都完成了。
最多的一天有3個分享,而這個階段的最大的改進就是分享價值公益化,具體內容參見上面的連結。簡單來說,就是給講師打call,別光點贊,捐個1塊,2塊,自己獻愛心,還能給講師一點肯定,一舉多得。
這個資料我來說一下,截止目前有105次的捐款,一共有330元的捐款額。我們是鼓勵按照1元來捐。平均下來還是超出預期的。一個是15個主題,加上這個,我貢獻了3個主題。
年後的計劃
年後的計劃,我來簡單說下。
這是近期要落實的事情,年後要落實的事情更多,之前設想琢磨的事情都要落地。
這些加深的部分是我要發力解決的,之前在分享中的時候都是提想法,會感覺有些虛,但是落到了實處再說就會有底氣了。
平臺我規劃了幾期,也在逐步落實。
所以這是一個艱鉅的攻堅戰,希望大家都能認真參與。
過年的時間段就不要求了,年後還會嚴格來要求大家。簡而言之,這個微信群是個學習的地方,大家如果認可它,它就會在你的微信中變得更加重要,要不它就是一個簡簡單單的微信群,很可能沒落,我一個人做不到,但是幾十人,上百人做是肯定沒問題的。群的規模不要太大,有質量其他的一切都是浮雲。
我的分享就到這裡吧。感謝大家。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2152321/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- IT運維之自動化運維運維
- 自動化運維利器Ansible要點彙總運維
- Ansible自動化運維工具運維
- 介紹一個 MySQL 自動化運維利器 - InceptionMySql運維
- 什麼是自動化運維?為什麼選擇Python做自動化運維?運維Python
- ansible自動化運維入門運維
- 簡化IT運維工作,就要學會使用自動化運維工具!運維
- 自動化運維和普通的運維的區別是什麼?哪個好?運維
- 自動化運維工具Ansible介紹運維
- 分層運維自動化監控運維
- 自動化運維的快速演進運維
- ansible自動化運維資料庫運維資料庫
- Python 運維總結Python運維
- 來自泰山運維的2023年終總結運維
- 指標是構築自動化運維與智慧化運維的基石指標運維
- Linux Shell互動式自動化運維程式Linux運維
- 阿里雲釋出ECS自動化運維套件,幫助企業實現自動化運維轉型阿里運維套件
- 自動化運維工具——ansible詳解(一)運維
- 自動化運維工具——ansible詳解(二)運維
- 運維自動化之賬單系統運維
- Oracle 自動化運維-Python連線OracleOracle運維Python
- 論IT運維自動化的重要性運維
- Python自動化運維之IPy模組Python運維
- 自動化運維工具ansible的實踐運維
- Python+Django+Ansible Playbook自動化運維PythonDjango運維
- 自動化運維工具之Puppet模組運維
- 自動化分享里程碑小結20180127
- IT運維和自動化運維以及運維開發有啥不同?能解釋下嗎?運維
- 自動化運維,國產化信創替代方案運維
- Linux 運維必備的 40 個命令總結Linux運維
- 自動化測試總結(二)
- 透過運維編排實現自動化智慧運維與故障自愈運維
- 運維效率之資料遷移自動化運維
- 網路工程師眼中的自動化運維工程師運維
- 雷神 Thor —— TiDB 自動化運維平臺TiDB運維
- 自動化運維平臺的流程草圖運維
- [Linux]Ansible自動化運維① - 入門知識Linux運維
- [Linux]Ansible自動化運維② - 工具與模組Linux運維