读书笔记-DevOps实践指南

理解时间线

• 这是一本讲理型书籍。
• DevOps能解决开发和运维之间的对抗和怀疑。
• DevOps这类概念将会是历史的必然，因为哪个技术领导不希望自己管理的项目更可靠呢？
• 能稳定且持续可靠，并且还不乏创新，这是如何的令人不得不服？
• 化玄学为科学。
• IT成功已作为企业成功的刚需，DevOps文化持续优化IT技术，所以从企业发展角度来讲DevOps也是刚需了。
• 目前对三步工作法的理解是：加快交付，有事儿干事儿，没事找事儿。都是褒义哈哈哈。
• 好记性不如烂笔头。
• 三个持续：持续集成、持续反馈、持续学习。
• 三个心情：放心、省心、开心

序言

• 要想在现代技术上取得成功，必然需要多方向和多专业领域的协作。

导言:展望 DevOps 新世界

• 病因：开发部门和 IT 运维部门的目标是对立的
  • 开发：对变化莫测的市场做出反应;
  • 运维：为客户提供稳定、可靠和安全的服务。
• 症状：恶性循环三部曲：
  1. 应用程序和基础设施过于复杂、异常脆弱、文档不完备。技术债务越背越多。最脆弱的组件正支撑着最重要的业务系统或者最关键的项目。
  2. 在以上基础上，接更高标准的项目。必然需要解决新的技术难题，需要利用各种捷径以赶上承诺的发布日期，而这又导致了技术债务的增加。
  3. 所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多。包袱越来中，工作质量持续恶化。
• 一个 IT 做得失败的公司，整个公司也都是失败的。
• 即便是技术支出最低的“低科技”行业（诸如能源、冶金、资源开采、汽车和建筑行业），对有效IT管理的依赖程度远远超出了他们的预想。
• 困于这种恶性循环中多年，特别是那些处于开发下游的人，经常感觉被困在一个注定失败的 系统中，无力改变结果。伴随这种无力感的是倦怠感，还有疲劳、愤世嫉俗，甚至是无助和绝望。
• 创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏 性的一件事——我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭 受惩罚、失败或危及生存而不敢做正确的事。这创造了“习得性无助”的环境，人们变得不愿或 无法采取行动来避免未来遇到同样的问题。

第一部分 DevOps介绍

• DevOps “三步工作法”:流动原则、反馈原则、持续学习与实验原则
  • 流动原则:它加速了从开发、运维到交付给客户的流程。
  • 反馈原则:它使我们能建设出更安全可靠的工作体系。
  • 持续学习与实验原则:它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。
• DevOps是把精益原则应用到技术价值流中的结果

第1章 敏捷、持续交付和三步法

• 价值流
  • 部署前置时间
  • 处理时间
  • 返工指标——%C/A（完成时间/精确的总花费时间）

第2章 第一步:流动原则

• 使工作可见：模仿制造业
• 限制在制品数：才能更专注、高效。
• 减小批量大小
• 减少交接次数
• 持续识别和改善约束点
  • 环境搭建：自动化
  • 部署：尽可能自动化
  • 测试的准备和执行：自动化
  • 紧密耦合的架构：创建松散耦合的架构
• 消除价值流中的困境和浪费（浪费是业务兴盛的最大威胁——精益定义）
  • 半成品、额外工序…

第3章 第二步:反馈原则

• 及时发现问题：在技术价值流的每个阶段，建立快速的反馈和前馈回路。提高系统的质量和安全性，创造组织性知识。
• 群策群力，战胜问题获取新知：停止开展任何新工作，直到问题解决。防止由于记忆模糊和情况变化导致的关键信息遗失。鼓励提出问题。
• 在源头保障质量：让所有人都负起了质量责任，而不是仅让一个部门来负责。能自动化就自动化，能自己解决绝再经过别人，比如开发人员直接测试后部署生产环境。
• 为下游工作中心而优化：我们最重要的客户是我们的下游，为他们做好服务。
• 总结：建立快速的反馈机制，对于实现技术价值流中的高质量、可靠性和安全性至关重要。

