本文是基于 中国DevOps社区峰会 2021·深圳 + 本人在工作中所遇到的问题进行一个简单的梳理，本来是准备连带着 《DevOps实践指南》读后感一起的，但是发现可能会导致这篇文章内容过于臃肿，决定分两版产出。

DevOps

DevOps官方介绍

DevOps维基百科定义 DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

由于博主本身不是做运维相关的工作，所以博主不会过多关注运维工具，以下介绍中可能会缺失运维工具这一块，请大家谅解。

DevOps前世今生

我们的开发模式大致经历了三个阶段：单体架构+瀑布模式 -> 分布式架构+敏捷开发模式 -> 微服务架构 + DevOps

• 单体架构 + 瀑布模式
  • 需求响应慢、上线时间久、无法跟上市场的变化、一次写众多的功能代码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内容，非常可惜有不少精彩的分享可能因为涉及敏感数据并未公开。 以上内容如有侵权，请联系作者，将会立刻修改删除