timg (1)
本来打算回家搞搞工作上的事情,突然发现线上环境在维护
所以抽空再写一篇文章吧。
今天CEO全员发送了一封邮件,大致内容是介绍DevOps,以及其好处与目的。
我这个敏感的神经被撩拨了起来,这是个什么?竟然值得CEO发全员邮件这么郑重?

首先,什么是DevOps?
百度查了一下关键字,我摘抄几个比较容易懂的定义:
1.术语“DevOps”通常指的是新兴的专业化运动,这种运动提倡开发和IT运维之间的高度协同,从而在完成高频率部署的同时,提高生产环境的可靠性、稳定性、弹性和安全性。
2.随着软件发布迭代的频率越来越高,传统的「瀑布型」(开发—测试—发布)模式已经不能满足快速交付的需求。2009 年左右 DevOps 应运而生,简单地来说,就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程,开发运维一体化,通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
然后还有一张比较经典的图,出现了好多次:
310906-735d15ceea69b44d

我们分析一下上面的两段话:
记得重庆强在离职聚餐的时候,泪眼婆娑的抱怨了一下IT运维,
包括团队内部也流传着‘每次去找运维不是走着去的,是跪着去的’,包括我自己也是有同样的想法,
我讨厌各种等待,耗尽激情,我想做什么事情的时候,下一分钟我就想知道结果,继续我的工作。
举个栗子,测试环境崩溃,QA无法测试,RD无法开发,排查后发现是服务器问题导致,找到运维部门,运维部门排查.
排查后发现是RD代码有问题,如此反复。
然后QA开始抱怨测试不了,影响排期巴拉巴拉。RD开始甩锅。
再举个栗子,开发完成后,找到运维部署测试,测试完成后找到运维部署线上,运维又不懂一些关键性的配置,需要开发人员旁边辅助,浪费人力物力。
其实对应的例子有好多,关于运维,环境好大家好,一旦环境出问题,中间的沟通成本让人心烦。

要说QA和RD之间也有冲突,和PM也有冲突,为什么会把运维作为高效迭代的突破点呢?
个人理解,因为IT部门承担了环境搭建,基础设施建设的责任,其他部门都是在此基础上生存,他们要保证环境的稳定安全运行,
所以应该说不论你是敏捷开发还是,快速迭代,这一切的前提都是有一个良好的基础环境。
怎么解决这个问题呢?最简单的就是增加运维人员的配置,达到人手一个运维,但这不太现实。
那换个思路,能不能每个人都是运维呢?

如何让每个人都是运维,或者像第一句说的那样,让开发和IT运维之间的高度协同?
工作量在那里,运维不愿意多了解开发相关的内容,开发不愿意接触运维的事情。这种情况我觉得是无解。
我还是认为,再好的想法或者政策,都要有一个积极推动的团队去实践才能得到最大化的收益。
当你提出一个比较好的建议时,你的上司你的同事回复你‘这个不行’,‘我们没时间搞啊’,‘这个公司不允许啊’…..
咋开心..咋开啊?
下载
所以,如果你没有一个积极向上的团队的话,来谈敏捷我觉得有点为时尚早。
我们假想一个环境,所有的人都是主动和积极的去完成事情,不排斥跨部门的学习,不排斥新功能的接入。
这种情况不太现实。那如果说少量的,简单的学习能不能达到高度协同?怎么做?
首先,运维部门要放权,不要把所有的事情都抓在手里,把有限的精力放到性能优化这些需要专业技能比较高的点上,实现产出最大化。
把一些日常的部署,维护,测试迭代,数据库维护丢给RD和QA
那RD开始拍桌子了,我TM也事情好多的好吗,排期这么紧,我哪有时间?
那如果这些日常的部署,维护,测试迭代只需要你鼠标点一下,或者说根本都不需要操作,完全自动化你能不能接受呢?
一定是可以的,我们之前就有介绍过Jenkins这个工具,他会帮你完成一些琐碎的事情,同样的工具有好多,BAT这些大厂都会有自己的一套实现,大家可以参考下。
做到这一步,第一句话中的高频率部署工作交给自动化工具和RD来做,对生产环境的维护交给运维来做,减少沟通成本。
能做到什么地步呢?拿现在的流程来说,一天5次部署测试环境到极限了吧?
每一次的部署需要和各部门沟通,我们假设每一次沟通10分钟,一天就浪费50分钟在等待上,而且5次的部署实在是慢极了,要想快速迭代开发,需求会多,测试任务会多,
部署次数越来越多,一天达到了10次,就浪费了100分钟,这100分钟多少人参与还说不准。

