运维小哥的工作自述

　　光阴似箭，日月如梭！弹指间，回首想想，进公司的时间也不短了。在平凡的岗位上默默地耕耘着，似乎是那么不起眼~~但作为一颗螺丝钉，我要大声的告诉自己：螺丝钉也能有自己的价值体现！

       于是乎，三省吾身！

       几千号员工的上市企业，以总部和分部为个体划分，在个体中又以部门为单位划分，各部门的管理、财政、人事都实现独立。总而言之，一个独立的部门就像只小麻雀，五脏俱全！从新人入职的身份到看着新人入职，从环境的陌生到熟悉，从同事的初识到相处，一切的一切，似乎都是那么顺理成章的进行着~~

      现在总结来看，上份工作算是系统运维，上至集群的升级和扩容，下至机房的上架与拉线，还得拉个箱子满世界的跑~~而目前的运维类型能也就给归个应用运维的类吧，部门做的是医疗健康的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 ！