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.白盒技术与编程语言和开发框架之间的耦合更为紧密