第4章 第三步:持续学习与实验原则

• 建立学习型组织和安全文化：比如事故发生后进行不指责的回顾，对事故发生的原因和过程做出客观解释，并就优化系统的最佳措施达成一致。
• 将日常工作的改进制度化：通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。
• 把局部发现转化为全局优化：建立全局知识库，如把所有事故报告转化成可搜索的知识库，同时建立起组织级的共享源代码库，方便大家共同成长。
• 在日常工作中注入弹性模式：通过缩短部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时解耦架构，都属于在系统中引入类似张力的做法，也都能够提高开发人员的生产效率及可靠性。另外，还可以通过演习的方式来预演大规模故障，比如关闭某个数据中心。
• 领导层强化学习文化：领导者必须强调解决问题的能力和学习的价值。具体上是设定目标，为团队创造条件，并帮助一线工作者在日常工作中发现并解决问题。

第二部分 从何处开始

• DevOps转型的过程：首先评估组织的价值流，再找到合适的切入点，并制定策略，以组建专门的转型团队、设定改进目标并最终进行推广。

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

• 项目：选择合适的项目切入，绿地项目（新项目）、棕地项目（老项目）
• 团队：从最乐于创新的团队开始
• 并以以上为基础慢慢扩大范围，提高影响力，最终全面扩大DevOps的范围

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

• 确定价值流的所有成员（产品、开发、测试、主管…）
• 绘制价值流图，把必要的工作可视化
• 组建专门的转型团队
  • 团队要素
    • 专门执行 DevOps转型
    • 熟悉多个领域的人
    • 人际良好的人
    • 独立的办公区域
  • 拥有共同的目标：未来 6 个月到 2 年设定可度量的能创造显著价值的目标
  • 保持小跨度的改进计划（具有默认指导性）
  • 非功能性需求预留20%时间：减少技术债务
  • 提高工作的可视化程度
• 用工具强化预期行为：比如腾讯的Coding之类的

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

