What

TDD(Test-Driven Development)是敏捷开发中的一项核心实践和技术、是一种方法论。思路是通过测试来推进整个开发的进行。表现为测试代码优先于业务代码。UTDD呢，其实U就是unit，一般习惯直接叫成TDD。

从长远角度来看，他加快了组织价值流输出的质量、速度、稳定性，所以我想他理应纳入DevOps技能范凑。

Why

为什么要用到他呢？为什么说他加快了组织价值流输出呢？这就要说说他的优点了：

1. 自解性：测试代码即文档，新接触代码的开发人员通过阅读测试代码即可充分了解业务。
2. 健壮性：业务建立在一个个单元测试的保护之下，规避了大批bug。
3. 正确性：修改已有代码不再烫手，测试带来了正确性保护，这将在重构或者维护时体现。
4. 改进API：测试自然的让开发人员变得从客户端角度编写可测试的OO代码，驱动了API的设计。

以上的优点都在一定程度上提升组织的单位价值输出。

另外，他的引入也是有代价和风险的：

1. 开发成本：开发人员需要编写测试代码。
2. 维护成本：开发人员需要维护测试代码。
3. 环境搭建：测试环境的建立成本。

所以，对于组织来说它的引入则是一把双刃剑，要看用在什么场景以及用到什么程度。成本大于收益那就不要采用了。

How

一、学TDD前该知道的

• 单元测试

  单元测试应该是面向业务的，而不是面向代码的，编写单元测试时应该将一个业务场景当做一个被测试的单元。单元测试应遵循FIRST原则，即快（不依赖外部）、可重复、隔离（独立性）、清晰的成功或失败、频繁且小规模。测试方法命名采用ruby命名法should_xxx_xxx()，内容应用Given-When-Then模式，When时注意运用CQS命令查询分离原则。框架上，主要有做测试的Junit，做验证的AssertJ，做模拟的Mockito。

• 面向对象

  业务代码编写遵守SOLID六大原则，单一职责原则、开闭原则…..等。简单来说要记住迪米特法则，即不要和陌生人说话，以及信息专家模式，以减少外部的数据访问权，然后就是注意组合优先，无差异无继承。

• 重构

  重构即在保证原有代码功能的前提下，去除代码坏味道，进行的一种代码的优化操作。Kent Beck简单设计原则能很好的指导重构：

  1. 通过所有测试
  2. 减少重复代码
  3. 表达程序员的意图
  4. 尽可能减少方法的数量
  

  重构的运用需要注意重构策略的选择和考虑引入Code Review。另外，重构可以且需要随时进行。

二、TDD

TDD核心可看做一个闭环：RED -> GREEN -> REFACTOR，即运行一个失败的测试 -> 让测试通过 -> 及时重构代码。

TDD还包括以下知识：

1. 需求分析

   TDD遵循简单设计，而这个简单设计不是不设计或少设计，而是清晰的设计。在进行单元测试编写之前，开发人员要用足够的时间去弄清需求，然后再做任务分解和子任务分解。任务分解是对用户故事的拆解，子任务分解是对任务的进一步细分拆解，最终任务和子任务能达到：

   1. 任何子任务均可通过测试来验收
   2. 所有任务的集合恰好等价于原问题域
   3. 子任务之间无交集

   任务之间保持递进原则。

2. TDD的三大支柱

   1. 一次只写一个刚好失败的测试
   2. 不写任何产品代码，除非他刚好能让失败的测试通过
   3. 只在测试全部通过的前提下重构或开始新的功能

3. 编写测试上，涵盖单元测试需要注重的点，比如FIRST原则等。

Last

最后，感谢测试驱动开发训练营张逸老师的倾囊相授！

• 区块链
• 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章 建立能发现并解决问题的遥测系统

• 建设集中式监控架构

  1 2 3 4 5 6 7 8 9 10 11 12

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

• 建立生产环境的应用程序日志遥测：注意运用日志级别，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%

