持续交付实战

## 背景

1. 本文是最近工作的总结和分享，希望对各位技术体系的成长有些参考。

2. 公司间竞争体现在产品、技术、效率、运营等多个维度，业务发展要求技术 leader 从团队、技术、流程、标准等多管齐下保证自己负责的维度不成为公司瓶颈（或保持进攻态势）。

3. 测试 leader 的底线思维：测试只能保证产品的质量下限，也就是我们精心设计的涵盖大多数已知用户场景的 user story path 可以通过。真正的质量上限需要全团队努力，同时质量下限要“又快又稳”，每轮迭代都可以让团队沉淀下一种能力。这就是这套系统的价值

4. 万事万物同理，公司或团队的发展也可以理解成三个阶段：温饱、脱贫、致富。各个阶段都有相应的建设套路，并不是一步到位就合适，温饱阶段随便几个码农就把事干了，为难的是脱贫到致富的升级阶段，需要一系列技术手段以保证研发效率的提升以适应高速迭代的业务，同时各路大神也有多种忽悠的套路。需要 leader 为团队量身定做一套合适的升级方案并执行到位。“架构师的价值=他踩过的坑”

5. 研发效率的核心就是交付效率（其次是质量和人效），交付过程中一个可以量化的指标就是发版频率（或叫需求吞吐效率），测试就是要保证又快又稳。

6. 整个体系的建立基于以下核心理念：

* 工程师精神：“如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。”（by 陈皓）

* 以解决痛点拿结果为荣、以大而全自 high 为耻。做服务的心态，保姆式的服务，利用自己的经验帮助业务团队找到痛点并解决问题，而不是把自己的经验和背景强加于人；不是指手画脚，而是撸起袖子一起干。

* 渐进式推广：饱和攻击打标杆 -> 多方借力 -> 单点突破 -> 全面推进。借力技术委员会和安全部门等，形成事实上的标准；卡住关键环节（如构建）；每轮迭代让团队沉淀一种能力。

* 铺路：优化 -> 整合 -> 内外赋能 。不要闭门造车，一个人或团队包打天下是低投入产出比的，高级别的贡献体现在做生态而不是仅仅做产品。

* 查漏补缺、持续学习。

* 最关键的：简洁就是美，尤其顶层架构要足够简洁。（时刻提醒自己）

7. 工程效率平台的价值

1. 反向思维，如果没有自建只能东拼西凑一些开源工具，缺点是无法“拥抱变化”和“传承”。

首先，不管是互联网的轻公司还是重公司，业务方向、业务流程、数据流、部门组织结构都会随需而变，甚至是剧烈变化，无法修改和传承的 IT 系统等同于死物，让人求生不能求死不得，要么沦为信息孤岛，要么被人快速遗弃。

其次，买了一套或几套现成的、通用的、割裂的 IT 系统，知其然不知其所以然，自己的队伍既没有得到锻炼，也没有可以一代一代传承下去的经验教训、设计理念和技术架构。铁打的营盘流水的兵，如果连营盘都是水货，那后面人还玩什么啊。

2. 技术型 leader 的价值还体现在理解开源等业界工具的本质，并能够适时适度的使用，举例：Jenkins 是小团队神器，但从无大规模使用，本质原因就是 master 的负载均衡和动态扩容等稳定性问题无法解决（团队要是已经强到能改源码做扩展，何必不自己写一个完全可控的）

3. “持续交付中台”问题本质在于如果没有中台（或者其他强有力的理由）推动并做到了所有业务标准化、流程化、电子化、数据化，那么全业务生命周期的支撑随时随地调度和决策的数据报表是不可能的，至少是滞后的或者可有可无的。中台只是一个“统一共识”而已，各个业务单元与支撑单元一起构建业务命运共同体，目的是业务数据化和数据业务化。

4. devops“八荣八耻”

以随时可扩容、可缩容、可重启、可切换机房流量为荣，以不能迁移为耻（三种猩猩）。

以可配置为荣，以硬编码为耻。

以系统互备为荣，以系统单点为耻。

以交付时有监控报警为荣，以交付裸奔系统为耻。

以无状态为荣，以有状态为耻。

