技术

并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go细节 codereview mat使用 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 MVCC 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes自动扩容缩容 神经网络模型优化 直觉上理解机器学习 knative入门 如何学习机器学习 神经网络系列笔记 TIDB源码分析 《阿里巴巴云原生实践15讲》笔记 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 扩展Kubernetes 副本一致性 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全机制 jvm crash分析 Prometheus 学习 Kubernetes监控 Kubernetes 控制器模型 容器日志采集 容器狂占cpu怎么办? 容器狂打日志怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes objects之编排对象 源码分析体会 自动化mock AIOps说的啥 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 kubernetes实践 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 marathon-client 源码分析 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 swagger PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 《深入剖析kubernetes》笔记 精简代码的利器——lombok 学习 编程语言的动态性 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 分布式计算系统的那些套路 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 mysql 批量操作优化 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 mesos 的一些tips mesos 集成 calico calico学习 AQS2——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 硬件对软件设计的影响 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记2 《mysql技术内幕》笔记1 log4j学习 为什么netty比较难懂? 回溯法 apollo client源码分析及看待面向对象设计 学习并发 从一个marathon的问题开始的 docker 环境(主要运行java项目)常见问题 Scala的一些梗 OpenTSDB 入门 spring事务小结 事务一致性 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型 java exception Linux IO学习 network channel network byte buffer 测试环境docker化实践 netty(七)netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 mesos深入 Macvlan Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker中涉及到的一些linux知识 hystrix学习 Linux网络源代码学习——整体介绍 zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty(六)netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 Redis概述 机器学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 那些有用的sql语句 异构数据库表在线同步 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM内存与执行 git spring rmi和thrift maven/ant/gradle使用 再看tcp mesos简介 缓存系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 VPN(Virtual Private Network) Kubernetes存储 Kubernetes 其它特性 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 使用etcd + confd + nginx做动态负载均衡 如何通过fleet unit files 来构建灵活的服务 CoreOS 安装 CoreOS 使用 Go学习 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

标签


研发效能平台

2018年10月15日

简介

你真的懂效率?

  1. 定义效率
  2. 度量效率
  3. 提高效率

从持续交付到业务创新(上):互联网时代研发效能的核心

为什么要效率以及定义效率

  1. 瀑布开发的本质问题并不是阶段,而是批量。
  2. 一个功能有多少价值, 不仅取决于其本身,还取决于什么时候交付。所以要敏捷开发,分feature,以最快的速度交付第一个feature。
  3. 团队(包括产品也包括开发、业务)什么时候对于产品和项目的知识最充分、最多?项目结束的时候。产品和业务开发本来就是一个探索的过程,开始时一定是最无知的时刻。项目中的大部分决策,是什么时间做出的呢?项目开始的时刻。这里埋藏了一个重大的悖论,我们在最无知的时刻,做出了最重要而且是绝大部分的决策,并把它作为随后执行的依据。对于这一悖论,敏捷的对策还是迭代。

  4. 敏捷指的是创建一个组织更快(早)的交付价值,和更有效学习和灵活应变的能力。
  5. 产品开发的最终目的是交付价值,那我们就必须让价值交付的过程顺畅起来,也就是让价值流动顺畅起来。计划、管理、协调活动,以及资源的配置等等,都应该服务于价值的流动。价值流动是目的,资源忙起来不是。

度量效率

我们在阿里内部做团队效能改进时,提出了称之为“2-1-1”的愿景,得到了不少部门的认可。什么是211呢?

  1. “2”指的是交付周期2周——85%以上的需求可以在2周内交付;它涉及到整个组织各职能,和部门的协调一致,紧密协作。
  2. 第一个“1”指的是开发周期1周——85%以上的需求可以在1周内开发完成;
  3. 第二个“1”指的是发布前置时间1小时——提交代码后可以在1小时内完成发布。需要持续交付流水线,产品架构体系和自动化测试、部署等有力保障。

提高效率

