那些年我们追过的Devops

曾几何时Devops突然大火，所有的互联网公司趋之若鹜，有人在查阅了一些资料后，不屑一顾的说，不就是流程自动化么，我们早就做了啊。

这里借用一张图来看一下大家理解的Devops。

运维小王：这不是废话么，哪个公司没有这个流程？，jira+Jenkins不就搞定了么？

下面让我们借用一些名场面认识一下Devops的重要性。

场景一：

运营：产品姐姐，咱们上周说的10个需求你觉得怎么样，可以做吗？

产品：我是谁，我在哪？咱们上周不是说的怎么吃鸡么（啥破需求，先拒掉3个再说）？

运营与产品直接沟通基本靠会议、邮件、以及微信，无法行成完整的“证据链条”，极容易造成“技术失忆”。

我们需要把运营跟产品拉到一艘名为Devops号的船上来（You jump,I jump!）,这时候就要使用zentao、jira这类项目管理工具，将双方沟通的需求文档、原型图、统统放上去，因为文档的存在，对于人员的变动，项目的交接，以及后续开发人员的参考，极其有力。

好吧我知道大部分公司都有的。

场景二：

开发：产品姐姐，请你把原型图发给我。

产品：我放到zentao里了，你上去看吧。

开发：不行啊，我bug太多，不敢打开看。

产品：……

这时候我们需要一个预览产品原型图的功能，让产品可以实时改需求，开发可以实时看到原型图的变化。

总监：借助jenkins、gitlab以及web服务去做原型图的实时展示，Jenkins将原型图构建到web服务中完成预览，zentao中只填写相应的预览地址就可以了。

开发：我可以从gitlab中找到产品修改需求的铁证。

场景三：

测试：老哥，你这个方法都return了，后面还写鸡毛啊？

开发：咱们近不是按代码的行数算工作量么？

测试：……，你这接口的响应时间都够我打一把农药了。

测试：开发老哥限于水平与项目进度，无视代码质量与性能，我也很无奈啊？

总监：代码构建的时候加上sonarqube，在测试环境加上APM，把这帮人的垃圾代码扼杀在摇篮里。

场景四：

客服：各位大佬，有个好消息，咱们的平台502了。

运维：天呐，我把测试环境的代码发到线上了。

总监：你特么的赶紧回滚。

运维：大哥，不好意思，没有做回滚的功能。

总监：滚。

这时候我们需要改造上线流程，分为“预生产>灰度>生产”，每次上线根据不同的级别，去做审批与预案，预案内容包括代码与数据库级别的回滚，以及备用生产环境的切换。另外还需要建立完整的代码验证与环境的监控，出现上线故障时可瞬间响应，及时使用Plan B或者跑路。

场景五：

总监：近3个月大家都挺努力，我们准备做一下项目的复盘。

测试：我先来，我在线上发现了大约2000多个bug，可能比同期减少了20来个。

开发：我开发了大概200多个功能模块，好像都没有上线。

运维：本季度平均每天上线180余次，回滚200余次。

运营：我们收到了市场部门的大量反馈，用户说我们502页面做的不错。

产品：我拒绝了运营的280多个需求，把剩下的360个改成了700多个。

总监：我听出来了,你们个个都是身怀绝技啊。

每个人每天的工作量基本饱和，但是项目做不出成绩，领导如何把控项目进度？这时候需要一个可以从宏观角度查看整个项目进展的工具，像进度条或者流程图一样，实时展示项目的进展。

总监：我们可以从zentao或者jira的数据库中收集数据，然后做归集与整理，做一个可以实时展示项目进度的工具，我看谁还敢偷懒。

场景六：

开发：这个6年前的项目有架构图吗？

运维：不知道啊。

运维A：监控偶尔报504，这个服务在哪？

运维B：我也不知道，顺着nginx查吧，nginx在哪？

开发A：这个接口调用好奇葩啊，有说明吗？

开发B：N年前的项目，有代码就不错了。

开发与运维没有相关可查阅或者追溯的文档，随着项目的迭代，人员的变动，很多历史遗留问题逐渐暴露。

总监：以后所有的技术文档统统写wiki，写的接口都扔到YApi里，上CMDB，把这些服务都管理起来。

场景七：

总监：今晚1点钟上线。

全体：天呐……

选择低频时段上线是为了降低对用户的影响，其实处于这个目的，可以用很多种方法解决，比如Kubernetes，正所谓一个k8s解千愁，滚动升级，弹性伸缩，易于回滚。传统运维离失业又近了一步。

总监：这个月我们把服务改造一下，都扔到Kubernetes里，以后上线咱们做主，想上就上，想滚就滚，想啥时候上就啥时候上。

后记：

使用工具链的好处是显而易见的：

1.减少人工干预，降低人员工作量

2.流程标准化，降低人为失误概率。

3.一切记录有迹可循，方便追溯。

随着项目的迭代，工具的增多，整个团队使用了几十个不同的系统或者工具，后我们的工具流变成了这样

这么多的工具如何完美的协调使用呢？这又涉及到了Devops里另一个话题，工具的改造。

其实Devops并不只是各种工具的合集，更多的是一种互联网的文化或者制度，只有严格按照流程执行才能达到终的效果，所以设定规章制度依然很重要。

青山不改，绿水长流，有机会再更。