Blast RadiusvsSRE

Blast Radius

Blast Radius 是评估系统变更风险的核心概念——如果这次部署失败了，会影响多少用户、多少服务？好的架构设计应该尽量缩小每次变更的 Blast Radius。

SRE

SRE 是 Google 提出的运维方法论：用软件工程的思维和工具来保障系统可靠性。SRE 团队写代码来自动化运维任务，用 SLO/SLI 量化可靠性目标，用 Error Budget 平衡可靠性和迭代速度。

Blast Radius

• 评估变更风险的核心维度
• 微服务和灰度发布缩小 Blast Radius
• CrowdStrike 蓝屏事件是 Blast Radius 失控的典型案例

SRE

• Google 提出，用软件工程方法做运维
• 核心概念：SLO、SLI、Error Budget
• SRE 不是运维的新名字，是一种工程文化

Blast Radius

—

SRE

用软件工程方法和自动化工具保障大规模系统可靠性的工程实践体系

Blast Radius

—

SRE

• 大规模系统的可靠性保障
• 运维自动化和 Toil 消除
• 服务级别目标的定义和管理

Blast Radius

Blast Radius 借用了军事术语，在 DevOps 和 SRE 中指系统故障或变更失败时的影响范围。缩小 Blast Radius 的策略包括：微服务架构（故障隔离在单个服务）、灰度发布（先部署到 1% 的用户）、Feature Flag（功能开关控制）、以及网络分段（限制故障传播）。2024 年 CrowdStrike 的全球蓝屏事件是 Blast Radius 失控的典型案例——一次更新影响了全球 850 万台电脑。

SRE

SRE 由 Google VP Ben Treynor 在 2003 年创立，核心理念是「用软件工程方法解决运维问题」。SRE 的关键实践包括：SLO（服务级别目标）定义可靠性标准、SLI（服务级别指标）量化实际表现、Error Budget（错误预算）在可靠性和迭代速度之间取得平衡。当 Error Budget 充足时加速发布，耗尽时冻结变更专注稳定性。SRE 文化强调自动化一切可自动化的工作，将 Toil（重复性手工操作）降到最低。