作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践
从2019年上半年，我们启动了DevOps过程实践相关工作，其中既包括了整个容器云+DevOps支撑集成交付过程整合，也包括了我们传统单体系统的微服务架构化改造。本文主要对项目DevOps过程实践的一些内容进行总结。
些方面进一步做下阐述。
对于DevOps基本概念的理解
首先看下DevOps的定义：
DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
在18年12月11日，当时写过一篇对DevOps实践价值的思考，其中的重点是在谈DevOps，容器云和微服务架构框架的三元一体化。只有三者相互结合才能够产生DevOps最佳实践。
DevOps = Dev + Ops + QA
对于DevOps首先还是要回到这个概念的最基础理解，即是开发，运维和QA工作本身的三元一体化。在有篇文章里面谈到一点，对自己很有启发，就是原来的软件开发流程，分工边界，包括了开发，SCM配置管理，QA，测试，运维等各个环节，相对来说分工明确，但是在核心软件交付流程中流转太多，自然导致效率低，同时也导致更多的上下游扯皮。
而DevOps带来的一个关键点就是，Dev处于整个核心交付流程中，而且这个过程通过方法工具等的支撑完全实现自动化和流水线作业，而对于SCM配置，QA等则处于核心流程的外围角色，即这些支撑过程角色不参与核心交付流程，只是对交付完成的内容进行管理验证。只有这样才容易实现整个交付流程的自动化。
开发和运维
如何理解开发和运维？实际上这里面最关键的一点就是运维的基因已经融入在了整个开发过程中，再展开说明下，就是实际在系统上线后的运维阶段，传统是运维人员发现故障问题，然后转给开发再去分析和定位。
而实际上一个自动化可运维的软件，在出现问题后自动就会转为开发可理解的语言之间转到开发人员。也就是说整个过程里面并不需要运维去太多干预。
即传统路线是系统运行-》运维发现硬件故障-》运维发现中间件故障或性能问题-》转开发分析解决。而新的路线是系统运行-》各类问题直接预警或通知到对应的开发。当然整个过程硬件故障还是需要工程人员解决。
其次，传统的持续交付，特别是测试环境朝生产环境的持续交付，一定需要专门的运维和工程人员接入，进行严格的版本管理和发版流程管理。而开发运维一体化后，我们希望的是整个朝生产的持续交付过程也是自动化和流水化的过程，最多只是增加需要的人工审批环境而已。
开发和配置和QA
即使是在传统的持续集成模式下，我们看到整个过程分工也是开发每日将修改好自测通过的代码Check in，而由配置管理员负责进行自动化构建和打包，打包完成后进行自动化的部署。在部署完成后通过测试人员进行测试和验证，验证有问题后测试人员提交Bug并反馈给开发。
简单来说，传统方式下类似配置或测试人员参与了整个软件交付过程，那么整个过程就一定会有协同和沟通，产生效率问题。类似开发提交的代码构建不通过，可能需要反复沟通，或者说在分支合并的时候，也需要双方反复沟通确认等。
对于开发和配置QA一体化，简单来说就是在整个持续交付过程中，不再需要过程支撑类人员的参与，这些人都在外围，整个持续交付构成完全自动化和流水线作业，类似QA或测试，只是对最终交付的结果进行检查和测试，交付过程中（包括代码提交合并，构建，打包部署，环境迁移）等各类问题全部由开发负责，这些问题属于开发内部的问题，由开发主导去解决更加高效快捷。
DevOps的核心还是在于持续集成和持续交付
个人理解对于DevOps的核心仍然是在持续集成和持续交付上，要实现整个持续集成就包括了配置版本管理，自动化构建和打包，自动化部署，自动环境迁移，自动化单元测试或冒烟测试等诸多内容。这些内容都为核心的持续交付目标而服务。
在DevOps和容器云结合的时候，我们增加了基于Docker容器的自动化部署，资源动态调度和集群管理能力。在和微服务架构结合的时候，增加了对微服务基础管理平台框架，微服务网关的集成能力。在和运维过程集成的过程中增加了类似ETL日志分析，类似Zabbix，Nagios等平台监控预警能力。
DevOps和文化组织变革
企业要进行DevOps实践，另外一点谈的比较多的就是要进行文化和组织变更，这句话如何理解，即一个DevOps最佳实践不是简单的各种工具的堆砌，而是涉及到企业内部开发，QA和运维团队调整，开发框架，开发流程等诸多方面的调整，最终人+工具+DevOps方法论融为一个整体，才能完成最佳实践。
DevOps = 工具 + 文化。上面是对于DevOps实践的另外一个关键说法，即工具和文化的集成，只有工具不行，还需要在组织和文化上面做调整和变更，还需要整个开发运维团队转变传统的开发和思维模式。这里面究竟涉及到哪些文化，个人理解至少涉及到敏捷文化，质量文化，流程文化，客户服务这几个大的方面。只有真正理解了这些文化，DevOps实践才能够在企业内落地实施，并取得好的效果和收益。
工具从下朝上完成了整体集成，但是文化的推行一定是从上到下的。
一个完整的DevOps解决方案应该包括的内容
对于DevOps实践，可以看到涉及到业务，技术，工程，管理规范，组织等多个方面的内容。DevOps过程实践不是简单的开源技术或工具链集成，更加重要的是整个研发文化，组织，研发项目过程管理的协同改进。
同时对于对于DevOps实施同样需要目标和业务场景驱动进行持续优化和完善。对于DevOps过程实践我们可以看到实际上包括如下方面的内容：
- 传统软件过程和单体技术架构存在的问题和需求分析
- DevOps支撑平台的搭建和总体架构
- DevOps支撑平台涉及到的工具集集成
- DevOps实现端到端流水线作业和持续交付过程
- DevOps与容器技术集成实现自动化部署和环境迁移能力
- 基于DevOps的度量分析和最佳实践
- DevOps平台和微服务开发框架的集成
- DevOps平台和PaaS平台技术服务组件和技术服务能力的集成和最佳实践
- 基于DevOps平台实现的典型案例和场景分析
下面对上面这些点做一个简单的展开说明
1. 传统软件过程和单体技术架构存在的问题和需求分析
再次说明一下，不要为了微服务和DevOps而去迎合，要业务和技术需求驱动，比如当前软件开发过程，软件交付上究竟有哪些问题，是否已经影响到效率和质量。包括我们说的微服务架构的数据库拆分也是一个道理，技术成熟度不够的时候，你完全可以数据库不拆分，只拆上层组件，这也是折中可行方案。对于持续交付同样，前期你完全可以不用DevOps和容器化，仅仅实现传统持续集成最佳实践即可。
上任何新东西都必须要想清楚，具体解决的是资源，成本，效率，后期管控治理哪方面的问题。一定要有实际的需求和问题驱动，否则很难真正实践成功。包括我们现在看到的很多互联网架构最佳实践，都是互联网应用在面对海量数据，大并发实际场景下逐步积累和演进出来的。
2. DevOps支撑平台的搭建和总体架构
一个DevOps支撑平台在搭建总体架构的时候可以看到，其核心更多的是围绕持续交付进行的各种能力的集成和自动化，而不是说其本身新创作了什么能力。对于这种集成本身包括几个关键部分。
其一是和Docker容器化平台的集成，以实现自动化部署和环境间的动态迁移，包括灰度发布，资源动态调度，集群等关键能力。其二是和微服务平台的集成，类似开源的SpringCloud平台中的注册中心，微服务网关的集成。其三包括和前面提到的PaaS平台各技术组件和服务的集成。其四则是对持续交付过程中的涉及到的各类工具链的集成，包括了配置和代码管理，代码静态检查，自动化编译构建，自动化测试，自动化运维，自动化监控，日志管理等各种工具的集成。
一个DevOps平台需要提供对源代码管理，开发，编译构建，打包，部署，测试，运维完整的能力支撑，同时通过流水线设计将这些任务过程进行自动化串联。一个流水线既可以是完全的自动化流水线，也可以包括人工处理和检查节点。流水线可以对上述动作和任务进行可视化的设计和编排。
5. DevOps与容器技术集成实现自动化部署和环境迁移能力
一个DevOps支撑平台离不开和容器化PaaS平台的集成，即最终的编译构建完成的内容形成镜像并放到镜像仓库，后续部署，环境迁移，资源扩展基于镜像仓库进行快速的拷贝和复制。对于Docker容器一般会和K8S结合来实现资源的动态调度，集群管理能力。
环境迁移是基于镜像进行环境拷贝和迁移，而不再需要重新构建和打包，这也是我们原来在谈持续集成技术的时候一直强调的一点。只有这样才能够保证测试通过的包就是最终部署到生产环境的包。
6. 基于DevOps的度量分析和最佳实践
在谈CMMI的时候我们经常会谈到软件度量，而对于DevOps也有标准的成熟度模型，我们需要对DevOps执行构成中的关键活动和任务，其执行的质量和效率进行度量分析，以确认DevOps过程执行效果，并指导后续的持续改进工作。
这里面既会涉及到构建，部署和自动化测试的效率指标，也会涉及到传统的代码检查和人工测试，变更处理，缺陷泄露等质量指标等。
7. DevOps平台和微服务开发框架的集成
实际上要把这个功能谈透彻并不容易，一涉及到微服务架构开发模式，就涉及到基于微服务架构下的团队拆分和多团队协作，就会引入类似微服务网关和注册中心等基础能力。就会涉及到一个独立的微服务模块要真正能够运行并进行单元测试，离不开其它微服务模块提供的API接口服务能力支撑。
因此这种集成不是件的对开源微服务框架在开发态的集成，更多的是开发态如何和运行态集成和协同。如何在多团队协同模式下来实现多项目，多微服务模块的集成能力。实际上这个问题在我13年左右在谈私有云PaaS平台的持续集成的时候详细分析过，但是现在感觉在谈微服务架构和DevOps的时候反而没有谈透彻。
8. DevOps平台和PaaS平台技术服务组件和技术服务能力的集成
这个也是需要专门写文章来谈的，就是对于PaaS平台提供的各类技术组件和技术服务能力，如何和整个DevOps持续交付过程集成起来。当然对于单个技术组件的开发，测试和部署上线也可以使用DevOps支撑平台来完成。在原来谈私有云PaaS平台的时候，我们谈到过一个概念，即一个组件要能够运行起来需要两个方面的服务集成，一个是技术平台提供的技术服务能力集成，一个是横向的其它微服务模块组件的接口服务集成。
如何集成，包括在集成后如何进行集成测试，都是需要考虑的问题点。
基于微服务架构开发过程持续集成实践
虽然对于DevOps过程不强制要求采用微服务架构进行开发，但是如果你采用微服务架构开发那么更加适合实施DevOps持续集成和交付过程。
微服务模块划分
在微服务模块划分清楚后，各个微服务模块划分到不同的团队和人负责，那么每个团队对于自己负责的模块，在配置管理库和代码管理，数据库，开发项目上完全独立一套。负责A模块的团队不应该，也完全没有必要看到B模块开发的代码，而只需要关心接口即可。
微服务模块划分清楚后，实际上有个重点工作就是前期的架构设计和接口设计，需要先把各个微服务模块间的交互接口初步定下来，这个总体设计完成后再开始各个微服务模块的并行开发。而不是在开发中，想到需要什么接口就临时开发，这样很容易导致后续的接口混乱。
环境准备和微服务模块的开发
独立的项目，独立的代码管理，独立的数据库，但是不同的团队是基于相同的微服务开发框架，类似SpringCloud或其他开发框架进行微服务模块的开发。
A模块要调用B模块的接口才能够完成相应功能的开发和验证，这个时候就需要B模块提前准备好可用的接口并部署，在多模块协同下注意，一定是接口开发先行，即要确保接口提前开发出来可供其它模块测试用。
各个模块开发完成的接口不能部署在自己本机，因此要有独立的开发环境来部署这些接口，当然在开发环境还需要有类似SpringCloud中基础注册中心和管理中心的部署。
开发人员的本机在自测的时候可以调用开发环境提供的API接口服务能力，因此自测还是可以在本机完成，比如A模块调用B模块的API接口服务。但是需要B模块提前已经将可用的接口服务部署到开发环境。当然对于A模块而言如果也提供API接口给其它模块使用，也需要提前部署到开发环境并准备就绪。
A模块的开发项目里面，没有B模块的任何代码，而只是基于API接口远程调用接口能力。而这里最好的思路是实现一个本地化的接口代理包，即代理包封装一层后实现调用的时候是本地方法，在接口代理中再将本地方法转化为远程API接口调用。
如果A模块依赖的B模块，C模块提供的API接口服务都没有准备好，按道理A模块是无法进行后续开发的。基于传统集成思路，A模块也可以自己实现了一个本地API的接口模拟，在B模块或C模块准备好后再配置为调用远程API接口服务能力。
编译构建
按持续集成思路，开发要管的就是自己开发好的代码在本地编译通过，同时在本地测试通过后，将代码Check in到源代码管理库，后续的编译构建完全是自动化的过程。例如完成通过Git + Maven + Jekins的结合来完成整个编译构建过程。
独立的源代码管理库，各个微服务模块的项目相对也要独立，各自管理并进行权限隔离。对于数据库变更脚本注意也要进行版本管理和脚本入库，实际上最难以管理的还是在数据库的变更上。
构建服务器和源代码管理服务器可以在相同服务器，也可以在不同的服务器上。
实际的编译构建过程，首先是update到最新的源代码，然后基于常规持续集成的思路，例如Maven+Jekins完成自动化编译构建，最终形成部署包。这个过程中远程API接口调用是松耦合方式调用，因此不会对组件依赖性进行检查，也不会出现编译依赖无法通过的问题。
部署过程
构建完成后形成可部署的部署包，按容器集成思路，首先要制作镜像，并推送到镜像库存储，然后再完成部署操作。部署完成后形成并发布可访问的地址信息。该过程会涉及到一些自动化脚本的编写，可以用Jekins，也可以用Puppets等各种工具来实现这些脚本自动化。
实际的部署操作最终由K8s来接管，包括具体的初始化部署容器数量，负载均衡设置等。
在采用微服务架构开发的时候，多个微服务模块同享一套服务注册中心，包括微服务网关等，这些基础内容需要提前部署到开发环境中，并在可用状态。
微服务模块中API接口注册到网关
如果整体架构中，所有的微服务模块都不需要和外面的业务系统打交道，那么你可能并不需要使用微服务网关，但是如果存在整个架构朝外部提供API接口服务能力，包括你的APP端也需要理解为外部。那么就一定涉及到微服务网关的使用。
微服务模块中的接口方法不是所有的都需要注册到微服务网关上面，要梳理清楚，究竟哪些接口方法要注册到微服务网关上面。而这块注册操作我们希望是完全自动化注册并运行。
即微服务模块部署-》k8s发布可访问的API地址-》微服务网关封装后暴露最终的API服务地址
而这个API服务地址是可以给外部系统或前端APP使用的一个地址。对于其它应用的开发我们可以使用该地址。如果说到DevOps支撑平台，那么在集成微服务网关能力后，最基本的就是要有服务注册和管理能力。
环境迁移能力
环境迁移难的不是单个微服务模块的环境迁移，而是相关微服务模块多个部署环境同时的自动化迁移。比如A模块调用B模块的接口发生变化，这个需要同时对A和B两个模块进行环境迁移和重新部署。按持续集成的思路，从开发-SIT-UAT-生产的多套环境，一定有一个环境看板视图，能够可视化的看到各个微服务模块在每个环境的部署版本情况。
环境迁移按道理应该进行独立的流水线设计，特别是涉及到多个模块的时候。
性能监控和日志管理
对于资源和中间件监控，对于Zabbix或Nagios等完全能够实现，最难的还是APM性能监控和服务链监控等，对于这些监控的实现，一定要提前在微服务开发框架中进行标准规范定义，相关的代理组件的植入。如果采用标准的开发框架模型，你也可以考虑在镜像制作的时候将代理植入到镜像文件中并启动运行。
基于DevOps实施和组织变革
对于DevOps过程实施不仅仅是指DevOps支撑平台和标准规范体系，也包括了容器化PaaS平台，微服务架构开发框架和标准规范体系，基础技术服务平台等诸多内容，而这些内容实际上在我最近刚出版的《SOA与大数据实战-企业私有云平台规划和建设》一书里面都有涉及。
只是持续集成变成了DevOps，组件化和服务化开发变成了微服务架构，基于CloudFoundry的PaaS平台变成了基于Docker容器 Kubernates的轻量PaaS平台，对于传统的ESB服务总线和集成平台变成了微服务网关或API网关。
对于大型的基于DevOps思路下的微服务架构开发和实践，如果我们作为完整的基础平台开发商和集成商，那么在实施这个项目的时候应该具备哪些能力。而我们经过这几年的发展和技术沉淀，本身也具备提供这种基础架构平台并进行实施落地的能力。
1. 微服务架构总体设计和规划团队
这个偏业务和实施层面，即进行微服务架构的总体设计，而总体设计里面最重要的又是微服务模块的划分，模块划分后各个微服务模块的接口服务设计。这个需要有专门的既熟悉业务又懂技术的人往往才能给胜任，比如传统软件工程里面的系统分析员或资深的软件需求顾问角色是比较适合的。
这个规划不同于一个企业完整的信息化和IT架构规划，可以理解为企业某一个业务域的IT总体架构规划设计，当时对于IT架构规划的总体思路我们仍然可以参考，包括流程和业务建模，关键数据对象识别和数据架构设计，应用架构设计，技术架构设计等。特别是在应用架构设计中需要进一步体现集成架构设计，体现平台 应用的构建思想。
2. DevOps支撑平台技术团队
这个可以看做是DevOps支撑平台这个产品提供加技术支撑团队，即在有了DevOps支撑平台后，我们会对已有的Docker容器化PaaS，持续集成各类工具集全部进行打包提供，而真正面对开发者的就是DevOps支撑平台，这个团队即包括了产品本身的开发，也包括了对于DevOps支撑平台在使用中的技术支持。
3. 微服务开发框架和接口设计技术支撑团队
如果我们的微服务架构开发框架选择的是SpringCLoud话，那么这个团队重点就是在总体设计完成微服务模块已经划分好后，确保各个模块的开发商严格按照已经制定好的微服务框架，技术标准规范，技术设计开发规范，集成规范进行各自微服务模块的开发。
由于即使你没使用微服务开发框架或架构，你也可以使用DevOps支撑平台，因此对应微服务架构的实践额技术支撑，最好和DevOps技术支撑团队进行分离。这个团队核心是确保微服务架构总体设计团队的输出成果，包括前期已经制定好的微服务架构技术标准规范能够真正落地。
在采用微服务架构框架的时候，里面涉及到类似微服务注册中心，微服务网关等公共基础支撑组件，而这些基础组件的进一步定制开发，封装和实施也应该由该团队来支撑。对于微服务网关，包括服务的注册和接入，我们希望的是在DevOps整个实施过程中实现完全的自动化。
4. 基础技术平台开发和技术支撑团队
按传统平台 应用构想，在整个项目实施过程中还涉及到公共的基础技术平台建设的问题，其中最大的就是基础流程引擎能力提供，4A能力提供。其次就是涉及到日志，文件，缓存，消息，通知等各种技术服务能力提供。而这块可以统一纳入到基础技术平台开发和支撑团队。
对于技术服务的开发，每个技术服务本身也是一个独立的微服务架构模块，完全可以遵循我们已经制定的微服务架构开发条件和技术标准进行开发，并按标准提供API接口服务能力。
5. QA，测试，过程支撑团队
这个团队也是一开始就要建立，包括了质量保证，评审，配置管理和检查，测试团队。注意由于实施了DevOps实践，那么这个团队和开发团队产品交付之间将处于更加松耦合协同状态，而且边界也将划分的更加清楚。当然传统很多进行配置管理，构建，代码检查等工作也全部在DevOps实施后转为自动化处理和执行。
6. 运维监控团队
注意，这个团队一开始就要成立并进入到整体项目实施和管理，而不是等到最终的开发上线后再介入。一开始介入的好处就是确保整个项目在交付过程中就具备可运维属性。同时运维团队更加强调运维监控的自动化能力，传统的手工重复运维过程要在DevOps实施后被进一步替代。
也正是这个原因，在一个完整的DevOps和微服务架构实施过程中，提前就需要一个完整的运维监控平台，这个平台不是资源监控层面，而是需要在中间件服务监控层面，包括我们常说的APM应用性能间和服务链监控能力。
要意识到在实施微服务架构后，各个微服务模块间的接口数会呈现指数级增长，模块间的集成也会异常复杂，既包括模块和模块间的横向集成，也包括了模块和底层基础技术平台的纵向集成。因此对于后期的自动化运维，自动化服务监控预警就异常重要，这个必须是一开始就介入并进行评估。
也就是我们将原有的硬件资源监控，工程运维，服务链监控分析，日志采集监控分析等全部拿出来，合并到单独的运维监控团队，一开始就介入到整个项目实施过程中。