如果我们使用上了自动化构建,只要你提交代码就会自动构建,不夸张的说一天100次不是很费劲。每次最多耽误1分钟,同样是100分钟,你们公司是能迭代10次,我们迭代100次
简单算算我们的效率是你们的数倍。这是测试阶段,上线呢?
运维部门将上线的权限也放出来,开放给leader,关于代码的可靠程度,需要leader来负责,每次上线必须review代码,不要甩锅给运维了。
我们白天测试好,下午6点review代码,全部没问题之后回家,等待晚上交易少的时间段上线,同样,上线只是点一下鼠标的工作,上线之后马上回归测试。

但是部署次数增加之后QA开始头疼了,我们刚测过的东西你又推代码部署,我要不要重新测一遍?我已经测过的东西是不是要重新跑一边?
这里就涉及到了自动化测试,测试要保证一些基础功能,基础的流程产出脚本,可以通过配置保证代码构建之后将所有的脚本跑一遍,
将主要精力集中在手头的测试,发现问题迅速解决,一遍测下来基本上bug同时修复完成,马上开始第二遍测试.

当你的团队过渡到这个阶段之后,作为leader,你也应该转换思路了,你要的不只是他是否工作了,你只需要关心你要的产出是否正常
这就是一个敏捷团队应该做到的,结果导向,说出来要被拍砖,PM常说的一句话就是,不管你怎么做,在这做还是回家做,我就要一句话,今天能不能上线

敏捷团队从源头来说,首先要保证需求的产出,没需求敏捷个啥子嘛。高质量的需求对PM团队要求很高的
所以做一些割舍,我不要求每一个需求100%是用户想要的,只要你提出来,大家觉得可以一试,那就开始开发,开始排期。
毕竟没有哪个pm敢说自己的需求就是用户想要的,但是你想尝试,我就给你这个机会。可以推行灰度发布,A/B测试,来逐步优化你的需求方案,不断的改进
需求有了之后,RD开发,如何能看到这次需求的上线带来的结果呢?
之前接触过好多后台开发,一天都在查数,出报表。头疼,又不能体现工作量。
并且这个周期也很长,线上数据库量级大,查询一些数据不是几分钟的事情,怎么办?怎么优化?
首先,PM接手其中一部分查询,比如转化率,有好多界面友好,操作简单的工具,例如growingIo,百度统计等等,这些工具互相配合,出个转化率应该没问题吧,
其次,报表还是要出,能不能将查询语句图形化?简单到拖拖拽拽就能查数?
这一切都在释放一些资源,让特定的工种完成最有意义的价值,把一些繁琐的事情自动化,流程化。
敏捷开发完了之后,就会涉及到上线,上线很简单,但是这里有一点要注意,你的线上问题暴露时间有多长?
一个用户进不去系统,你最快多长时间能发现并作出处理?这段时间会流失多少用户?
用户找另一个替代产品只需要10分钟,如何在这10分钟内发现问题,解决问题?挽留用户?
如何做到线上bug发生3分钟内通知到RD,RD花6分钟排查,修改,1分钟上线?
这一切都是有解决方案的,完善的预警机制,健壮的用户行为分析机制,做到10分钟解决问题不无可能。

说了这么多,我们总结一下DevOps
首先它是为了团队高效敏捷开发而产生的一套解决方案
这套方案不针对某个部门
而是针对整个开发流程
他的核心最重要的是各部门放权,以及各种自动化工具图形化工具的介入,细化流程中的每一个节点,缩短节点时间
最终形成DevOps。
大流程的东西只能慢慢介入进来,周期会很长,但是一定要有一个发现问题的能力,哪个环节除了问题,怎么快速解决,哪个流程出了问题,哪个流程耗时特变长,慢慢一点一点优化调整,每一个团队都能达到DevOps
没有什么事情是做不到的,只要你做了,你就离做到近了1%
u=31648402,2566505206&fm=23&gp=0
个人的一些见解看法,漏洞百出,欢迎拍砖。