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 mud7.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.URL9.5.1.URL是对值的表示的引用，可以通过解析URL来获取对应的表示，就像解引用指针一样9.5.2.URL能够带来获取底层表示所需要的上下文9.5.3.需要对发送给用户的URL进行加密，这样就能验证所收到的内容是否对应之前所生成的请求