一.抽象的 DevOps
DevOps 是使软件开发和 IT 团队之间的流程自动化的一组实践，以便他们可以更快，更可靠地构建，测试和发布软件。DevOps 的概念建立在建立团队之间协作文化的基础上，这些团队过去一直在相对孤岛中运作。 类似于这种的 DevOps 相关的描述听起来特别抽象，非常学术，非常教科书，让人感觉无法落地，不知道该如何入手。很多团队在了解 DevOps，实践 DevOps 的时候不能很好的多维度看待 DevOps，实践的过程也很痛苦，不知道这种新型的理念如何实际提升自己团队的战斗力。
本文从开发和运维两个视角多层次的讲解什么场景应该 Dev 和 Ops 什么场景应该 DevOps，即 DevOps 的分与合，并使用一个 Demo 示例告诉大家 DevOps 中的关键步骤持续部署如何实践。
二.DevOps 的两个视角
DevOps 从字面上看就是开发和运维，也有翻译为开发运维（运营）一体化。我们这里的两个视角不是别的东西，正是开发和运维。这里的开发，不能简单的理解为开发工程师，指代的是整个软件的研发过程所含的所有要素，涵盖需求分析、开发、测试等等，其终点是可交付的软件制品。同样运维不仅仅是运维工程师，指代的是软件交付后投产过程以及后续的运营，反馈等系列过程，其起点是接受交付的软件制品。
这么两个视角的区分是隐含着软件工程背后的逻辑的，就像一栋大楼，他的建设方是建筑和设计公司，他的运营方是物业公司一样，两者之间有相对清晰的界限。
我们需要回顾软件行业的发展，来看为什么 DevOps 被提出来，为什么现在要强调 Dev 和 Ops 的紧密结合以及什么场景要紧密结合，什么场景不需要。
以下四个方面促使了软件行业开始意识到 DevOps 的作用：
- 网络化：典型的传统软件代表 Office 系列，Photoshop 等大都不需要网络支持，单体安装在电脑上即可使用，这类软件不牵涉运维，所以更没有 DevOps 概念。新型的以互联网为基础的软件，例如微信，腾讯会议等都是建立在网络基础上的，这属于典型的 C/S 的架构，C/S 架构中服务器端软件地位极为重要，服务器端软件是隐藏在众多用户背后的不可见的，需要稳定性、安全性等运维诉求，就引出了开发和运维工作的协同化诉求。
- Web 化：相对于 C/S 的软件，B/S 的软件在用户端的部分（C/S 是桌面或者手机应用，B/S 是网页）上有更高的更新发布频率，需支持更新过程不停止服务，无感更新等特性，对软件的交付速度和质量有了更高的要求，这也引出了开发和运维工作的协同化诉求。
- 云化：传统的 ERP，CRM，HRM，视频会议系统都是有软件供应商独立实施给客户方，而这些软件也都在逐步云化，产生了例如销售易，腾讯会议，钉钉，企业微信等 SaaS 应用软件，这类 SaaS 化的软件对 DevOps 诉求更为迫切。
- 敏捷化：传统的外包软件交付模式因其反馈周期长，实施成本高等弊病已经开始大规模的转向敏捷、小步快跑、高速迭代的模式，更高的交付速度要求开发和运维之间必须建设协作文化，流程，标准以及工具。
- 如果你的软件不符合上述四个发展方向，看到这里就够了，你不需要去实践人云亦云的 DevOps，尝试只会给你带来不必要的麻烦。
DevOps 正逐渐把开发和运维中间的界限模糊掉：
本文在探讨完毕两个视角、双向移动、四个层面后会把开发和运维的中间重叠部分（软件交付）为主题来详细阐述这一 DevOps 实践的最大难题。
开发视角 开发阶段关注的信息和概念跟运维运营阶段有相当大的差异又有部分的重叠：
运维视角 同样的，运维阶段关注的信息和概念与开发阶段有相当大的差异，又有部分重叠：
视角的聚焦 在对 DevOps 概念进行理解，全局考虑的时候需要能像上文中提的一样理解开发阶段和运维阶段的广义性，但在本文设计的持续部署话题，因篇幅限制，会把视角聚焦在开发阶段的结束和运维阶段，考虑狭义的运维概念（即传统理解的运维工程师的工作范畴）通过剖析运维工程师的工作内容变化来讨论 DevOps 的分与合。
那么对于运维工程师的基本工作而言，可以把模型简化为如下两个方面：
三.业务运维的左移
在高频次的程序发布，爆发式业务增长的场景下，运维团队越来越痛苦，在加上很多团队没有合适的工具系统和标准化的部署流程，经常会看到团队内的双向吐槽：
开发团队说： 为什么我们这边修好了 bug 今天不能给我发布？我需要查一下生产环境日志要等 3 个小时？运维同学能不能不要总是抄错配置项？
运维团队说： 请用文档详细撰写清楚发布步骤和注意事项并仔细评估发布风险。运维团队已经排满了所有发布计划，你这个修复问题不严重，请等下周再排。
运维团队陷入无限的机械性重复劳动中，而其中大部分工作都是低杠杆的执行发布，查询日志，执行回退等。
这属于 DevOps 的分离的场景，团队与团队之间有工作压力不均，信任感缺失，目标不一致等问题，建议尝试做一些业务运维的左移，也即在合适的工具系统基础上把业务运维的部分权力或者人员分配到开发团队，使之可以完成大部分的程序发布、配置更新、日志查询等工作，解放运维。
形成下图效果，从人员上可以是开发兼职业务运维，也可以是开发团队有专职业务运维人员，其本质是业务运维的主要工作闭环在开发团队内部，实现高效运转。
这样即在某种程度上实现了 Dev 和 Ops 的合。
四.基础设施运维的右移
信息数据的安全诉求，以云为代表的基础设施的虚拟化、弹性化、甚至于代码化的发展也给运维团队的基础设施运维工作带来了新的挑战和机遇。我们会发现基础设施运维团队在云的发展下渐渐的实现了右移（把基础设施全信任的交给云处理）。
在没有云主机的年代，运维团队不得不扛着沉重的服务器去机房里，对照着官方指南，安装操作系统、配置网络策略；云主机时代，容器还未到来之时，运维团队摆脱了物理服务器，却不得不维护大量的服务器软件，安装、卸载、批量发布等，去维护业务运行的基础软件环境；在有了 Kubernetes，Docker 等容器技术之后，运维工程师从维护软件运行基础环境中解脱，转而做更上层的基础设施：监控体系、负载均衡等；不远的将来，当 Serverless 重构云计算体系的时候，运维人员连监控体系、负载均衡等都不需要关注了，全量交给云来解决。
云的不断发展的历程也是一个逐步吞噬基础设施运维人员工作的历程，如今运维人员在云的基础上有了云 LB 不需要再运维 HAProxy，Nginx 等，有了云数据库不需要再运维 MySQL、Redis 等。如此种种，基础设施运维的工作都右移给了云。
当然这个右移不是一蹴而就的，是个渐进的过程，需要行业慢慢去接受，也需要云的成熟与发展。最近沸沸扬扬的微盟运维人员删库跑路事件是一个很好的佐证，他们使用了腾讯云，腾讯云最终帮他们找回了数据，但他们基础设施运维的右移程度不够高，换句话说叫做云原生渗透不够深，如果使用的是类似于云数据库这类云提供的数据库基础设施，那也许大可不必使用硬盘恢复技术来找回数据。
诚然，云产品还有长远的路要发展，但在现有的云的能力下，各位可以思考下，自己团队的基础设施运维右移了多少，阻碍右移的问题是什么，右移不够导致浪费了多少人员精力，带来了多少风险。
