对DevOps实践的一些思考01(1.15)

最近1到2年的博客文章，我谈微服务架构的比较多，而专门谈DevOps的比较少，包括对DevOps支撑平台和DevOps实践的一些关键点思考。19年准备对DevOps这块进行深入的了解和实践。在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实践才能够在企业内落地实施，并取得好的效果和收益。

工具从下朝上完成了整体集成，但是文化的推行一定是从上到下的。