有启发的 10 句话 1.DevOps 并非一个标准、一种模式或者一套固定方法，而是一种 IT 组织管理的发展趋势 2. 从生产过程开始，就做到质量内建 3. 你无法管理你不能衡量的事情 4. 古德哈特定律：如果一项指标变成了目标，它将不再是一个好指标 5 持续交付的需求拆分总原则：坚持以业务视角对需求进行分解 6. 技术债也是需求 7. 规范化和标准化并不等于僵化 8. 功能开关技术：通过开关来隐藏未开发完成的功能 9. 问题处理是一个学习过 10. 没有反馈，就是 “风险” 重点整理 :1. 没有放之四海皆准的企业管理解决方案能够完美解决每个企业遇到的问题。但是，管理者只有从整体视角出发，抵住局部优化的诱惑，才能在资源有限的情况下，引领企业创造更大的价值 2.DevOps 是一种软件工程文化和实践，旨在统一整合软件开发和软件运维 3.DevOps 并非一个标准、一种模式或者一套固定方法，而是一种 IT 组织管理的发展趋势，改变 IT 组织内部的原有合作模式，使之更紧密结合，从而促进业务迭代速度更快 4. 部署流水线模式的 4 条指导原则:* 每个构建阶段都应该交付可工作的软件，即中间产物的生成不应该是一个单独的阶段 * 用同一个制品向不同类型的环境部署，即将其与运行时配置分开管理 * 自动化测试和部署，即根据测试目的，分成几个独立的质量关卡 * 部署生产线设计也应该随着你的应用程序的发展而不断演进 5. 部署与交付 / 发布的意义并不相同:* 部署：一种技术领域的操作，但它并不一定意味着 “必须包含业务功能的发布或交付”* 交付 / 发布：是一个业务决策活动 6. 持续交付 2.0 的 4 个核心工作原则:* 坚持少做 * 持续分解问题 * 坚持快速反馈 * 持续改进并衡量 7. 探索环的 4 个关键环节:* 提问：通过有针对性的提问与讨论，找出团队期望达成的业务目标或者希望解决的业务本质问题 * 锚定 * 共创 * 精炼 8. 量化式影响地图的用 Why-Who-How-What 的分析法:* 角色 * 影响 * 方案 * 量化 9. 用户旅行地图，将用户与产品或服务之间的互动，按业务流分阶段呈现出来:* 用户接触点 * 接触阶段 * 用户痛点 * 用户情绪 10. 探索环遵循:* 分解并快速试错 * 一次只验证一点 * 允许失败 11. 共创与精炼的常用方法:* 装饰窗方法：新功能预留一个 “入口”，让用户能够看到，但实际上并没有真正实现其功能 * 最小可行特性法：寻找用户可直接感知到的需求假设作为产品的最小可行特性优先开发的方法 * 特区法：是指在特定用户范围内进行试验，以验证某个新功能的有效性 * 定向探索法：指针对具有某种特定行为的特定用户群体，依据该用户的具体行为模式，设计调查提纲，有针对性地探索其行为背后的动机 * 稻草人法：不开发任何真实的功能，只假装这个功能已经完成了，并向用户展示该功能的真实效果，从而得到用户的真实反馈 * 最小可行产品法：尽可能少的成本快速开发产品的核心功能，并找到用户，收集真实反馈，验证真实的用户需求，以确定新产品方向和形态 12. 彼得・德鲁克：结果只存在于企业的外部…… 在企业的内部，只有成本 13. 验证环的 4 个关键环节:* 构建 * 运行 * 监测 * 决策 14. 验证环的工作原则:* 质量内建 * 消除等待 * 尽量并行 * 监测一切 15. 戴明：我们无法依靠大批量的检验来达到质量标准。依靠检验提高质量已经太迟了，且成本高而效益低。正确的做法是，从生产过程开始，就做到质量内建 16. 工程师质量文化：* 第一步：定义想要做的事情 * 第二步：定义期望的做事方法 * 第三步：提供相应的培训 * 第四步：做些必需的事情来强化那些行为 17. 行动原则：价值导向、快速验证、持续学习 18. 彼得・德鲁克：你无法管理你不能衡量的事情 19. 衡量 IT 高绩效组织的 4 个度量项：发布频率、发布周期、MTBF 平均失效间隔 / MTTR 平均恢复时间和吞吐量 20. 古德哈特定律：如果一项指标变成了目标，它将不再是一个好指标。当一个人对一项政策有一定的预期，并以人为操作的手段去偏向化改变结果的时候，就会有此种现象发生 21. 改善套路进行持续改进 * 第一阶段：明确方向 * 第二阶段：掌握当前状态 * 第三阶段：定义下一个目标状态 * 第四阶段：迭代改进: PDCA 循环 22. 系统架构在设计时考虑因素：* 为测试而设计 * 为部署而设计 * 为监控而设计 * 为扩展而设计 * 为失效而设计：一旦部署或发布失败，如何优雅且快速地处理 23. 大系统小做的原则：* 每个组件或服务有清晰的业务职责，可以被独立修改，甚至被另一种实现方案所替代 * 高内聚、低耦合 * 整个系统易于构建与测试 * 使团队成员之间的沟通协作更加顺畅 24. 微核架构又称为插件架构：常用于需要向用户分发的客户端软件，指的是软件的核心框架相对较小，而其主要业务功能和业务逻辑都通过插件实现 25. 微核架构优点：* 良好的功能延伸性 * 易发布 * 易测试 * 可定制性高 * 可以渐进式地开发 26. 微核架构不足：* 扩展性差 * 开发难度相对较高 * 高度依赖框架 27. 分层的巨石应用也称巨石架构，常见于创业公司的产品项目，其设计理念就是自己从头到尾完成某项功能所需的所有步骤，而不只是实现其中某个环节 28. 对遗留系统进行架构改造的 3 种方式：* 拆迁者模式：一次性重写所有代码。这是大家最熟悉的方式 * 绞杀者模式：不改变或少改变原有遗留系统，通过增加新的服务来不断替代遗留系统的功能 * 修缮者模式：通过迭代，对原有遗留系统进行逐步改造，同时开发新的功能 29. 持续交付的需求拆分总原则：坚持以业务视角对需求进行分解 30. 技术债也是需求 31. 用户故事拆分方法：* 路径拆分法：用户使用场景中的不同路径进行拆分 * 按接触点拆分 * 按数据类型或格式拆分 * 按规则拆分：业务规则或者技术规则。* 按探索路径拆分 32. 提高团队协作的工具与方法：* 共享时间表 * 回顾会议 * 持续集成 * 故事验证 33. 流水线的设计遵循：* 一次构建，多次使用 * 与业务逻辑松耦合 * 并行化原则 * 快速反馈优先 * 重要反馈优先 34. 部署流水线发挥最大的作用，研发团队遵守原则：* 任何软件包的取用皆须通过受控源，各角色之间禁止通过私有渠道（如电子邮件、即时通信工具等）获取 * 尽可能将一切流程自动化，并持续优化执行时间 * 每次提交都能够自动触发部署流水线 * 尽可能地少用手动触发方式 * 必须执行立即暂停原则 35.“未开发完成的功能代码不能带入将要发布的版本里” 曾被认为是一种最佳软件质量管理实践。然而，在这种高频交付模式下，很难再遵守这一实践。相反，应该允许提交未完成功能的代码，前提是不影响用户的正常使用和发布 36. 常见分支开发模式 * 主干开发，主干发布 * 主干开发，分支发布 * 分支开发，主干发布 37. 版本发布模式三要素：* 交付时间点 * 特性数量 * 交付质量 38.GitHubFlow 分支模式的原则：* 分支越少越好，最好只有一条主干 * 分支生存周期越短越好，最好在 3 天以内 * 在业务允许的前提下，发布周期越短越好 39. 持续集成的自我检查：* 主干开发，频繁提交 * 每次提交应该是一个完整的任务 * 让提交构建在 10 分钟以内完成 * 提交构建失败后应禁止团队成员提交新代码，也不许其他人检出该代码 * 立即在 10 分钟内修复已失败的提交构建，否则回滚代码 * 自动化构建验证通过后，对软件质量有比较大的信心 40. 对自动化测试的实践管理原则：* 自动化测试用例运行次数越多，平均成本越低，收益就越大 * 自动化测试用例之间应该尽可能相互独立，互不影响 * 在质量有保障的前提下，自动化测试用例的数量越少越好 * 遗留代码的自动化测试编写应该从代码热区开始 * 自动化测试用例从测试金字塔的中间层开始补充，投入产出比最高 41. 软件配置管理的基本原则：* 一切皆有版本 * 共享唯一受信源 * 标准化与自动化 42. 规范化和标准化并不等于僵化，所有的规范管理都应该有相应的改进机制，并持续进行优化 43. 常见的包依赖问题：* 依赖过多或者链条过长 * 依赖冲突 * 循环依赖 44. 解决依赖冲突：* 想办法令被依赖库的两个不同版本可以在同一环境下运行 * 打平依赖：通过对产品代码的修改，使 A 和 B 依赖于同一个版本 * 分裂依赖 * 每次升级时使用梯形升级法 45. 环境准备的 4 种状态：* 蛮荒：以 “人脑 + 手工” 为代表 * 规范化：以 “文档 + 私有脚本” 为代表 * 标准化：以 “办公自动化” 为代表 * 自动化：以 “受控式自动化脚本” 为代表 46. 配置项的内容：* 环境配置项 * 应用配置项：信息安全控制及应用程序自身相关 * 业务配置项 47.Heroku 云原生应用的 12 要素：* 一套基准代码，多环境部署 * 显式声明依赖关系 * 在环境中存储配置 * 把后端服务当作附加资源 * 严格分离构建、发布和运行 * 应用本身应该是一个或多个无状态进程，进程之间没有数据共享 * 通过端口绑定提供服务 * 通过进程模型进行扩展 * 快速启动和优雅终止 * 尽可能让开发环境、预生产环境与生产环境等价 * 日志作为事件流 * 将管理 / 管理任务作为一次性进程运行 48. 验证检查放入版本管理：* 产品源代码和测试代码 * 软件应用的配置信息 * 各类环境的系统配置 * 自动化的构建和部署脚本 * 软件包 49. 高频发布是一种趋势 50. 下降低发布风险的方法：* 蓝绿部署 * 滚动部署 * 金丝雀发布 * 灰度发布 * 暗部署 51. 功能比较复杂，无法在两次发布之间完成开发的办法：* 拆分功能 * 先后再前法：先实现服务端功能，再实现用户界面 * 功能开关技术：通过开关来隐藏未开发完成的功能 52. 商业套装软件来说，通常软件授权证书就是一个开关，用于激活你购买的软件。而且不同的授权证书，还可以激活该软件中的不同功能 53. 对高频率的软件部署来说，开关技术被赋予了两种新的用途：* 隔离：即将未完成功能的代码隔离在执行路径之外，使之对用户不产生影响 * 快速止血：一旦生产环境出了问题，直接找到对应功能的开关选项，将其设置为 “关闭” 54. 后台服务监测包括 3 个层次，分别是基础监测、应用监测和业务监测 55. 一部分告警信息都会被接收者直接忽略的原因：* 警信息的第一处理人不是自己 * 警信息是一个预备告警，并不需要马上处理 56. 缓解 “告警海洋” 的问题：* 通过关联分析，让监控点离问题发生地更近 * 通过动态阈值设定合理的告警 * 定期梳理告警设置，清理不必要的告警 * 通过人工智能动态解除告警 57. 问题处理是一个学习过 58. 混沌工程是指通过在生产环境中注入 “问题”，从而发现生产环境系统性弱点，并进行系统性改进的方法或手段。其目标是不断提升生产环境面对任何变更的可靠性 59.“目标驱动，从简单问题开始，持续改善” 是整个改进的指导思想 60. 团队上下的目标一致，并且 “让所有人理解这个目标” 是成功关键 61. 发版原则：* 不能让用户感觉到骚扰 * 外发版本的质量要达标 62. 持续改进最重要的就是核心管理层要有持续改进的决心，特别在短期改进没有明显效果的情况下，需要管理团队有坚定的信心，并克服组织惯性对变革的阻力而坚持下去 63. 选择试点团队：* 项目压力适中，有相对富裕的时间 * 团队负责人心态开放，能够承受压力，勇于尝试 * 团队成员有热情 * 业务方有频繁及快速频繁交付的强烈诉求 64. 没有反馈，就是 “风险” 65. 团队产能，回答问题：* 理想情况下，团队每周工作时间是多少？* 理想情况下，每周能完成多少需求？* 实际每周最有可能开发完成多少需求？* 如何处理整个项目开发过程中的线上需求变更？* 系统测试的时间在哪里？* 其他类型的测试（如性能测试和压力测试）怎么办？* 计划时还需要考虑依赖因素？* 项目计划在整体上要加一个缓冲时间，更符合实际？66. 自动化测试金字塔理论：* 自动化单元测试 * 模块自动化测试 * 服务接口自动化测试 * 子服务系统自动化测试 * 大环自动化测试 67. 改进工作：* 业务目标合理 * 项目计划透明（过程透明与结果透明）* 流程 “自定义，自遵守”，团队确保高质量交付 * 定期主动回顾，而非事件驱动的回顾 * 通过细粒度需求组织开发流程 * 持续集成六步提交法 * 适当使用自动化测试，提高质量反馈效率 68. 一致性是效能提升的必经之路 69. 企业所展现的组织能力由 3 个基本要素组成：* 流程机制 * 工具平台 * 个体能力 70. 提升企业整体产品研发胜任力的问题：* 愿不愿意做？* 能不能做？* 会不会做？

从 “软件工程” 这一名词诞生以来，“质量” 和 “效率” 就是它的目标。IT 组织大多在这条路上探寻，从最初的瀑布模型，到 CMMI，很多组织曾经尊其为软件开发过程的 “圣经”。而当 “敏捷运动” 兴起时，他们想要 “做” 敏捷；当听说 “持续交付” 时，他们想要 “做” 持续交付。现在，DevOps 也来了！在各种各样的交流大会里，不断传来 DevOps 胜利的凯歌，各种媒体也在报道它的好处。

《人月神话》一书提到了两个概念：本质复杂性和偶然复杂性。对于软件所要解决的某个具体业务领域的问题，问题本身的复杂性就属于本质复杂性。为解决该问题，组织制订的解决方案自身也会有其本质复杂性。同时，解决方案很可能会由于对问题的理解不够深入而引入一些偏差，这属于偶然复杂性。另外，在整个生产和运营过程中，选用的做事方法不当也会带来偶然复杂性，比如，无效的沟通、质量不合格的返工，以及问题修复不及时等会导致次生问题。