以标准化为荣，以特殊化为耻。

以自动化工具为荣，以人肉操作为耻。

以无人值守为荣，以人工介入为耻。

## 概述

下面分别说下影响发版效率的几个核心问题，以及我们的解决方案。

1. 统一信息中心：需求池和需求生命周期的管理

2. 统一研发能力库

3. 高效的质量保证体系

4. 高度自动化的运维中心

5. 其他

## 统一信息中心：需求池和需求生命周期的管理

需求是整个研发的源头，大家都知道要控制，但实际操作中需求方一向很强势（比如直接来自老板、事故等，你懂的！）而且技术是成本部门，本身就是为业务需求服务的；同时，打造一支高需求吞吐量的团队也是技术 leader 的价值所在，所以不要抱怨，动起来，解决问题吧。

1. 务必形成迭代和交付节奏，让研发、产品和需求方形成心理预期。同时以需求池的方式对所有需求进行统一的管理：新建 -> 评审定级/转交/拆分 -> 转流水线。

2. 保证需求评审和周知到位，磨刀不误砍柴工。具体可以多级评审体系：成立产品委员会和技术委员会做 high level 评审；开发和测试架构师做实施方案评审；开发测试业务 owner 做具体细节评审。

3. 严肃需求变更：正常的敏捷流程大家都会，而且流程是双刃剑，流程越多越说明管理的低效（管理的最高艺术是没有管理，大家可以无脑操作，donot make me think），所以把有限的精力 focus 在最高风险的地方。严格执行审批和周知（这涉及一个心理学因素，一件事情不可避免，就人为增加流程成本以降低发生概率）

4. 需求生命周期流水线 dashboard，让研发团队的交付透明化（透明化是降低团队沟通成本的必要手段）和数据化（数据化是一切度量和优化的前提）。如下图，可以清晰知道每个需求开发测试、灰度的状态，以及线上运营数据反馈，甚至实时数据大盘。


## 统一研发能力库

随着业务和团队的扩张，要从业务团队中抽取可复用的能力和组件，对内对外提供“积木赋能”，提供基础能力的保姆式的服务，让开发更专注于写业务代码。

1. 建立通用分层组件库，并以 code sample 或 IDE 插件的方式提供，参考下图（盗图）。


2. 完善基础服务（如 git、maven 库、安全协议、自定义 tcp 等等）


3. 通过 ATC 平台实现对完成评审立项的需求自动建立 git 分支、自动分配开发测试灰度发布机器、自动注册各种服务和监控、自动配置弹性计算和负载均衡平台等一站式保姆服务。

4. “代码只有在正确的环境中才能正确的运行”，这句话有点拗口，但意思就是“配置就是代码，要和代码一样对待”所以统一配置中心、k8s docker 的引入必不可少。devops 的理念也是“everything is code”。太多线上事故的 root course 都是配置混乱。

5. 同时这也是“大中台小前台”的企业 IT 架构的基础。


## 高效的质量保证体系

交付要求“又快又稳”，不止要做好发布前和发布中测试，还要做好发布后的数据监控报警和线上巡检。同时互联网时代要“小步快跑”，所以多级灰度发布、数据反馈、问题定位系统也必不可少。

1. 横向全面测试必不可少，该干的不能偷懒，如图，查漏补缺。当然，根据公司业务技术特点识别出质量高风险点是衡量测试 leader 的重要标准，因为资源总是有限的。


2. 纵向的 CI 流水线能够极大提高交付效率，建立 BVT 和 release gate 的机制以降低人为参与和提高自动化率（从实践看，自动化率低才是流水线失败的最大原因）


3. 测试 leader 都有过半夜 2 点被老板拎起来的经历，因为测试是兜底的，不管啥问题，大家第一反应都是测试的锅，但实际上具体原因到 debug 才能知道，所以 ATC 平台提供用户排查体系和智能告警系统（因为内部图还要脱敏处理，比较麻烦，所以多处盗图，说明个大概的理念，感谢原作者）；同时建议成立由开发测试运维运营等统一组成的“稳定性小组”并设立值班长制度，“团结一切可以团结的力量，结成快速响应联盟”；其次，内测群、摇一摇上 bug 之类的内灰机制也要搞起来。比较狗血的收集老板们用的手机型号以防止兼容性问题也是要考虑的（老板报的 bug，你不复现，那不忧伤了！）


