文章来源：本文根据嘉为蓝鲸2021研运治理实践大会嘉宾段亚浩的演讲总结得出
背景
Why：为什么需要DevOps？
伴随着新一代信息技术（人工智能、区块链、云计算、大数据等，通常称之为ABCD）的深度应用，全面推进数字化转型，已成为了新时期企业生存和发展的必然选择。
DevOps作为支撑数字化转型的基石，通过体系化的研发实践导入、软件架构的整体革新、组织管理理念的不断升级和企业文化的影响塑造，来帮助企业改善整个软件交付过程，实现高质量和高效率兼得，同时持续改善企业内部的文化建设（工程师文化、学习型组织等）。
What：什么是DevOps？
什么是DevOps，这个概念已经并不陌生，但对于各个团队来说都会有自己的侧重点：开发希望只编写代码，其他的事都不用管，全部自动化完成。而运维希望，每次的部署都是小步的、短周期的，从而进行充分的测试验证，保证部署上线时不容易出问题。在开发和运维之间则希望能更好地沟通协作，在保证质量的情况下来提升交付效率。
以下是DevOps Master白皮书中对DevOps知识体系的定义，即一个基础三大支柱，以精益管理的基础，通过敏捷管理、持续交付和ITSM来支撑从需求到运营的端到端的过程。
精益管理
在精益管理方面强调的是内建质量，通过单建流的方式实现小批量的交付，同时建议整个组织转型为学习型的组织。
敏捷管理
敏捷管理方面，需求是要条目化的，需求拆分到什么颗粒度，任务多大比较合适，都要有一定的标准。同时要做DoD，即对完成的明确定义，比如开发要做单元测试，能把整个功能向其上下游，即业务、测试做show case。开发敢把自己实现的功能做演示，那么基本可以认为他的功能开发是比较成功的、bug是少的，否则也不敢做展示。
持续交付
在持续交付里面有两个重要的概念，一个是自动化，一个是流水线。自动化这一块要求所有过程全部自动化，如测试自动化，部署自动化等。同时，还需要建立一个可重复且可靠的流水线，保证随时可触发、持续性的。
IT服务管理（ITSM）
最后是ITSM，传统的方式一般都会有上线评审会，需要做一连串繁琐流程的审批。这部分有些审批环节是非必要的，则建议能去掉的就去掉，能精简的就精简，尽量避免影响整个交付过程，保证业务的连续性。
How：DevOps平台选择的常见疑问
到底是自研好还是采购一个平台好？
- 企业原本已经有了一些工具，应该如何做迁移、替换？
- 公司各个部门都有各自的工具，如何将其集成打通？
- 引入了工具、平台，但试点团队用的效果并不理想，应该如何处理？
这几个问题在DevOps的建设过程中是非常常见的，以下通过系统地思考和梳理，总结了十个关键点，作为企业进行DevOps平台建设的建议或参考依据。
平台选择的依据
1.研发协同
- 开发模式，平台可以支撑传统开发模式和敏捷开发模式，即支持稳敏双态；
- 对产品和项目管理提供支持，通过主办系统和辅助系统的协同实现项目集管理；
- 底层流程引擎可以通过拖拉拽方式实现各种模式的灵活自定义和配置。
研发协同，通过需求这个核心抓手，实现对软件交付全生命周期的精细化、可视化管理，贯穿各个阶段进行跟踪与管控，从而对团队中的瓶颈或研发效能较低的部分能够快速洞察，以便不断进行协同优化。
2.分支策略
对于开发人员，更多的是希望自己能够专注在代码开发中，期望平台能够支持多种类型的分支策略。支持分为两个层面，松散型和强绑定型，这里希望是强绑定的，即平台固定支持几种模型，自动化创建分支、合并分支、打tag等等，解决研发人员一切分支烦恼，使其能够聚焦于重大问题解决，专注于功能代码的实现。
3.代码评审
平台需要能够提供代码评审能力。谷歌作为代码评审的佼佼者，不仅将评审经验总结为最佳实践分享出来，同时还开发了一个工具，即Gerrit。其两个优秀的特点：通常我们都希望开发主干的代码是比较稳定的，bug少的；在这里Gerrit提供了评审分支，未通过评审的代码，是不允许合入远端分支的，以此来保证远程分支不被新代码破坏。第二个好处是可以多人评审，通过打分机制进一步提高代码的质量。
4.质量门禁
软件交付的各个阶段都需要对质量进行把控，如果没有达到标准的话是不允许通过的。举个例子，代码质量门禁应该怎么做？最好的方式是有代码规范的扫描，有安全的扫描，在单元测试方面覆盖率最起码的要达到60%以上，并且通过率达到100%，否则是不能通过的。对质量的把控，就需要平台具备质量门禁的功能。
5.CI引擎
常见的CI引擎一般使用较多的是Jenkins，入门简单使用方便，但并发量太高时，无法避免会出现一些问题。这就要求CI引擎能够满足稳定性、可扩展性的需求。首先是功能上，要能支持常见的CICD场景。第二点是可通过可视化的，拖拉拽的方式创建流水线，方便快捷。第三点，架构支持横向扩展，比如说根据并发量进行自动扩缩容。第四点是CI引擎可以支持各种操作系统，复杂构建环境等。除此之外，流水线的插件、模板、代码检查规则集等其他能力也是对平台CI引擎的衡量指标。
6.自动化测试
- 需要支持分层测试框架；
- 可以快速集成常用的测试工具，复用企业已有测试资产；
- 支持测试左移，主要强调两个点，一是测试人员在需求澄清阶段就可介入，二是可以在开发测试环境中提前做一些测试工作。
7.配置分离
配置中心可以把不同环境的所有配置进行纳管，一方面可以统一管理配置，另一方面应用和配置分离可以实现一个制品包从不同测试环境一步步晋升到生产环境的要求。
8.容器/非容器发布的支持
平台需要支持传统的发布模式和容器发布模式，即支持统一应用发布。既可以发布到云上，也可以发布到容器集群上，当然，对传统的应用也要能够进行主机发布。
9.制品库
- 对私库类型的支持；
- 对制品包类型的支持；
- 元数据可追溯；
- 支持多数据中心同步分发；
- 支持严格权限管理、安全扫描等功能。
10.综合能力
- DevOps平台需要对各种研发模式有很好地支撑，如敏稳双态的支持；
- 对常见开发语言的支持，不同开发语言会涉及不同的构建方式；
- 对部署方式的支持，传统的方式、灰度方式等；
- 对部署载体的支持，对虚拟机支持、对容器支持等。
以上从四个方面分析了平台需要具备的能力，嘉为蓝鲸DevOps平台设计理念从四个方面：一站式平台、自动化一切、数据流贯通、高可扩展性，可以覆盖以上阐述的内容。
一站式平台
实现底层工具的集成打通，毋需在各个工具之间切换，支持研运人员高效协同。
自动化一切
通过插件化能力实现交付过程完全自动化，支持异构化应用持续交付。
数据流贯通
一站式一体化平台，数据收集、分析、展示统一口径、统一标准，实现精益度量。
高可扩展性
架构高可用的，并支持通过研发商店进行能力扩展。
嘉为蓝鲸DevOps的能力，可以满足从协同、到开发、到集成、到测试、到运维、到度量的各种场景。
有平台就够了吗？
整个平台的能力建成之后，我们还要思考下一个问题：有平台就够了吗？
显然，回答是否定的。
仅有DevOps平台还是不够的，平台仅是一个皮囊，我们还需要给平台赋予灵魂。这就要求企业结合自己的实际情况，将其特有的研发模式、工作流程、工作规范与平台进行深入融合，这样的平台才是一个符号企业自身特点的平台。有了灵魂以后，还需要把各阶段自动化脚本进行完善，即自动化一切，初步建成完整的平台能力。再对企业不同角色进行赋能，使其具备快速交付用户价值所需要的能力。最后通过试点项目总结企业自己的最佳实践，并进行推广，从而实现组织级的效能提升。
DevOps的建设从来都不是简单的平台引入。有了平台以后还需要：
- 前期需要系统地咨询、专业的教练进行引导，构建组织及建设蓝图；
- 结合企业自身实际，对流程、规范体系进行优化，而后与平台进行深度融合；
- 融合平台后，一般通过试点项目完成最佳实践的演进；
- 最佳实践推广，在推广过程中进行团队建设，包括技术能力、协同能力、工程师文化以及学习文化的建设，不断识别团队中的问题，持续改进；
- 通过团队敏捷教练的培养、工程教练的培养，持续反哺优化整个过程。
DevOps平台的建设是一个长期的、持续改进的过程，伴随着工具、平台的引入，企业也需要不断地调整，以达到整个组织的敏捷化、高效化，从而实现业务价值交付层面的提升，推进整个企业从内到外的数字化进程。
