开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：阿里云云原生 DevOps - DevOps 基础概念】
课程地址：https://edu.aliyun.com/course/3112075/lesson/19057
阿里云云原生 DevOps - DevOps 基础概念
内容介绍
一、开发实例二、传统开发模式讲解
二、DevOps 基础概念
三、DevOps 与传统开发模式对比
四、DevOps 与传统开发模式对比
课程目标
希望通过本章节的学习，能够掌握 DevOps 的基本概念及核心组成，了解企业开发在云原生时代的困境及诉求，以及阿里云是如何助力企业轻松实现一站式 DevOps 平台，最后以企业开发所面临的困境为切入点，带领体验阿里云云效成是如何构建企业 DevOps 解决方案的。
一、开发实例
1、问题现象
此处列举了一个具有代表性的例子，某企业有20人左右，分工明确的一个开发团队，有产品经理、开发人员。部署人员、测试人员等，以传统的瀑布式开发模式运行，整个开发过程如下，开发12天，联调（集成）5天，测试（端到端）8天，上线8小时，计算出发布一个需要一个月的时间，此过程还存在异常情况的发生，需要消耗额外的精力排查和修复。
2、问题分析
从两个方向对该现象进行分析，一是各阶段周期时间拆分二是各个环节中的等待、阻塞及资源浪费情况，最后定位出关键问题。
3、问题定位
（1）系统紧耦合问题较严重，相互影响和阻塞。
该项目本身是由多个子系统组成的复杂性，且没有采用微服务的架构，而是传统的多系统间的紧耦合，模块之间相互依赖，这样会造成多个子系统间无法并行交付，相互之间影响较多。一个子系统上线，其他相应的子系统就需要做相应的集成和联调，并且故障的传播是不可控的，只要一端出现问题，整个版本会被阻塞。
（2）各端未控制质量，集成时问题爆发。
首先，开发人员的自测不足，带有隐患的输出物直接进入后续环节，导致大量的缺陷在集成阶段集中暴露；其次，自动化能力的缺失，大量依赖人工处理，包括部署、测试、交付在内的所有操作均需要人工方式来执行；此外，团队间存在资源争抢问题，相互之间的冲突比较严重。
（3）环境交付未归一化，发布效率低。
一个版本开发完成后，首先会被部署到测试环节，测试完成后再放到类生产环节，最后才能部署上线。在此过程中，需要以手工的方式做多次版本的迁移，很容易导致线上线下不一致，同时测试环节、类生产环节也需要专门的维护，耗费大量的成本；并且串行式的发布上线，需要长时间的停服。为了尽可能减少对业务的影响，经常看到很多团队在凌晨进行版本升级，但是对于电商、短视频等许多行业，即使凌晨停服升级，在业务上也是无法接受的。
二、传统开发模式讲解
传统的开发模式如下，将业务、开发、测试、运维等许多环节都区分很清晰，PD 将需求写出，开发者根据需求完成代码的书写，传达到 SCM ， SCM 将代码带包，打包后传达给 QA ， QA 运维完成后通知 Ops 上线， Ops 进行上线部署，最后整个需求 relieve 版本。
这种方式的优势在于分工明确、职责清晰以及质量有保证，层层制约容易把控；劣势也较明显，开发和运维团队是完全独立的，在这种情况中会容易产生两个问题，一是整个过程需要多个部门人员的参与，沟通成本高，如开发人员需要了解需求才明确如何写代码， QA 也需要了解需求才能明确如何做测试， Ops 同样需要了解需求才能够维持线上版本的稳定；二是在过程中存在大量的人工操作，每个环节的质量都是不可控的，每个环节都可能成为项目推进的瓶颈。
三、DevOps 基础概念
为了解决上述问题， DevOps 应运而生，在这种模式下都发生了改变，不再是每个人做完自身事情交给下一个人，而是通过工具驱动所有的流程往前走，如开发写完代码，通过工具驱动自动打包、自动测试、自动升级、自动部署，同时还会配置监控，在工具的外围，确保工具中的每一个环节能够正常运转，同时还要保障工具中的模块能够支撑新的业务变化。
DevOps 分工模式的好处很明显，可以减少沟通成本及等待风险和降低正常需求交付所需时间，使得各个团队减少时间损耗，能够更加高效协同工作； DevOps 分工模式的劣势是，每个环节参与的角色较多，风险较高，另外对于业务形态多的企业，工具支撑成本高，因为每一种业务形态都需要 DevOps 工具集做支撑，工作量十分巨大。
DevOps 是一套集组织文化、团队协作、工程实践和工具为一身的工作方式， DevOps 并不是一个工具集，也不是一个开发流程，它是一种工作方式，以帮助企业高效、快速、高质量地交付应用程序和服务为目的，从而更好地实现客户价值为目标，它的出现正是可以帮助企业能够帮助企业跨越业务高速发展和研发低效交付的鸿沟。
DevOps 这个词是由 Development 和 Operations 组成的，它是一种促进开发和运维团队之间的协作，以自动化和可重复的方式更快的将代码部署到生产中的文化， DevOps 帮助团体提高软件和服务的交付速度，使团队能够更好的为客户服务并提高在市场中的竞争力，简而言之， DevOps 可以定义为通过更好的沟通和协作，使开发和运维保持一致，进而减少团队间的损耗，更加高效的协同工作。 DevOps 实现了技术与流程的自动化，是一种组织管理和流程方式，是软件质量和监控的关键环节，同时也是一种企业文化。
四、DevOps 与传统开发模式对比
研发运维一体化是很早以前就已经提出的敏捷开发的概念，它提倡团队在开发和运维的过程中进行有效的沟通，从而形成一种敏捷的开发模式。 DevOps 1.0 就是在这种敏捷开发模式的基础上提出的，它的核心是为了解决开发和运维过程中的沟通和协调问题，但是因为一些技术问题，并没有完全实现自动化测试，自动集成和自动部署，系统架构也都为分布式的，并没有完全实现微服务的架构。 DevOps 2.0时，就能通过技术手段实现自动化的流水线，能够自动化的集成和自动化的部署，由此， DevOps 也进入了云原生的时代，下面从软件的架构特性、开发周期、代码和系统质量、部署难度和时间以及实施成本这五个角度逐一进行对比。
软件架构，传统模式下采用的是单体架构，每个小模块的升级改造都会对整个系统产生影响，导致上线存在很多风险，在一个大型的项目中，往往需要几十甚至上百人连续通宵多个晚上才能够实现版本的上线； DevOps 1.0虽然才采用了分布式的模式，但是缺乏自动化的流程，所以软件开发周期基本是以周为单位； DevOps 2.0 的时代采用了微服务的架构，以小功能模块为服务单元，升级时只需要升级特定的服务单元，从而大大的提高了软件的交付效率，可以做到小时甚至分钟为单位进行迭代，一天能够迭代十几次甚至更多。
代码和系统质量，传统模式往往使用一种语言模式做开发，这会导致一些场景上的开发受到限制，子系统间紧耦合，没有很好的代码质量保障； DevOps 1.0 系统可以是异构的，不同层次之间可以使用不同的语言，但核心后台数据库的质量对系统影响严重； DevOps 2.0 时代使用了微服务，每一个模块都可以绑定自己的存储，使用不同的存储方式，可以使用不同的语言来解决特定的问题，子服务更加益于单独测试，代码的质量也更加有保障，系统能够以子服务为单位做到扩容和故障隔离。
部署难度，传统模式部署是以月为单位，并且有大量的工作依赖于手工操作，难度大、风险高、易出错； DevOps 1.0时代部署是以虚拟机为单位，可以通过云服务厂商提供的模板降低部署难度，但是部署回退的问题依然没有解决； DevOps 2.0以容器为单位的发布和更新，支持灰度、蓝绿等发布风格，可以方便的回退。实施成本，传统模式下，开发、部署和运维会浪费非常多的成本； DevOps 1.0 采用了敏捷模式开发，大大提升了开发的效率，采用自动化运维工具，也降低了很多运维成本； DevOps 2.0需要投入更多的成本在前期阶段，开发之群需要有一个整体的流程，需要配置自动化的代码流水线还有相应的工具集，在整个流水线架构完成之后，后续的开发成本会大大降低，同时带来了部署和运维的时间成本的极度优化。
