鉴于简历的严肃性,有些东西都不太好往简历上写。就从这儿随便写写,算是对简历的一个补充,对自己工作的简单回顾,也算是对面试话术的总结吧。
先丰满下最后一家公司的项目吧。然后再唠叨唠叨。
公司的项目
DEVOPS系统 CI/CD功能
我讲的会比较简单,我觉得讲核心逻辑,越简单越好,先让人有个整体轮廓,再讲细节。而且Devops不是越复杂越好,而是要满足自身业务。
CI
1、用户提交代码到git
2、git触发webhook调用Devops系统接口
3、Devops系统根据git信息,及git项目在Devops系统中的配置调用Jenkins
4、Jenkins进行打包,返回结果
CI中的细节:
1、webhook触发后,要校验这个分支代码要不要进行打包。
2、打包后,要不要进行单测扫描。
3、打包后,要不要自动发版到某个环境中去。
CD
1、用户点击发版,触发发版任务。
2、一系列校验后调用Jenkins,执行对应的ansible
3、ansible 进行环境初始化、摘网关,停服务,启服务,挂网关
CD中的细节
1、操作人有没有对这个环境的发版权限
2、生产环境的话,有没有进行安全扫描
3、有没有做发版申请
在上边流程中有些校验,这些校验是配置的,那么配置的位置在哪呢?这就引出了我们的一个概念:流水线。
当一个开发在git上创建出一个项目时,想使用Devops,就要将这个git项目接入到Devops中。Devops就给这个git项目创建了一个流水线。
流水线上两个最重要的信息:git地址,项目类型。在流水线的基础上进行配置,比如:项目分支是否打包,单测扫描,自动发版,以及发版权限。
发版,完整来说是将代码发到对应的环境中去。因此在流水线上又会有四套环境:SIT、UAT、PRE、PROD。这个四套环境在我们系统中,我们称之为link。
link上记录了一些用户自定义的配置,以及服务器地址,网关信息等发版时需要的信息。还有一个比较重要的信息:ansible的id(我们将ansible用一个小系统管理起来了)
安全扫描使用的奇安信的服务,发版前手动触发。
同时系统还提供了回滚、重启的功能。
至于说系统支持哪些语言的发版,其实这都是ansible决定的。来一种新的语言,我们就会找需求提出方的人来一块儿写ansible。我们写流程脚本,核心的发版脚本请教他们来写。在发版脚本这块我们远没有他们理解深刻。
可能有人看到安全扫描要手动触发,为什么不自动触发。可以,但没做。其实,当基本功能都有了,自动其实就是在规定的地方调用下现成的接口。
我做了什么
1、头三个月做了个废掉的功能。领导想通过Apollo配置画一个中间件拓扑图。利用java代码写出核心逻辑,利用groovy解析apollo中的配置。将groovy配置在apollo中,以方便修改。
2、将三个中心的项目接入Devops,差不多又花了两个月。为什么花这么久,一个是项目多,一个是项目不规范,我要给他们切分支一个个的改。
3、一些python代码,全都翻译成java
4、ansible版本太乱整理了一遍。
5、CI/CD 代码基本上重构了一遍
6、工单及自动化处理。
7、回滚、重启功能
其他时间就是帮其他小伙伴看问题,出技术方案,运维工作。运维的时候,秒回。没有秒回,大概率是找的人多,排队呢。
资源管理系统
其实就是管理研发中心用到的资源的系统。一句话概括就是:哪个中心的哪个项目用到了哪些资源。这些资源的信息。这里边三个重点词:哪个中心的哪个项目,资源,资源信息。引申出来就是要资源归属要准,资源数量要准,资源信息要准。
资源归属要准,用工单加自动化处理,减少人工干预来解决。
资源数量、资源信息要准,用定时与云上的资源信息同步,以云上的资源为准来解决的。
我做了什么
简历上写的,都是我真实做的。跟一线运维聊,找到他们流程不闭环的地方。数据库设计、代码框架的书写,工单功能的实现,数据迁移方案:canal,数据双写。从0到1整个过程。
监控系统
这个系统我就得吐槽了,不记得做监控的那个中心叫什么了,人员离职,都不知道转了几手到的我这儿,也不知道之前怎么交接的。几乎没有什么有用的文档留下来。就几个url,账号秘密。自己一个人,一边要应付找过来咨询监控怎么用的,一遍要扒系统。从url入手,到slb,到服务器。在服务器上找代码。看配置文件中的数据库链接,去阿里云上找链接记录。根据链接记录找服务器,再找代码。光项目就有七八个,三种语言写的。
我做了什么
1、给人提供监控使用方案。幸亏我习惯性的多问,还真有的人不知道监控都该怎么用。明明是要监控服务内存使用情况,要用服务可用性监控。
2、梳理项目,为以后重构做准备。写了系统部署架构图,资源清单,项目清单,核心功能时序图,项目问题及改进的思维导图
我脑子里的监控系统
1、提供的是中心、项目维度的资源列表及资源当前状态的展示
资源列表 应该来自 CMDB 及 用户自定义 包括接口推送,页面录入
资源的状态就应该来自各个资源对应的监控工具
2、资源告警的订阅功能,让用户自己决定他所关注的资源,当然也可以强制要求组长核心开发啊必须关注自己资源的状态
3、统一的告警服务。由这个服务对外统一发送告警信息。当然,也可以对监控系统以外的应用提供服务。
4、告警信息处理服务。来统一不同监控工具发送的格式不统一的告警信息。因为监控工具的不同,再加上一些其他业务方个性的告警需求,都在这儿做定制化开发,保证监控服务的统一稳定。
5、各种监控工具的搭建
6、资源自动加入监控工具,监控资源根据CMDB的信息,自动加入到监控工具里去等等。这个就是看监控工具的不同做定制了。
7、监控告警后续处理配置页。告警后,应该可以支持做一些处理,比如:调用某个接口,执行shel脚本等。调用接口、执行shel脚本只是触发的处理类型。具体接口或shel应该可以支持根据告警配置化。可以先支持接口、shell,后期有实际需要再支持其他类型。
唠叨唠叨
工作八年,算是一直处在核心岗位上吧,大家简历都这么写,怎么证明自己说的是真的呢?那就从刚开始工作简单写吧。这部分想到哪儿写到哪儿,不做修改,就想体现个原汁原味。
第一家公司
刚入行,就带着团队修数据,有同事将订单总金额算错了,后续的逻辑全错了,我主导的修了两周。
老板要做个绩效系统,我亲自跟hr聊需求,出原型草图,用配置的形式,给各部门弄不同的绩效模板。页面jQuery写的,根据后端返回的数据动态渲染,单元格该合并的合并
后来还带了三个人
第二家公司
做互联网问诊的,做互联网问诊的时候,业务上没什么突出的,就是什么活紧什么活在我这儿。加班打车费用,每个月我都是最高的。北京团队所有项目的权限我都有。干过早上没出门呢,领导让回滚全部团队代码的事儿。
后来公司收购了一家公司,去他们那边说是重构他们业务,但我感觉应该是了解透了,上层闹掰了,业务我们也能撑起来。早上9点上班,晚上就不一定了。算是成功完成任务,重构做完了,业务也了解清楚了。都是蹲在人家工位边,一点点的聊出来的 。
在这个公司两年多,记得好像就第二年有几个优秀员工吧。我就是其中之一
第三家公司
没有java开发,我们是第一批。出代码规范,写模板代码,各种支援。
第四家公司
有大佬在,我也就显得没那么突出了,做Devops,负责CI/CD模块,核心代码都被我重构了。 出了运维手册,工单并且工单自动化处理,我们几个负责对接的,原来每天都得半天花在对接上,工单做出来,瞬间清净了。
两个月就开始负责对接其他中心了。一负责还负责三个中心。保姆式对接,不仅仅要解决他们使用Devops的问题,还要解决他们代码问题。
周三我们发版,周二、周四其他中心发版,晚上10点之前找的就都不算了,十二点以后找过来的,每个月都有那么几次吧,基本上都是秒回,不秒回的基本上都是,排队中。就没有一次是因为Devops系统有问题找过来的,都是忘了改Devops中配置啊,防火墙忘开,还有一些神奇操作的。
后来又和鹏哥去重构CMDB,再后来独自负责监控系统。