周六参加的一个 devops 沙龙，看的不仅是测试，更是整个团队。听完后感觉还是有不少收获的，在此记录一下，也是作为自己的成长记录。

官网：http://DevOpsDays.org
中国：http://ChinaDevOpsDays.org

银行项目落地 DevOps 的难点及攻克之道

讲师：汇丰基金服务软件负责人 刘华 著有：《猎豹行动：硝烟中的敏捷转型之旅》

银行项目特点：非 MVP ，偏向大而全

业务需要计划与承诺

时间、预算、范围、外部依赖

传统内部开发团队：先做几个迭代，测速再估算
银行难点：外部依赖多，非内部团队
工具：MS Project（工作分解结构）

业务组织架构复杂，难以找不到 Product Owner，依赖供应商

敏捷交付模式：
通过限制在制品，确保聚焦最高优先级的交付

• 需求排序 + 供应商交付计划会
• 需求存 jira
• 供应商、业务每日例会 (进行决策)

优先级排序：IT 上线标准>合规要求>公司内控要求>业务定制化需求

敏捷原则：
去中心化、协作、透明...

敏捷教练需要在战壕里

需求不清晰、复杂且难以理解

业务人员如果给不出具体验收条件，需求就是不完整的，进入不了开发阶段。

验收条件目标：可测试、任何人均可操作。

举例：开四停四、新个税办法说明。核心点：举个具体的例子

总结

• 项目计划方法
• 敏捷交付
• 实例化需求

问答

问：瀑布流团队，如何快速反馈
答：各个节点切换（如提测、发布前）时，均需要和需求方进行反馈沟通，确认理解一致

敏捷测试项目实践案例分享

埃森哲卓越测试中心负责人 17 年从业经验 陈晓鹏

项目背景

赌场项目 博彩管理系统

挑战：

• 用新 it 技术转型
• 进度紧，质量要求高
• 从瀑布转到敏捷

组织架构图：

5 个 scrum team，每个 team 2 个 BA，5 个开发，1 个功能测试。2 个测试开发（5 个 team 共用）

系统架构图：

BDD 简介

given when then

价值：

减少浪费——业务导向
变更安全——自动化验收减少变更风险
发布更快——自动化验收提高效率
需求明确——避免理解不一

对测试带来的困难：

技术风险——对新技术经验不足
进度风险——测试时间少
质量风险——涉及会员账户，对质量要求高
管理风险——Scrum+BDD，测试人员玩法和瀑布流差异大，需要探索

解决思路：

1. 自动化测试——API+UI 分层，最上层探索性。cucumber 做 BDD 框架
2. 持续集成——集合单元测试、配置管理等，把流程串起来，加快交付速度

解决方案：

cucumber 粘合，产生代码框架，节省转换工作
selenium 执行 web UI
cucumber 基础上加关键语句，做 api

架构：

测试流程：

1. sprint 计划会，指定 user story（feature)
2. 开发人员：开发、单测
3. 测试人员：学习、探索性
4. 测试开发：判断自动化可行性，设计脚本，加入用例库
5. 执行用例库已有用例

持续集成流程：

各节点图

整体流程图

一个 sprint 中的自动化测试流程

收益

1. 自动化覆盖率高
2. 减少不良成本（错误导致阻塞，不正确的功能）

问答

问：feature 由业务写，可能吗？
答：BA 和客户沟通后编写，开发、测试、BA 一起 review 确认

问：测试数据怎么管理
答：放到配置管理中，脚本自行创造需要的测试数据和测试后进行消除

问：对于复杂度较高，链条较长的系统，测试稳定性会受到非常多的影响，数据如何管理？
答：建议听后续微服务的分享，做好服务解耦 ：（

问：自动化发现不了 bug ，意义何在？
答：杀虫剂理论（第一次杀得了，后续会免疫），自动化需要不断更新维护

问：自动化测试开发做更强，测试人员价值何在？
答：1. 测试人员也会自动化。2. 关注集成层面、整个系统层面的测试，以更全面的角度查看系统质量

感悟

1. 自动化执行的环境，数据、配置需要有一定的稳定性。是否和普通测试环境共用，需要具体问题具体分析。
2. 流程涉及多系统交互，如何确保流程本身的稳定，需根据具体项目各自优化。

DevOps、容器！微服务架构转型的救赎

PPmoney 容赜

救赎：曾经拥有，失去后找回来

踩坑经历

13-14 年：重复的业务封装在几个服务，SOA 架构，演进较慢
15-16 年：提出口号：打造世界一流的微服务框架，自研 dolphin
16-17 年：反思，spring cloud 全家桶，100+ 服务
17-18 年：救赎，微服务 + 容器化部署

热闹驱动三连击：

框架转型态度

• 单体不好扩展，微服务好扩展
• 可伸缩、松耦合、独立交付
• 推倒重写，全拆成微服务

框架选型态度

• dubbo 太老，spring cloud 太新
• 微服务理论、框架都懂
• 自己造轮子，grpc+etcd+http2

工程效率的严重挑战

开发：架构复杂、服务拆分粒度
测试：复杂接口测试、代码质量、Bug 追踪分析
运维：交付频率、监控复杂

困惑

微服务在 12-15 年均未纳入采用阶段。在使用微服务前，需要在持续交付和基础设施自动化实践方面具备最低程度的成熟度。

持续交付和基础设施自动化、演进式设计等，需要补足。

如何救赎

• 工具完善——标准化工具、微服务工具链、容器化的持续交付流水线
• 流程改进——完善规范、测试左移、自助式发布
• 文化变革——责任共担、自组织文化、学习融入日常工作、持续反馈和优化

流程文化——建立规范

代码评审委员会

• 自组织管理
• 优秀基层员工为主
• 轮系主席
• 制定规范指引
• 员工晋级考核
• 分支组织——泰山计划、女娲计划

组织变革

• 基础框架组
• 平台技术组
• 运维开发组
• 测试效率提升组 合并成 DevOps 专家团队（虚拟团队），到业务中 eat your dog food ，把改进落地

工具引入

完善微服务基础设施（ppmon 全家桶）

案例：监控系统的挑战

度量（立体化监控）、日志（elk）、跟踪（pinpoint）
改造 logback 插件——注入调用链主键（transanctionId）串联各系统信息——统一日志规范让其在全团队落地——发起错误日志零容忍活动——发起仪表盘设计大赛

容器化的持续交付流水线——jirachi 研发云平台，构建产物为 jar 及 docker 镜像

实践案例

第一个：测试环境部署频繁，业务测试相互干扰，环境间相互调用关系复杂

使用 jirachi ，各环境独立隔离，各服务自主部署

• 快速搭建环境
• 性能测试，寻找基准线，确认扩容后性能提升效率
• Chaos 混乱工程
• 自助式域名服务

第二个：新入职员工培养

组织技术比赛>优胜作品成果>DevOps 团队参与技术框架升级>输出入职培训流程，实践 PPmon 框架

总结及规划

总结

• 价值驱动
• 代码未动，devops 先行
• 微服务是提炼出来的

规划

• 持续梳理服务边界，完成微服务增减
• CI/CD 100% 迁移到生产环境
• 更完善的开发者体验
• 持续改进的自动化
• 提升集成安全、变更管理和合规性的综合实践
• 关注 CNCF，观望 SERVICE MESH

问答

问：怎么拆耦合度比较合适？
答：没有统一标准，需要根据实际情况不断调整

问：这么多改进，如何如此快速地推进
答：文化先行，让大家兴奋起来。放权，协助协调资源，交给具体的负责人推行。软硬兼施，软靠活动，硬靠考试、规范。

测试一下专栏编辑