DevOps就是开发抢了运维的工作？

先说说多人协同开发问题，人员一多，为了更好的分工，大多会将项目进行拆分，每个人负责专注于一部分，有点包干到户的感觉，<br><br><font color="#00ff00">敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，<br></font><br>然后通过不断迭代，以小步快跑的方式持续开发。。<br><br>另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，<br><br>QA的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，<font color="#00ff00">每次可交付的都是一个可用的功能集合</font>，<font color="#ff0000">对开发交付的内容进行持续验证</font>。<br><br>这样开发产品的可控性也更强，遇到了sb甲方的时候，<font color="#00ff00">阶段性的让他检验一下项目成果，防止画鸡成鸭</font>。<br>&nbsp;

项目研发的阶段

再说说多机器问题，之前机器很少架构简单的时候，开发就可以干运维的活，<br><br>就算加了几台服务器，那也是脚本将&nbsp;JAR&nbsp;包同时发布到这些机器上，<br><br>好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，所以大家在上线之前可能会去群里吆喝一声，<br><br>”我要上线了，大家先别上线哈“，可想而知这样效率也很低下。<br>&nbsp;

公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，<br><br>一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，<br><br>另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。<br><br>但是这个时候也不是&nbsp;DEVOPS，而是&nbsp;<font color="#00ff00">DEV+OPS</font>，<br><br>这时&nbsp;Ops&nbsp;的主要职责就是：<b><font color="#00ff00">硬件维护、网络设备维护、DBA&nbsp;、基础服务维护、数据监控</font></b>等，<br><br>运维们擅长写各种部署，监控脚本，减少机械的重复工作，<font color="#00ff00">开发模式变成了敏捷开发模式</font>。<br>&nbsp;

加入运维，就要协调人员配合，<font color="#00ff00">运维的宿命就是维稳，他们是很讨厌变动的</font>；<br><br>开发的天职确是<font color="#00ff00">不断地推代码上线，进行代码变动，更替迭代</font>，这两个<font color="#ff0000">工种天生就是对立的</font>。

很多大公司有那种，开发人员想要上线，需要提交各种审批，层层签字画押，<br><br>多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。<br><br>所以，<font color="#00ff00">敏捷开发解决了协同开发和多机器部署开发问题</font>，但是没有解决<font color="#00ff00">内部人员的矛盾</font>，<br><font color="#00ff00"><br>留着这个矛盾在公司，开发和运维随时都可能约‘生死架’。&nbsp;</font>

第一，公司发展到BAT这种体量，会招很多人，JAVA，PHP，GO&nbsp;技术栈都会有，<font color="#00ff00">需要协调技术栈</font>；<br><br>第二，项目到后期往往会变得很大，全部都兑到一个项目里，最直接的后果就是<font color="#00ff00">项目变得很大</font>，上线项目<font color="#00ff00">启动时间变长</font>，<br><br><font color="#00ff00">一个BUG可能导致整个业务全线崩溃</font>，最终的后果就是项目变得越来越难以维护，加一个改一个东西几乎搞不动，而且还越来越难重构，牵一发而动全身。<br>&nbsp;

所以，<font color="#00ff00">拆分解耦</font>是最终的出路，将项目<font color="#00ff00">拆成一个个小的服务单独部署</font>，以电商项目为例如图，<br><br>将整个项目拆分为用户服务，商品服务，订单服务，积分服务......每个服务单独部署，<br><br>之间通过互相调用的方式来交互，而且可以将一些<font color="#00ff00">基础服务</font>例如上传图片，发送短信等很多服务都需要的基础东西，<br><br>抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘<font color="#00ff00">中台服务</font>’。<br>&nbsp;

<font color="#00ff00"><b>拆分部署催生出DEVOPS</b></font>&nbsp;<br><br>再看看这种架构下的开发模式DEVOPS，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，<br><br>微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，<br><br>如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。<br><br>而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦。<br>&nbsp;

那么为何不能再远程部署一些机器，<font color="#00ff00">专门用来管理代码，进行上线工作</font>，由<font color="#00ff00">运维事先把上线的规则都给定义好了</font>，<br><br>开发只要按照他的规则都访问这台服务器进行<font color="#00ff00">各自的代码合成和发布，自己上线</font>呢，<br><br>能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。<br><br><font color="#00ff00">运维需要做的事情，慢慢的都沉淀到了各个平台上面</font>，例如<font color="#00ff00">监控，有专门的监控组件和可视化</font>，<br><br><font color="#00ff00">基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，<br></font><br>日志也有专门的日志工具，<br><br>链路追踪也有专门的组件和可视化，<br><br>还有网关等，渐渐的，只要这些都配置好了，<font color="#00ff00">开发也可以做运维的部分工作</font>，<br><br>毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，<br><br><font color="#00ff00">于是DEVOPS开发模式诞生了，开发也是运维。</font><br>&nbsp;

人+流程=文化

流程+平台=工具

平台+人=赋能