光陰似箭，日月如梭！彈指間，回首想想，進公司的時間也不短了。在平凡的崗位上默默地耕耘着，似乎是那么不起眼~~但作為一顆螺絲釘，我要大聲的告訴自己：螺絲釘也能有自己的價值體現！
於是乎，三省吾身！
幾千號員工的上市企業，以總部和分部為個體划分，在個體中又以部門為單位划分，各部門的管理、財政、人事都實現獨立。總而言之，一個獨立的部門就像只小麻雀，五臟俱全！從新人入職的身份到看着新人入職，從環境的陌生到熟悉，從同事的初識到相處，一切的一切，似乎都是那么順理成章的進行着~~
現在總結來看，上份工作算是系統運維，上至集群的升級和擴容，下至機房的上架與拉線，還得拉個箱子滿世界的跑~~而目前的運維類型能也就給歸個應用運維的類吧，部門做的是醫療健康的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 ！