你有没有遇到过这样的情况：早上刚点开公司后台系统，页面直接显示‘503 Service Unavailable’；或者App更新后，用户疯狂反馈‘登录不了’‘订单提交失败’——而运维团队还在满世界找日志？这背后，往往不是服务器突然坏了，而是高可用设计没跟上业务节奏。
高可用不是‘不宕机’，而是‘出问题时少影响人’
很多人以为高可用就是买一堆服务器、堆个集群就完事。其实不然。SRE（站点可靠性工程师）眼里，高可用是‘可预期的故障应对能力’：服务挂了1分钟，是否只影响0.1%的用户？关键接口超时，能否自动降级返回缓存数据？数据库主库崩了，30秒内能不能切到备库继续写？这些不是靠祈祷，而是靠日常埋点、压测、演练和自动化兜底。
几个接地气的保障动作
1. 把‘多少人受影响’量化成数字
比如电商大促前，SRE会盯死三个黄金指标：延迟（P95 < 300ms）、错误率（< 0.1%）、吞吐量（≥ 5000 QPS）。一旦错误率突破0.2%，自动触发告警并暂停新功能上线——不是等老板打电话来问，而是系统自己‘喊停’。
2. 故障不靠人盯，靠‘自愈’
常见场景：某台应用服务器CPU飙到98%，传统做法是微信拉群、登录机器top看进程、kill掉异常进程……SRE的做法是提前写好脚本，一旦监控发现连续2分钟CPU > 95%，自动重启对应服务容器，并发消息到钉钉群：【AUTO-RECOVER】app-srv-07 已重启，耗时12s，请求无损。
3. 每次发布都像‘拆弹’，先小范围再放大
新版本不上全量，而是按流量比例灰度：先放1%真实用户，观察错误日志和慢查询；再升到5%，重点看支付链路成功率；确认没问题才全量。哪怕代码真有Bug，也只影响极少数人，而不是全站瘫痪。
一个真实的健康检查配置示例（K8s readiness probe）
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3这段配置的意思是：容器启动10秒后，每5秒发起一次健康检测；如果连续3次失败（比如HTTP返回非200），K8s就会把这台实例从负载均衡池里摘掉——用户根本感知不到它已‘离线’。
别迷信工具，先管好‘人的反应链’
再好的监控系统，如果值班工程师收到告警后要翻3个文档才找到处理命令，那高可用就是空谈。SRE会把常见故障的处置步骤固化成Runbook，比如‘Redis连接超时’的一页纸指南：第一步查连接数是否打满，第二步看慢日志是否有大KEY，第三步执行redis-cli --scan --pattern "user:*" | head -100 | xargs redis-cli del临时清理……谁值班都能照着做，不靠记忆、不靠经验。
说到底，SRE保障高可用，不是追求‘永远不坏’，而是让系统坏得明白、坏得可控、坏得快恢复——就像家里装了烟雾报警器+自动喷淋+逃生通道，不怕起火，怕的是火起了才发现不了、灭不了、跑不出。