DevOps初学
DevOps_Share_Mol_001
@(我的分享)[DevOps]
按照惯例，扯闲篇
哟，敏捷了？
我想大家都或多或少地听说过一些关于敏捷开发的知识，不管是书本上的知识，或是平常工作中的实践。敏捷的思想“好像”被普及了一样。
比如我们在某石油企业上班的时候，曾经做过一段时间的“伪敏捷”开发。之所以说它是敏捷，是因为开发过程中借鉴了很多敏捷开发的表现形式，譬如站例会。之所以说它是敏捷，是因为从demand到depoly的这一列过程，都是瀑布模式，比如我们会做很非常详细的需求文档，这种文档详细到开发人员拿到这个文档以后，几乎就只剩下重复性的代码工作了。
而且，这样的现象并不是个例。有大量的公司打着“敏捷开发”的旗帜，假装自己在敏捷开发，以致于最后自己都相信是在敏捷开发。
我不想在这里分享什么是敏捷开发，而且我相信各位看官对这个概念甚至比我要理解得更深入。而且，敏捷也不是本文分享的重点，只是本文要分享内容DevOps的一个引子。
从全局看技术团队
我相信本文的看官大部分都是基层的开发人员，那么，我们首先要脱掉“程序员”这身外衣，假装你自己是一个研发中心的大领导。从领导的角度，看一下这帮技术人员平常在干什么。
瀑布团队：
- 需求人员：我们主要就是接触客户（用户），了解他们想要什么。因为这帮SB客户根本不知道自己想要什么。我们花大量的时间有了沟通结果以后，再把这些需求以文档的形式表述出来。
- 设计人员：他喵的，我一定是上辈子造了什么孽，摊上这一群SB需求人员。自己写的文档，自己都不知道是啥意思，业务也没有闭环。管他呢，我就按我拿到的需求文档来出设计图。
- 架构师：我觉得这个需求和业务一定有坑。最好还是复用现有的业务，这样的话，我们只需要在代码级别做发动就可以了。架构非常稳定，不需要变。什么？用户很强硬？告诉他，实现不了。
- 程序员：coding....debug...coding...debug。我去，单元测试是什么鬼？老子只是个写代码的，测试的事交给tester去做。再瞎BB信不信老子砍死你？什么？需求变更？你知道上一个Product Manager是怎么死的吗？
- 测试人员：我们天天干的就是得罪人的活，没有哪个开发人员待见我们。没办法，为了KPI，脸面算什么？
- 运维人员：都说我们的工作简单，来你看看这实施文档写的是什么鬼？生产出了故障都是我们的责任。公司里面能做到7*24小时神经紧绷的人，除了我们，还有谁？
敏捷团队：(以Scrum来举例)
- Product Ower：我们这一次冲刺（Sprit），我希望多解决掉两个用户故事。当然，上个冲刺留下的问题是必须要解决掉的。
- Scrum Master：李老板，把上个冲刺的问题解决掉；嚣张哥，来把这个“用户登录”的故事领走；小曾，把“海外健康”的故事领走；老田，你把Jenkins搞崩了吧，赶紧搞定，另外，.net core的移植工作也要抓紧了。
- 开发人员：说得好轻松的样子，从开发到测试不都是我们自己搞嘛。
- 运维人员：实施文档能不能写得清楚一点？生产上出了故障谁负责？
归纳
可以看到，敏捷团队的工作效率是比较高的，但也存在很多问题。
DevOps
题外话
上面我所描述的两个场景，大家应该都是比较熟悉的吧。瀑布模式我就不说啥了，毕竟很多大型公司也在使用这种模式来开发。我想说的是所谓的敏捷开发。
“敏捷开发”的本质是开发，敏捷只不过是开发的方式。好，重点来了。如果只把敏捷思想用在开发团队上，那么必然会造成开发团队与其它团队的沟通断层。
举个不恰当的例子，我把一堆详细的需求文档交给敏捷团队的时候，目的一定不纯。我想，我更多的是想消磨这个团队的意志，并离间团队成员间的关系。
这种沟通断层会非常明显地体现在开发和运维人员之间。
进入主题
扯了这么多废话，终于进入到主题了。主题就是开发（Developer）和运维（Opdrations）之间那些不得不说的事情。
哲学上讲，矛盾和统一是客观存在的（至于谁说的，有没有人说过，我根本不知道，此处纯属装X）。为了让事物更好地向良性方向发展，我们就需要弱化矛盾，强化统一。
现有的矛盾
开发团队在开发完成以后，把代码和实施文档进行提交。运维人员拿这个实施文档进行生产服务器的布署。也就是说，我们要求开发人员把运维人员当成是一个电脑小白，你必须把所有的操作步骤都写得非常清楚。对运维人员来说，他要干的事可不只是布署服务器这么简单。他们还要监控生产机的运行状态，配合开发人员排除生产问题，对生产问题进行提前预警……
有没有发现，开发和运维之间只是通过实施文档来联系的。也就是说，运维人员不清楚代码逻辑，开发人员不知道生产机的运行方式。
这样的沟通断层经常会闹出各种乌龙。比如开发人员把session写在了进程内或者是实施人员直接把package.config忽略掉。
令人欣喜的统一
前面我提到了，矛盾和统一一定是同时存在的。我们非常开心地看到开发和运维有一个共同的目标，就是让系统持续稳定地运行。
提出问题
有没有办法让开发和运维之间的沟通断层减少甚至消失？
解决方法
我大天朝土地广袤，精英辈出，岂能被此等问题难住？
我曾经工作过的一家公司是这样解决的。开发团队和运维团队进行轮岗。比如我是作为程序员应聘到公司的，那我需要做3个月开发工作，然后去做一个月实施工作，再做3个月开发……这样轮循。
这样做的好处就是让开发人员和运维人员都比较清楚对方所做的工作。这样就可以增加这两个角色之间的共同语言，用来减少沟通断层。但也有不好的地方。比如，我是一个程序员，而且只会写C#代码，当我轮岗到运维部门的时候，我会面对大量Linux服务器、JVM、apache……等一些不是我知识范畴内的技术。这样，必然会造成生产力低下的问题。同样的，如果我是一个运维人员，那么，只会写shell脚本的我，在面对一大堆java代码的时候，也是一筹莫展。
引出DevOps
是DevOps出场的时候了。前面说了一大堆，只是为了告诉大家。开发和运维之间有着亲朋剪不断，理还乱的种种暧昧。我们都知道，暧昧肯定不是个好事，就好比说，你女朋友和她的蓝颜知己很暧昧，长此以往，你就绿了。所以，我们不希望这种暧昧出现，那就需要有人既能写得了代码，又能当得了网管。
这其实就是一种DevOps的表现形式。我之所以说它是表现形式，而没有给DevOps下一个准确的定义，是因为DevOps就像敏捷开发一样，它只是一个方法论。当我们讲敏捷开发的时候，也会讲到，Scrum是敏捷开发的一种表现形式。同样的，全栈工程师也是DevOps的一种表现形式。
有了全栈工程师，那么一切就好好办了。我做为领导，只需要向product backlog中放入用户故事就可以了。剩下的事，每个工程师把故事领走，自己设计、开发、测试、发布。对于单模块来说，由某个特定的人来负责。这样的做法是非常暴力的，我硬生生地砍掉了。
当然，这样的做法也有弊端，任何一个全栈工程师都不可能精通整个流程中的某个环节。这样，就会造成工作中会出现纰漏。
我们更喜欢让专业的人去做专业的事！
有人一定会说了，如果让专业的人去做专业的事，那么一定还会造成沟通断层的问题。对，一定是这样的，所以我们需要想办法让这种断层减到最少。
比如，我可以写一个自动发布的脚本，这个脚本由开发人员去执行。这样，就可以实现“持续集成、持续交付”。我还可以使用其它的日志管理软件、系统监控软件，来对生产服务器进行管理和监控。
我去！这TM也很暴力啊，硬生生地让运维人员失业了，当然不会有沟通断层了。开发人员笑了，运维人员哭了。
遇到问题
并不是所有的开发人员都比较精通运维知识栈。比如，我就不懂网络。那如何让这样一帮运维小白去做运维工作呢？
如果有这样一种技术该多好呀，开发环境和生产环境是一模一样的，我只要开发完成，调试通过，那么，生产环境也就一样运行正常了。当然这只是一个美好的愿望，我们不可能在生产机上安装一个win7或是XP系统。为了解决这样的冲突，出现了类似docker之类的虚拟化技术。我可以我本机开发完成以后，发布到本机docker上面。调试通过以后，直接把docker拷贝到生产机上。
在.net framework时代，还只能用jenkins来实现持续交付，不过，到了.net core时代，我们有了自己的docker。我们写的.net代码也可以发布到docker上面了。
大家可以设想一下，一个网站由多个docker共同支撑。有的docker负责用户登录，有的docker负责用户支付……。这样，我们可以很方便地把每个用户故事转换成一个docker来发布到生产上。
这也是一种微服务的思想。用一堆短小、专一的docker来提供不同的服务。各docker之间甚至都不知道对方的存在。
总结
我们列举了一些DevOps的表现形式，我们的目的是减少沟通断层。现在我们已经看到，机器已经在慢慢地替代运维人员的工作，运维人员的饭碗快要保不住了！
那些偷笑的开发人员人，你们也不能高兴地太早。AI技术正在以我们肉眼可见的速度在发展。说不定，明年的这个时候，公司也不需要写代码的开发人员了。
但做为一个领导来说，这样的现象是极好的。因为，资本家的本质就是剥削剩余价值嘛。用机器替代人，它的剩余价值可是无限的哦，毕竟人家不要加班费，也不需要休息，最重要的，人家还会主动学习！
浙公网安备 33010602011771号