（图片源自网络）
截止今天，在SVI干满5年啦，几乎占我整个职业生涯一半的时间，这些年总体比较充实，公司提供了很多机会和发挥空间，个人成长和收获非常大。
本想分三部分来写，后面发现外行读者可能根本就看不懂，索性重新整合在一起，初衷也是为了对自己这些年实施工程能力建设方面的回顾和总结。（当时管这一套叫CI/CD，后来不断发展成DevOps理念）
多做总结才会发现自身的不足、才会思考如何改变，不至于稀里糊涂熬成了自己最讨厌的老油条。
我认为工程能力是一个软件公司竞争力的根基，如果一个企业的研发团队每天陷入和测试、运维之间的扯皮（测试手法不对？安装姿势不对？...），至少要浪费30%的时间和精力，最终体现有点类似于打仗是拿土炮还是扛机枪了。
这里需要先植入一个背景：
SVI之前的研发大致流程：
研发人员需求编码、测试->
将系统打包、编写安装操作文档提交给测试/运维部->
测试/运维人员根据安装操作文档一步一步安装->
完成安装后正式验收
因为每个研发人员都是基于自己的知识体系写文档，各种奇葩理解和遗漏，到发布环节前前后后还要折腾一周才能完成系统上线，测试环节更是用折磨来形容，典型的“石器时代”。
（半自动化）
2016年9月加入到SVI，当时主要是做OTT业务，刚加入公司，就被告知要做一个基于YouTube的爬虫项目，爬取的内容元数据供终端盒子使用。
该项目的项目经理、设计、开发、测试都是我一个人，其实这一天期待良久。
第一周完成项目命名（AF项目）、立项材料撰写、Google YouTube API（V3）技术预研，输出项目任务书、需求设计文档、接口设计、数据库设计等。
第二周完成项目框架搭建，当时是采用非常流行的SpringMVC+Redis+PostgreSQL+Jetty架构，该框架是公司第一个Java项目框架，后面的项目都是基于此复制延用。
完成代码编写和自测试，项目大致框图如下：
第三周完成项目调优和缓存方案重构，Jenkins自动化编译、打包、安装、部署全流程一键式自动完成，并且集成SonarQueb完成代码质量检测的修改，这便是我们初期自动化V0.1的架构（半自动化）。
第四周完成终端联调和项目上线，记得运维同事非常惊讶，部署升级怎能如此简单。
最终项目顺利上线，完成结项报告。
AF项目线上运行2年多，除了几次YouTube爬取故障（爬数失败会6次重试并且发邮件通知），几乎没有做过维护。采编人员只需要在YouTube编排自己的频道和订阅频道，频道更新内容会自动爬取到AF，终端刷新就能看的最新频道数据。
很庆幸这个项目全程是由我一个人来完成，有了很大的发挥空间，做了很多新尝试，最终在结项会议上惊艳所有人。
心得：在组织内打破原有习惯推行新的流程，势必要有一个已经成型的模范，大家看到收益的同时也有一个模仿对象，不然团队成员遇到任何问题都会跳出来质疑，然后迅速回到舒适圈内，说的再好不如做出来让大家看到。
（DevOps v1.0）
有了AF项目的成功案例，公司管理层大力支持新项目全部依此为模板，实现了从代码到安装的自动化流水线。为此我输出了Jenkins自动化指南、AF项目指南等文档，方便大家查阅和参考，同时也输出了一系列规范并验收所有项目的自动化成果。
2016年底-2017年，随着公司的发展和新人才的引进，先后成立了测试部门、云计算产品部、大数据部门等，并对原有老系统进行重构，原架构由几个Python编写的模块，性能和可扩展性都面临瓶颈。新架构是Java（在线业务模块）+Python（离线管理模块）+C（CDN、存储、转码等三方功能模块）等多语言40+个模块的复杂系统，可伸缩性非常强。
系统模块激增，随之带来运维成本增大。不同语言、操作系统兼容、一致性都面临很大挑战。经常转测试后，不同环境安装的结果不一样，配置也出现不一样，导致各种折腾。
此时云计算产品部全力投入云平台产品的研发中，将Docker+Rancher体系引入进来。
同时测试部也在着手自动化测试平台的立项，确定了自动化测试平台框架。
通过几个月的努力，我们的DevOps v1.0体系问世：
每个模块（网元）已有的setup.sh安装脚本集成到了Dockerfile中（有了v0.1的基础，Dockerfile只需要几行代码），在完成镜像构建到私有仓库后，自动将网元镜像推送安装到Rancher平台。
所有网元Docker化后，研发、测试、灰度、培训、生产环境高度一致，曾经因不同环境导致各种安装手法问题一去不复返，最终复杂的安装文档变成了一份系统版本配套表。
华为当年为了达到这一目的，安装盘更是连操作系统一起重装。
部署40+网元也从原来的1天或几天缩减到几分钟内完成，研发团队再也不需要花大量精力和时间在各种琐碎环境问题上了，生产力显著提升。
至此，SVI的DevOps体系已经初具雏形，虽已经满足项目需求，但要走的路还有很长。
这一年在深圳参加了DevOps运维大会，接触了各大厂的DevOps模式，又有了新的方向~~~
（DevOps v2.0）
2018年初，公司成立BBJ子公司布局非洲项目，而我从非洲考察回国后就离开了奋斗8年的深圳，异动到长沙分公司。
记得那次我特意买了一趟深圳至长沙的绿皮硬座火车票，想再体验一次春运，当时认为再也不会有这种感觉了，硬是熬了10个小时硬座到长沙。
随后立了PAYGo+CRM+WMS几个子系统的项目（PowerCloud项目），负责PowerCloud项目交付和测试开发部的管理工作，同时负责DevOps全流程实施落地。
这一整年，PAYGo方案、CRM系统、WMS系统从摸索到应用，不断适应非洲当地销售场景。其中也有折腾，研发流程体系的建立、实施、优化，PowerCloud项目从原来的几个月一个版本，发展成按每2周或1个月的节奏快速迭代，期间发布了十多个迭代版本。
这一整年，原来纯测试部门打造成了测试开发部，完成2800+自动化测试用例的编写（成功率达99%），并且完成所有项目测试工作、同时主导项目发布和线上运维工作。团队70%是应届毕业生，老员工新学编程。
这一整年，我们制定了DevOps_V1.0规范，并全部实施达成，并过渡出DevOps_V2.0目标，从需求到代码，从代码到交付自动化流水线的全流程固化，项目几十个网元系统部署缩短到10分钟内完成。
2019年-2020年，总部和长沙研发团队发生几轮非常大的调整，通过这两年的团队磨合，我们整个研发团队在无测试和运维团队的情况下，通过流程牵引做到了全员轮值版本经理。并且不断的优化和提升工程能力，实现了部分服务故障自动漂移的自动化运维。
2021年，一个全栈人员维护了全套系统解决方案，正常交付需求、发布版本，并支持非洲项目在线运营。
总结：
1、多总结和复盘，任何问题都需要有闭环，不然问题会一直存在；
2、团队要适当有目的性的做出新的尝试；
3、多鼓励团队做分享和总结，并归档好这些财富；
4、流程制度一旦建立并实施，管理者就要充当好裁判角色，维护好游戏规则。可以调整和优化规则，但绝对不要经常打破它。
- end -
微信扫描二维码，关注我的公众号