• 康威定律：系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象也就越明显。
• 组建以市场为导向的团队(“速度优化”)，避免过度职能导向的危害(“成本优化”)
• 使职能导向有效：前提是只要服务团队能够快速(最好是按需)从运维团队获得可靠的帮助。
• 使团队成员都成为通才
• 投资于服务和产品，而非项目：基于产品的投资模式注重组织成绩和客户成果，包括公司营收、客户终身价值，以及客户采 用率，同时尽可能减少付出(如时间和精力、代码行数等)。
• 根据康威定律设定团队边界、保持小规模(“两个比萨原则”）：软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。

第8章 将运维融入日常开发工作

• 创建共享服务，提高开发生产力：创建一套集中式的平台和工具集服务，让所有开发团队都能够通过使用这套平台和服务来提高生产力，例如搭建类生产环境、部署流水线、自动化测试工具、生产环境遥测控制台等。
• 将运维工程师融入服务团队；或者为每个服务团队分派运维联络人
• 邀请运维工程师参加开发团队的会议：每日站会、回顾会议
• 使用看板图展示运维工作

第三部分 第一步:流动的技术实践

• 持续交付的技术实践

第9章 为部署流水线奠定基础

• 按需搭建开发环境、测试环境和生产环境：使用公有云、私有云或其他PaaS平台。使用一组虚拟镜像或容器(例如 Vagrant 和 Docker)搭建环境…
• 应用统一的代码仓库：管理包括且不限于代码、库、环境、配置、静态文件、各种脚本、构建文件、发布说明、需求文档。这样的版本控制还为价值流中的所有人提供了有效的沟通方式，减少信息不对称，并帮助建立和增强信任。
• 使基础设施的重建更容易
  • 依靠自动化配置管理系统：例如 Puppet、Chef。
  • 通过自动化构建机制，创建新的虚拟机或容器，将其部署到生产环境，再销毁或移除旧资源。
  • 运用不可变基础设施：生产环境不再允许任何手动操作。唯一途径是把变更先检入版本控制系统，然后从头开始重新构建代码和环境。这样做杜绝了差异蔓 延到生产环境中的可能性。
  • 此外，必须保证预生产环境是最新的
• 运行在类生产环境里才算“完成”：“完成”是指不仅实现了功能正确的代码，而且在每个迭代周期结束时，已经在类生产环境中集成和测试了可工作和可交付的代码。
• 小结：构建从开发到运维的快速工作流，需要确保任何人都能按需获得类生产环境。此外，通过把所有生产工件纳入版本控制系统，我们有了“唯一的事实来源”，这使我们能 够用快速、可重复和文档化的方式重新搭建整个生产环境，并在运维工作中采用和开发工作一致的实践。

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

• 对代码和环境做持续构建、测试和集成（CI+）：通过工具来搭建部署流水线，如Jenkins
• 构建快速可靠的自动化测试套件：缩短反馈时间，降低引入错误、返工等风险
  • 单元测试（测试率80%）：独立测试每个方法、类或函数（通常会使用打桩stub out的方式，隔离数据库和其他外部依赖）。目的是证明应用的某一部分符合程序员的预期
  • 验收测试：整体测试应用，确保各个功能模块按照设计正常工作。目的则是证明应用能满足客户的愿望，而不仅仅是符合程序员的预期。
  • 集成测试：能与生产环境中的其他应用和服务正确地交互，而不再调用打桩的接口。
  • 在自动化测试中尽早发现错误（测试金字塔）
    • 当验收测试或集成测试（上方）发现一个错误，就应该编写相应的单元测试（下方），以便更快、更早、更廉价地识别这个错误
  • 尽可能并行地快速执行测试：必要时进行并行测试
  • 先编写自动化测试：测试驱动开发(Test-Driven Development，TDD)和验收测试驱动开发(Acceptance Test-Driven Development，ATDD)
    • 在对系统做任何变更时，都要先编写一个自动化测试用例，执行并确保测试失败，然后再编写实现功能的代码，并且让代码通过测试。
  • 尽量将手动测试自动化
    • 自动化测试的目的是尽可能多地发现代码错误，并且减少对手动测试的依赖。
    • 不要单纯地将所有手动测试自动化，而是少量可靠的自动化测试
  • 在测试套件中集成性能测试：目标是验证整个应用栈(代码、数据库、存储、网络、虚拟化等)的性能，并把它作为部署流水线的一部分
    • 可以将能够并行执行的验收测试作为性能测试的基础，如“搜索”和“结账”是两个高价值功能。
    • 偏差不超过 2%
  • 在测试套件中集成非功能性需求测试：安全性、性能和可用性，包括所使用的应用、数据库和软件库等;编程语言的解释器和编译器等;操作系统(例如启用审核日志记录等);所有依赖项。
• 在部署流水线失败时拉下安灯绳：若致自动化测试失败，大家都要竭尽全力地将系统恢复到绿色状态。

第11章 应用和实践持续集成

• 小批量开发与大批量合并
  • 提高个人生产力：所有人都在自己的分支上工作。代码合并将是一场噩梦。
  • 提高团队生产力：所有人都在同一个区域里工作。任何一次提交都有可能破坏整个项目。
• 应用基于主干的开发实践：解决大批量合并问题的对策是，应用持续集成和基于主干的开发实践，让每个开发人员每天都至少向主干提交一次代码。
  • 可以针对整个软件系统执行所有的自动化测试，出问题也能及时收到告警信息
  • 每个人对系统都有了更好的理解，并且都了解部署流水线的状态，而且能在出现问题时互相帮助
  • 严格点的或需要的，可应用主干/分支发布模型——每两周新建一个专用的发布分支，在非紧急情况下，该分支不允许任何代码提交。

第12章 自动化和低风险发布

• 自动化部署流程
  • 记录目前的部署流程，然后尽可能地简化和自动化手动步骤（举例了10点…省略）
  • 部署流水线需求：用相同的方式处理所有环境的部署、对部署执行冒烟测试、维持环境的一致性
  • 应用自动化的自助式部署：包括构建、测试、部署不需要任何手动操作或工作交接
  • 在部署流水线中集成代码部署：提出多点要求…省略
• 将部署与发布解耦
  • 基于环境的发布模式：蓝绿部署、金丝雀发布和集群免疫系统
    • 处理数据库变更：创建两个数据库(即蓝数据库和绿数据库)；将数据库变更与应用变更解耦（扩展与收缩模式）
  • 基于应用的发布模式：对应用进行修改，从而通过细微的配置变更，选择性地发布或开放应用特性。
  • 基于应用的发布模式更安全：
    • 实现特性开关：优势是，轻松地回滚、缓解性能压力、采用面向服务架构提高恢复能力。
    • 实现黑启动：实现特性开关后可实现，正式发布之前偷偷测试。
• 持续交付和持续部署实践的调查
  • 持续交付：指所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常的工作时段里按需进行一键式发布。开发人员在引入任何回归错误时(包括缺陷、性能问题、安全问题、可用性问题等)，都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保持主干始终处于可部署状态。
  • 持续部署：指在持续交付的基础上，由开发人员或运维人员自助式地定期向生产环境部署优质的构建版本，这通常意味着每天每人至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。
  • 说明：持续交付是持续部署的前提条件，大多数团队都采用持续交付实践，但也有一些团队选择持续部署。
• 小结：发布和部署不一定是高风险、状况百出的工作，也不一定需要几十个甚至几百个工程师加班加点地完成。相反，它们可以成为日常工作的一部分。

第13章 降低发布风险的架构

• 能提高生产力、可测试性和安全性的架构：接口定义清晰、松耦合、小团队、面向服务
• 架构原型:单体架构与微服务：根据当下组织需求选用，各有好处
• 安全地演进企业架构
  • 绞杀者应用模式：所有服务都通过版本化API访问，也称为版本化服务或不可变服务，然后逐步迁移到新应用。

第四部分 第二步 :反馈的技术实践

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

• 建设集中式监控架构

  事件路由器 -------> 目的地存储、图形化告警
      ^
      |
      |    <------- [业务逻辑]
     事件
      |
     日志   <------- [应用程序]
      |
     指标
      |    <------- [操作系统]
      
      [监       控       框       架]

• 建立生产环境的应用程序日志遥测：注意运用日志级别，DEBUG、INFO、ERROR…

  • 选择正确的日志记录级别：”在确定一条消息应该是‘错误’还是‘警 告’时，设想一下在凌晨 4 点被叫起来处理‘错误’吧”
  • 潜在的重大应用事件应该被记录：认证/授权的结果、系统和数据的访问等等多条
• 使用遥测指导问题的解决：如监控系统中有什么证据表明了问题实际上正在发生?等等多条
• 将建立生产遥测融入日常工作：运用简单的度量库技术，如StatsD+Graphite/Grafana将度量数据呈现在图形和仪表板上。
• 建立自助访问的遥测和信息辐射器：团队放置在一个非常显眼位置上，让所有团队成员以及路过的人都可以快速浏览最新信息:自动化测试次数、速率、事故报告、持续集成状态等。
  • 团队成员中传播着责任感，同时也积极地展示出以下价值观:1.团队对观察者(客户、利益相关者等)毫无隐藏;2.团队对自己无所隐藏，他们承认并直面问题。
• 发现和填补遥测的盲区：
  • 度量指标级别
    • 业务级别，如订单量；
    • 应用程序级别，如事务处理时间；
    • 基础架构级别(如数据库、操作系统、网络、存储)，如Web 服务器吞吐量；
    • 客户端软件级别(如客户端浏览器上的 JavaScript、移动应用程序)，如出错和崩溃；
    • 部署流水线级别，如构建流水线状态(例如:各种自动化测试套件的红色或绿色)、变更部署前置时间；
  • 应用程序和业务度量指标：不仅要确保产生的遥测能够反映应用程序的健康状况(例如内存使用、事务计数等)，还要度量目前组织的业务目标的实现情况(例如用户增长数、用户 登录次数、用户会话时长、活跃用户比例、某些特性的使用频率，等等)。
  • 基础架构度量指标：能够快速定位问题是不是由基础架构引起的。此外，还能够定位到究竟是基础架构的哪个组件引发了问题(例如，数据库、操作 系统、存储、网络等)。
  • 显示叠加的指标组合：可观察彼此之间的影响、周期，更快找到和解决问题。
• 小结：使用遥测的好处有：提前发现解决问题、快速清晰的定位问题以便得到快速有效的解决；此外的好处还有让客户更加满意、减轻工作压力和降低倦怠程度，让工作变快乐和更有成就感。

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

• 用均值和标准差识别潜在问题：需要注重智能化，避免告警疲劳
• 异常状态的处理和告警：分析历史数据，并预测
  • 应用级别——网页加载时间正在增加等;
  • 操作系统级别——服务器闲置内存不足、磁盘空间不足等;
  • 数据库级别——数据库事务处理时间超出正常值等;
  • 网络级别——负载均衡器背后运行的服务器数量下降等。
• 非高斯分布遥测数据的问题：如某些呈周期性变化的数据（服务器算力预测和扩展）
• 应用异常检测技术（偏向专业，了解）：这些技术广泛地分类为异常检测，其通常的定义是“搜索不符合预期模式的数据条目或事件”

第16章 应用反馈实现安全部署

• 通过遥测使部署更安全
• 开发和运维共同承担值班工作：让开发人员、开发经理和架构师轮流和运维团队共同值班。运维人员不再独自、孤立地解决生产环境中的代码缺陷;相反，所有人都会帮忙在修复生产环境缺陷和开发新功能之间实现平衡。
• 让开发人员跟踪工作对下游的影响
• 让开发人员自行管理生产服务：
  • 建立服务发布指南：缺陷计数和严重性、告警的类型/频率、系统架构松耦合的程度等
  • 谷歌的HRR和LRR实践
    • “交接就绪审核”(Hand-off Readiness Review，HRR)
    • “上线就绪审核”(Launch Readiness Review，LRR)
• 小结：承上启下，融合发展：让开发管理服务，促使开发转换到运维工作视角，然后在LRR和HRR的指导下进行，这不仅使服务转换变得更容易、更可预测，而且有助于在上游与下游工作中心之间建立同理心。

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

• A/B测试：A/B测试技术是在直效营销中率先使用的，它是两大类营销策略之一。另一类称为大众营销或品牌营销。
• 在功能测试中集成A/B测试：在一个网站上，给访问者随机地展示一个页面的两个版本之一，基于对这两组用户后续行为的统计分析， 可以判断这两者的结果是否存在显著差异，从而找出实验组(例如，功能的变化、设计元素、背景颜色)和结果(例如，转化率、平均订单大小)之间的因果联系。
• 在发布中集成A/B测试：通过在生产环境中快速轻松地按需部署，利用特性开关将软件的多个版本同时交付给多个用户群，可以进行快速、迭代的 A/B 测试。
• 在功能规划中集成A/B测试：必须确保产品经理将每个功能都视为一个假设，并基于在生产环境中实际的用户实验结果来证明或反驳这些假设。如果没有达到预期，就用替代方案修改工作路线图，并最终实现业务成果。
• 小结：通过以上科学的产品开发方式，能够安全、轻松地进行用户实验，从而让员工发挥出创造力和创新能力，并进行组织性学习。

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

• 变更审批流程的危险：在低信任度的指挥与控制型文化环境中，这些变更控制和测试实践反而会增加问题复发的几率，甚至造成更严重的后果。
• “过度控制变更”的潜在危险：
  • 大量额外的步骤和审批，增加了部署过程的阻力
  • 增加了批量尺寸和部署的前置时间，降低了收获成功的工作成果的可能性
  • 降低了反馈速度
• 变更的协调和排程：对变更进行排程和序列化，确保它们不会相互干扰。
• 变更的同行评审
  • 代码评审的指导原则
    • 提交到主干以前，必须要有同行来评审他们的变更
    • 每个人都应该持续关注其他成员的提交活动
    • 定义哪些变更属于高风险的变更
    • 变更尺寸要小，否则拆为多次
  • 代码评审形式：结对编程、“肩并肩”等
  • 为了避免形式主义的评审，可能还要检查一下代码评审的统计数据，从而确定有多少个代码提交通过了评审，有多少个没有通过，也可以对特定的代码评审进行抽样和检查。
• 人工测试和变更冻结的潜在危害：不要忘了把持续测试融入日常工作
• 利用结对编程改进代码变更：
  • 方式：一名工程师扮演驾驶者角色，他是实际上编写代码的人，而另一名工 程师则作为导航员、观察者或督导者。
  • 作用：两名软件开发工程师同时在同一台工作站上工作的开发方法，这种方式可以平滑的将代码审查融入日常工作，培养审查习惯，因为两个人会不可避免的进行深度沟通。
  • 评估 Pull Request 的有效性：必须足够详细地说明变更的原因、如何做的变更，以及任何已识别的风险和应对措施。
• 消除官僚流程
• 小结：创造条件，让变更实施者完全掌控自己的变更质量，这是我们努力建设的高度信任的、生成性文化的重要组成部分。

第五部分 第三步 :持续学习与实验的技术实践

第19章 将学习融入日常工作

• 建立公正和学习的文化：不要让人产生恐惧，阻碍弄清事情产生原因的真相，和从中应该被学习到的知识和经验
• 举行不指责的事后分析会议：对事不对人的事后分析，这里提出构建时间表、说明自己如何导致了故障等多点会议中应该做的事
  • 应该明确禁止使用“原来应该”或“原本可以”等词语，因为它们是反事实的陈述
  • 必须预留足够的时间，开展头脑风暴和决定应对措施，一旦确定了对策，就必须排定工作的优先次序，指定负责人和实施时间表。
• 尽可能广泛地公开事后分析会议结果：最好放到一个都看得到的地方，比如建立一个论坛
• 降低事故容忍度，寻找更弱的故障信号
• 重新定义失败，鼓励评估风险：创新（技术和文化）是必要的，有创新就有失败，我们应该接受它。
• 在生产环境注入故障来恢复和学习：捣乱猴是真的牛批。
• 创建故障演练日：通过在受控的情况下引入故障，暴露系统中的潜在缺陷。
• 小结：组织唯一的可持续竞争优势就是比对手更快的学习能力。

第20章 将局部经验转化为全局改进

• 使用聊天室和聊天机器人自动积累组织知识：amazing
• 软件中便于重用的自动化、标准化流程：将专业知识组织化自动化，而不是写在没人能找到的word文档里
• 创建全组织共享的单一源代码库：或另一种维护程序库的方法如nexus等
• 运用自动化测试记录和交流实践来传播知识：TDD，在编写代码之前编写自动化测试，好处是测试几乎 全部自动化。这个原则将测试套件变成活跃、保持更新的系统规范。
• 通过确定非功能性需求来设计运维：提出对各种应用和环境进行充分的遥测、轻松搜索和理解各种服务日志信息的能力、准确跟踪依赖关系的能力等多个方向。
• 把可重用的运维用户故事纳入开发：把能自动的自动化，把不能自动的拉好清单步骤，处理多了后分析共性更好的优化流程。
• 确保技术选型有助于实现组织目标：识别排除有下列特征的技术，才可以专注于最有助于实现组织全局目标的基础设施
  • 阻止或减慢了工作流;
  • 造成了不成比例的大量计划外工作;
  • 产生了不成比例的大量支持请求;
  • 与我们所需的架构结果(例如吞吐量、稳定性、安全性、可靠性和业务连续性)完全不一致。
• 小结：通过上述方法的施展，能提升开发和运维团队，更能提升整个组织。

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

• 偿还技术债务的制度化惯例：留20%时间改进工作而不是产品和市场的创新。
• 让所有人教学相长：创造相互学习和相互教导的机会。如组织内部DevOpsDays，或参加外部会议。
• 传播实践的内部顾问和教练：成立内部的教练和咨询组织
• 小结：如何建立一系列惯例，来帮助强化终身学习以及重视在日常工作中改进日常工作的文化？预留偿还技术债务的时间；创建论坛；支持辅导、咨询；

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

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

• 将安全集成到开发迭代的演示中：在每次开发间隔的最后，邀请信息安全人员参加产品演示，使他们能够在组织目标背景下更好地理解开发团队的目标，观察开发团队的实施和构建过程，并在项目的最早期阶段就提出指导和反馈，从而为问题修复留出更多的时间和自由度。
• 将安全集成到缺陷跟踪和事后分析会议、共享源代码库及共享服务、部署流水线、生产环境遥测
• 保证应用程序的安全性：如静态分析、动态分析、依赖组件扫描等
• 确保软件供应链的安全：如关注第三方组件或库的漏洞
• 确保环境的安全
• 在应用程序中建立安全遥测系统：检测如成功和不成功的用户登录、用户密码重置等事件
• 在环境中建立安全遥测系统：检测如操作系统的变更、安全组的变更等事件

第23章 保护部署流水线

• 将安全和合规性集成到变更批准流程中
• 将大量低风险变更重新归类为标准变更
• 如何处理常规变更：指出变更的原因(例如，提供指向特性、缺陷或事件的链接)，变更影响到的人员，以及变更的内容。让组织人员放心，最终使其认同能将自动化变更安全地归类为标准变更。
• 减少对职责分离的依赖：选择结对编程、持续 检查代码签入和代码审查等，它们能为工作质量提供必要的保障。而不是减少反馈、降低学习的能力。
• 确保为审计人员和合规人员留存文档和证据：与相关人员合作，通过迭代完善其需要的合规性证据，创建提供数据的替代方法，用来清楚地向审计人员展示控制手段的运行方式和有效性。
• 总结：安全问题可能会迟到，但一定不会缺席，所以要一步步融入价值流。

其他理解

和传统模式对比，技术上、员工上、业务价值上、经济上

行为	传统	DevOps
程序员心态	经常崩溃、无助	满足幸福
技术总监心态	紧绷	满意轻松
运维心态	易怒、毛躁	满面春风
部署时间	周五的午夜开始	随时随地
部署难度	鏖战整个周末	按一下回车
技术债务	越堆越多	就地正法
出错反馈时长	数天、数月（玄学）	几分钟，取决于自动化测试时间
把公司推荐给朋友的可能性	1	2.2倍
生产力、市场份额以及营业目标	1	大约 2 倍以上
代码和变更部署次数	1	频繁 30 倍
生产环境部署	1	变更成功率高 60 倍
平均服务恢复时间	1	快 168 倍
代码和变更部署前置时间	1	快 200 倍
吞吐量指标	低	高
可靠性指标	低	高
组织性能指标	低	高
市值增长	1	3 年内高出 50%
安全问题修复上的时间	1	低50%