最近在看一本书，上面讲到人需要有目标有蓝图有计划，还要敢于”做大梦“。

目标这些词语听得多了，没啥感觉。但做大梦一词让我产生了想象。

我想啊想，想了一两天，最后发现我脑中所能和梦想扯上关系的，都是些浅显的兴趣爱好、和一些比较消磨人的欲望。

于是，**我发现我莫得梦想！

这实在让我有点懊恼。

我去知乎上搜索”没有梦想“，在一个问题里，我看到了这些：

• 德善和父亲关于梦想的对话
• 一段寻找梦想的真实经历
• 一个寻找梦想多年的朋友

这不禁让我怀疑，拥有梦想其实是一件幸运且奢侈的事情。

我的梦想是什么？

我不知道，但我想是这个方向：

做快乐的自己，并传递他人。

有梦想才能有蓝图，有蓝图才会有目标，有目标才可有计划，有计划才能更清晰实现。

第一章 把握人际交往的关键

天底下只有一种方法可以影响他人，那就是提出他们的需求，并让他们知道怎样去获得。

为了要得到友谊和情爱，我们必须先认清”施比受更有福”

只是，我们把次序弄错了————我们是希望别人先来喜欢我们，去不曾想到要如何才能让人喜欢。

获得友谊的全部秘诀也在于不要担心结果，不要在意别人是否会喜欢我们，现在就着手去做所有能激发爱和友谊的事。

如果没有好话可说，那就什么也别说。

莫逞口舌之快而伤害别人，留口德才能广结善缘。

没有人能孤独的发现他自己，别人总是他的发现者。

错过与一个胜过我们自己的人相交往的机会，实在是一个很大的不幸，因为我们常能从这个人身上得到许多益处。

社交过程中，不要用选择朋友甚至是知心朋友的条件来作标准。新朋友的见解即使与你大相径庭、迥然不同，也是一大幸事，这可以补充、丰富你的思想。

人类本质中最殷切的需求是：渴望被肯定。

让对方有备受重视的感觉，会让你更容易得到友谊，就算不能，你也能得到助人的快乐。

莫与小人较劲：敌人并不存在，只是由于某种原因才出现。

一种正确的人生观是：你不要欺负人，也不可随便让别人踩在你头上。

熟悉的朋友平时没事也多联系，不然有事的时候才联系就显得突兀。

该告别时就告别。

第二章 把别人吸引到身边来

有意识的尽量拿出最好的仪表，注意干净整洁，竭力保持自尊和真诚，这样才能帮助你渡过重重难关，带给你尊严、力量和美丽，使你赢得别人的尊敬和钦佩。

了解与你对话者的生活，并用他们最感兴趣的内容来打动他们。

称赞对方希望被称赞的事物。

使事实更生动、有趣而戏剧化得表现出来，才能有效的吸引人们的注意力。

第三章 不露痕迹，改变他人

第四章 如何是交谈变得更愉快

你可能有理，但要在争论中改变别人的主意，一切都是徒劳。

换位思考。

除了吸引对方的兴趣，还要多引导对方说话。

争取让对方说是。

鼓励对方多说话。

词语上，强调我们，而不是你、我的对立。

遇到分歧，要先明确对方真正述求的主题：到底是情绪出了问题（不满、牢骚、愤怒、无理取闹），或是仅想吸引注意力，或者是对方自我的困惑与矛盾。

分歧是探索对方需求的时候，而不是自我表达的时候。

表达诚意、保持礼貌、维护尊严、营造愉快的氛围才可以更好更人性化的进行互动。

求同存异：人与人之间，由于观点不同、信仰各异、性格有别等等原因，存在分歧，应该是完全正常的事情。遇到这种情况，必须透过一方或双方的让步，取得大的原则、方向上的基本一致（即求同），在枝节问题上不纠结（即存异），达到互谅互惠的目的。

第五章 做好一生的规划

