1. 最大限度地避免直接对生产系统进行人为操作最为妥善

1.1. 人为干预生产环境会导致问题

1.1.1. 把“无须摆弄”做到极致，就是“不可变”的基础设施，因为那里根本就不存在供人摆弄的途径

1.1.2. 如果系统需要大量手动操作来保持运行，那么管理员就必须养成始终记日志的习惯

1.1.3. 通过限制系统管理员登录生产环境服务器的需求，鼓励更好的运维纪律

1.2. 系统应该能够在没有人工干预的情况下，至少运行一个发布周期

1.2.1. 系统应在无须手动清理磁盘或每晚重新启动的情况下，至少运行一个发布周期

1.2.2. 在发布周期中，那些从版本控制系统中持续部署的微服务，应该非常易于实现稳定部署

2. 存储桶

2.1. 稳态模式表明，针对每个累积资源的机制，要相应存在另一个机制回收该资源

2.2. 随着数据的累积，存储桶会以一定的速率填满

2.3. 存储桶必须以相同或更快的速率清空数据，否则最终会溢出

2.4. 当该存储桶溢出时，坏事会发生

2.4.1. 服务器停机

2.4.2. 数据库变慢

2.4.3. 抛出错误信息

2.4.4. 响应长

3. 数据清除

3.1. 数据清除总会被忽视

3.2. 计算资源总是有限的，因此不能无限制地持续增加消费

3.3. 数据增长最明显的症状，就是数据库服务器上的I/O速率稳步增加

3.4. 在恒定的系统负载下，也能看到延迟时间会增加

3.5. 数据清除的另一半工作，是确保在清除数据之后应用程序仍能正常工作，而这需要进行编程和测试

3.6. DBA可以通过创建脚本清除数据，但他们不知道删除数据之后，应用程序会如何运转

3.6.1. 为了保持逻辑完整性（特别是在使用对象关系映射工具时），应用程序需要清除自己的数据

4. 日志文件

4.1. 不要无限量保留日志文件

4.1.1. 如果日志文件无限制地增大，最终会填满其所在的文件系统

4.2. 文件系统空间耗尽之后的状况就无从得知了

4.2.1. 最好的情况，就是日志文件系统与任何关键数据存储（例如事务）是分离的，而且应用程序代码本身具有足够的安全防护能力，用户永远不会意识到有任何错误发生

4.3. 最好一开始就避免一直往文件系统里添加内容

4.3.1. 基于日志文件的大小来配置日志文件回转

4.4. 日志对系统的明晰性有极大的帮助，确保所有的日志文件都能被回转使用，并最终被清除

4.5. 生产环境系统的日志文件信噪比很糟糕

4.5.1. 最好能尽快将日志文件从单个主机上移走，发送到集中式日志记录服务器（例如Logstash），进而对其进行索引、搜索和监控

4.6. 多年保留日志

4.6.1. 单个机器不可能把日志保留这么长时间，大多数机器的寿命也不会这样长

4.6.2. 最好的办法是尽快从生产环境的机器中取出日志，将它们存储在中央服务器上，并对其密切监视，防止篡改

4.6.3. 如果合规性要求保留，则在非生产服务器上执行

5. 内存中的缓存

5.1. 内存中的缓存可以加快应用程序的运行速度

5.2. 若不对内存中的缓存加以控制，执行速度会降低

5.3. 低内存的状态对稳定性和容量都是威胁

5.3.1. 需要限制缓存可消耗的内存量

5.4. 如果缓存键数量没有上限，则必须限制缓存大小，并且采用某种形式的缓存失效机制

5.5. 定时刷新缓存是最简单的缓存失效机制

5.5.1. 定时刷新缓存能够处理90%的情况

5.6. “最近最少使用”或工作集算法

526互联

读发布！设计与部署稳定的分布式系统（第2版）笔记14_稳态

1. 最大限度地避免直接对生产系统进行人为操作最为妥善

1.1. 人为干预生产环境会导致问题

1.1.1. 把“无须摆弄”做到极致，就是“不可变”的基础设施，因为那里根本就不存在供人摆弄的途径

1.1.2. 如果系统需要大量手动操作来保持运行，那么管理员就必须养成始终记日志的习惯

1.1.3. 通过限制系统管理员登录生产环境服务器的需求，鼓励更好的运维纪律

1.2. 系统应该能够在没有人工干预的情况下，至少运行一个发布周期

1.2.1. 系统应在无须手动清理磁盘或每晚重新启动的情况下，至少运行一个发布周期

1.2.2. 在发布周期中，那些从版本控制系统中持续部署的微服务，应该非常易于实现稳定部署

2. 存储桶

2.1. 稳态模式表明，针对每个累积资源的机制，要相应存在另一个机制回收该资源

2.2. 随着数据的累积，存储桶会以一定的速率填满

2.3. 存储桶必须以相同或更快的速率清空数据，否则最终会溢出

2.4. 当该存储桶溢出时，坏事会发生

2.4.1. 服务器停机

2.4.2. 数据库变慢

2.4.3. 抛出错误信息

2.4.4. 响应长

3. 数据清除

3.1. 数据清除总会被忽视

3.2. 计算资源总是有限的，因此不能无限制地持续增加消费

3.3. 数据增长最明显的症状，就是数据库服务器上的I/O速率稳步增加

3.4. 在恒定的系统负载下，也能看到延迟时间会增加

3.5. 数据清除的另一半工作，是确保在清除数据之后应用程序仍能正常工作，而这需要进行编程和测试

3.6. DBA可以通过创建脚本清除数据，但他们不知道删除数据之后，应用程序会如何运转

3.6.1. 为了保持逻辑完整性（特别是在使用对象关系映射工具时），应用程序需要清除自己的数据

4. 日志文件

4.1. 不要无限量保留日志文件

4.1.1. 如果日志文件无限制地增大，最终会填满其所在的文件系统

4.2. 文件系统空间耗尽之后的状况就无从得知了

4.2.1. 最好的情况，就是日志文件系统与任何关键数据存储（例如事务）是分离的，而且应用程序代码本身具有足够的安全防护能力，用户永远不会意识到有任何错误发生

4.3. 最好一开始就避免一直往文件系统里添加内容

4.3.1. 基于日志文件的大小来配置日志文件回转

4.4. 日志对系统的明晰性有极大的帮助，确保所有的日志文件都能被回转使用，并最终被清除

4.5. 生产环境系统的日志文件信噪比很糟糕

4.5.1. 最好能尽快将日志文件从单个主机上移走，发送到集中式日志记录服务器（例如Logstash），进而对其进行索引、搜索和监控

4.6. 多年保留日志

4.6.1. 单个机器不可能把日志保留这么长时间，大多数机器的寿命也不会这样长

4.6.2. 最好的办法是尽快从生产环境的机器中取出日志，将它们存储在中央服务器上，并对其密切监视，防止篡改

4.6.3. 如果合规性要求保留，则在非生产服务器上执行

5. 内存中的缓存

5.1. 内存中的缓存可以加快应用程序的运行速度

5.2. 若不对内存中的缓存加以控制，执行速度会降低

5.3. 低内存的状态对稳定性和容量都是威胁

5.3.1. 需要限制缓存可消耗的内存量

5.4. 如果缓存键数量没有上限，则必须限制缓存大小，并且采用某种形式的缓存失效机制

5.5. 定时刷新缓存是最简单的缓存失效机制

5.5.1. 定时刷新缓存能够处理90%的情况

5.6. “最近最少使用”或工作集算法