DevOps指南

每个公司都是科技公司，无论他们认为自己处在那个行业。银行也只是拥有银行执照的IT公司而已。绝大多数投资项目都在某种程度上依赖于信息技术。想要做出一个不会带来任何IT变更的商业决策几乎不可能。

DevOps介绍

敏捷、持续交付和三步法

在DevOps中，我们通常将技术价值流定义为：把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程。流程的输入时既定的业务目标、概念、创意和假设，并将其添加到待完成工作列表中。应用程序或服务只有在生产环境中按预期正常的运行，并为客户提供服务，所有的工作才产生价值。所以，我们不但要快速的交付，同时还要保证部署工作不会产生混乱和破坏。

价值流始于工程师向版本控制系统中提交了一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。

聚焦于部署前置时间

1. 定义前置时间和处理时间
2. 常见的场景：为期数月的部署前置时间
3. 我们的目标：分钟级别的部署前置时间

关注返工指标

三步工作法

1. 实现开发到运维的工作快速从左向右流动
2. 在从右到左的每个阶段中，应用持续、快速的工作反馈机制
3. 建立具有创意和高可信度的企业文化

第一步：流动原则

停止开始，开始结束

1. 使工作可见
2. 限制在制品数
3. 减小批量大小
4. 减少交接次数
5. 持续识别和改善约束点
   1. 识别系统的约束点
   2. 决定如何利用这个系统的约束点
   3. 考虑全局工作
   4. 改善系统的约束点
   5. 如果约束点已经突破，则重新开始循环
6. 消除价值流中的困境和浪费
   1. 浪费和困境的类型：
      1. 库存
      2. 过量生产
      3. 过度加工
      4. 运输
      5. 等待
      6. 移动
      7. 缺陷

第二步：反馈原则

1. 及时发现问题
   1. 对系统设计和假设进行验证
   2. 所有工作执行的过程中，建立快速的反馈和前馈贿赂
   3. 建立全方位的监控系统
2. 群策群力，战胜问题获取新知
   1. 防止把问题带入下游处理环节
   2. 防止工作中心启动新的工作，避免引入新的错误
   3. 如果问题没有解决，下次操作之后可能还会遇到相同的问题
   4. PDCA循环
   5. 安灯绳的使用
3. 在源头保障质量
4. 为下游工作中心而优化

第三步：持续学习与实验原则

技术价值流的核心时建立高度信任的问题，整个组织都愿意尝试和实践新技术。

1. 建立学习型组织和安全文化
   1. 使用事故回顾记录工具Morgue
   2. 消除指责
2. 将日常工作的改进制度化
3. 把局部发现转化为全局化
4. 在日常工作中注入弹性模式(抗脆弱性)
   1. 改善日常运营，持续引入张力提高生产效率，注入更大弹性
   2. 通过演习的方式来预演大规模故障，来验证可靠性
5. 领导层强化学习文化

从何处开始

选择合适的价值流作为切入点

1. 绿地项目于棕地项目
2. 兼顾记录型系统和交互系统
3. 从最乐于创新的团队开始
4. 扩大DevOps的范围
   1. 发现创新者和早期采用者
   2. 赢得沉默的大多数
   3. 识别钉子户

理解、可视化和运用价值流

1. 确定创造客户价值所需的团队
2. 针对团队工作绘制价值流图
   1. 使用价值流图记录工作方式
   2. 了解向客户交付价值需要完成多少工作
   3. 重点分析和优化工作
      1. 需要等待数周甚至数月的工作
      2. 引发或处理重大返工的工作
3. 组建专门的转型团队
   1. 拥有共同的目标
   2. 保持小跨度的改进计划
   3. 为非功能性需求预留20%的开发时间，减少技术债务
   4. 提高工作的可视化程度
4. 使用工具强化预期行为

参考康威定律设计组织结构

1. 康威定律：系统设计受限于组织自身的沟通结构
2. 过度职能导向的危害
3. 组织以市场为导向的团队
4. 使职能导向有效
5. 将测试、运维和信息安全融入日常工作
6. 使团队成员都成为通才
7. 投资于服务和产品，而非项目
8. 创建松耦合架构，提高生产力和安全性

将运维融入日常开发工作

通用原则：

1. 构建自服务能力，帮助开发人员提高生产力
   1. 创建集中式的平台和工具集服务
   2. 创建共享服务促进标准化
   3. 发掘内部广泛应用的工具链
2. 将运维工程师融入服务团队
   1. 为每个服务团队分派运维联络人
   2. 邀请工程师参加开发团队的会议
      1. 邀请运维工程师参加每日站会
      2. 邀请运维工程师参加回顾会议
      3. 使用看板展示运维工作

流动的技术实践

准备部署流水线

部署流水线的目标就是能够基于版本控制系统中的信息重复搭建整套生产环境