有目标：心中拥有目标，便会使自己不会太留意与之不相关的烦恼，不会与一般不相关的小麻烦计较，这会使你变得豁达、开朗。

有规划：只有你知道需要什么，这样才能直达目标。

什么是目标：能激起强烈向往的事物。

什么是蓝图：目标的难度所做的时间上的编排。

什么是计划：为达成目标而事先进行的分析、推演。

一月 2020年01月28日

• 读书笔记 （1/20） 零到壹，好起来了
• 技术博客 （0/20） 这里有20颗定心丸我还没碰过，虽然不知道疗效，但一定有效。
• 改变小事 （1） 有序进行中。在特殊时期，加上最近坐得有点老火，那就加个方便锻炼身体的吧，每天一套。在家健身有些什么简单有效的方式？
• 分析大事 （0） 目前还是全图黑，前方注意插眼。看找个太阳天，在阳光下客观分析下。

二月 2020年02月29日（没想到吧？哈哈29号）

• 读书笔记 （2/20） 整挺好，这本DevOps实践指南勾起了我无限遐想！
• 技术博客 （0/20） 开始接触一个新的练手项目，但还没有博客输出。
• 改变小事 （3） 有序进行中。最近还是坐得有点老火，那就再来个锻炼套餐吧。然后睡眠还是没更上，得想下办法。
• 分析大事 （1） done!
• 探索系列 （0/3） 有一套才可留一手。

三月 2020年04月05日

• 读书笔记 （2/20）do
• 技术博客 （0/20）do
• 改变小事 （7） 清早起来读一读半年计划
• 探索系列 （3/5） do
• 总结：1. 太放松了难以收回 2. 多喝鸡汤，补充力量

四月 2020年04月29日

• 读书笔记 （2/20）do
• 技术博客 （0/20）do
• 改变小事 （7） 清早起来读一读半年计划
• 探索系列 （3/5） do
• 总结：每天都写出来，推进它就完事了

这本书是怎么知道的呢？是19年初我在网上逛的时候看到李笑来的那本公开的’和时间做朋友’，期间我竟然发现他的文风啊和我以前写作文的时候很像?

比如海量的运用排比句，对比句，（）和””。。。当时我就产生兴趣了，因为我深刻的怀疑我和他是有一定共同点的。

比如混，因为我用这些排比引号啥的是由于读书的时候语文作文有最低字数限制，这样写比较容易筹够字数。。。

但就如书中写的那句话”无论看起来多么荒谬的现象，背后都有一定的道理”。

所以，我认为他的书值得一读，因为我们的思考方式有大概率是有相似性的，他思考的东西我是有较高效率’内化’的。

全书里面有几个大的概念：

• 思维：元认知、一把叫最重要的刀、行动中思考、个人的操作系统
• 学习：复利性和长期、重复和应用、认知和更深更高的认知、通识类知识
• 社交：交友建议
• 心态：乐观、不要抱怨
• 投资：复利性和长期、风险、成长率

“人所拥有的任何东西，都可以被剥夺，唯独人性最后的自由————也就是在任何境遇中选择一己态度和生活方式的自由——不能被剥夺。（维克多·弗兰克）” 21节

学习内因：”正确的刚需是一切驱动力的源头。” 21节

决定价格的最重要因数是需求，顾挑最被需要的事情做最有价值。24节

‘和自己没关系’，是很可怕的自证预言。25节

学习外因：耳濡目染。其可以激发情绪（镜像神经元），进而促进模仿（学习）。26节

学习能力的三个阶段：1.能学会有人手把手教授的知识。2.能学会书本上的知识。3.能学会书本上没有的知识。28节

《Beyond Fellings: A Guide to Critical Thinking》，这本书作者推荐。28节

万能钥匙：当你遇到被锁上的锁头时——应该去别的地方找钥匙。29节

当一件事被赋予重大意义的时候，这件事就不需要’坚持’。30节

至少习得（熟练、精通）一项技能，其实是所有人在任何技能习得道路上的起点，也是他们能够到达终点的根本————有经验、有能力、有资格’心存希望’。31节

