大家好，今天分享2个概念。高可用（High Availability，HA）和 SRE（Site Reliability Engineering，网站可靠性工程）。他们是是现代分布式系统架构与运维领域的核心概念，二者紧密关联又各有侧重。作为曾深耕系统稳定性领域的从业者，我可以从核心定义、关键实践和内在逻辑三个层面展开分享：
一、高可用（HA）：系统的 “抗造能力”
高可用本质是系统在规定时间内保持正常运行的能力，核心目标是减少 “不可用时间（Downtime）”，让业务尽可能 “不宕机、少卡顿”。
1. 核心指标：用 “9” 的数量定义可靠性
行业常用 “可用性百分比” 量化高可用能力，比如：
99%：全年允许宕机约 87.6 小时（≈3.65 天）；
99.9%（“三个九”）：允许宕机约 8.76 小时（≈525 分钟）；
99.99%（“四个九”）：允许宕机约 52.56 分钟；
99.999%（“五个九”）：允许宕机仅 5.256 分钟 / 年。
注：这个指标的计算逻辑是 “（总时间 - 不可用时间）/ 总时间 ×100%”，但实际业务中需结合核心场景（如支付、登录）定义 “不可用”—— 比如 “响应延迟超过 1000ms” 对用户而言等同于 “不可用”，需纳入统计。
2. 实现高可用的核心手段
高可用的本质是 “通过设计对抗不确定性”，常见实践包括：
冗余设计：关键组件（服务器、数据库、网络链路）多副本部署，比如主从架构、集群化部署（如 Redis Cluster、K8s 集群），避免单点故障；
故障转移（Failover）：当主节点故障时，自动切换到备用节点（如 MySQL 的 MGR、K8s 的 Pod 自愈），切换时间需控制在用户无感知范围内（通常＜10 秒）；
负载均衡：通过 Nginx、F5 等设备将流量分发到多个节点，避免单节点过载崩溃；
限流与熔断：当系统接近负载上限时，主动拒绝部分流量（限流）；当依赖的下游服务故障时，快速 “断开连接” 避免级联失败（熔断，如 Hystrix、Sentinel）；
数据多活：跨地域部署数据中心（如 “两地三中心”），即使一个区域故障，另一个区域仍能提供服务（如支付宝的异地多活架构）。
二、SRE：让高可用 “可落地” 的工程方法论
SRE 是 Google 在 2003 年提出的理念，核心是 “用软件工程的方法解决运维问题”，目标是平衡 “系统可靠性” 与 “业务迭代速度”。简单说：传统运维更侧重 “被动救火”，而 SRE 更像 “主动建防火墙 + 设计灭火器”。
1. SRE 的核心支柱：SLI、SLO、SLA
这三个指标是 SRE 的 “语言体系”，用于量化和管理可靠性：
SLI（Service Level Indicator，服务水平指标）：可量化的 “系统表现数据”，比如 “API 调用成功率”“页面加载时间”“故障恢复时间（MTTR）”；
SLO（Service Level Objective，服务水平目标）：对 SLI 的 “目标值”，比如 “API 成功率≥99.99%”“页面加载时间＜500ms 的比例≥95%”；
SLA（Service Level Agreement，服务水平协议）：与用户（或内部团队）签订的 “契约”，约定若 SLO 未达标需承担的责任（如赔偿、道歉）。
举个例子：
SLI：某电商支付接口的 “调用成功率”；
SLO：团队内部设定 “成功率≥99.99%”；
SLA：与用户约定 “若月成功率＜99.9%，赔偿当月服务费的 10%”。
2. SRE 的关键实践
错误预算（Error Budget）： SLO 未达标的 “允许范围”（比如 SLO 是 99.99%，则错误预算是 0.01%）。当错误预算未耗尽时，开发团队可放心迭代；若耗尽，则需暂停新功能，优先修复稳定性问题 —— 这解决了 “开发想快、运维想稳” 的核心矛盾。
自动化运维：用代码替代人工操作（如自动扩缩容、自动备份、故障自动诊断），比如用 Prometheus+Grafana 监控，用 Ansible/Terraform 编排部署，用 ELK 栈分析日志。Google 曾提到：“SRE 团队的时间应 70% 用于自动化，30% 用于应急响应”。
容量规划： 提前预测流量增长（如电商大促），计算所需的服务器、带宽等资源，避免 “流量来了顶不住”。比如通过历史数据建模，预测双 11 峰值流量是日常的 10 倍，提前扩容 15 倍资源（留冗余）。
事后分析（Postmortem）：故障发生后，不追责、只复盘，输出 “5Why 分析报告” 和改进措施（如 “为什么支付接口超时？因为数据库连接池满了→为什么满了？因为未设置自动扩容→如何避免？添加连接池监控和自动扩容脚本”）。
三、高可用与 SRE 的关系：目标与手段
高可用是 “目标”：希望系统尽可能稳定；
SRE 是 “手段”：通过工程化方法（SLI/SLO/ 错误预算、自动化等）实现高可用，同时兼顾业务迭代效率。
举个形象的例子：
高可用像 “希望家里全年不停电”，而 SRE 像 “提前安装备用电源（冗余）、监测电流负载（SLI）、约定每月停电不超过 5 分钟（SLO）、跳闸时自动切换电源（自动化）” 的一整套方案。
总结一下
在分布式系统越来越复杂的今天（微服务、云原生、全球部署），“绝对可用” 几乎不可能，而高可用和 SRE 的价值在于：通过科学的指标定义、工程化的手段，让系统可靠性 “可测量、可控制、可改进”，最终在 “稳定” 与 “迭代” 之间找到动态平衡 —— 毕竟，用户需要的不是 “永不故障的系统”，而是 “故障时能快速恢复、平时能持续优化” 的服务。
