運維小哥的工作自述

光陰似箭，日月如梭！彈指間，回首想想，進公司的時間也不短了。在平凡的崗位上默默地耕耘著，似乎是那麼不起眼~~但作為一顆螺絲釘，我要大聲的告訴自己：螺絲釘也能有自己的價值體現！

於是乎，三省吾身！

幾千號員工的上市企業，以總部和分部為個體劃分，在個體中又以部門為單位劃分，各部門的管理、財政、人事都實現獨立。總而言之，一個獨立的部門就像只小麻雀，五臟俱全！從新人入職的身份到看著新人入職，從環境的陌生到熟悉，從同事的初識到相處，一切的一切，似乎都是那麼順理成章的進行著~~

現在總結來看，上份工作算是系統運維，上至叢集的升級和擴容，下至機房的上架與拉線，還得拉個箱子滿世界的跑~~而目前的運維型別能也就給歸個應用運維的類吧，部門做的是醫療健康的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 ！