1. 按需搭建开发环境、测试环境和生产环境
2. 应用统一的代码仓库
3. 使基础设施的重建更容易
   1. 出现问题应当快速重建，而不是耗时修复
   2. 确保环境的一致性
   3. 可以禁止远程登录生产服务器，杜绝不受控制的配置差异
4. 运行在类生产环境里才算“完成”

实现快速可靠的自动化测试

恐惧是心灵杀手。它使新手不敢变更，因为他们不了解系统。它也是老手不敢变更，因为他们太了解系统。

1. 对代码和环境做持续构建、测试和集成
2. 构建快速可靠的自动化测试套件
   1. 自动化测试的类型
      1. 单元测试
      2. 验收测试
      3. 集成测试
   2. 自动化测试中尽早发现错误
   3. 尽可能并行的快速执行测试
   4. 先编写自动化测试
   5. 尽量将手动测试自动化
   6. 集成性能测试
   7. 集成非功能性需求测试
3. 部署流水线失败时拉下安灯绳

应用和实践持续集成

1. 小批量开发与大批量合并
2. 应用基于主干的开发实践

自动化和低风险发布

1. 简化和自动化手动步骤
   1. 用相同的方式处理所有环境的部署
   2. 对部署执行冒烟测试
   3. 维持环境的一致性
2. 应用自动化的自助式部署
   1. 构建：部署流水线必须基于版本控制系统构建可部署到任何环境的软件包
   2. 测试：任何人都应该能够在他们的系统中运行任何一个自动化测试套件
   3. 部署：任何人都应该能够将这些软件包部署到具有访问权限的环境
3. 在部署流水线中集成代码部署
4. 将部署与发布解耦
   1. 基于环境的发布模式
      1. 蓝绿部署
         1. 生产环境和预生产环境的版本切换
         2. 处理数据库变更
            1. 创建两个数据库
            2. 将数据库变更与应用变更解耦
      2. 金丝雀发布
         1. 内部生产环境
         2. 小规模客户生产环境
         3. 标准生产环境
      3. 集群免疫系统
         1. 将生产环境的监控系统与发布流程向联系
         2. 面向用户的生产环境超出预定范围，自动回滚
   2. 基于应用的发布模式
      1. 实现特性开关
      2. 实现黑启动

降低发布风险的架构

1. 能提高生产力、可测试性和安全性的架构
2. 单体架构与微服务
3. 绞杀者应用模式

反馈的技术实践

运维团队面对的是复杂系统，没有哪个人能了解整个系统，能说清楚系统的每个部分是如何配合的

建立能发现并解决问题的遥测系统

1. 建设集中式监控机构
   1. 在业务逻辑、应用程序和环境层收集数据
   2. 负责存储和转发事件和指标的事件路由器
2. 建立生产环境的应用程序日志遥测
3. 使用遥测指导问题的解决
4. 将生产遥测融入日常工作
5. 建立自助访问的遥测和信息辐射器
6. 发现和填补遥测的盲区
7. 应用程序和业务度量指标
8. 基础架构度量指标
9. 显示叠加的指标组合

分析遥测数据以更好地预测故障和实现目标

1. 用均值和标准差识别潜在问题
2. 异常状态的处理和告警
3. 非高斯分布遥测数据的问题
4. 应用异常检测技术

应用反馈实现安全部署

将假设驱动的开发和A/B测试融入日常工作

建立评审和协作流程以提升当前的工作的质量

持续学习与实验的技术实践

将学习融入日常工作

1. 建立公正和学习的文化
2. 举行不指责的事后分析会议
3. 尽可能广泛地公开事后分析会议的结果
4. 降低事故容忍度，寻找更弱的故障信号
5. 重新定义失败，鼓励评估风险
6. 在生产环境注入故障来恢复和学习
7. 创建故障演练日

将局部经验转化为全局改进

1. 使用聊天室和聊天机器人自动积累组织知识
   1. 每个人都能够看到发生的一切
   2. 新来的工程师也可以看到团队的日常工作及其执行方式
   3. 看到其他人的互相帮助，激发其他人寻求帮助和施予援手的热情
   4. 建立组织学习，知识得到快速积累
   5. 固定方式记录并公开所有的沟通信息
2. 软件中便于重用的自动化、标准化流程
3. 创建全组织共享的单一源代码库
   1. 程序库、基础设施和环境的配置标准
   2. 部署工具
   3. 测试标准和工具，包括安全方面
   4. 部署流水线工具
   5. 监测和分析工具
   6. 教程和标准
4. 运用自动化测试记录和交流实践来传播知识
5. 通过确定非功能性需求来设计运维
6. 把可终用的运维用户故事纳入开发
7. 确保技术选型有助于实现组织目标

预留组织学习和改进的时间

1. 偿还技术债务的制度化惯例
2. 让所有人教学相长
3. 在DevOps会议中分享经验
4. 传播实践的内部顾问和教练

集成信息安全、变更管理和合规性的技术实践

将信息安全融入每个人的日常工作

保护部署流水线