51 lines
2.9 KiB
Markdown
51 lines
2.9 KiB
Markdown
# 大规模存储：我每天真正盯着的指标
|
||
|
||
- **期号**: SRE Weekly Issue #532（2026-08-31）
|
||
- **作者**: Sridhar Rajarao
|
||
- **链接**: https://sridharrajarao.com/blog/storage-at-scale/
|
||
|
||
## 简介
|
||
|
||
> 八年里，我为一套以 EB（艾字节）计量的存储系统做 SRE。我每天早晨查看的仪表盘最终缩减到七个数字。就是它们。
|
||
|
||
## 正文
|
||
|
||
八年里，我领导着支撑一套以 EB 计量的存储系统的 SRE 团队。随着时间推移，我每天早晨检查的仪表盘缩减到了一小撮数字。下面就是告诉我服务是否健康的七个指标。
|
||
|
||
可用性（Availability）告诉你系统是否在线。持久性（Durability）告诉你数据是否还在。两者不是一回事。
|
||
|
||
先看速览版。
|
||
|
||
| KPI | 衡量什么 | 我们如何跟踪 |
|
||
|---|---|---|
|
||
| 可用性 | 请求成功百分比 | 每个区域、每个服务 99.99% |
|
||
| 持久性 | 数据存活的概率 | 11 个 9（年损失率 10^-11） |
|
||
| TTFB | 返回首字节时间 | 按对象大小分桶的 p50、p95、p99 时延 |
|
||
| 金丝雀 | 合成测试流量 | 每个区域持续 PUT/GET |
|
||
| 热点 | 存储节点间的倾斜程度 | 前 N 节点负载对比集群中位数 |
|
||
| IOPS | 每秒操作数 | 每个分片、每块磁盘的读写 IOPS |
|
||
| DB 分片 | 元数据分区健康 | 分片 CPU、滞后、热键偏斜 |
|
||
|
||
## 可用性与持久性是两条不可妥协的底线
|
||
|
||
可用性就是正常运行时间。持久性关乎数据能否存活。你可以做到 100% 可用却丢了数据；你也可以做到 100% 持久却离线不可用。客户两者都在乎。我们用纠删码把每个对象写入多个可用区，达到了 11 个 9 的持久性，并且每月用一次恢复演练来证明它。
|
||
|
||
## TTFB 才是用户真正感受到的东西
|
||
|
||
整体可用性会掩盖慢尾部。一个 99.99% 可用、但 p99 TTFB 达 2 秒的服务，用起来就像坏了一样。永远按对象大小分桶跟踪时延。10 MB 的读取请求不应该和 100 字节的 HEAD 请求共享同一条 SLO。
|
||
|
||
## 金丝雀才是真相
|
||
|
||
客户不开心时不会告诉你，他们直接流失。金丝雀是从每个区域持续运行的合成 PUT/GET/LIST 流量。如果金丝雀失败 30 秒，你会在客户的寻呼机响起之前发现问题。
|
||
|
||
## 热点和 IOPS 暴露无声的故障
|
||
|
||
一个存储集群可以在 99.99% 可用的情况下，某个节点已经烧起来了。跟踪每个节点的 IOPS 和字节服务量，并对偏离集群中位数最多的前 N 个节点告警。热点是客户密钥区间压垮某个分片的前兆指标。
|
||
|
||
## DB 分片是没人谈论的部分
|
||
|
||
对象存储看起来无状态，但元数据层其实是一个分片数据库。一个过热的分片、一次出了岔子的再平衡，就能让你的控制面瘫痪。要用盯数据面同样的方式盯分片 CPU、复制滞后和热键偏斜。
|
||
|
||
数据面可以水平扩展；控制面会咬人。
|
||
|
||
这七个数字放在一起看，几乎告诉了我判断服务是否健康所需的一切。 |