缘起
真北敏捷社区的宗旨是：求知、连接。求知就是学习，家里没矿的话，学习是一个人最重要的动力之源。连接就是把人拉在一起，我们相信人与人的互动会带来美好的变化。今天的直播是把大家拉在一起学习，就是求知、连接。
嘉宾介绍
董越，DevOps 资深专家，阿里巴巴集团前研发效能事业部架构、高级产品专家等职，从事 Aone&云效 DevOps 产品设计、阿里云专有云集成与交付解决方案设计等工作。在加入阿里之前，他还曾就职于西门子、摩托罗拉、雅虎、索尼、去哪儿网等大型企业，一直从事软件配置管理、软件集成与交付、DevOps 相关的工作。当前主要从事企业级DevOps体系建设与咨询工作，帮助众多企业提升软件研发交付效能。已服务过的客户有华为、工商银行、交通银行、招商银行、中信银行、中国移动、中国联通、中国电信、华泰证券、泰康人寿等。
直播笔记
# 简明DevOps学习地图
50+位真北敏捷小伙伴参与了学习与互动。
## 概念辨析
* 软件工程：随着软件规模和参与人员的扩大，如何把造金字塔的智慧、造长城的智慧应用到软件开发，做工作的分解、计划、把握质量等，这就是工程化。
* 敏捷、精益：是对工程化的反动，需求和实现的不确定，严格的工程方法不适用。敏捷宣言左边是软件工程，右边是矫正。大项目更需要工程，小项目更适用敏捷。敏捷包括工程实践和管理实践，工程实践如PP二十年推广的不够好。推荐TDD。
精益来自精益制造，落实到软件：精益看板墙、精益创业。精益范围很广，从需求到发布上线都涉及，是一个方法论。精益有明确的思想。DevOps是一个大杂烩。
* 持续集成、持续交付、持续部署：敏捷关注开发过程，对测试研究不深入，是从开发者的视角。持续是说不应该放在最后搞，而是要不断搞。不追求开发人员每天提交到主干。集成是说先做出一个个小零件，再组装成汽车、手机。软件中指的是对代码改动的组装。集成的演化含义，持续集成没那么重要，如果在本地没有质量问题，合起来也没什么问题，特别是模块化微服务做的好。把改动捏到一起，做一定测试，才算集成，否则就只是构建。
持续交付是对持续集成的演进。是在接近生产环境做更多测试。持续的含义有变化。CI一天做N个Build。CD里的持续不太持续，两周上线一次已经很持续交付了。
持续部署，来源非常草率。最早的文章说不要做测试了，直接发到线上，等着别人提意见。后来被引申修补，指的是改动后经过自动化的过程后上线。没有人工测试很难做到。单个特性自动化测试和发布没问题。
* DevOps：故事是愉快地合作。实际是把Ops自动化，开发可以完成变更发布，不由运维人员操作。配管也发生了同样的故事，以前开发与配管5：1，随着工具进步，变成500：1，工具化平台化服务化。最后是去掉了运维的手工的工作，运维人员去做平台或咨询（帮助开发人员启动）。再演化成BizDevOps，什么都是DevOps。
* 研发效能：国内概念。阿里有研发效能事业部。不像精益有自己的思想，只有一个范围，从需求到上线，怎么提升效能。平台工程说的是把平台做好，让开发更好用，跟DevOps一体两面。工具其实很重要。
* 云原生：是关于部署架构，云计算，弹性，容器化，偏向架构。12要素，也有部署发布相关，但主要是架构相关。
问答：chatgpt会代替devops吗？
答：不会。低代码会影响。chatgpt对软件开发过程有影响。
## 研究范围
全图：
* 软件开发(广义) = 定义需求 + 实现需求
* 实现需求 = 软件开发(狭义) + 软件交付
DevOps聚焦软件交付。
软件交付包括：
* 程序形态的转化
* 程序质量的提升
* 程序改动的聚积
体现在分支策略、代码提交等。
## 追求目标
* 整体目标：为了业务的成功
* 定义需求：有效率地找到有效的软件需求
* 从定义需求到实现需求：小步快跑
* 实现需求：效率与质量
* 效率要兼顾需求吞吐量和需求响应时长：资源利用的效率，能处理多少个需求。另一方面是反应的速度，改两行代码，多长时间能上线，两分钟还是两个月。
* 质量不是越高越好，是要适合业务：星舰要高质量，个人小游戏不用。
* 质量由问题出现量和问题修复时长共同决定：难修的要质量高。降低修复时长比降低问题数容易，效果好。
* 兼顾短期和长期：避免技术债。
> 数量
>
> ↑
>
> 需求吞吐量 | 问题出现量
>
> 效率 ←------------+--------------→ 质量
>
> 需求响应时长 | 问题修复时长
>
> ↓
>
> 时间
* Dora的DevOps核心指标
* 部署频率（Deployment Frequency）：响应时长。
* 变更前置时间（Lead Time for Changes）
* 变更失败率（Change Failure Rate）：问题出现量。
* 服务恢复时间（Time to Restore Service）：问题修复时长。
吞吐量统计就会变形。
## DevOps三步工作法
* 从左到右，快速流动
* 从右到左，快速反馈
* 持续学习与实验的文化
DevOps没有特质方法论，三步法是精益的老生常谈。流动是精益。反馈是敏捷。学习与改进也不是原创，也是敏捷原则之一。
不是原创，但三步法挺好。梳理价值流，从代码改动到上线，看修复时长等。
## 核心策略
1. 小批量持续流动的流程
2. 综合手段保证质量和安全
- 各种各样的测试
- 左移+右移
- 开发人员+测试人员
- 自动化测试+人工测试
3. 细粒度、低耦合、可复用的架构
- 软件架构
- 测试脚本与测试数据的架构
- 组织架构
4. 自动化与自助化
- 单项活动的自动化
- 流程的自动化
- 自助化
5. 加速各项活动
- 提高硬件能力
- 考虑并行处理
- 避免重复
- 只关注增量
- 使用缓存
6. 及时修复
- 通知要及时和精准
- 优先处置
- 修不如退
- 便捷排查
7. 完备记录，充分展现
- 跟踪事项，记录执行
- 版本与配置信息
- 关联关系
8. 标准化和一致性
- 规范可重复
- 方案收敛
- 环境一致性
9. 协调完成完整功能
10. 基于度量的持续改进
头脑中有个弦，要做自动化。
## 入行必读书
* 《持续集成》
* 《持续交付》
* 《DevOps实践指南》（特别是第2版）
* 《精益产品开发：原则、方法与实施》
《全程软件测试》
《SRE：Google运维解密》
问答：
关于如何学习：根据实际的工作，选择确定的领域，比如流水线，再去做相关的学习。
关于DevOps教练：为组织服务的团队，做工具，就是搞DevOps的。有了工具之后还需要方法和流程，比如相对统一的分支策略、发布流程，需要统一的人来协调，不要太百花齐放。这时候就有DevOps教练。敏捷的工程教练也可以说是DevOps教练。DevOps教练包括工具和方法。进驻到项目，一起工作一段时间。做开发平台，做培训分享。
道与术：道术法器用。
DevOps人员占比：100比几万研发。小企业偏向开源，大企业偏自研。
转型：测试、工具开发、配管、有开发背景的Ops、开发人员、只要更软件沾边的，都可以转DevOps。
如何评价一站式平台：是方向。不过拿开源工具攒，比较费事。
DevOps甩锅现象？目标是避免甩锅，让大家有良好沟通的环境，不担心被指责，分析问题根因，避免。
DevOps认证：更推荐企业认证。
chatops：代替不了DevOps。IDE作为DevOps入口是有前景的。gitops是解决特定的问题，也不能代替DevOps。
反馈：从价值流的每一步都有对前一步的反馈，是普遍适用的。
小团队：投资不能太大，可以买一套平台，azure或国内的。如果只搭个Jenkins，就两天。整套打通可能要几个人月。
著作推介
董越老师的新书《软件交付通识》从头到尾梳理了软件交付过程（也就是从改了一行代码到它发布上线的过程），分门别类地讲解了流程各个阶段的各个要点，以及流程中各个活动的各个要点。软件高效交付的10个策略更是这本书中的核心观点和内容，如果你想快速通读所有10个策略，请关注这本不容错过的好书。
未尽之处，欢迎留言提问。
欢迎打赏，本篇打赏归董老师。
