云 / 系统
EFS 的容量问题，可能早在症状出现前就已存在。一个小文件系统可以看似正常地支撑数周甚至数月，同时不断消耗有限的突发积分。应用没报错，仪表盘也是绿色，于是人们逐渐信任这套架构。直到积分归零，同样的负载才撞上低得多的可持续吞吐量上限。
问题因此看起来突然发生，但从容量趋势看，它早有迹象。
隐藏的不匹配
在突发模式下，基准吞吐量随 EFS Standard 中的数据量增长。AWS 文档给出的基准是每 GiB 对应 50 KiB/s，每个文件系统至少可获得 1 MiB/s 的计量吞吐量。负载低于基准时积累积分，高于基准时消耗积分。
长期平均需求只要略高于基准，就可能形成危险的消耗趋势。之前积累的积分可以暂时补足差额，不一定立刻出故障，但余额会一天比一天少。
为什么症状指向错误的方向
存储操作变慢后，应用工作进程就会等待。Linux 平均负载也计入不可中断的 I/O 等待，所以存储瓶颈很容易看起来像算力不足。即使 CPU 不是根因，请求积压、工作进程耗尽和超时，也会影响整个服务。
如果新实例仍然访问同一个受限的共享文件系统，扩容反而可能加重问题。瓶颈没有变，更多并发请求却会继续增加它的压力。
正常运行六个月，并不能说明容量设计没问题
长期无故障，只能说明当时的需求、基准吞吐量和剩余积分共同支撑了服务，不能证明积分耗尽之后仍然够用。因此，不断下降的 BurstCreditBalance 不只是一个容量细节，更是可靠性方面的早期预警。
负载测试也应覆盖稳定运行状态，而不只看短时峰值。十分钟的测试可能证明突发上限够高，却看不出几千小时里逐渐累积的容量缺口。
更好的调查顺序
- 将 CPU 利用率与平均负载和 I/O 等待进行比较。
- 检查 EFS
BurstCreditBalance在数周或数月内的变化。 - 比较
MeteredIOBytes和PermittedThroughput. - 将存储限制与应用程序延迟和工作线程饱和度相关联。
- 看清 Standard 存储类别中的实际数据量，因为它决定突发模式的基准。
- 判断负载更适合突发、弹性，还是预置吞吐量。
从中得到的工程经验
突发容量是缓冲，不是容量规划。对任何依赖积分的服务，都应关注余额变化的方向与速度，而不是只看它是否还大于零。前文记录了真实故障的形成过程，下一篇则把这些经验落实到具体的 CloudWatch 监控设计中。