1. 导致运维失误的两大因素

1.1. 隐秘的连锁反应

1.2. 暗藏的高复杂度

1.3. 影响着配置属性

2. 配置

2.1. 配置属性是系统用户接口的一部分，供支持其开发和运维的人员使用

2.1.1. 最易被忽视

2.2. 生产级别的软件都有大量可配置的属性

2.2.1. 主机名

2.2.2. 端口号

2.2.3. 文件系统位置

2.2.4. ID号

2.2.5. 用户名

2.2.6. 密码

2.3. 任何属性出现错误，系统都会遭到破坏

2.3.1. 即使该系统大部分时间能够正常工作，也仍有可能在某个重要时刻中断服务

3. 配置文件

3.1. 由于同一个软件需要在不同的实例上运行，因此某些配置属性可能会因机器而异

3.2. 代码应该在部署目录之外查找适合相应部署环境的配置

3.3. 配置文件会包含整个企业中最敏感的信息：生产数据库的密码

3.3.1. 要避免将不同部署环境的配置值保存在版本控制系统中

3.4. 只要将配置信息存放在与源代码不同的存储库中，将其锁好，仅对有权访问的人开放，并且管理员能够根据过程、程序和执行人等授予或撤销对相关配置信息的访问权限，那么配置信息也可以存放在版本控制系统中

4. 易处理基础设施的配置

4.1. 基于镜像的环境中无法针对不同的实例改变其配置文件

4.2. 方法

4.2.1. 在启动时注入配置信息

4.2.1.1. 提供环境变量或文本blob来注入配置信息

4.2.1.2. 对大多数小团队来说，注入配置信息更为适用

4.2.2. 使用配置服务

4.2.2.1. 将配置信息注入镜像的方法通过配置服务完成

4.2.2.2. 实例会对配置服务产生严重的依赖

4.2.2.2.1. 配置服务只要一中断，就立即会引发严重级别高达1级的事故

4.2.2.2.2. 当配置服务不可用时，实例就根本无法启动

4.2.2.3. ZooKeeper、etcd以及其他任何配置服务，都是复杂的分布式系统软件

4.2.2.3.1. 必须依赖一个精心设计的网络拓扑才能最大限度地提高可用性，并且必须对其容量进行精细的管理

4.2.2.4. 配置服务需要高度的运维成熟度，并会带来一些显著的开销

4.2.2.4.1. 只是服务于一个应用程序，那么就不值得使用配置服务

4.2.2.4.2. 只有服务于组织中更广泛的应用程序时，才适合进行配置服务

5. 定义配置属性

5.1. 属性名称应足够清晰，帮助用户避免“自我失误”

5.2. 主机就定义为hostname，这样的命名虽然没错，但毫无帮助

6. 明晰性

6.1. 指的是系统容许运维工程师、开发工程师和业务负责人了解其历史趋势、当前状况、即时状态和未来走向的程度

6.2. 系统级的明晰性视图将呈现历史分析、当前状态、即时行为和未来走向，每个实例都可以提供足够多的数据构建系统级视图

6.3. 当且仅当具有某种程度的明晰性时，系统才能更加成熟

6.4. 良好的数据有助于做出正确的决策，在缺乏可信数据的情况下，决策就只能根据某人的影响力、偏见

6.5. 缺乏明晰性的系统无法在生产环境中长期运行

6.5.1. 如果系统管理员不了解系统在做什么，就无法对其进行调整和优化

6.5.2. 如果开发人员不了解生产环境中系统各个部分的运行状况，那么他们就不能随着时间的推移，提高系统的可靠性或韧性

6.5.3. 如果业务负责人不了解系统是否在帮助他们赚钱，那么他们将不会投资系统未来的工作

6.5.4. 如果缺乏明晰性，那么每次发布都会让系统变得更糟，从而令系统发生退化

7. 明晰性设计

7.1. 严格的局部可见性只能实现严格的局部优化

7.2. 如果每次仅提升一个应用程序的可见性，则会掩盖扩展效应引发的问题

7.3. 监控和报告系统应该像在系统周围构建的外骨骼，而不是交织在系统内部

7.3.1. 要密切关注系统内耦合现象，监控框架侵入系统内部相对容易

7.4. 从进程中获取信息

7.5. 在实例上运行的进程是完全不明晰的

7.5.1. 除非能在该进程中运行调试器，否则进程几乎不会揭示任何关于自己的信息

7.6. 黑盒技术在系统外部运行，通过外部观察到的事物检查进程

7.6.1. 可以在系统发布后实施，通常由运维人员完成

7.6.2. 易用的日志抓取系统（如Splunk）就是黑盒技术的例子

7.7. 白盒技术在系统内部运行，通常这种技术看起来像是由特定语言库提供的代理

7.7.1. 在开发过程中，白盒技术和进程必须要集成到一起

7.7.2. 白盒技术与编程语言和开发框架之间的耦合更为紧密