SRE四大黄金指标：搞懂这四个数据，服务器稳了
在运维圈里混久了，总听人提“SRE四大黄金指标”。听起来挺玄乎，其实说白了，就是衡量系统健康状况最核心的四个数据。你要是管着几台服务器，跑着Web服务或者API接口，这几个指标不盯紧，半夜被报警电话叫醒是常事。
1. 延迟（Latency）
延迟指的是从用户发请求到收到响应所花的时间。比如你点个“提交订单”，页面转圈三秒才出结果，这就是延迟高。对用户来说，慢比宕机更折磨人——系统没挂，但用不了。
关键不是看平均延迟，而是看尾部延迟。比如95%的请求都在200ms内完成，但剩下的5%要两秒，那倒霉的用户正好撞上，体验直接崩盘。监控得看P95、P99这类分位数。
2. 流量（Traffic）
流量代表系统的负载能力，通常用每秒请求数（QPS）或并发连接数来衡量。比如你的电商后台在大促时QPS从平时的500飙到5万，这时候系统能不能扛住，就看架构和资源准备得够不够。
流量本身不说明问题，但它和其他指标联动才有意义。比如流量突然上升，同时延迟飙升、错误率上涨，那很可能某台服务已经快撑不住了。
3. 错误（Errors）
这个最直观——有多少请求失败了。HTTP 500、数据库超时、接口返回空数据，都算错误。但别只盯着错误总数，得分类看：是用户输错参数（4xx），还是服务自己崩了（5xx）？
举个例子，登录接口每天有1%的500错误，看起来不高，可如果你的平台有百万用户，那就是一万人登不进去。时间一长，用户流失跑路都不奇怪。
监控配置里可以加个简单的告警规则：
IF http_server_errors_rate > 0.01 FOR 5m THEN alert4. 饱和度（Saturation）
饱和度说的是资源有多“满”。比如CPU用了95%，内存剩不到1G，磁盘IO堵死了，这些都属于饱和。它不像前三个是直接面向用户的，但它是系统崩溃前的最后预警。
就像地铁早高峰，还没停运，但车厢已经挤得动不了，再进人就要出事。服务器也一样，资源一旦打满，响应变慢、请求排队，接着错误率上升，最后整个服务卡死。
建议监控时加上资源水位看板，比如：
node_cpu_usage > 90%
node_memory_free < 1GB
disk_io_wait > 50ms把这四个指标放在一张 dashboard 上，值班的时候扫一眼，心里就有底。哪个颜色变红，问题大概出在哪，基本能定位八九不离十。
实际工作中，很多小团队一开始不上监控系统，等出了问题才临时翻日志，往往为时已晚。不如早点把四大指标接进Prometheus+Grafana，设定合理阈值，让系统自己“说话”。
别等到用户骂上微博，才想起去看服务器啥情况。运维这活，拼的就是提前量。