宕机期间,用户无法访问服务,导致流量中断、交易失败、订单丢失和客户投诉。对电子商务、金融支付、API服务等具有实时性要求的业务,短时间宕机即可造成直接的收入损失和信用受损。
另外,宕机还可能引发合规与审计风险(例如数据无法按规定保留或访问),并导致SLA违约赔偿。长期看,频繁或长时间的宕机会影响品牌信任度并增加获客成本。
1. 收入损失(每分钟/每小时的平均交易额乘以停机时间)。 2. 客户流失率上升与品牌声誉损害。 3. 运维与恢复成本(加班、人力、第三方服务)。 4. 法律与合规罚款或审计成本。
技术原因包括网络骨干故障(光缆切割、运营商中断)、机房供电问题、虚拟化平台故障、硬件损坏、软件缺陷或配置错误、数据库死锁与磁盘耗尽。此外,DDoS攻击或依赖第三方服务的中断也会导致可用性下降。
非技术原因常见于运维流程、变更管理不到位、人为误操作、缺乏应急预案、合同与SLA条款不清晰等。灾难事件(火灾、洪水)和监管突发要求也可能导致业务中断。
网络、计算、存储、应用、运维与合规等多维度风险需要分别识别,并制定相应的检测与缓解策略。
案例描述:某电商在双11促销期间,托管在香港单一可用区的云主机因机房网络设备故障导致三小时宕机,期间超过20万次下单请求失败,直接损失及补偿费用合计数十万港币。
根因分析:单可用区部署、无异地容灾、数据库写入未做重试与幂等处理、备份恢复时间超过业务可承受范围、缺乏自动故障切换与流量削峰措施。
1. 单点故障风险不可接受;2. 事务设计需支持重试与幂等;3. 备份与演练必须验证RTO/RPO;4. 流量高峰需预置弹性扩展或CDN缓存。
推荐设计原则:多可用区与多区域部署(Active-Active或Active-Passive)、数据库主从异地同步、跨区负载均衡、采用CDN与边缘缓存来削峰。结合异步消息队列实现流量削峰与突发请求缓冲。
1. 自动化运维与基础设施即代码(IaC),保证可重复部署与快速恢复;2. 健康检查与自愈组件(自动替换故障实例);3. 定期全量与增量备份并演练恢复流程;4. 应用层实现幂等、事务重试与降级策略。
保证备份加密、访问控制与日志审计,符合数据主权与监管要求;合同中明确SLA、赔偿与恢复责任。
事件响应流程应包含监控告警、值班与升阶机制、临时缓解(流量分流、限流)、根因分析与恢复执行。制定详细的Runbook并定期演练,保证关键岗位熟练度与沟通链路畅通。
演练类型包括桌面演练、半自动恢复演练与全量切换演练。通过演练可以验证恢复时间目标(RTO)与恢复点目标(RPO),并发现流程与技术缺陷。
多区域高可用架构会增加固定成本(冗余资源、数据传输费用)。企业需评估每种服务中断带来的预计损失,按风险优先级投入,以达到性价比最优的方案。
选择云服务商时,应关注其历史可用性记录、SLA条款、支持能力、以及在香港及邻近区域的互备能力,并在合同中约定演练与演练支持条款。