目录
- DevOps
- DevOps官方介绍
- DevOps前世今生
- DevOps能做什么
- 自动化与持续反馈
- 如何推动DevOps转型
- 技术债
-
- 研发效能分析
-
- 团队数据收集
-
- 浅谈敏捷
-
本文是基于 中国DevOps社区峰会 2021·深圳 + 本人在工作中所遇到的问题进行一个简单的梳理,本来是准备连带着 《DevOps实践指南》读后感一起的,但是发现可能会导致这篇文章内容过于臃肿,决定分两版产出。
DevOps
DevOps官方介绍
DevOps维基百科定义 DevOps(Development和operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
由于博主本身不是做运维相关的工作,所以博主不会过多关注运维工具,以下介绍中可能会缺失运维工具这一块,请大家谅解。
DevOps前世今生
我们的开发模式大致经历了三个阶段F1a;单体架构+瀑布模式 -> 分布式架构+敏捷开发模式 -> 微服务架构 + DevOps @H_295_126@
- 单体架构 + 瀑布模式
- 需求响应慢、上线时间久、无法跟上市场的变化、一次写众多的功能代码BUG多、服务冗余不易扩展;
- 分布式架构 + 敏捷开发模式
- 开发与运维的隔离、多人协同开发效率上不来、版本与版本之间并行开发却不同时间上线导致的代码合并、脚本管理、分支管理、测试环境A/B版本叠加后问题排查复杂化;
但是小团队依然适合这个模式,它依然很棒
;
- 微服务架构 + DEVOPS
- 吸取敏捷模式的优点并扩大化;
- CICD、自动化测试、无需复杂的代码分支管理、更快的需求响应、更高频的生产发布、开发运维一体化;
- 主要体现在:人、流程、平台、自动化;
- 也是一种文化;
团队越来越大后需要思考和转型的模式
;
DevOps能做什么
- 更多的在技术视角上解决痛点、提升效率、团队成员的成长是巨大的
- 一定的体现在业务交付更快、频率更高
更高频率的生产发布
- CICD(持续集成、持续交付、持续部署)
- 自动化
- 左移
- DevOps的目标一定不能是:提高开发团队的需求吞吐量!!!虽然当您成功的完成DevOps转型后吞吐量会有提升,但是请保持初心!!!
自动化与持续反馈
- 结对编程(PairPRogramming)
- 极限编程(ExtremeProgramming,简称xp)同样也是提倡结对编程,敏捷中的一种方式,提倡两个人来一起完成同一项任务,并互相了解阅读对方的代码,来保证质量和规范;
- 自动化测试覆盖率问题
- 不要被100%的代码覆盖率欺骗,有些语句并没有覆盖的价值,100%的代码覆盖率会让人迷失目标;
如何推动DevOps转型
- 自上而下
- 一定要有一个高层领导认可,且愿意去负责推动DevOps,并能给与你一定资源上的支持;
- 以点带面
- 先从愿意转型且能够承担失败风险的团队开始
最好只挑选一个团队,集中全部精力,打造典范,这个团队不能是太边缘的团队
,制定阶段性指标,并周期性复盘指标完成情况; - 当打造出成功案例后再去逐步推广,此时遇到完全不愿意配合的团队Leader,可以视情况放弃。先搞定那些愿意的、不抵触的团队
人都是从众的,当所有人都去这样做,那么他也会选择跟随
; - 最后再去瓦解"钉子户";
- 改变能改变的,接受不能改变的
- 规范是死的,人是活的。因地制宜,不要死搬规范,硬走流程,退一步海阔天空;
技术债
什么是技术债
技术债是指我们当前所做出的决定会导致一些问题,而这些问题随着时间推移会越来越难解决,未来可采取的措施也会越来越少。即使我们审慎地承担债务,也会产生利息——摘抄自《DevOps实践指南》
如何解决技术债
这一块不论是书中还是DevOps社区峰会的大佬们的分享,都是采用每个版本或者说每个周期拿出 20%的资源 去做技术团队 自提 的需求,可以是代码 重构 、数据库 表结构优化 、慢SQL优化 、 新技术 研究引入,等等用户不可见的需求。 当然很多团队都在做着这些,但是他们是让技术团队在满足需求后再去做这些东西,这样可能存在 工作量 的问题,使得开发人员的 抵触情绪 ,同时没有明确这件事的 重要性,也无法保证其 持续性,且多为团队中极少数人提出或只有Leader提出,因为提出这些建议会导致他们的工作量的增加。
去QA是提高质量的有效手段
为什么这个bug都测不出来; 测试怎么测的,到底会不会测试; 测试快点啊,为啥总是测试拖后腿,最后才测试出bug; 不知道大家团队中会不会遇到这个问题,到底漏测BUG是开发的问题还是测试的问题呢?
- 去QA的目的
去QA并非完全的砍掉,而是解决研发过度依赖QA的问题
- 消除对职位的依赖
- 提升对职能的要求
- 构建质量内建的文化
- 强化自身关联性
研发效能分析
核心:研发效能指标分析不能和KPI挂钩!研发效能指标分析不能和KPI挂钩!研发效能指标分析不能和KPI挂钩!
研发效能是什么
度量的方式
- 工具
- 需要一个好的需求管理工具来根据实际操作生成图表
TAPD、禅道等等都能满足
; - 图表有很多,请根据自身团队情况与瓶颈选择对应的指标图;
- 规范
- 有了工具自然还需要规范,大家需要依据规范操作,这样产生的数据图表才是准确的、有效的;
- 流程管控需要更细粒度,这样才能找到真正的 瓶颈 ,正如一条流水线,我们去优化瓶颈前的流程,会导致瓶颈处堆积更加严重;我们去优化瓶颈后的流程,会导致它们更加饥渴;只有对瓶颈的优化才能让整体产能发生质变;
- 文化
- 规范总是那么的冷冰冰,哪怕你还不知道我的规范的内容,你就开始抵触,这是后需要灌输文化,让大家支持且认同我们所做的一切,我们的选择是正确的,我们正在让自己变得更加强大;
- 而文化可以通过行为影响,也能通过培训灌输,培训的形式可以是 分享会 、 有奖竞赛等等方式;
度量的维度
- 交付效能指标
- 工程能力指标
- 研发及架构
- 代码扰动率
- 测试及质量
- 变更部署及发版
- 监控排障
度量的误区
- 过度依赖工时、代码行数 等易于获得的数据
- 忽视团队成员的发展需求
- 缺乏统一的标准,主观性强
- 缺少过程工具,指标数据人工录入
- 度量指标的滞后性
- 单一评价维度
团队数据收集
下面这些不管您的团队是否正在推行DevOps,我认为它们都是对团队有帮助的东西。 当然我们需要先明确一个事情,就是许多时候需要下面的同事们反馈表决的时候,会发现更多的人是不愿意敞开心扉来表达自己真实的想法,特别体现在举手表决上,所以我们需要为这帮兄弟们提供一个绝对安全的环境,供他们畅所欲言——匿名投票、匿名反馈 特此鸣谢 中国DevOps社区,因为下面许多指数都是在本次学习中 谢意 老师分享的
工作数据
帮助最大的人
- 总分制、每人可投递总分5分,可全部给一个人也可以按照最小单位为 1 的情况下给不同的人;
- 每个版本结束后或每个月一次,匿名或非匿名均可;
- 让优秀的人得到肯定与表扬,可以定期给与拿分高的同事一定的奖励,但是切记不要固定的去惩罚那些分数最低人!!!
在参与大会前其实我们团队中也会有这个形式,但是并没有形成这样规范、固定的模式,导致没有具体分值留底
开心与伤心
- 内容收集,并尽可能的当场确定行动方案;
- 每个版本结束后或每个月一次,按小组或按人提交均可;
- 这里注意用的是 开心 与 伤心,而不是 做的好 与 做的不好 ,避免在标题上让人出现一种我在批评人的错觉,而是用伤心来体现出这是我自己的情感,并非指责大家。
其他指数
起床指数
- 指数为1 - 5分,分数越高代表起床意愿越强烈,也代表今天对工作的意愿更强,也可以一定程度代表今天的心情;
- 每天早上、非匿名打分;
- 对于低分的同事给与更多关心,了解其今天的状况,避免在不知情的情况下对其造成更大的伤害;
吃饭指数
- 指数为1 - 5分,分数越高代表聚一顿的意愿越强;
- 不定周期、下班前、匿名提交;
- 当大家意愿都很强的时候可以考虑来一顿说走就走及聚餐,团建无处不在
建议提前订好是Leader自掏腰包 or 团建经费 or AA制
;
浅谈敏捷
敏捷的误区
- 拥抱变化 = 需求频繁变更
- 过度依赖晨会进行沟通同步
- 对需求进行不合理的拆分
- 敏捷就是更紧密的迭代
文中大量内容来自 中国DevOps社区峰会 2021·深圳 大家可以关注公众号 “DevOps社区Meetup” 回复内容 :“深圳峰会” 可获取本次分享的部分PPT内容,非常可惜有不少精彩的分享可能因为涉及敏感数据并未公开。 以上内容如有侵权,请联系作者,将会立刻修改删除