4. 整个研发是成本部门，测试更是重灾区，人效更是 leader 永远的痛，所以必须要把整个测试行为数据化，数据化才是一切度量和优化的前提，ATC 平台从如下维度进行数据化。同时通过 data insgiht 和 engage 的分析找出流程痛点。

* Bug 是 report 的一部分，

* report 是测试的最根本产出（测试的意义在于确保产品达到发布标准而不是发现所有 bug）。

* Plan 分解成 task（matrix 是艺术、是资源协调能力和思维缜密性的最佳体现，也是高级经理的唯一考核标准）。

* Task：可追述的执行历史记录、个人 performance 的体现、kpi 的度量、团队能力的积累和传承。

* Test case 是一切的基础（树形、一句话：你说不明白是你的分析表达能力、业务理解深度不到位，他看不懂是他有这些问题）。



5. 统一自动化测试平台：自动化程度决定交付流水线的效率，所以要开发一套高效的框架。这个东西简单的说照着网上的 demo，5 分钟就能把 appium、selenium、接口测试跑通，但大规模应用就是一个大坑，所以 ATC 平台提供最具 ROI 的方案“以接口为龙头的灰盒测试+核心场景 UI 自动化”，这个说来话长，先画个业务架构图放这里，下回分解。



6. 线上全链路压力测试

7. 云兼容性测试平台

我们开发的是一站式应用全生命周期解决方案：提供从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑，以上简单的说了下需求、开发、测试阶段，后面下回分解。欢迎大家交流，这会是一个系列文章（但愿我能坚持），也算是对以前工作的总结。

## 高度自动化的运维中心

陈皓同学在《从 Gitlab 误删除数据库想到的》中说道：一个公司的运维能力的强弱和你上线上环境敲命令是有关的，你越是喜欢上线敲命令，你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。而我希望的是：环境维护，应用部署，只是勾勾点点，没有心理负担，dont make me think。一个代码分支，对应的一个包（或镜像，对应于 Docker 的 Image），可以流经开发联调环境、测试环境，直接上预发环境，上生产环境，上云端，一路穿行没有障碍，全程无需手工干预，无需手工改配置文件重新打包。

这么思考问题的原因也很简单，我们笃信工程师文化，靠技术而不是管理解决问题，正如陈皓同学所言：如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题。相信管理，那就只会由制度、流程和价值观来解决问题。

1. 全链路灰度发布平台

2. 线上质量监控平台

### PS：如何构建一个公司内部的持续交付平台

1. ROI 第一：降低用户接入成本和平台运维客服成本，真正解决研发团队的痛点。

2. 铺路，正向循环：收集公司内部散落的各种能力，制定标准、并以 api 的形式标准化对内对外“赋能”

3. 多方借力：借助安全、技术委员会等第三方组织进行推广。（他们想要管控但无实际产品，而你们的产品要推广，一拍即合的事）；从上到下达成共识

4. 稳定性小组法则：遇事不乱，分头核查，群里同步，简单陈述，绝不恋战，恢复服务。

分头核查：QA 负责线下复现现象，确认问题是否存在；SA 负责核查业务对应的机房、数据库、内外网流量、应用负载有无变更操作、有何异常指标。

绝不恋战：如果迟迟定位不了问题（比如五分钟之内），就不可恋战，必须快速恢复业务。第一，不要把生产环境当成测试环境，不要在线调试；第二，不要一直留着现场观察来观察去。

简单陈述：出了事儿一定各方面都动员起来了，七嘴八舌，各说各话，这时候一定要有一个临时总指挥不断地总结大家现在的进度，做精炼的“简单陈述”，发在群里，相当于一个新闻发言人。他在第一时间出来做简要综述，把 WHEN/WHO/WHAT/HOW/RESULT 几句话说清楚，同步给核心干部。不要点对点。请务必广播。表明我们在跟，我们在解决，所有事情都在掌握中，别怕，别慌。