下面看如何解决带着问题上线这一问题 。

文章图片

我们的质量文件叫Cable ， 它会消费各种自动检查手段、自动化工具执行的一些结果 ， 把他们推送的一些消息推送到 IC中 ， 然后我们的质量文件在消费这些消息的同时提供接口给Qodin、发布系统进行拦截跟结果展示 。
自动化工具我刚才介绍了4种 ， 我们内部还会有一些项目流程、慢查询等自动化工具 。 这些工具并不全部都是我们来提供的 ， 有很多是业务线来提供的 。 这是因为我们在实现Cable的时候 ， 采用了一个通用的方式 ， 即定义了一个通用的接入标准——业务线各种检查手段 ， 你只要把你的结果推送IC消息即可 ， 这样的话如果你某个业务线有自己的一些检查工具 ， 你只要按照这个标准去推送消息 ， 我就可以快速地接入 ， 在你的业务线去落地 ， 这样能极大的发挥整个业务对自己质量负责的积极性 ， 同时也会更有利于我们整个公司的质量保证 。
3）效果

文章图片

① 环境效果
这个是基于之前环境不隔离即完全资源独立的情况下做的方案 ， 可以看到我们有应用83个 ， 数据库23个 ， 中间件7个 ， 我们能保证10分钟之内交付 ， 每一次变更都会有一些变更记录 。 这是基于资源完全隔离的情况 ， 基于上述新方案 ， 我们应用精简后 ， 环境交通速度就更快了 。
② 质量门禁效果
这是质量门禁现在的状况 。

文章图片

我们上述说到 ， 业务线也可以提供各种各样的检查手段 。 我们现在有丰富的检查手段 ， 业务线根据自己的配置去选择需要的一些手段 。 这是我们组织维度暂时的质量情况 ， 最终我们做的各发布系统集成的发布拦截 。
总结这一部分的话就是质量 ， 我们通过多种手段加发布门禁 ， 确保了我们的质量 。 有了流程 ， 保证了质量 ， 我们现在要去发布上线了 。
【去哪儿网核心领域DevOps落地实践】3、应用画像助力发布运维
1）背景

文章图片

理想是测试完了 ， 直接一键点击发布按钮上线 。 但是现实往往不是如此 。
QA人员发布时 ， 先要去OPS那边申请机器 ， 再去配置发布步骤 ， 即发布的一些相关的信息 ， 配置非常复杂 ， 前期需要许多准备工作 。
对于开发人员来说 ， 开始运维 ， 如果线上出现了一个问题 ， 要先找到它这个机器的资源 ， 然后再去找应用 ， 找代码 ， 这是非常割裂的 。
还有一个问题 ， 一旦遇到问题的网络 ， 还要去各个地方找这些信息 ， 定位也十分困难 。
所以总结起来是什么问题？
我们会各种工具平台 ， 虽然大家现在强调一站式的 ， 但是在背后的话 ， 各种资源服务还是不同的Team提供 。 因为不同的Team提供的时候只关注自己管理的领域 ， 所以它的管理维度是不一样的 ， 这样就会导致管理维度不一样 ， 这些数据信息无法串联起来 。
2）方案
① 应用画像
基于这个问题 ， 我们可以思考一下 ， 我们真正发布运维的到底是什么东西 ， 它最小单元是什么？我们确定了我们最小的管理单元 ， 其实就是我们的应用 ， 那么我们应用有哪些属性呢？我们就猜出了我们的应用画像 ， 包括基本属性、环境属性、发布参数和依赖信息 。