资本三要素：本金、时限、操作方式（背后的智慧）。33节

不受限于世俗的条框，人至践则无敌。34节

（实践：选三两个股票每月定时查看记录价格，算出相对最初1美元的涨跌幅）35节

复利是财富领域最重要的概念。36节

特立独行且正确，是把事情做到最绝的要素。36节

《Fooled by Randomness》,这本书作者推荐。作者纳西姆·尼古拉斯·塔勒布也许是地球上最聪明的人之一。36节

人生无常，未来不可确定，故要减少自身的风险，永远不要all in。36节

后发优势可能更厉害。38节

是不是早不重要，关键是是不是对，更重要的是看是不是长期对。38节

随机漫步理论，说的是最好做长线。39节

人生规划：经济有周期，人也有周期，故人生规划只能自己来，因为自己最了解自己。40节

正确的选择成长性公司，并对其进行定投，是一种简单有效的投资方式。41节

（实践+：为列表中股票加上定投策略。思考和探索成长型公司的属性与特质。可加入新公司。）41节

添加必要，且不遗漏必要的条件，可提高选择的质量。42节

不能不断成长的生意，谈不上是创业。43节

在风险投资者眼里，’成长率’最重要最必要。43节

长期复利捷径：更强的个人能力、更正确的策略、在投资之外也有收入。44节

复杂二分法。45节

年轻人要重视赚钱的能力，若是赚到很多钱，你很可能会变得更有理想、更有报复、更讲情怀、变成更讲究格调的人。（经济结构决定上下层建筑）45节

长期来说，对自己有用的就是知识。多数人只看重短期有用的知识，而选择性忽略了很多长期有用的知识。所以就算到了中年也不知道当初错在哪里。46节

上学只是一种行为，而学习则是一种技能，读书是一种自我成长。46节

通识类知识：有些知识能繁衍出来更多的知识，于是他们更高级，也更有价值。比如英语、概率论、编程。46节

融汇贯通就是两个看上去无关的知识产生了意外的联系，并且这个联系还足够有用和重要。46节

一把刀：什么最重要？可用来做任何选择。47节

人灵魂的三重本质：一个车手，驾着一辆有一黑一白两匹带着翅膀的马拉着的战车。黑马代表欲望灵魂，白马代表意志灵魂，骑手代表理性灵魂，驾驭这两匹神马勇往直前。————苏格拉底。48节

情绪是理智的快捷方式，直觉是情绪的快捷方式。（理（情（直觉）绪）智）这是人脑结构图，哈哈哈，里面的更优先。48节

执行力差的原因：不是另外一个物种。不是另外一个物种的原因：重复与应用的次数不够多。48节

光是知道（认知）并不起作用，真正起作用的是比别人更有高度的认知，或者比别人更有深度的认知。49节

对老朋友花时间。50节

交新朋友看亮点，一看这人不能太’黑’，二看这人对老婆好不。50节

大牛是那种’内视’的人：他们看到的不是外界，而是他们在自己的内心里构造的那个世界，与那些自以为是的人不同的是，他们很在意自己的构造是不是合理。50节

只用嘴道歉的人不值得交往，用行动道歉道歉的人遇到一个珍惜一个。50节

所谓的幸福感就是你与你所在世界之间的强关联。50节

人微言轻，默默成长，是为佳策。尾记

多学习、多运动人自然的开心了。（多巴胺高于平均水平）尾记

按照计划周来说，今天是2020年第一周的最后一天。趁着这一周还未过完，赶紧来把2020年计划安排了。

2019要我来形容就是：幸福又痛苦的一年。第一次滑雪成功，第一次看见海的那刻，第一次看演唱会，第一次出国哈哈。。痛苦的就是自己似乎在冥冥之中抵触这些，让我放不开双臂去拥抱这些美好。

叔本华说：”一切幸福都是虚妄不实的，唯有痛苦才是真实的”。那我可能是痛苦有点多了，多到失去了感受幸福的能力？

