102 lines
3.9 KiB
Markdown
102 lines
3.9 KiB
Markdown
---
|
||
title: "Kill Switch (应急切断开关)"
|
||
tags: [devops, disaster-recovery, reliability, feature-management, emergency-response]
|
||
created: 2026-04-25
|
||
---
|
||
|
||
# Kill Switch (应急切断开关)
|
||
|
||
**Kill Switch**（应急切断开关）是 [[Feature Flag]] 的一种紧急用法——在生产环境出现故障时，无需重新部署代码即可绕过或关闭故障组件的机制。Kill Switch 是 [[High Availability]] 的软件层保障。
|
||
|
||
## Definition
|
||
|
||
Kill Switch 是部署在关键系统路径上的功能开关，用于在紧急情况下将流量切换到备用路径、备用组件或降级服务，从而实现秒级 RTO。
|
||
|
||
## Core Use Cases
|
||
|
||
| 场景 | Kill Switch 动作 | RTO |
|
||
|------|-----------------|-----|
|
||
| 支付网关异常 | 切换到备用支付提供商 | 秒级 |
|
||
| 搜索结果异常 | 回退到旧搜索算法 | 秒级 |
|
||
| AI 模型产生幻觉 | 切换回上一版本模型 | 秒级 |
|
||
| 数据库迁移造成延迟 | 禁用新迁移相关功能 | 秒级 |
|
||
| 第三方 API 超时 | 切换到缓存数据或模拟响应 | 秒级 |
|
||
|
||
## 与传统回滚的对比
|
||
|
||
| 维度 | 传统部署回滚 | Kill Switch |
|
||
|------|-------------|--------------|
|
||
| 触发时间 | 分钟到小时 | 秒级 |
|
||
| 数据影响 | 可能丢失新事务数据 | 不触碰数据层 |
|
||
| 故障窗口 | 整个回滚期间用户受影响 | 切换完成后立即恢复 |
|
||
| 操作复杂度 | 需要 CI/CD 流程重新部署 | 配置变更，点击开关 |
|
||
| 适用范围 | 全局，影响所有用户 | 可定向（地区/用户群/设备） |
|
||
|
||
## Kill Switch 的价值
|
||
|
||
> "Instead of debugging under pressure while users suffer, you flip a switch and fix the problem properly later. Everybody wins."
|
||
|
||
**传统方式**：在压力下调试 → 用户持续受损 → 时间窗口内无法保证修复质量
|
||
|
||
**Kill Switch 方式**：立即止血 → 切换到安全状态 → 有时间从容分析问题根源
|
||
|
||
## 设计原则
|
||
|
||
### 1. 识别关键路径
|
||
- 支付流程
|
||
- 用户认证
|
||
- 核心数据写入
|
||
- 第三方依赖调用
|
||
|
||
### 2. 预设备用路径
|
||
- 备用支付提供商
|
||
- 旧版本算法
|
||
- 缓存数据
|
||
- 降级服务（Degraded Mode）
|
||
|
||
### 3. 可观测性优先
|
||
- Kill Switch 切换前需要明确知道发生了什么
|
||
- 监控指标、告警、日志必须到位
|
||
- 切换后需要持续监控备用路径的健康状态
|
||
|
||
### 4. 文档化
|
||
- 每个 Kill Switch 的触发条件需要事先定义
|
||
- 团队成员需要知道开关在哪里、如何使用
|
||
- 定期演练（Chaos Engineering）
|
||
|
||
## Kill Switch 与 [[RTO]]/[[RPO]]
|
||
|
||
Kill Switch 直接影响 RTO 和 RPO：
|
||
|
||
- **RTO**：从小时级降至秒级（配置变更，不需要代码部署）
|
||
- **RPO**：保持近零（不触发数据回滚，不丢失新事务）
|
||
|
||
## Kill Switch vs. Circuit Breaker
|
||
|
||
| 维度 | Kill Switch | Circuit Breaker |
|
||
|------|-------------|-----------------|
|
||
| 触发方式 | 手动（人为决策） | 自动（基于错误率阈值） |
|
||
| 适用场景 | 已知故障、有预案 | 未知故障、无预期 |
|
||
| 灵活性 | 高（可指定备用路径） | 中（自动跳转到 fallback） |
|
||
| 协同需求 | 需要备用方案就绪 | 自动感知系统压力 |
|
||
|
||
## 实践建议
|
||
|
||
1. **不要过度设计 Kill Switch**：每个关键路径设计 1-2 个关键开关即可
|
||
2. **开关命名要语义化**：`kill_payment_v2` 而非 `flag_42`
|
||
3. **测试 Kill Switch**：定期在非紧急情况下测试开关是否正常工作
|
||
4. **监控开关状态**：确保知道哪些开关处于开启/关闭状态
|
||
|
||
## Related Concepts
|
||
|
||
- [[Feature Flag]] — Kill Switch 是 Feature Flag 的紧急用法
|
||
- [[RTO]] — Kill Switch 将 RTO 从小时降至秒级
|
||
- [[RPO]] — Kill Switch 保护 RPO（不丢失数据）
|
||
- [[High Availability]] — Kill Switch 是 HA 的软件层保障
|
||
- [[Disaster Recovery]] — Kill Switch 是现代灾备的重要工具
|
||
- [[Micro-Recovery]] — Kill Switch 实现 feature 级别的精准恢复
|
||
|
||
## Sources
|
||
|
||
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
|