1. 控制层囊括所有在后台运行的成功处理生产负载的软件和服务

1.1. 处理用户生产数据的那些软件，就是生产软件

1.2. 主要工作是管理其他软件的软件，就是控制层

1.3. 工具和问题之间存在着重叠和空白，并不是每个工具组合都能协同工作，不存在能解决所有问题的万能软件包

1.4. 在集成工具时要耗费巨大的精力，进行大量的实验，经历无数的错误

2. 适合的控制层工具

2.1. 当考虑控制层时，请记住其中的每一部分都是可选的

2.1.1. 有了日志记录和监控这些控制层选项，就有助于开展事后分析、事故恢复和缺陷发现等工作

2.1.2. 没有这些选项，上述工作将花费更长的时间，甚至根本没有办法完成

2.2. 控制层越先进，其实现和运维的成本就越高

2.3. 控制层中的每个工具都有持续的运维成本

2.3.1. 将持续的运维成本看作权衡固定成本与可变成本

2.3.1.1. 专职运维人员的固定成本

2.3.1.2. 部署加速、事故恢复和服务整备等可变成本

2.4. 2007年

2.4.1. 记录日志和监控几乎是一个商业化的市场

2.5. 如今

2.5.1. 这个市场几乎是开源的

2.5.2. 最困难的问题变成了如何从所有精良的开源软件中选择一个自己满意的工具

2.6. 不要误以为必须安装所有工具

2.6.1. 控制层工具的发展日新月异，要持续评估不同解决方案的开销和难度

3. 机械效益

3.1. 机械效益指人类可以依靠简单机器增强自身力量

3.1.1. 阿基米德说过：“给我一个支点，我能撬动地球。”

3.2. 既能帮大忙，也能帮倒忙

3.2.1. 强大的杠杆作用使人花很少的力量就能做出巨大的改变

3.3. 运行得太快也有问题

3.3.1. 无论怎样，一旦关闭的实例数量超过了总服务器容量的50%，自动化工具就应该停下来，从而使人们能够确认移除容量确实是正确的行为

4. 平台和生态系统

4.1. 监控团队应该能够帮助相关人员响应应用程序告警

4.2. 监控团队不会进行监控，而会帮助其他人实现自行监控

4.3. 一种从占有某个领域向为客户提供服务的思维转变。

4.4. 监控团队提供了一个开发团队可以使用的接口，并负责编写接口的实现细节，而且在持续支持其接口协议的过程中，可以随时改变实现细节

4.5. 监控团队只负责实现相关工具，让其客户通过这些工具实现自身的监控器

4.6. 平台团队的数据库管理员主要负责保持数据库健康运行，数据库管理员要确保数据库具有足够的容量

4.6.1. 数据库管理员应该关注创建高性能和高稳定的平台

4.7. 数据模型的设计工作则由应用程序团队负责

4.7.1. 一个应用程序能很轻易地做出有害的模式变更，从而影响其他数据库消费者

4.7.2. 使用基于SQL的RDBMS要求我们为每个服务分配一个单独的物理数据库

4.8. 平台团队的目标是为客户赋能

5. 开发环境就是生产环境

5.1. 如果你的开发服务器镜像是一个带有已知配置的全新虚拟机，那就太棒了

5.2. 如果QA环境和生产环境能由同一个自动化工具创建，并且QA环境存有经过匿名化处理的一周以来的生产环境用户数据样本，那么你就继续保持吧

5.3. 开发人员完成工作所需的工具、服务和环境，应该以生产级别的SLA对待

5.4. 开发平台就是创造软件这项工作的生产环境

6. 整个系统的明晰性

6.1. 当网络规模较大时，“部分系统故障”也是正常的运维状态

6.2. 即使是网络规模较小的场景，在一切都没有运行的情况下，系统也应该能够继续“存活”一段时间

6.3. 真实用户监控

6.3.1. real-user monitoring，也可称其为RUM

6.3.2. 判断用户体验的最佳方式是直接测量

6.4. New Relic或Datadog等服务

6.5. AppDynamics或CA公司的APM

6.6. 3个优势

6.6.1. 能快速启动，无须构建基础设施或配置监控软件，很有可能在一小时内就开始收集数据了

6.6.2. 能为各种技术提供代理软件和连接器，这使所有监控集成到一处更加容易

