DDoS 洪水
DDoS 洪水是 SysAdmin Crisis 中的第一个事件：流量来自非客户地址，带宽条涨红。了解它的日志特征。
最后更新:
洪水是游戏教授的第一个事件，也是唯一可能在第 1 夜出现的事件。流量来自并非客户的地址，带宽条被填满，其后的一切都开始受苦。
它做什么
攻击在大约十五秒的真实时间内逐步升级，而不是一下子全部到来，所以从第一行异常日志到第一根红条之间，留有一段窗口。在峰值处，它瞄准的是略低于服务器群总带宽容量的水平——这意味着容量很重要，更大的服务器群确实能吸收更多。
需求一旦超过容量的约 1.35 倍，其后的机器就会进入饱和：CPU 升到 99%，延迟上升，大约每隔十五秒就有一个目标掉到 DOWN。
日志特征
洪水不会报出自己的名字；症状体现为边缘机器上的内核和 monit 日志行。下面的日志行只是示例，数值每晚都不同：
03:11:42 web-02 kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies. Check SNMP counters.
03:11:45 web-02 monit[612]: 'web-02' cpu usage of 94% matches resource limit [cpu usage > 90.0%]
03:11:49 web-02 kernel: nf_conntrack: nf_conntrack: table full, dropping packet
这些日志行不会说明来源。netstat 和 Web 访问日志会显示是谁在发送请求；用 grep、awk 和 sort | uniq -c 汇总日志，才是这个事件真正的工作。游戏中的每个地址都来自 RFC 5737 文档专用地址块——192.0.2.0/24、198.51.100.0/24、203.0.113.0/24——所以这些地址块之外的地址绝不是攻击者。
置之不理的后果
先是带宽饱和，然后是 CPU，接着机器开始一台接一台地宕机。宕机的服务器是粘滞的：不会自行恢复。而且未解决的事件在宽限期结束后会开始累积 SLA 债务，所以置之不理的洪水会让可用率受两次损失——一次来自它拖垮的机器，一次来自时钟。参见升级与 SLA。
如何区分
| 看起来相似 | 区分依据 |
|---|---|
| 失控进程 | 洪水造成的 CPU 压力覆盖整个服务器群，并伴有内核的 SYN 警告；失控进程则是单台机器上一个有名字的进程。 |
| 内存泄漏 | 泄漏推高的是 RAM，而不是带宽，也没有流量特征。 |
| 过热 | 洪水之后，高温可能作为次生效应出现。如果两者同时在运行，温度是症状，不是原因。 |
何时出现
| 最早出现的夜 | 1——也是教程的第二课 |
| 前提 | 服务器群中至少有一台 web 机器 |
| 同时出现 | 一场洪水，绝不会有两场 |
| 变体 | 从第 6 夜起，洪水可能以分布式形式到来：五个来源分布在三个 RFC 5737 地址块中，而不是单个地址 |
分布式变体由带种子的 PRNG 决定，所以同一个种子每次都会产生同样的一夜——参见确定性与种子。