李笑来说过：”做正确的事情，比把事情做正确更好”。客观的视角决定价值观，价值观决定选择，选择又决定了人生。

2020年的计划，需要注意从客观出发，选择第一。而现在的我陷入的境地是：痛苦如藤蔓，缠住我迎接美好的双手，能力如潭水，越是看不清越是粘着你，让你步履维艰。

那我想，减少痛苦，重视成长，不抱怨。可以是我2020年的一个基本出发点。

• 读书并写笔记20篇
• 学习devops，并写博客20篇
• 改变做一些小事的方式，连续做21天算完成
• 分析大事，拆分他们再解决
• 每月27号，客观总结并建议

附加奖励金，用于娱乐基金，每件事奖励100元，每月底一算。

最后，预测一下2020我会有以下记录：2020读书笔记（01）：XXX devops学习（01）：在XXX部署XXX 2020小事探险 2020大事分析（私密）

19年回顾-时间线

• 1月 建立’NEW BALANCE’计划，企图让自己找到生活中的平衡，心想不管怎样不能败在战略上。
  

• 2月 患上重度起床困难症。开启数月的成都地区刷美食之旅。
  

• 3月 年初计划已经完全乱套，情况堪忧。西岭雪山之旅。
  

• 4月 已购票的b哥334被取消。川西之旅。拍了我的日常vlog。
  

• 5月 浏览完Think In Java。看了陈老师演唱会，结束还下了暴雨。
  

• 6月 开始持续没多长的夜晚慢跑。较为深刻的认识到”报复性熬夜”。（下图不是我啊哈哈）
  

• 7月 公司出状况，工作暂停。青城山之旅。
  

• 8月 进入数月的报复性娱乐，能感觉到自己被自己摧残了。看了请回答1988，泪目n次。乐山大佛之旅。
  
  

• 9月 苏梅之旅，差点遇见周董一家。手机被海水淹了。买了新手机。
  
  

• 10月 买了HomePod。买了ipad，并用其开始新的探索。去了重庆，牛肉面好吃味道足。
  
  

• 11月 进行正式的’正确的100次’实验，主要提出了更好的生活习惯，成功，有中变好了一些的感觉。
  

• 12月 跟着进行了’正确的200次’实验，成功，真实的感觉变好了点。收获实验成功的3k经费。
  

19年总结

19年计划执行情况：4/7，不及格。完成度就更不说了。。。回过头来看看这个计划，我只看到了几个大字：假大空。

19年应该是我有生之年玩出新高度的一年吧，往上去雪山上滑过雪，往下去海岛浮过潜，🌶🔟💉💧🐂🍺。其实渐渐的，在玩乐中也更知道自己想要的是什么，缺的是什么。

• 机器人
• AI
• 量子计算
• 生物科技（DNA）
• 物联网（全自动汽车、AR）
• 区块链
• 石墨烯
• 3D打印
• 可控核聚变（文明过滤器，手动滑稽）

文明等级

• I、能利用所在行星的全部能源（人类0.7）
• II、能利用所在恒星的全部能源
• III、能利用所在星系的全部能源

费米悖论的相关猜测

高等（II、III型文明）文明不存在假说

1. 稀有地球假说，条件极为苛刻
2. 我们是第一批智慧生命
3. 大过滤器，一个人类不可预知或无法理解的天灾人祸

高等（II、III型文明）文明存在假说

1. 他们来过，我们不知道
2. 他们正在来，我们不知道
3. 黑暗森林，他们存在，但避免暴露，我们不知道
4. 存在一个超级文明，会消灭所有对其有威胁的文明，但我们还没有触发这个警报
5. 高等文明已经超脱于物质而存在了，我们无法探测到
6. 高等文明纬度升级了
7. 动物园理论，我们被圈养了
8. 虚拟现实说，我们只是数字化但
9. 天文馆理论，被高等文明隔离了