牛年收官之作：谈一谈DevOps框架与流程
这里，我把几个有代表性的DevOps定义列出来，然后综合这些定义，我再试图给出更为清晰、完整、易理解的DevOps定义，从而帮助大家全面了解DevOps的内涵。
【维基百科】DevOps是一种重视 “软件开发人员（Dev）” 和 “IT运维技术人员（Ops）” 之间沟通合作的文化、运动或惯例。通过自动化 “软件交付” 和 “架构变更” 的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。（注：“软件开发人员” 已经被误用，所以这个定义是有问题的，这里的Dev应该是指整个研发）
【Gartner的定义】DevOps代表了一种IT文化的变化，侧重于通过在面向系统的背景下采用敏捷、精益的做法来快速提供IT服务。DevOps强调人（和文化），寻求改善运维和开发团队之间的合作。DevOps的实施利用了技术（特别是自动化工具），可以从生命周期的角度利用日益可编程和动态的基础设施（注：如基础设施是代码、容器/虚拟化技术）。
【PMI的定义】严谨的DevOps是指IT解决方案的开发、IT运维活动以及支持企业的其它IT活动（如安全和数据管理）的流水线化（streamlining），以便为企业提供更高效的结果。
【Gitlab的定义】DevOps是软件开发人员（dev）和运微（ops）的结合。它被定义为一种软件工程方法，旨在通过促进协作和责任分担的文化，整合软件开发和软件运维团队的工作。（注：狭义的DevOps，问题同上）
【SAFe】DevOps是一种思维方式、一种文化以及一套技术实践。它提供了沟通、整合、自动化以及计划、开发、测试、部署、发布和维护解决方案所需的所有人员之间的紧密合作。DevOps是精益企业的敏捷产品交付能力的一部分，企业实施DevOps是为了打破组织上的隔阂，开发一个持续交付（CD）流水线（CDP）——一个高性能的创新引擎，能够以业务的速度交付市场领先的解决方案。
【Atlassian的定义】DevOps是一套实践、工具和文化理念，它使软件开发和IT团队之间的流程自动化和一体化，强调团队授权、跨团队的沟通和协作以及技术自动化。
【Amazon的定义】DevOps 集文化理念、实践和工具于一身，可以提高组织快速交付应用程序和服务的能力。开发团队和运维团队不再是“孤立”的团队，他们的工程师会在应用程序的整个生命周期（从开发、测试到部署、再到运维）内相互协作，开发出一系列不限于单一职能的技能，并使用能够帮助其快速可靠地操作和发展应用程序的技术体系和工具，可以独立完成通常需要其他团队协作的任务。
【Microsoft的定义】DevOps使以前孤立的角色——开发、IT运维、质量工程和安全——能够协调和合作，以开发更好、更可靠的产品。通过采用DevOps文化、实践和工具，团队获得了更好地响应客户需求的能力，增加了对其构建的应用程序的信心，并更快地实现业务目标。
在清楚了DevOps概念之后、讨论DevOps框架之前，我们需要了解一下DevOps主要实践有哪些，这样有利于理解DevOps的框架和流程。
从宏观上看，DevOps主要实践有：MVP、CI/CD、交付流水线、微服务架构、基础设施即代码、自动化测试、测试左移和测试右移、A/B实验、混沌工程、持续测试、智能监控、日志分析、快速反馈/持续反馈、面对面沟通、加强协作、快速创新、可观察性等。
如果更深入看DevOps实践，可以看一下张乐老师之前在QECon大会上的分享： DevOps五大理念及其落地实践（注释版），其中五大理念是：
局部性和简单性； 专注、流动和快乐； 改善日常工作； 心理安全； 以客户为中心。
在规模化之前先去规模化 通过依赖矩阵识别并暴露依赖 通过管理和技术手段减少依赖 通过云原生应用架构简化开发工作
通过看板暴露未计划的工作
通过看板管理端到端价值流动
通过滞留项报告暴露流动阻塞
建立代码分支及质量守护模型
高频集成，打造持续交付流水线
建立管理流与工程流之间的联动 建立满意度反馈体系
关注代码的技术负债率 为每种工作类型预留工作时间
事后：不指责的事后故障回顾 事前：通过混沌工程加强服务健壮性
基于价值流的研发效能度量 系统思考，打造研发效能提升的金三角
3. DevOps框架
上面列出了DevOps的各种实践，虽然由于篇幅有限，无法展开讨论，但我们构成的框架，需要把这些实践包含进去或整合起来，例如：
从文化看，包括以客户为中心、跨部门的密切沟通与协作、MVP、价值交付、快速创新、质量内建文化、测试左移和测试右移思维方式、CI/CD文化等。
从组织和人员看，建立自组织的特性团队，提升组织意识和客户意识，提升团队技术能力和沟通、协作能力，培养DevOps文化、质量文化。
从流程看，关键是构建交付、反馈的闭环，构建有效的、价值流、管理流、工程流的流程及其管理平台，建立看板和协作机制等；
从技术和工具上看，涉及的内容更多，微服务架构、CI/CD基础设施、基础设施即代码、自动化测试、单一代码管理平台、交付流水线、A/B实验、混沌工程、依赖矩阵、智能监控、实时日志分析、满意度反馈平台等，如基于Jenkins 全过程自动调度的流水线、基于容器技术的研发/生成环境管理。
DevOps框架就可以简单描述如下图所示。
我们也可以看一下更为简单或企业应用的DevOps框架或模型，例如CAMS模型（Culture, Automation, Measurement, Sharing）就更简单，4个基本要素：
自动化（Automation）可以映射到领域1：交付过程，包括自动部署、自动测试、自动监控，消除等待时间、减少人为错误等；
度量（Measurement）似乎可以映射到领域2：反馈过程必须穿越部门墙、跨越传统的筒仓（烟囱）界限，充分共享、密切协作；
文化（Culture）属于领域3：生产环境中的嵌入式研发（人员），开发人员在利用运维知识时能做出更好的决定；
分享（Sharing）到领域4：嵌入项目（研发）中运维（人员），运维人员在应用研发知识时也能做得更好。
领域1：将交付延伸到生产，这是开发和运维合作的地方，以改善项目交付到生产中的任何事情。 领域2：将运维延伸到项目，所有来自生产的信息都会被辐射到项目中。 领域3：将项目（开发）嵌入到运维中，当项目对生产中发生的所有事情拥有共同所有权时。 领域4：将生产（运维）嵌入项目中，从项目一开始，运维就参与进来。
（基于CAMS模型的DevOps框架）
另外一个类似框架就是CALMS，它是评估公司采用DevOps流程能力的框架，也是衡量DevOps转型期间成功与否的一种方式。这个缩写是由The DevOps Handbook的作者之一Jez Humble创造的，代表文化、自动化、精益、度量和分享，也只是比CAMS多了一个精益（Lean）。
IBM的企业级DevOps框架（含流程）更完整，参考下图及其文字。
分析和计划：查看组件间依赖关系（应用发现和交付智能），提高速度，计划和协作（工作流管理）。 代码和构建：快速交付，云原生开发，更快地构建混合应用，一次构建、随处部署（一致的管理和协调），自由选择SCM（软件配置管理，自动配置和变更控制）。 自动测试：测试左移，容器化测试，单元测试。 预置、部署和发布：自动化部署（利用快速反馈、持续交付和审计跟踪），预置多云环境，同步分发应用程序。 监控：监控应用程序，代码级的洞察力，提高性能。 为复杂环境创建优质系统。
华为集30年经验提炼为一张DevOps 实施框架图，如果看不清楚，请访问 这里 下载高清版本。
DevOps流程其实大家看的比较多，如同上面这张图所显示的那样，形成研发与运维闭环、闭环、闭环（重要的事说三遍），其核心就是研发这边的CI/CD（持续集成与交付）和运维那边（来自客户）的持续反馈，并需要持续的协作和沟通的支持。即使加上安全、质量保证，称其为DevSecOps、DevQAOps，其实也是形成安全、质量保证的闭环。
如果只强调持续交付流水线，就可以用SAFe的两张图来描述，这里的核心是持续探索、持续集成（包含的持续测试）和持续部署，而且这种发布是可以做到按需交付。
让价值快速流动，其中有六个实践：可视化、限制在制品、减少规模、减少交接数量、持续识别和拓展约束，以及在价值流中消除浪费。 反馈原则，有四个实践：是在出现问题时及时发现，密集解决问题、构建新的知识，将质量向源头推进，为下游工作进行优化。 持续学习和实验原则，有四个实践：开启组织学习和安全文化，让日常工作的改进做到制度化，将局部发现转为组织全局改进，在日常工作中注入恢复模式
https://en.wikipedia.org/wiki/DevOps
https://www.atlassian.com/devops
https://www.scaledagileframework.com/devops/
https://cloud.google.com/devops
http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/
https://devops.com/surprise-broad-agreement-on-the-definition-of-devops/
借此机会祝各位读者新春快乐！
未来事业有成、生活幸福安康！