3. 业务影响分析（BIA）与风险评估

灾备方案不是从“买几台备用服务器”开始的，而是从“业务能承受多大的中断”开始的。业务影响分析（Business Impact Analysis，BIA）要回答三个问题：哪些业务功能最关键、它们依赖什么、停多久会造成多大损失。风险评估则进一步回答：这些依赖中哪些最可能出问题、后果有多严重。两者结合，才能推导出每个业务系统真正需要的 RTO（恢复时间目标）与 RPO（恢复点目标），形成可落地的需求矩阵。

一、识别关键业务功能：从业务能力而非服务器出发

BIA 的第一步是列出业务功能，而不是列出 EC2 实例或数据库。业务功能是“公司对外或对内必须持续提供的能力”，例如：电商下单与支付、订单履约与发货、会员登录与鉴权、客服工单受理、财务对账与结算、内部报表查询。每个功能都应指定一名业务负责人，由他确认中断影响，而不是由运维单方面判断。

识别时可用“收入影响、客户影响、合规影响、内部效率影响”四个维度打分。以示例评分（1～5 分，5 为最严重）为例：下单支付收入影响 5、客户影响 5、合规影响 3、内部效率影响 2；内部报表查询分别为 1、1、2、4。评分不是为了精确计算，而是为了把功能排出优先级，避免所有系统都被标成“最高优先级”。

二、梳理依赖关系：业务功能到技术组件的映射

关键功能确定后，要向下拆解依赖。一个业务功能通常依赖多层组件：接入层（Route 53、CloudFront、ALB）、应用层（ECS/EKS/Lambda）、数据层（RDS/Aurora、DynamoDB、ElastiCache）、集成层（SQS、SNS、EventBridge）、身份层（Cognito、IAM）、外部依赖（支付网关、短信服务商、物流接口）。依赖关系必须区分“强依赖”和“弱依赖”：支付网关不可用会直接阻断下单，属于强依赖；推荐服务不可用只影响转化率，属于弱依赖，可降级。

依赖梳理还要标注共享组件。例如多个业务功能共用同一个 Aurora 集群、同一个 VPC、同一个 KMS 密钥或同一个第三方支付通道。共享组件一旦故障，会同时影响多个功能，是风险评估中的重点对象。下图展示了从业务功能到技术依赖、再到 RTO/RPO 需求的推导关系。

三、量化停机成本：把“很严重”变成可比较的数字

停机成本要尽量量化，至少给出量级。常用拆解方式：

• 直接收入损失：每分钟订单数 × 客单价 × 毛利率。示例：某电商每分钟约 120 单，客单价 180 元，毛利率 25%，则每分钟毛利损失约 5400 元。
• 补偿与退款成本：中断后用户取消、优惠券补偿、客服人力增加。
• 合规与合同罚则：SLA 违约赔付、监管上报义务。
• 客户信任与流失：难以精确计算，可用“预计流失客户数 × 客户生命周期价值”做保守估算。

把上述项按小时累加，可得到“停机成本曲线”。曲线通常不是线性的：前 15 分钟可能只是体验下降，超过 1 小时后损失快速上升，超过 4 小时可能触发合同罚则。曲线的拐点就是 RTO 的重要参考。RPO 则对应“能丢多少数据”：订单数据丢失 5 分钟可能可接受，支付流水丢失 1 分钟都不可接受。

四、风险评估：可能性 × 影响

风险评估把“依赖项”与“故障场景”对应起来，评估发生可能性与影响程度。常见场景包括：单可用区故障、区域级故障、数据库误删、勒索软件、配置误发布、第三方支付网关中断、IAM 密钥泄露。评估时不要只写“可能发生”，要给出依据，例如“过去 12 个月发生过 2 次 AZ 级网络抖动”“支付网关近一年有 3 次 30 分钟以上中断”。

风险矩阵中，高可能性 + 高影响的场景应优先设计缓解措施。例如共享 Aurora 集群同时被下单、履约、对账依赖，一旦故障影响面极大，应优先考虑 Aurora Global Database 或跨区域只读副本；支付网关属于外部强依赖，应设计降级路径（如先落单后支付、切换备用通道）。

五、输出 RTO/RPO 需求矩阵

BIA 与风险评估的最终交付物是 RTO/RPO 需求矩阵。矩阵按业务功能或系统分层，通常分为 Tier 1～Tier 4。分层依据是停机成本与合规要求，而不是技术偏好。示例矩阵如下：

矩阵中的 RTO/RPO 是业务需求，不是技术承诺。技术团队需要评估当前架构能否满足，若不能满足，则要提出差距与改造方案。例如当前 Aurora 只有单区域多可用区，RPO 约 5 分钟，无法满足 Tier 1 的 1 分钟 RPO，就需要引入 Aurora Global Database 或变更数据捕获到跨区域流存储。