思考与实践 | 从0到1构建 DevOps

引言

DevOps是开发、运维和质量保证三个团队之间的沟通、协作和集成所采用的流程、方法和体系的一个集合，一个方法论。

在织云对外产品化过程中，我们结合自身的现状,痛点,迈出了"织云 DevOps"能力建设的第一步.这里主要从开发，测试，运维经常协同的阶段：持续集成(CI)，持续运营两个维度来分享我们的经历及对DevOps的思考及实践。

织云DevOps介绍

织云 DevOps, 是织云协同开发,测试,运维,运营的一个平台和能力, 将协同的过程明确化,自助化,自动化, 提升版本的迭代效率与质量。织云 DevOps 生命周期如下:

1 持续集成CI

在当前，持续集成流程如下:

整个过程中，开发,测试,运维的分工又如何呢？

开发:

1. 录入及维护服务,镜像,配置,变量元数据;

2. 编写及提交功能代码

测试:

1. 编写及提交QTA功能用例.

2. 跟进每日构建日报中出现的问题

运维:

1. 负责 DevOps 平台以及公共能力建设

PM:

1. 关注每日构建日报中版本的成功率,质量.

2. 推动问题的修复,版本的迭代推进。

剩下的事件交由织云 DevOps 平台实现.

下面逐个介绍下织云 DevOps 各个要素，使用方法及案例：

服务管理

服务是织云 DevOps 管理中的一个功能特性实体。基于微服务的设计，方便后续灵活的部署及伸缩。定义一个服务, 只须两个步骤:

1. 定义服务的基础信息:

服务名, 描述, 服务git代码仓库,负责人

所用端口:   DevOps 自监控工具,在服务部署时会监控这里定义的端口;

进程列表:   DevOps 自监控工具,在服务部署时会监控这里定义的进程;

以“登录管理”服务为例，如下：

2. 定义服务相应的包,配置,脚本:

• 包路径定义:

主要是指定git代码源路径, 部署后目标路径;日志目录, 编译脚本等.

• 配置定义:

主要包括两方面：

1.指定nginx配置,

2.服务配置模板及生成路径: 织云公共变量是统一管理的.所有特性的配置文件: 根据开发自定义的配置文件模板由 DevOps 部署工具部署时生成到指定的目录.

• 脚本定义:

定义服务生命周期管理中所需要的初始化、启动、校验监控、停止、备份、数据清理等脚本。各个特性服务可根据自身特性需要，实现自己的脚本。织云 DevOps 工具，会通过这些脚本来实现服务生命周期管理。以“登录管理”服务为例，如下：

3. 服务列表（服务市场）

当前织云服务中，分为公共服务和功能特性服务，共93个服务。服务间共享：A同学加入新的公共服务，也可以给B同学使用。当前的公共服务（基础组件）部分如下：

镜像管理

docker镜像是服务的载体。基于微服务的设计，织云既可以快速将所有的服务合在一个镜像中，变成服务全家桶；也可以很灵活的把服务编排成各个特性的镜像。实现按需组装，满足各种部署需要。

1. 定义镜像基本信息

• 指定版本及类别

2. 编排镜像服务

镜像需要的服务及服务的启动顺序，由开发者自定义。以“前端&平台”镜像为例，如下：

3. 定义镜像公共host

定义镜像中所需求的公共host。

4. 镜像自动构建入库

• 镜像构建场景：

场景一：在自定义完镜像后，要点击“生成镜像”触发自动构建，且推送到镜像仓库；

场景二： 织云 DevOps 有自动探测功能。探测到镜像所对应服务的git代码变更或服务定义变更，会自动触发生成新镜像。

配置管理

1. 变量管理：

添加变量时，需录入变更名，分类，默认值。

添加变量的操作权限已回归：确保添加的每个变量都是合理的。防止变量杂乱及重复。

2. 客户配置管理

• 配置管理策略：

1.客户配置独立化：对于各个客户，其部署的环境及织云版本不一样，所以其公共配置也是不一样的。所以，为每个客户生成单独的配置实体。

2.多版本管理：一个配置实体中，管理多个版本的配置文件。

• 创建客户配置实体：

指定客户配置名，对应版本号后，填写具体公共变量值（分为前端+后台两类变量）。

• 查看客户配备列表：

• 管理客户配置版本

若客户配置已创建，可新建配置版本。生成新版本配置后，可以：

1. 下载配置

2. 下发到目标机

3. 切换配置状态：标记配置是未发布，已发布。

3. 自动构建引入Jenkins

为了提升构建的效率及容灾能力，织云自动构建引入了 Jenkins。通过 Jenkins 集群实现自动调度容灾和并行构建。总体流程如下：

1.织云构建的编排脚本由“织云交付管理系统”生成，通过 JenkinsHandler 将任务提交到 Jenkins 集群。

2.Jenkins master 接收任务，将任务分发到相应的 node worker;

3.Jenkins node worker 按构建编排脚本逻辑，执行相应的构建操作。打印日志，且将镜像推送到仓库。

自动部署

织云自动部署，在我们内部有两套集成环境：

1.正点部署环境：

此环境主要是为了方便开发同学及时验证提交的修改（集成性修改、功能性修改）。因为正式的集成测试环境是每日凌晨构建。每日只运行一次。

规则&流程：

 1）5分钟探测变更，自动构建变更镜像，且入库。

 2）每小时正点自动部署生成最新开发环境。

 3）开发同学，不会关心部署操作；只须在预定时间进行变更验证即可。

2.每日构建环境：

此环境是织云正式的构建，集成，部署，测试环境。每日凌晨触发。同时，生成相应的质量日报发送到织云所有同学。

