8小时外的成长 广州 DevOpsDays 社区第二届沙龙 (20181027) 沙龙笔记

陈恒捷 · October 27, 2018 · Last by 陈恒捷 replied at November 11, 2019 · 2394 hits

周六参加的一个 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

问答

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

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

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 6 条回复 时间 点赞

转型的难点可能主要在于工作习惯的改变 光kanban里的限制在制品这一条 感觉我们做了半年多了都还有团队成员觉得别扭

顺便 片子有下载吗

AngryTester 回复

是的,改变人是最难的,需要时间和不断地重复宣传。

ppt 可以到这里下载:https://mp.weixin.qq.com/s/vpaYtV30_iukSgMJgrnwdA

陈恒捷 回复

感谢!

陈恒捷 回复

已经过去了一年,下载链接失效了,不知道还有没有可能再看到分享的ppt

我不是活动主办方,控制不了这些 ppt 。

建议你可以在那个公众号下留言给他们。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up