Update nexus: fix conflicts and sync local changes

This commit is contained in:
Shen Wei
2026-04-26 12:06:50 +08:00
parent 191797c01b
commit f09834b5a5
2443 changed files with 254323 additions and 255154 deletions

View File

@@ -1,102 +1,102 @@
---
title: "Business Impact Analysis (业务影响分析)"
tags: [devops, disaster-recovery, risk-management, business-continuity, planning]
aliases: [BIA]
created: 2026-04-25
---
# Business Impact Analysis (业务影响分析)
**Business Impact Analysis (BIA)** 是确定不同应用系统故障对业务影响的分析过程,用于设定 [[RTO]] 和 [[RPO]] 目标以及分层保护策略。
## Aliases
- BIA
- 业务影响分析
## Definition
BIA 的核心问题:
1. 如果系统停机 1 小时,会发生什么?
2. 如果丢失过去 1 小时的数据,会发生什么?
回答这些问题,才能科学地确定每个系统的 RTO/RPO 目标,而非凭感觉设定"激进但无法实现"的目标。
## 关键分析问题
### 如果系统停机 1 小时?
- **收入损失**?损失多少?
- **客户不满**?影响多少客户?
- **员工受阻**?他们能绕过去工作吗?
- **合规风险**?法律问题?
### 如果丢失过去 1 小时的数据?
- **数据能重建吗**
- **是否涉及资金/交易**
- **用户会注意到吗**
- **合规要求**是否要求保留这些数据?
## Tiered Protection Model
基于 BIA 结论,将应用分为不同保护级别:
| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 |
|------|------|----------|----------|----------|
| **(1) Critical** | 支付处理、用户认证、核心产品功能 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 + 热备 |
| **(2) Important** | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag主要发布+ 业务时间监控 + 标准备份 |
| **(3) Nice-to-have** | 内部工具、开发环境、文档站点 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 + 每日备份 |
## 投资优先级
> "Most teams try to give everything Tier 1 treatment, which can lead to burnout. Be ruthless about what actually matters to your business. You can't do *everything*."
### Tier 1 投资
- [[Feature Flag]] + 自动化监控
- 自动化告警(支持 3AM 叫醒)
- [[Kill Switch]] + 备用路径就绪
- 近实时数据复制
### Tier 2 投资
- [[Feature Flag]](主要发布场景)
- 业务时间监控
- 文档化的回滚程序
- 小时级备份
### Tier 3 投资
- 基础监控
- 手动恢复程序
- 每日备份
- 期望最好的结果
## BIA 与成本收益
> "Do the math honestly. What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it. You're better off accepting some downtime and investing in faster recovery."
| 系统停机损失 | 合理灾备投资上限(年化) |
|-------------|------------------------|
| $10K/小时 | $100K/年 |
| $100K/小时 | $1M/年 |
**关键洞察**:预防和恢复的成本必须与实际业务损失相匹配。
## BIA 与 [[Feature Flag]] 的关系
BIA 结论指导 Feature Flag 的使用策略:
- **Tier 1 系统**:必须有 Kill SwitchProgressive Rollout 强制
- **Tier 2 系统**:建议 Feature Flag 主要发布场景
- **Tier 3 系统**:根据 ROI 决定是否使用 Feature Flag
## Related Concepts
- [[RTO]] — BIA 结论决定 RTO 目标
- [[RPO]] — BIA 结论决定 RPO 目标
- [[Feature Flag]] — 基于 BIA 分层保护的技术手段
- [[Kill Switch]] — Tier 1 系统的必备应急机制
- [[Disaster Recovery]] — BIA 是灾备规划的基础
- [[Risk-Mitigation]] — BIA 是风险管理的一部分
## Sources
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
---
title: "Business Impact Analysis (业务影响分析)"
tags: [devops, disaster-recovery, risk-management, business-continuity, planning]
aliases: [BIA]
created: 2026-04-25
---
# Business Impact Analysis (业务影响分析)
**Business Impact Analysis (BIA)** 是确定不同应用系统故障对业务影响的分析过程,用于设定 [[RTO]] 和 [[RPO]] 目标以及分层保护策略。
## Aliases
- BIA
- 业务影响分析
## Definition
BIA 的核心问题:
1. 如果系统停机 1 小时,会发生什么?
2. 如果丢失过去 1 小时的数据,会发生什么?
回答这些问题,才能科学地确定每个系统的 RTO/RPO 目标,而非凭感觉设定"激进但无法实现"的目标。
## 关键分析问题
### 如果系统停机 1 小时?
- **收入损失**?损失多少?
- **客户不满**?影响多少客户?
- **员工受阻**?他们能绕过去工作吗?
- **合规风险**?法律问题?
### 如果丢失过去 1 小时的数据?
- **数据能重建吗**
- **是否涉及资金/交易**
- **用户会注意到吗**
- **合规要求**是否要求保留这些数据?
## Tiered Protection Model
基于 BIA 结论,将应用分为不同保护级别:
| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 |
|------|------|----------|----------|----------|
| **(1) Critical** | 支付处理、用户认证、核心产品功能 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 + 热备 |
| **(2) Important** | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag主要发布+ 业务时间监控 + 标准备份 |
| **(3) Nice-to-have** | 内部工具、开发环境、文档站点 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 + 每日备份 |
## 投资优先级
> "Most teams try to give everything Tier 1 treatment, which can lead to burnout. Be ruthless about what actually matters to your business. You can't do *everything*."
### Tier 1 投资
- [[Feature Flag]] + 自动化监控
- 自动化告警(支持 3AM 叫醒)
- [[Kill Switch]] + 备用路径就绪
- 近实时数据复制
### Tier 2 投资
- [[Feature Flag]](主要发布场景)
- 业务时间监控
- 文档化的回滚程序
- 小时级备份
### Tier 3 投资
- 基础监控
- 手动恢复程序
- 每日备份
- 期望最好的结果
## BIA 与成本收益
> "Do the math honestly. What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it. You're better off accepting some downtime and investing in faster recovery."
| 系统停机损失 | 合理灾备投资上限(年化) |
|-------------|------------------------|
| $10K/小时 | $100K/年 |
| $100K/小时 | $1M/年 |
**关键洞察**:预防和恢复的成本必须与实际业务损失相匹配。
## BIA 与 [[Feature Flag]] 的关系
BIA 结论指导 Feature Flag 的使用策略:
- **Tier 1 系统**:必须有 Kill SwitchProgressive Rollout 强制
- **Tier 2 系统**:建议 Feature Flag 主要发布场景
- **Tier 3 系统**:根据 ROI 决定是否使用 Feature Flag
## Related Concepts
- [[RTO]] — BIA 结论决定 RTO 目标
- [[RPO]] — BIA 结论决定 RPO 目标
- [[Feature Flag]] — 基于 BIA 分层保护的技术手段
- [[Kill Switch]] — Tier 1 系统的必备应急机制
- [[Disaster Recovery]] — BIA 是灾备规划的基础
- [[Risk-Mitigation]] — BIA 是风险管理的一部分
## Sources
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]