简历补充及我的唠叨

  鉴于简历的严肃性，有些东西都不太好往简历上写。就从这儿随便写写，算是对简历的一个补充，对自己工作的简单回顾，也算是对面试话术的总结吧。
  先丰满下最后一家公司的项目吧。然后再唠叨唠叨。

公司的项目

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，再后来独自负责监控系统。