对DevOps实践的一些思考01(1.15)
- - 人月神话的BLOG最近1到2年的博客文章，我谈微服务架构的比较多，而专门谈DevOps的比较少，包括对DevOps支撑平台和DevOps实践的一些关键点思考. 19年准备对DevOps这块进行深入的了解和实践. 在18年12月11日，当时写过一篇对DevOps实践价值的思考，其中的重点是在谈DevOps，容器云和微服务架构框架的三元一体化.
对DevOps实践的一些思考01(1.15)
标签：
IT咨询
| 发表时间：2019-01-15 09:17 | 作者：人月神话
出处：http://blog.sina.com.cn/cmmi
最近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实践才能够在企业内落地实施，并取得好的效果和收益。
工具从下朝上完成了整体集成，但是文化的推行一定是从上到下的。
相关 [devops 实践 思考] 推荐：
『DevOps 最佳实践』 — DevOps 实践
- -Culture – 文化：公司各个角色一起担当业务变化，实现有效协作和沟通；. Automation – 自动化：在价值链中尽量除去手工步骤；. Lean – 精益：运用精益原则更频繁地交付价值；. Metrics – 度量：度量并使用数据来优化交付周期；. Sharing – 分享：分享成功和失败的经验来相互学习.
DevOps实践一：DevOps概述 - 知乎
- -DevOps系列文章包含了本人在工作中的实践和认知理论，现总结并分享出来，希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改)：. DevOps实践一：DevOps概述. DevOps实践二：持续集成、持续交付和持续部署.
『DevOps 最佳实践』 — DevOps 平台 - Ledge DevOps 知识平台
- -DevOps 数字化转型框架. 企业为什么需要一站式综合研发平台. 越来越来多的组织开始搞敏捷和 DevOps 转型，打造了很多的 DevOps 基础设施，比如有管理需求的 Jira， 有持续集成的 Jenkins，有容器编排的 K8S 等等. 可是这纷繁复杂的 DevOps 工具链，同时也给企业带来新的困扰.
DevOps最佳实践(200711)
- - 人月神话的BLOG今天准备谈下DevOps过程最佳实践以及DevOps支撑平台建设中的一些思考. 在前面文章里面我就已经谈到了传统企业IT架构转型或企业数字化建设需要解决两个方面问题. 其一：业务层面，重点是中台规划和建设. 其二：技术层面，重点是云原生解决方案，包括了微服务，DevOps和容器云. 当然，如果你是传统的软件开发框架技术，或者传统的基于虚拟机的PaaS平台也可以上DevOps实践，但是我们更加推荐的还是基于微服务和容器云技术来实践DevOps.
再谈DevOps实践和价值(12.11)
- - 人月神话的BLOG今天再谈下DevOps过程实践和实际的收益价值问题. 对于DevOps先引用网上的一段总结如下. 这里我们先分析一下DevOps是什么. 大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化，其实这样理解很片面. 其实我们不难从Patrick提出DevOps的过程得出结论，DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应，也就是DevOps
= Dev Agile Ops Agile.
中小团队基于Docker的devops实践 - 掘金
- -笔者所在的技术团队负责了数十个项目的开发和维护工作，每个项目都至少有dev、qa、hidden、product四个环境，数百台机器，在各个系统之间疲于奔命，解决各种琐碎的问题，如何从这些琐碎的事情中解放出来. devops成了我们不二的选择. 文章是基于目前的环境和团队规模做的devops实践总结，方案简单易懂，容易落地且效果显著.
对DevOps流水线设计的优化和改进实践（201014）
- - 人月神话的BLOG对于DevOps过程支撑平台，我在前面已经写过相应的文章. 在整个DevOps平台的建设过程中可以看到持续集成和持续交付始终都是平台的一个重要内容. 而在整个持续集成和交付过程中，流水线设计又是相对关键的一个内容. 通过流水线设计可以很灵活的通过可视化配置的方式，将我们软件持续集成中涉及到的编译构建，打包，部署，代码检查，测试，环境迁移等各种活动编排在一起，形成一个自动化执行的完成流程.
DevOps在证券互联网研发中的应用与实践
- - DockOne.io近些年金融科技在证券行业发挥的作用越来越重要，运用金融科技赋能业务发展，通过个性化服务构建护城河，将金融科技与业务创收和降本增效相结合开始成为证券从业人员所关注的问题，如何提升研发交付效率、小步快跑、快速迭代是所有证券行业科技研发团队共同关心的话题. 敏捷为快速迭代提供了理论思想和方法指导，DevOps为敏捷落地提供了补充和工具支持.
DevOps最佳实践之应用开发和部署 (insights.thoughtworks.cn)
- - IT瘾-jianshu本系列内容是我们在不同项目的维护过程中总结的关于DevOps/SRE方面的最佳实践，我们将致力于在项目上尽最大的努力来推行这些最佳实践. 我们希望这些最佳实践能对项目的稳定运营提供帮助，也希望刚接触DevOps/SRE的新人能通过学习这些最佳实践来提升自己在这方面的水平. 因为DevOps/SRE涉及到的方方面面比较多，一次性完成的工作量太大，所以我们决定分阶段来完成，这一次发布的是“应用开发和部署”这个部分的内容，后续我们将逐步发布“云平台与网络”，“操作系统和服务”，“用户与权限”，“监控与可视化”，“数据与备份”，“敏感数据”，“故障与应急响应”这几部分的内容.