運維小哥的工做自述

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

       因而乎，三省吾身！

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

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