路灯下醉汉在找什么东西,很长时间过去了,警察一直看着他,终于忍不住走上前,问道:“你在找啥?”。醉汉说:“找我的钥匙”。警察看了一下钥匙好像不在这,就问:“钥匙是丢在这吗?”醉汉说:“不是”。警察奇怪的问道:“那你为什么在这找?”。“只有这儿能看到啊”

  1. 现实中我们更多关注资源是否停滞,人是否闲着,但真正的问题并不在这儿。真正的问题是需求的停滞,需求在各个阶段的积压——如分析阶段、测试阶段、发布阶段等等。需求不能顺畅流动才是真正的问题所在,也就是我们所说的关键所在。
  2. 为什么我们往往对需求的积压很少关注?因为它很难看到,不是光照亮的地方。我们很难觉察(至少很难即时的察觉)。需求的停滞、积压和返工,而那才是改进价值交付的关键所在。

  3. 要改进端到端的流程,我们必须看到价值端到端的流动过程,在哪里出现了积压和停滞。为此,改进的第一步,就是要让光照亮关键所在——可视化端到端的价值流动过程,基于价值流发现流动过程中的问题。

  4. 我们还要保障价值流动的过程质量,把交付质量内建到开发过程中,而不是依赖最后环节的测试。为了做到内建质量,我们需要明确定义需求流动的标准

  5. 潘季驯,他是明朝治理黄河的水利专家,被称为“千古治黄第一人”,治黄河难,难在泥沙不断淤积。清淤是治理黄河的传统办法,问题是清了又会淤,年复一年。嘉靖到万历年间潘季驯四次临危受命治理黄河,取得前所未有的成效,并总结了切实可行的方略,其中最为重要的思想就是“束水攻沙”。什么是“束水攻沙”呢?潘季驯在治理黄河时既没有蛮力清淤,也不是一味地加高、加宽河堤。他反其道而行,收窄河堤——在大堤(称为遥堤)内再修筑一道更窄的堤(称为缕堤),遥堤用以防溃,缕堤用以束水。河堤收窄了,水流的速度就会加快,将沉积的泥沙带走,这就是所谓”束水攻沙”。“束水攻沙”与产品开发有什么关系呢?“束水”加快了水的流速,也带走了泥沙。对应的,产品开发中我们也要限制并行需求的数量,同样是为了缩短需求从开始到完成的平均交付周期——加快流速,并即时发现和处理交付过程中的问题——带走泥沙。

  6. 以站会为例,团队在站会上,会去审视需求的状态。这里面有两个策略,一种是从左向右审视,还有一个从右往左审视,大家认为哪个合适?对,大家都说从右往左。为什么呢?因为我们应该聚焦于完成而不是开始,我们应该聚焦于尽快的交付,比如测试中的需求是不是有缺陷,并优先解决这些缺陷,好让需求尽快上线;开发中的需求,有没有阻碍,并即时解决这些阻碍,完成它们。

在精益和敏捷开发实施过程中,我们首先做的是可视化价值流动,并以此为基础逐步减小并行需求的数目,力求需求的持续流动——持续小批量的输入、开发、转测试和交付。在减小批量的过程中,问题逐渐暴露。

更重要的是:要让团队看见问题(前提是统一对问题的认识),并且提供合适的路径,一个时间解决一个问题,并且解决问题后要能看到立即的想过。核心有两个,第一:“看见”,它的关键是看见系统,看见价值的端到端流动,以此为基础看到问题和改进机会;第二:“路径”,它的关键是小步快走,但每一步都要有可感知的成果。

小结

  1. 效率的本质:需求的高速流动
  2. 需求流动可视化,是否产生积压
  3. 保障价值流动的过程质量,未达标时不允许流动到下一阶段

阿里云效平台

阿里云效平台 简介

阿里云效平台 官网

28位阿里技术专家解密研发效能升级之道(含PDF文件下载) 所有的pdf 文件阅读

关键字

  1. 软件生命周期流程 线上化,透明化和自动化。说白了,每一个阶段要先做好,提高单个效率
  2. 打通。提供沟通效率。
  3. 借鉴敏捷的研发模式,摸索出了一套行之有效的方法和理念,并沉淀出一整套研发效能平台。

云效,一站式企业协同研发云,源于阿里巴巴多年先进的管理理念和工程实践,提供从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑。

持续交付

南京银行Devops持续交付实践之路

主要想表达的是:

  1. 研发效率里包含什么?
  2. 每个一个部分如何自动化,提高效率
  3. 串起来如何自动化,提高效率

承担集团数万应用、研发人员日常工作,阿里持续交付平台的设计、迭代之道

  1. 平台不能只是工具的堆砌,更需要针对互联网时代的研发模式进行深度思考,不断打磨,将工程师文化和工程师实践不断地融入其中。
  2. 从需求到代码,从交付到反馈的一站式平台。项目、需求、代码、构建、测试、发布、流水线、舆情反馈等等等等,产品大图基本完备。
  3. 发展历程

    1. 自动化,配置、代码、测试、运维的自动化。
    2. 标准化
    3. 定制化
    4. 一站式,一个需求的研发过程中,相关的所有同学要访问几个系统?
  4. 当交付速度决定市场:我们 CTO 曾说过,研发工具要保障一个 idea 从诞生到上线在 2 周内完成,快速试错,不行就干掉,好了就拉一帮人做大做强。
  5. 借助中间件全链路 trace 技术,建立测试用例与业务方法的关联关系,当代码变更时推荐需要执行的用例,精准回归,快速反馈。
  6. 双引擎测试,首先通过 client 对线上请求进行采集,其中包括 request 和 response,以及下游系统,缓存、db 等等的调用链路快照。通过 mq 消息发送给 beta 环境的 client 进行回放。这里就简单进行回放请求就完成了么?显然不是,该工具最核心的是对应用所有的下游依赖进行了隔离和 mock,比如应用发送给 db 一条 sql 查询数据,双引擎测试平台会将这个请求阻断,并返回线上同样查询的快照数据。最终拿到应用的 response 进行实时对比,存储不一致结果。