质量管理

织云持续集成的质量管理主要是通过“每日CI日报”来跟踪：

1.每天运维，测试，PM都会关注“每日CI日报”。

2.测试跟进及记录当天问题，推动相应开发修复。

3.我们的原则：

 1）争取每日构建QTA成功率100%通过。

 2）当天发现的问题，当日修复。重新部署与测试，确保当天最新镜像final成功率100%。

以下是每日CI日报主要的质量度量纬度：测试成功率，接口耗时，测试覆盖率。

1. 成功率视图：

当天QTA通过率：

CI成功率趋势图(2018年5月份)：

第一个图为凌晨构建成功率。

第二个图，为每天最新成功率图。

至于失败的原因，有很多方面（来自各个特性开发，测试，CI平台）。因为集成失败的原因很多，一个很微小的调整都会导致整个集成失败。

织云 DevOps 平台每日集成、修复、规范、输出一个可用镜像，为织云的版本效率和质量保驾护航。

2. 性能视图：

织云接口性能标准：接口耗时不多于500ms. 每日CI日报中会列出接口耗时大于500ms未达标的接口及开发负责人，接口调用次数，耗时等。可查看明细日志。

案例：

织云每日构建能力刚上线时，当时发现自动化服务，共有39个接口有调用记录。其中29个接口（66.7%）不达标（接口耗时超过500ms）。经开发性能后，慢接口大幅减少。

3. 接口用例覆盖率：

当前织云的用例，主要是优先保障核心业务的核心用例。当前占比为35%+。

接口覆盖率＝QTA用例要调用接口/总接口

2

持续运营

工具化

我们将常用的运维操作工具化，大大降低了开发或新运维同学排查/修复问题的门槛。操作很方便。

当前，只要进入织云的镜像，输入zy标记，tab自动列表，会列出所有可用功能。其常用的工具有：

zybackuptool：mysql备份工具

zydbutil      ：DB初始化与升级工具

zyenvtool    ：环境及配置管理工具

zyselfmonitor ：自监控管理工具

zyservicectl   ：服务管理工具（启停等各种操作）

zysetdomain  ：域名管理工具

zyupgrade：补丁升级管理工具

每个工具，输入命令后，会自动显示使用方法及说明。

自监控

织云对自身的服务也建立起自监控。

自监控类型

１.基础环境监控：CPU 负载，内存可用率，硬盘可用率，docker可用空间等。

２.进程与端口监控：自监控会巡检在织云 DevOps 平台定义服务时指定的进程与端口；

３.个性化巡检：自监控会巡检在服务定义时，开发自定义的校验脚本。

４.日志异常监控：监控服务日志，若出现指定的异常标记，则告警。

自监控策略

• 监控频率：5分钟巡检一次
• 告警通道：邮件告警/腾讯云Barad监控中心  
• 收敛策略：一小时/次

自监控展现

• 告警邮件展现

案例：

织云升级给上汽客户后，出现自监控－硬盘告警。

对客户影响度：

无影响：运维同学第一时间上去清理日志。避免硬盘无可用空间导致织云服务不可用。

原因：

２，自动化的日志目录被变更。但没有同步变更clear_dist中的清理路径。导致实际日志不会被clear_dist组件清理。

• 织云控制台

运维同学，也可以实时在织云控制台查看当前织云的实际运营状况。

快速定位问题

织云调用树的分析能力也于日前上线。利用API平台调用树，实现web可视化调用链路分析。

1. 我们的痛点

产品交付给客户后, 若出现问题, 常常需要开发介入; 这个过程中大家的痛点是:

• 开发频率被打断
• 售后问题定位慢

  1)若上层服务与底层问题服务相隔N层,则需求先后圈入N个特性开发. (各处特性开发互不了解).

  2)上机子看日志难: 环境多, 登子机须各种权限申请或配置.

2. 织云API调用树

API平台根据接口调用日志生成请求的调用树.一目了然的看到:

  1.请求的调用链路;

  2.每一层调用现场：服务调用方,服务提供方,接口返回码,耗时, 入参,出参, 异常日志(若有异常)

利用 API 平台的调用树能力，我们可以：

• 快速了解服务的调用关系，发现不合理调用；
• 帮助售后快速定位问题；减少开发介入频率；
• 现场复原：不须再重现；避免重现不了问题的定位
• web可视化分析：减少上机子查日志的次数。提升定位效率。 

案例一: 发现不合理调用

(1)问题现场： devtest环境,执行工具市场工具异常.

(2)获取requestId, 输入查询

(3)重现调用树+问题现场

(4)发现原因/问题

结论一(问题原因)：命令通道接口-判断设备连通性：发现设备不可通。

结论二：通过调用链，发现工具市场存在重复调用cmdb接口问题。 工具市场下个迭代修复。

案例二: cmdb异常

(1)问题现场：执行工具市场时，只提示cmdb异常。但不知道原因。

(2)查看API平台调用树：不需求上机子查日志啦。

可见原因是DB连接异常。

用户画像分析

我们通过piwik和对织云核心服务的定时分析，梳理出用户的使用习惯。

小结

织云 DevOps 能力，伴随着织云，迈出了从０到１的第一步，解决了开发，测试，运维，运营上一些较主要的痛点。在一些特定场景下，我们还有很多细节需要进一步的打磨与完善，助力织云腾飞，和企业一起面对运维新时代。（腾讯 DevOps 全链路解决方案也早前在 DevOps国际峰会上和大家见面。）

备注：文章所用 Qta 已有开源包。现在可以用 Qta 的开源包来编写、执行 Qta，获取 Qta 结果。