服务器与服务器群
SysAdmin Crisis 中的五种服务器角色、它们运行的进程、决定状态颜色的阈值，以及机架在战役中如何扩张。
最后更新:
管理的是一批有名字的机器——web-01、db-02、lb-01。每台都带有 CPU、RAM、磁盘和温度，由这些推导出的状态，以及一份 top 会显示出来的运行中进程列表。
五种角色
| 角色 | 加入时间 | 基线 CPU / RAM | 带宽 | 可见的进程 |
|---|---|---|---|---|
web | 第 1 夜 | 38% / 46% | 每台 1500 req/s | nginx, api-worker |
db | 第 1 夜 | 32% / 61% | — | postgres, checkout_tx |
lb | 第 3 夜 | 44% / 30% | 每台 3000 req/s | haproxy, keepalived |
cache | 第 4 夜 | 22% / 55% | — | redis-server |
worker | 第 6 夜 | 51% / 44% | — | celery, backup-agent |
只有 web 和 lb 提供带宽容量。这一点值得牢记：数据库永远不会是网络条变红的原因，增加缓存机器对流量问题也毫无帮助。
进程名是稳定的，所以它们成了词汇的一部分。凌晨三点出现一行点名 backup-agent 的日志，和点名 nginx 的日志，含义大不相同。
状态阈值
状态由最差的那项指标推导而来：
| 指标 | WARN 阈值 | CRIT 阈值 |
|---|---|---|
| CPU | 80% | 95% |
| RAM | 85% | 95% |
| 磁盘 | 90% | 98% |
| 温度 | 85°C | 95°C |
DOWN 不同——它不是由阈值推导出来的，而且是粘滞的。宕机的机器会一直宕机，直到有什么东西把它重新放回去。
温度被限制在 40–120°C 的区间内，所以散热问题有真实的上限，而不会失控到荒谬的数值。
机架如何扩张
服务器群每夜都按当晚的计划重新搭建。它不是随机的，也不是需要自行推导的公式——它是一张表：
| 夜 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
|---|---|---|---|---|---|---|---|---|---|---|
| 机器数 | 3 | 4 | 5 | 7 | 7 | 9 | 11 | 14 | 14 | 16 |
第 1 夜恰好是 web-01、web-02、db-01。到第 10 夜，运行的是涵盖全部五种角色的十六台机器，其中有两台数据库、两台负载均衡器和三台 worker。