1. 变化就是软件的特性

1.1. 变化保证天天有，存活保障无处寻

1.2. 非每一款软件每天都需要进行数据修改

1.3. 某些软件确实没有进行快速变化和适应的潜力

1.3.1. 航空电子设备和植入式医疗设备所用的软件的每一次发布都要经过昂贵和耗时的认证

1.4. 变化（适应性）从发布那一刻就开始了

1.4.1. 发布才是软件生命的开始，在这之前都是酝酿与准备

1.4.2. 当努力与回报之间存在凸型曲线关系时，良好的适应性就能起作用

1.4.3. DevOps会消除行动阶段中更多的延迟，并给观察阶段提供大量新的可视化工具

1.5. 系统要么随着时间的推移而成长，适应不断变化的环境，要么逐渐衰退，直到成本超出利润，然后死亡

1.6. 如果组织在改变方向时，没有花时间收集和处理反馈，那么就会发生颠簸（thrashing）

1.7. 虽然在软件内部进行了应对变更的设计，但在生产环境中忽视造成变更的行为

2. 工具

2.1. 计算容量，包括专门用途的高内存、高输入、高输出和高性能图形处理器配置

2.2. 工作负载管理、自动扩展、虚拟机的安置和覆盖网络

2.3. 存储，包括内容寻址存储和文件系统结构存储

2.4. 日志收集、索引和搜索

2.5. 度量指标收集和可视化

2.6. 消息排队和传输

2.7. 流量管理和网络安全

2.8. 动态DNS注册和解析

2.9. 电子邮件网关

3. 平台的可用性是衡量平台团队的标准

3.1. 必须让应用程序开发团队，而不是平台团队，负责应用程序的可用性

4. 发布

4.1. 以前的实践表明，每次发布通常都是成本高昂且风险巨大的

4.2. 简单但有害的解决方案是放慢发布频率

4.3. 正确的方式是减少每次发布所需的工作量，删除发布过程中需要人为参与的环节，并使整个过程更加自动化和标准化

5. 演化最重要的部分是灭绝，关闭服务，删除代码并重新分配团队成员

6. 谨防高效率

6.1. 让人们一直忙个不停，而公司的整体步伐却慢得像蜗牛

6.2. 高效率的价值流具有短交货期和高吞吐量

6.3. 当使价值流变得更有效率时，你也在将它变得更专业于今天的任务，而这可能在适应未来的任务时，难以进行改变

7. 大泥球法则

7.1. big ball of mud

7.2. 如果不去密切关注，依赖性就会激增，以此产生的耦合性就会将彼此不同的系统，都拉进一个脆弱的整体中

8. 系统架构

8.1. 新推出的系统必须要做一些正确的事情，否则就不会被推出

8.2. 演进式架构

8.2.1. 支持跨维度进行引导式增量变更

8.2.2. 水平耦合更可能成为演进的障碍

8.3. 适合演进式架构的

8.3.1. 微服务

8.3.1.1. 优点

8.3.1.1.1. 非常小的一次性代码单元

8.3.1.1.2. 强调容量的可伸缩性和团队规模的自治性

8.3.1.2. 缺点：在监控、跟踪和持续交付过程中容易与平台耦合

8.3.2. 微内核和插件

8.3.2.1. 优点

8.3.2.1.1. 进程内及内存中的消息传递内核，带有正式的扩展接口

8.3.2.1.2. 适合需求的增量变更，便于合并不同团队的工作

8.3.2.2. 缺点：易受编程语言和运行时环境的影响

8.3.3. 基于事件

8.3.3.1. 优点

8.3.3.1.1. 偏好异步消息通信，避免直接调用

8.3.3.1.2. 适用于时间解耦

8.3.3.1.3. 无须更改发布者，就能新增订阅者

8.3.3.1.4. 允许从历史中进行逻辑变更和重建

8.3.3.2. 缺点：随着时间的推移，易受消息格式的语义变化的影响

8.4. 松散的集群

8.4.1. 系统应该是松散的集群

8.4.1.1. 在一个松散的集群中，丢掉一个实例就如同森林中倒下一棵树，不会引起轰动效应

8.4.2. 单台服务器不再扮演差异化的角色

8.4.3. 任何差异化的角色都存在于多个实例中

8.4.4. 一个服务不会有任何独一无二的实例

8.4.5. 如果一个实例确实需要扮演独特的角色，那么它应该使用某种形式的领导者选举机制

8.4.6. 整个服务可以在失去领导者的情况下存活下来，无须人工干预来重新配置集群

8.5. 全局状态是隐式上下文中最隐秘的形式

8.5.1. 当需要从“一”切换到“多于一”的协作时，全局状态会拖慢进程

8.6. 模块化系统

8.6.1. 模块化系统天然就比单体系统拥有更多的选择

8.6.2. 拆分

8.6.2.1. 拆分将设计分解成模块，或将模块分解为子模块

8.6.3. 替代

8.6.3.1. 如果给定模块化设计，那么“替代”就是用另一个模块来替换某个模块

8.6.3.2. 原模块和替代模块需要共享一个通用接口

8.6.3.2.1. 它们具有相同的接口，而且父模块所需的接口部分也必须相同

8.6.4. 增添和排除

8.6.4.1. 增添是指为系统添加模块

8.6.4.2. 排除是指从系统中删除模块

8.6.5. 反转

8.6.5.1. 将分布在多个模块中的功能上移至系统更高的层级

8.6.5.2. 为变化创造了一个新的维度，并且可以从中显露出商业机会

8.6.6. 移植

8.6.6.1. 移植视为硬件或操作系统模块从一个CPU到另一个CPU的转移

8.6.6.2. 移植加大了耦合的风险

8.6.6.2.1. 增加了一种新的依赖

8.6.6.3. 实例化是将模块移植到系统中的另一种方式

9. 信息架构

9.1. 信息架构是构造数据的方式

9.2. 每种数据库都嵌入了一种对世界进行建模的方式

9.3. 我们不能捕获现实，只能对现实的某些方面进行建模

9.4. 消息、事件和命令

9.4.1. 利用消息肯定会带来复杂性

9.4.2. 事件通知：一个即发即忘的单向通告，并不期望获得响应或被使用

9.4.3. 事件承载状态转移：在事件中对实体的全部或部分进行复制，方便其他系统完成工作

9.4.4. 事件溯源：将所有变更记录为描述变更的事件

9.4.5. 命令与查询职责分离：使用不同的结构进行读取操作和写入操作

9.4.5.1. 不是事件，但事件通常会出现在其中的命令一侧

9.5. URL

9.5.1. URL是对值的表示的引用，可以通过解析URL来获取对应的表示，就像解引用指针一样

9.5.2. URL能够带来获取底层表示所需要的上下文

9.5.3. 需要对发送给用户的URL进行加密，这样就能验证所收到的内容是否对应之前所生成的请求