運維小哥的工作自述
光陰似箭,日月如梭!彈指間,回首想想,進公司的時間也不短了。在平凡的崗位上默默地耕耘著,似乎是那麼不起眼~~但作為一顆螺絲釘,我要大聲的告訴自己:螺絲釘也能有自己的價值體現!
於是乎,三省吾身!
幾千號員工的上市企業,以總部和分部為個體劃分,在個體中又以部門為單位劃分,各部門的管理、財政、人事都實現獨立。總而言之,一個獨立的部門就像只小麻雀,五臟俱全!從新人入職的身份到看著新人入職,從環境的陌生到熟悉,從同事的初識到相處,一切的一切,似乎都是那麼順理成章的進行著~~
現在總結來看,上份工作算是系統運維,上至叢集的升級和擴容,下至機房的上架與拉線,還得拉個箱子滿世界的跑~~而目前的運維型別能也就給歸個應用運維的類吧,部門做的是醫療健康的app,在進公司之前總想著偌大個企業,在運維體制、系統架構、服務優化、技術規範、監控手段等方面應該高大上,肯定很多地方能大開眼界,但是事實卻是並不是想象中的那麼高B格,啊哦~
公司的應用運維流程是開發在本地將程式碼除錯好推送到Gitlab,通過Jenkins構建,實現將程式碼打成war包,提取包的md5值並傳輸到備份伺服器,同時將包部署到Tomcat,上線後由測試進行功能驗證。系統架構體系則是Nginx+Tomcat !
因是傳統的war包方式持續整合,故Jenkins中並未用到太多外掛,打包、備份、部署等都是通過在Jenkins中新增的相關Shell命令進行操作。於是乎,當在Jenkins中新建Project時,通過原有的模板進行Copy後,還需多次手動的修改那些頻繁出現在Shell命令中的引數(打包的包名、備份伺服器地址、部署伺服器地址等)。為了刪繁就簡,於是乎,我將內容整合在指令碼中,通過執行指令碼並傳參的方式實現一次傳參達到多次Shell內容引數的呼叫,Oye!
然後說說Gitlab,公司的一些資料資料、專案程式碼等都存在Gitlab中,而Gitlab許可權掌管在運維手中,部門需要新開專案,在Gitlab上建立相應的程式碼Project都得是運維操辦,原有的流程是確定新開專案,運維在Gitlab建立相應Project,然後通過SourceTree工具對新建的Project進行git初始化和指定分支的建立。於是乎,每次新開專案,Gitlab新建完Project後,都得彆扭的在Windows中用SourceTree工具,總感覺怪怪的。為了刪繁就簡,於是乎,我將相關操作整合進指令碼,並建立Jenkins執行操作,拋棄了Windows工具的同時實現了相應功能,麻麻再也不擔心我不會用工具了,Oye!
隨著工作的循序漸進,有天開發突然抱著電腦來找我了,說線上Bug緊急修復,要提取線上的程式碼為基底進行改動,所以問我要線上的程式碼。然後我就在想:“講道理,運維負責專案上線,頂多也就支配下專案的版本回滾,程式碼是開發的命脈,確定線上程式碼的版本都還要找運維?開發難道不會對程式碼打好相應的版本標籤麼?”誒呀!腦殼疼,最終討論出的結果就是:一個專案可能對應多個開發,專案上線運維一定在,而開發不一定在,開發的水平參差不齊,標籤不知道打,或者沒法統一等等~~好吧好吧!最後我還是選擇在專案上線前通過指令碼對其進行版本標記,實時確定線上程式碼版本,Oye!
運維字面上理解為運營、維護;而更深層次的是扮演著管理、制度、推行和監督角色,處理著自動化、網站架構優化、監控預警、流量及日誌分析統計、許可權管理、安全優化等事務,負責維護整體專案架構體系的穩定執行;同時讓自動化的持續整合體系更具有制度化、規範化、流程化~~
然而我漸漸的發現了,此刻我不是個單純的應用型運維,這簡直就是啥活都乾的功能型運維吖!好吧,既來之,則安之!幹著幹著,事兒慢慢就多了,譬如:Hi,Gitlab給開個賬號;Hi,Gitlab給開個許可權;Hi,專案介面502了;Hi,Web頁面404了;Hi,專案加個代理;Hi,專案日誌哪裡看;Hi,這個專案上個預發;Hi,新建個專案環境;Hi,專案上個線~~等等,然後同事的內部訪問地址異常了找你給配個DNS;SourceTree拉程式碼異常了找你給解決下;新同事入職了裝些軟體給支援一波~~~然後我自我安慰的告訴自己:這是一個認識小哥哥、小姐姐的機會,嗯,不錯!
話說,不想當將軍的士兵不是好士兵,Nice!於是乎,雖然我是一顆螺絲釘,卻有著一個頂樑柱的夢~~所以,帶著嚴謹性和責任心默默地耕耘在平凡的崗位上,儘自己的能力去規範化、流程化整個持續整合的運維體系及運作方式,儘自己的努力去將運維流程的自動化做到最大化。當然,這不僅是崗位價值的體現,更重要的是提高工作效率和工作質量,方便了大家的同時也提升了自我!
哦,對了,聊正事了。部門做的是app專案,絕大多數專案都是以war包的形式部署到Tomcat中,而當大量新專案的產生,涉及到服務部署、專案遷移等,最讓人頭疼的問題就是環境的一致性問題。為了刪繁就簡,於是乎,在老大的默許下,用上了Docker(測試環境)。通過Jenkins+Harbor+Tomcat+Docker+Nginx等服務銜接,配合自己寫的Docker容器專案部署指令碼,基本實現了個小小的自動化,在實現功能的同時簡化了大量環境一致性的操作。因專案需多次更新程式碼重啟服務進行除錯,故容器的刪除與啟動較為頻繁,指令碼的大致思路是跑a專案容器前,先判斷其是否已經在執行,若是,則徹底刪除容器並更新程式碼重新啟動,若專案容器是第一次啟動,則隨機生成對映埠,啟動後將服務對映的埠記錄到指定檔案,當同一個專案需更新程式碼重新啟動容器時,將到記錄檔案中呼叫記錄的對映埠作為重新啟動容器時的對映資訊,即保證了容器重新生成的對映埠與第一次的生成資訊的一致性!當然,目前只是單純的用docker,後續估計要慢慢的用上編排工具Kubernetes~~~
誒呀!扯了辣麼多,不知道讀者有沒有看暈,反正我差點給自己寫暈了~~
目前個人工作的運維狀況及運維體系大致就是這些了,不知道是不是也有和我感同身受的同僚,希望看了博文的技術小哥小姐們給個鼓勵,同時,更希望的是有技術大佬能給一些建議和指教,站在現有的運維基底,怎麼讓運維體系更具自動化?更有B格範兒?傲嬌的小眼神期望著你呢!哼哼哼~~
最後來一句:打醬油,我是認真滴!
Thank you !