6.6.3. 仪表盘和可视化界面往往比开源替代方案设计得更精美

6.6.4. 商业服务，需要支付订阅费

6.7. 开源工具

6.7.1. 要投入人力和基础设施等相对隐性的成本

6.8. 经济价值高于技术价值

6.8.1. 大多数软件则是为了创造经济价值而存在

6.8.2. 成本也会源自运维工作量

6.8.2.1. 软件越难以运维，人们在运维上所花费的时间就越多

6.8.3. 成本源自平台和运行时系统

6.8.3.1. 有些语言能让程序员快速编程，但需要更多实例处理特定的工作负载（这样就增加了成本）

6.8.4. 监控、日志收集、告警和仪表盘等手段的经济价值，其实是高于其技术价值的

6.9. 日志和统计信息

6.9.1. 日志收集器能以推或拉的模式进行工作

6.9.2. 推模式意味着实例能在网络上推送日志，此时通常使用历史悠久的syslog协议

6.9.3. 推模式对容器非常有用，它们无须额外保存状态，且通常没有本地存储

6.9.4. 使用拉模式，那么收集器就在中央计算机上运行，且能连接所有已知主机进而远程复制日志，服务只将其日志写入本地文件

6.9.5. 仅将所有日志保存在一台主机上，就已经小有成就了

6.9.6. Splunk在当今日志索引领域占据主导地位

6.9.7. 由Elasticsearch、Logstash和Kibana组成的“三驾马车”则是另一组流行的工具

6.9.8. 度量指标

6.9.8.1. 大多数度量指标数据库会对最近的样本进行细粒度的度量

6.9.8.2. 随着样本变老，它们会将样本聚合到越来越大的时间跨度

6.9.8.2.1. 今天的网卡错误率能以秒为单位查阅

6.9.8.2.2. 如果要查阅过去7天的错误率，则最细能以分钟为单位查阅

6.9.8.2.3. 如果要查阅7天之前的，则最细仅能以小时为单位查阅

6.9.8.2.4. 好处

6.9.8.2.4.1. 节省不少磁盘空间

6.9.8.2.4.2. 让长时间跨度的查询成为可能

6.10. 监控点

6.10.1. 流量指示

6.10.1.1. 页面请求量、页面请求总数、事务计数、并发会话数

6.10.2. 每种类型的业务交易

6.10.2.1. 已处理的业务交易数量、被终止的业务交易数量、所创造的业务价值（以元为单位）、事务持续时长、业务转化率、业务完成率

6.10.3. 用户

6.10.3.1. 用户群分析或分类、用户使用技术的偏好、注册用户百分比、用户数量、使用模式、使用中遇到的错误数量、登录成功数量、登录失败数量

6.10.4. 资源池健康状况

6.10.4.1. 是否处于启用状态、总资源数量（适用于连接池、worker线程池和其他所有资源池）、检出资源的数量、高水位线、所创建的资源数量、所销毁的资源数量、资源检出的总次数、等待某资源而被阻塞的线程数量、某线程被阻塞等待的次数

6.10.5. 数据库连接健康状况

6.10.5.1. 抛出的SQLException数量、查询数量、查询的平均响应时间

6.10.6. 数据消费量

6.10.6.1. 用于展示的实体或行的数量、数据在内存和磁盘中的占用量

6.10.7. 集成点健康状况

6.10.7.1. 断路器状态、超时次数、请求数量、平均响应时间、良好响应数量、网络错误数量、协议错误数量、应用程序错误数量、远程端点的实际IP地址、当前并发请求数、并发请求高水位线

6.10.8. 缓存健康状况

6.10.8.1. 缓存项数量、缓存所占内存量、缓存命中率、垃圾收集器刷新的缓存项数量、缓存配置的上限、缓存项创建所用时间

6.10.9. 隐含的时间条件“最近n分钟”或“自上次复位以后”

6.10.10. 要衡量系统连续的度量指标的标称范围，“用某时间段的平均值加上或减去两个标准差”不失为一个实用的经验法则

6.10.11. 不存在适用于所有组织的正确度量时间段

6.10.11.1. 对零售商来说，强烈地关注在“每年最忙一周”里所得到的度量指标

6.10.11.2. 如旅游、花卉和体育，与访问流量最相关的度量往往发生在节假日或重大活动期间