devops从理论到落地

devops是什么？

DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以 C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织

devops落地建议：

从devops定义里我们可以看到，devops的整个落地分为三个要素：平台，流程和人；其中流程是搭建平台的基础，在开始搭建devops平台之前要先梳理清楚各部门项目/迭代研发的端到端流程，抽取流程中共性的东西，使之标准化，在基于标准化的流程上，构建适合公司流程规范的devops平台。

流程落地：

流程落地遵循2个原则：

1、自动化一切能自动化的流程

2、减少不必要的中间环节，特别是需要人为沟通的环节

下面我给大家举两个例子，分别说明：

自动化一切能自动化的流程，比如申请测试环境的流程， 流程中有以下几个节点：

1、申请主机资源

2、环境初始化：操作系统，数据库，中间件搭建

3、域名申请

4、安全扫描

如果这几个节点都是通过人工去推进的，那么当研发团队很小，假设处理这几个节点的同学没有并发任务的情况下，效率还算可以，但是一旦团队足够大，测试环境的申请并发量大于1的时候，必然会造成资源的等待，导致测试周期的拉长，而这些等待最终都会体现在团队的交付效率上。

如果这几个节点是通过自动化的方式流转的，当流程发起并流转到节点1的时候，系统根据一定的规则（比如剩余空闲的机器是否足够）去判断，自动的返回申请状态，然后把流程推送到节点2，节点2根据预定义好的脚本自动的去执行环节初始化，完成后自动的将节点推送到节点3，依次类推直到整个流程关闭，整个流程将大大减少人为沟通所造成的节点等待，最终提高整个团队的交付效率

 

减少非必要的中间环节，比如我上家公司处理客户反馈的线上故障的流程：

1、客服先受理

2、协调组成员复核问题

3、技术经理复核问题

4、开发修复问题

5、测试验证后上线

在这个流程里，第2步和第3步只是为了解决这个故障转给谁处理的问题，真正起作用的就是第4步和第5步，如果我们把每个产品对应的联系人做成一个表格，告诉给客服人员，让客服人员生成故障单后直接流转给对应的开发负责人，就可以减少这个故障单的流转节点，提高线上问题处理的效率

一个公司的流程梳理和标准化要远比我上面举的例子复杂的多，这需要devops的推进者充分的熟悉各部门各产品的流程特性，另外在梳理流程的时候，要把梳理重点放在研发流程中最痛的地方，因为这些最痛的地方，改进之后的效果最明显，也最容易得人心，当研发同学感受到devops流程是在帮助他们提升效率的时候，再推进其他流程梳理的时候

平台落地：

所谓平台就是一个能贯穿软件需求——编码——测试——交付——运维全生命周期的一个软件系统，在这个平台上要能实现需求，代码，测试，交付的自动化管理，还要能实现度量数据的自动化收集，为团队的持续改进提供准确的数据支撑，目前市面上比较有影响力的devops平台如阿里的云效，华为的devCloud，腾讯的织云，这些平台的能力大致可分为如下几块：

1.项目管理能力：包括需求，任务，用例，缺陷的管理能力，对应的项目管理的开源工具有：jira

2.代码管理的能力：代码提交，分支合并等能力，对应的开源工具有：git

3.持续构建&持续交付的能力：包括环境管理，自动化构建，自动化部署，自动化测试等能力，对应的开源工具有k8s, jenkins,junit

4.数据度量的能力：

5.制品管理的能力：主要是对制品进行版本化，分层化的管理，开源的工具有：nexus

在平台选择上，建议根据团队的实际情况优先考虑自研的产品，因为自研的产品流程是最贴切本公司实际情况的，其次考虑具备端到端管理能力的产品，因为只有端到端能力的平台，在数据度量上面才会更全面，更能够为团队的持续改进提供准确的数据支撑。

人：

关于人这块，主要是指人的观念改变，不要只关注自己所负责的一亩三分地，不是说一个团队搭建了一个统一的研发管理平台，这个团队就实现了devops，要站在整个交付链的效率和质量的角度去考虑问题，才是团队能否实现devops，能否持续改进的灵魂所在。

在传统的瀑布模式中，测试同学就是负责测试，开发同学就是负责写代码，修改缺陷，运维同学就是管环境，管线上发布，有明确的职责边界，但在devops流程中，为了追求更高的交付效率和更好的交付质量，我们提倡打破这些职责边界，通过协作的方式，来实现质量内建，测试提前，自助交付。

如何更好的实施质量内建和测试提前呢？在这个环节里，开发同学的作用尤其重要，让测试同学为开发赋能，测试同学给开发同学提供测试场景，测试数据，测试工具，让开发同学在代码完成之后就可以立即开展质量验证的工作，而测试同学可以聚焦于复杂场景的验证，减少代码交付，缺陷沟通过程中的资源浪费，既缩短了交付周期，也提高了交付质量，还有助于开发同学养成良好的测试驱动开发的习惯。

如何实现自助交付呢？传统的交付流程中，研发同学完成了产品的研发后，把对应的制品交接给运维同学，运维同学执行发布的过程，在这个过程中存在交接的动作，而且发布的过程中如果发生了问题，运维同学也需要反向的找研发同学确认问题，增加了沟通的成本，如果发布的应用的比较多，运维同学的生产力也会成为瓶颈，如果让研发同学直接执行发布的动作，运维同学给研发同学赋能：比如提供自动发布的工具，提供主机日志信息，流量信息自助监控的工具等一系列发布过程中需要的信息都能工具化，这样就能提高发布的效率