运维小哥的工做自述

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

       因而乎，三省吾身！

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

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