|
2009 年毕业于郑州大学软件学院，先后主导多家 IT 企业分层自动化测试框架的落地实践，积累了大量自动化实战经验。2014 年入职七牛，从零开始构建七牛质量保证体系，推进与完善了研发体系持续交付和持续集成。先后负责存储，数据处理，直播等产品的质量把控，构建了第一支使用 Go 语言为自动化框架基础支撑的质量保证团队，现任七牛工程效率部负责人。近一年多来主导效率提升工具落地和质量平台化建设，同时也对持续集成和持续交付有着独到的见解。 分享的结构首先会从七牛目前的场景及痛点展开叙述我们 Spock“出现”的原因，然后会介绍 Spock 的业务及技术架构细节，最后从实践出发，着重介绍在使用这个平台的过程中我们在做迭代时所引发的一些思考，以及从根本上解决了哪些问题。 场景 . 痛点 七牛从创立至今已经有七年时间，目前有六条核心产品线， 500+ 的组件和微服务，以及一些内部的平台和项目，所以无论是从产品还是代码层面上看，体量都算比较大的，因此我们编译和运行环境相对而言也是比较复杂的。七牛的业务直观上很难去讲，但是大家一定都知道七牛的一些用户的产品，比如美拍、陌陌、脉脉以及熊猫，我们提供的是 PaaS 云服务，直接面向企业级用户开发产品的底层环节，这样就定义了七牛必须是以技术为导向为用户提供服务。接下来会介绍一下我们的语言和技术版本。 七牛使用的是 GO 语言开发，从 1.1 版本就开始使用延续到目前的 1.9 版本。因为版本遗留的历史问题很多，需要维护的包管理工具也很多，发布频率要求也就自然很高，测试管理流程规范就变得非常重要。为了解决这些问题就会产生一系列的工具链，比如针对代码库管理的 GitHub 和 GitLab ； CI / CD 工具 Jenkins 和 Travis ；自动化测试框架 qtest 和 qappium ；以及流程管理/协作工具 Jira 和 Confluence。 因此在多代码存在、多平台交互、多服务组件之间互相依赖的情况下，要保证高质量的交付及产出效率，最关键的环节就是如何保证快速验证满足客户的场景，并且精准的达到可上线的状态，亦或是证明你的功能能够上线，这些都是在测试及生产环节需要着重考虑的问题。 Spock 的业务架构 下面会详细介绍我们根据以上场景痛点采用的解决方案，也就是我们目前自己在用的一个保证持续交付平台 Spock。 图 1 图 1 所示是 Spock 的 Pipeline（业务架构）分别从开发、测试、发布这三个维度对流程进行划分，当然发布人员大部分是开发人员（运维角度的开发人员/ SRE），下面着重介绍这三点。 自测 图 2 图 2 是整个环节互动迭代的过程，其主要会提供给开发人员一种自助型的自测环境，让开发人员可以快速去验证代码。这个过程是存在于整个软件开发过程当中并不断的重复这个过程。图 2 左边诸如“流程管理”是项目经理和产品经理着重会关注的地方；“自动化测试”会是 QA 人员比较关注的地方；“部署和环境”是大家都会着重去关注的；“ Spock”会贯穿一些相关环节；而对于开发人员来说则需要关心最顶层的“代码管理”。 图 2 的流程就是由开发人员先提交 PR，紧接着就会有 hook 触发 Spock Build，同时会触发单元测试服务（ UT）和静态代码扫描服务，单元测试对于代码的审核我们针对不同产品会有不同的策略制定，单元测试之后的环节并非是必要的（我们会对提交的每一个 PR 都进行标识处理，这个过程会由我们定制的 Pipeline 进行提供，因此在单元测试之后，会根据 PR 在单元测试之后的操作过程，一般我们都会让其进行 Deploy 以达到快速交付可验证状态）；自测环境在 Docker 以及底层稳定情况下一般都会保持稳定状态，一旦出问题则会给出相应的 test report，这边通常是会通过通知系统告知 dev 同学进行 check。 这一系列过程在“流程管理”当中都属于开发中，并且从分配需求到开发的整个过程目前都已经实现了自动化的操作。代码“ Test”通过之后就会提交到“评审中”流程当中，此时项目经理或产品经理在流程管理中就可以看到到达评审阶段的 PR 或 issue 分别有哪些，评审阶段的 PR 会被，人工的进行一些操作，保证其 UT、 Pipeline 集成测试均是通过的，之后就有 code review 人员人工进行 code review，整个阶段工作完成之后如果代码依旧没有问题，则会进入人工合并阶段，合并之后，会自动触发流程管理中的“测试中”状态。然而，整个流程我们所花费的时间仅为 2-10 分钟左右，至于为什么速度可以这么快，在之后我会再进行介绍。 集成 图 3 图 3 是集成的 Pipeline，和“自测”的流程图差异不大。集成方面主要关注 QA， QA 人员会将许多不同的 issue 集成为一个测试。与开发人员相比，不同的地方就是开发人员测得是一个 PR，而 QA 人员测得则是很多开发人员的 PR。一个 PR 不可能只进行一次测试，也不可能只将一个 PR 合并到 master 中，测试过程是一个不断迭代的过程，因为我们上线比较谨慎，所以集成 PR 的频度并不是特别高，通常一周若干次。 发布 图 4 图 4 是发布的流程。上线之前，我们仍然会在 master 分支再触发一遍 Spock Pipeline，此时被集成的 PR 还是会再进行一次单元测试，因为整个过程的效率还是很高的，所以以防万一再做一遍全套测试保证整个环节万无一失。 上面就是对整个 Spock 的业务流程所做的梳理。 Spock 的技术架构 图 5 图 5 是 Spock 的技术架构。其中 Pipelines 是核心，是一个已经上线的流程线，所以围绕这个讲一下整个过程中的技术涉及面。首先是使用了 jira 来对开发需求进行管理，产品经理或者项目经理可以将自己的需求描述在 jira 里面，此时我们会将 jira issue 写进 PR 的抬头当中，方便之后开发人员根据需求进行开发时，我们能清楚每块代码到底是根据哪一个需求开发的。这些内容在 jira 里都会进行留档，它拥有一个 development 模块，在 Spock 平台上也会有一个模块，代码一旦触发以后，我们就会很明确的知道这个代码包含的 issue 需求。之后， PR 会自动触发，并进入任务队列系统，由 MQ 进行接收，接收之后会与 Spock 平台进行交互。 编译 编译环节我们使用的 Reaper，在这里我们对它进行了一些改造，因为是需要与存储系统进行交互，所以我们写了一个插件用来执行构建过程，构建的结果直接存入 Kirk（容器平台）的 Registry 中同时会 archive 一份到七牛云存储，紧接着会进行下一步的部署工作。 部署 部署则采用了七牛的容器平台（ kirk）和大数据平台（ Pandora）。使用 Kirk 是为了解决多个服务构成服务组这样的行为产生。现在很多服务之间很难实现严格意义的解耦，这也是大家遇到的常态，那么就引申出了服务组的概念以提供灵活度，将相关服务作为一个服务组，一起构成一个“整体”，这样一来他们的升级和使用就会连在一起，整个业务与其他的不相干业务进行了隔离，但是在服务组内它们彼此之间又能保证相互独立，提升了整体的工作效率。在部署过程中会产生很多日志，我们将所产生的 log 统统都会打入 Pandora（大数据平台）中进行日志分析。过去使用的 Hadoop 是非实时性的，所以那个时候要导出日志会经历一定的周期，而 Pandora 真正做到了实时分析统计 log，我们可以通过这些 log 拿相关接口做一些质量分析。 测试 使用 Pandora 对大数据分析做了支撑，在这之后，便会触发测试环节，测试开发的服务是类似的。为了让整个流程变得简单，测试环节我们会尽量减少依赖，并且对 UT、 ST 以及 IT 的测试结果进行收集，最终将数据流打入质效平台上，当然产生的 log 也会打入 Pandora 中，方便日后对其进行分析。 分发 最后的分发环节，我们则采用了七牛的对象存储（ kodo）对测试结果分析并进行合规之后，由发布人员进行上线，这里可能对接有不同业务属性的上线发布系统/部署工具/直接对接容器平台。 最佳实践与思考 自动化与信息化 在做整个 Spock 的过程中，所需要思考的一个很重要的问题就是自动化。早期合作时，在一些信息一致、环境一致以及互相之间的协作上都出现过一些问题，因此那时我们就在想是不是可以用更好地方式去进行解决，自动化就是一个很不错的选择，当流程明确、结构清晰时，整个过程自然而然的就可以自动化的去执行。因此，不仅需要将测试自动化，整个流程管理（需求管理）甚至包括代码管理这些工作都需要进行自动化。当然，自动化的关键是整个体系必须是完整的并且要保证整个过程的稳定性以及测试用例的覆盖的有效性。前面提及的 Pipeline，在一些产品线已经实现了自动化程度较高，无大功能上线的情况可以无需 QA 人员的参与，由开发人员自行上线项目。当然，自动化是保证快速发布的保障，我们认为在 QA 资源短缺的情况下，自动化的存在更有意义。 自测环境与 Docker 下面说说单测与集测；其实往往自测采用集成环境更容易发现问题，并不是说 UT 不管用，在微服务的环境下，集测往往比单测更具有意义。因为即使微服务已经让我们足够清晰，但业务逻辑上仍然会存在一些问题，所以应该尽早的上集成环境进行测试，这在以前物理机的环境下技术实现上难度可能会比较高，但是 Docker 的出现降低了实现的技术门槛。容器化的部署，为每个人都提供一套独立的测试环境，一键起环境，开箱即用。 微服务化与挑战 现在大家也都会强调微服务的概念，那么为什么微服务会那么火呢？我认为是因为它将需求化整为零，将分工变得明确起来；那么在微服务当中着重需要进行注意的除了清晰可以表述给人家的接口之外，微服务之间的相互隔离，独立部署，问题出现时的运维排查都变得至关重要，因为可以将代码和服务化零为整，所以在持续集成和发布环节中，微服务也发挥着至关重要的作用。 图 6 七牛的愿景是缩短产品到想法的距离，但事实上，从知道你自己想要什么，到设计师设计出来的东西是否符合你的想法，再到需求设计，代码设计以及最终上线，这都是一个很漫长的过程。每一个过程都可以看成是一个“微服务”，将最终的目标进行不断的拆分，是一个化整为零的过程，化到零之后再集成，我更倾向于将这个集成看做是 DevOps 亦或是 CI / CD，而整个过程中， Pipeline 担任的则是将过程进行重组的功能（图 6） 微服务所面对的挑战就是容器和配置；容器的优势就是可以保证环境的一致性，并且可以进行弹性的伸缩，一个镜像可以在多处进行部署，这无论是对于开发、运维还是 QA 人员来说都是一个很愿意看到的情况，它让相关人员更加接近自己的产品，让环境的搭建变得简单容易，减少了去做不相干事情的时间，专注于自己的本职工作；可是在一切容器化之后怎么让服务在容器当中运行起来，这里面是需要进行研究的，这个就涉及到了配置的问题，我们主要利用模板去简化了配置的复杂度，并且可以通过配置中心管理在不同环境下使用什么东西，一切都趋向自动化，但是一定需要关注的还有安全的问题，不能随意让人进行更改信息，所以在配置平台中提供的一些安全保障即配置中心化管理变得尤为重要。 发布透明化 通过 Spock 平台解决了发布过程的透明化管理，因为在发布时，我们都会自动生成一个发布 issue，一个 issue 会对应一个 PR，通过 issue 中涵盖的信息，可以在 Spock 中看到发布的整个状态，这样一来，发布状态在平台上清晰明了，让运维、开发以及 QA 人员获知状态信息，了解目前项目进度。 质量门 图 7 为了保证更有质量的上线，在不同阶段我们会采取不同质量策略，这就衍生出了“质量门”的概念（图 7）功能分支代码使用单元测试和静态代码分析，合入测试分支后采取集成测试，合入测试后再进行编译、预发布，每一步都会收集一些质量信息，当信息收集失败则不会进入下一步环节，这样就保证了整个流程环节的质量稳定，所以，最佳的做法应该是将质量内建入整个流程当中，而不是单独的拎出来去完成。简单来说，质量门就是质量保障的体系化建设。 质量是持续集成驱动开发的杠杆，如果没有质量的保证，那么整个开发过程的价值就会大打折扣，质量不单单是指追求“快”，“稳”也是很重要的衡量标准。质量的数据可以反馈给开发，在开发环节发挥重要的作用。对于云计算行业来说，质量更加重要，比如在直播时，更要保证质量的稳定，一旦服务出现故障，那么影响的则会是几十万客户的体验，这样的情况是我们很不愿意看见的。因此在云计算行业，更加要注重质量的把控。 最佳实践 图 8 图 8 是我们目前的质效看板，是从 CI / CD JIRA 平台中收集的一些数据，抽取二十多个指标并使用指标建模，是根据现状抽取出的若干需要在此时期提升的指标，并将这些指标作为看板，结合各产品线阶段和质效数据，分析质量的现状，指导质量决策。比如说返工率高要推动自测 , 系统测试通过率低要提高自动化测试用例的稳定性。这些反映的是过程质量，事故和缺陷则直接反映结果质量。 质效看板起到了驱动开发的作用，这样做有两个好处： 1> 清楚了解现状，与之前的情况以及其他产品线进行对比，找到差异，针对相应的地方进行改善。收集的多维度数据，可以供开发、测试、运维、服务质量人员参考，更有针对性的找到关键数据，以及到底是哪一个环节出了关键性的错误，点对点的去分析解决问题； 2> 直接确定关键指标，确定 KPI，直接刺激和推动某个角色的工作。从而推进个人以及团队的产出效率。 而需要真正完成这项工作，数据清洗变得至关重要，前期需要铺垫很长的路， issue 等都需要进行规范，数据入口要一致，这样才能收集有效数据。才能更好的推动之后的工作。 图 9 图 9 是目前比较成熟产品线的质量数据，因为这些数据不便在平台上给大家看，所以用图片的形式给大家描述一下。由图可以看出，产品的单测覆盖率达到了 60% 左右，并且上下会有波动；代码合规量是 80% 左右； Pipeline 通过率高达 85% 左右（ Pipeline 通过率仅仅是 Travis 和 Jenkins 上的，不包含 Spock，但预计结果差不多）；集测覆盖主要使用代码插桩的方式，可以分析目前所做的自动化 case 的覆盖效果如何，目前比较成熟的两条产品线集测覆盖率达到了 35%，这算是一个比较安全的值，因为 QA 人员可以选择性的去做迭代，然而产品还能保证其稳定的质量。所以，集成测试的覆盖度分析是非常有价值的，节省了人员成本。 构建时间达到 2-10 分钟，就是因为使用 GO 的原因，因为 GO 在处理并发问题时功能很强大。发布频度保证每周会有 50 次发布。核心产品的 MTTR（平均故障恢复时间）的数值，是 JIRA 事故分析出来的， MTTR 可以证明一个产品面对故障以及产品研发团队的能力，目前我们成熟产品的 MTTR 达到了 1 个小时，这个时间提升是非常困难的，与现在的机制、现阶段的状态有很大的关系，是需要与开发、运维一起降低的指标。
图 10 列出了近期行业披露的 2017 IT 效能指标给大家参考，可以对应自己团队现状进行比对。从部署频度、变更前置时间、故障恢复时间、变更失败率这几方面进行定义，达到上述的一些标准也就满足了成为一个高效能团队的基本要求。从 IT 效能上来讲，一天部署多次，故障恢复时间少于一小时，变更时间少于一小时，变更失败率控制在 0-15% 之间，是成为高效能团队需要达到的目标。 本文作者李倩，转载请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。 推荐阅读
54 个架构案例 49 位作者 2 年打磨 『高可用架构』第 1 卷 10 月上市 点击 阅读原文 抢先预订 高可用架构 改变互联网的构建方式 长按二维码 关注「高可用架构」公众号 |
|
|
来自： 立月tracy > 《DevOps&QO》