测试环境

阿里测试环境运维及研发效率提升之道

  1. 资源稳定性
  2. 部署效率
  3. 业务稳定性

    发布上线完之后我们会去部署一个基础环境,开发环境去调用稳定环境的服务。基础环境部署的是主干代码,也就是线上的代码,会自动部署。

rick 的疑惑:对于一个服务实例,是启动时就知道隔离组,还是后面拖进去的,拖一拖的动作是为了什么?

从中可以看到

  1. 开发环境不是一个全服务的存在,只有正在测试的服务,最大限度的去复用基础环境下的服务。
  2. 基础环境的服务 不是想部署就部署的,是你上线后,同样的代码自动部署的
  3. 源头ip 也可以拖到隔离组,并且对于A调用B来说,怎么路由的,跟A和B在不在一个隔离组没关系,跟源头ip 和 B在不在一个隔离组有关系。
  4. 可以推断:实例创建的时候便已经指定了隔离组。否则,一个实例创建出来,并且没有分配隔离组的话,便游离在“三界”之外,既不是顶掉原来的服务,也不会有流量进来。
  5. 在新的理念下,开发/测试环境 不是一个全服务的、服务之间互通的、每个服务都由开发者各自管理的环境。而是一个自动管理的稳定环境 + 服务间隔离的开发环境。从每一个开发者的视角看,他们都拥有稳定的上下游服务。

分支管理策略

在阿里,我们如何管理代码分支?

  1. 开始工作前,从主干创建特性分支。
  2. 通过合并特性分支,形成发布分支。从主干上拉出一条新分支,将所有本次要集成或发布的特性分支依次合并过去,从而得到发布分支。发布分支通常以release/前缀命名。

    发布分支的用途可以很灵活

    1. 基础玩法是将每条发布分支与具体的环境相对应,比如release/test分支对应部署测试环境,release/prod分支对应线上正式环境等等,并与流水线工具相结合,串联各个环境上的代码质量扫描和自动化测试关卡,将产出的部署包直接发布到相应环境上。
    2. 进阶点的玩法是将一个发布分支对应多个环境,比如把灰度发布和正式发布串在一起,中间加上人工验收的步骤。
    3. 高级的玩法呢,要是按迭代计划来关联特性分支,创建出以迭代演进的固定发布分支,再把一系列环境都串在这个发布分支的流水线上,就有点经典持续集成流水线的味道了。

    当然,这些花哨的高级玩法是我臆想的,阿里的发布分支一般都还是比较中规中矩。

  3. 发布到线上正式环境后,合并相应的发布分支到主干,在主干添加标签,同时删除该发布分支关联的特性分支。

由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的,在流程上可以要求只有通过前一环境验证的特性,才能传递到下一个环境做部署,形成漏斗形的特性发布流。

AoneFlow 的技术门槛以及阿里内部的应对之道

  1. 除了开发流程和代码分支的管理方式以外,还包括日常开发中的一些约定俗成的规约。
  2. 工具可以使得团队协作更加平滑,在阿里内部,使用 AoneFlow 流程的团队基本上不用自己运行 Git 来处理分支的事情

    • 由于是内部工具,平台的功能高度内聚。对于项目而言,从提出原始需求,将需求拆分为任务,然后根据任务在线创建特性分支,再聚合生成发布分支,同时根据模板自动创建测试环境,直到后期的运维保障都可以一站式的搞定。
    • 平台对于 AoneFlow,向前做到了将特性分支和需求项关联起来,确保了特性分支的命名规范性;向后做到了将发布分支与部署行为关联起来,确保了各环境版本来源的可靠性。打通了端到端交付的任督二脉。
    • 发布分支的流水线。当这些分支被创建或更新时,往往需要伴随其他的一系列行为,比如自动进行集成测试、代码检查与部署
    • 平台提供代码仓库各个分支状况的统一展示,包括分支所对应部署环境的机器信息、操作记录等全都一览无余

要点:

  1. master分支
  2. 特性分支
  3. 发布分支,发布分支的操作关联流水线
  4. 特性分支与发布分支关联,这个关联数据要记录下来