1.
步骤1:列出在日本机房运行的所有服务(Web、API、数据库、缓存、文件存储、消息队列),并标注依赖关系。
步骤2:为每个服务定义可接受的RTO(恢复时间目标)和RPO(数据丢失允许范围),例如:Web 5分钟、数据库RPO 1小时。
步骤3:对照RTO/RPO确定优先级,优先保证对外暴露的API与认证服务。
2.
步骤1:选择至少一个备援区域(近距离建议:新加坡/首尔,远距离建议:美西或欧洲),保证网络延迟可接受。
步骤2:按“无状态服务优先”原则把应用改造为无状态,使用环境变量和外部共享存储(S3/对象存储、分布式配置中心)。
步骤3:对会话进行集中化(Redis/ElastiCache/Cloud Memorystore),并配置跨区域复制或多写策略。
3.
步骤1(托管DB):启用云厂商的跨区域只读副本(如RDS跨区域只读),并准备自动或手动提升步骤。
步骤2(自建MySQL):开启GTID并设置主从复制,备机定期演练提升:STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO ...; START SLAVE(演练前务必在测试环境)。
步骤3:对象存储启用跨区域复制(S3 Replication),确保静态资源在全球可读。
4.
步骤1:将边缘流量引导至CDN(如Cloudflare、Fastly、阿里云CDN),利用Anycast吸收DDoS并做清洗。
步骤2:启用WAF规则与速率限制,针对常见攻击(HTTP Flood、Layer7)配置拦截阈值,日志保留以便取证。
步骤3:与云厂商/安全厂商签署应急联动(流量清洗、黑洞/灰洞策略),并准备开启“只读/静态页面”模式。
5.
步骤1:DNS采用低TTL(例如60秒)并使用支持健康检查和自动故障转移的DNS服务(如Route53、NS1、Cloudflare)。
步骤2:设置健康检查脚本(HTTP 200、TCP 端口、应用层校验),当日本节点失败时自动切到备援节点IP或CDN。
步骤3(进阶):使用全球加速服务(AWS Global Accelerator、GCP Cloud CDN/Global Load Balancer)或与CDN配合Anycast BGP,提高切换速度与稳定性。
6.
步骤1:应用层配置探针(/healthz),返回业务就绪信息而非简单存活,探针应检查下游依赖(DB、缓存)。
步骤2:配置自动扩缩容策略(CPU、内存、QPS、自定义业务指标),并将冷启动时间纳入容量计划。
步骤3:在流量激增或受到攻击时预先扩大边缘实例数或启用“保护模式”(只允许正常流量并黑洞异常请求)。
7.
步骤1:部署集中监控(Prometheus+Grafana/云监控),对流量、错误率、延迟、带宽进行阈值告警并推送到值班群和PagerDuty。
步骤2:编写并执行故障切换演练:停掉日本机房服务、观察DNS/Load Balancer切换时间、验证数据一致性和回滚流程。
步骤3:定期进行DDoS压力测试与Chaos工程(在受控环境),记录演练步骤和SOP以便复盘。
8.
问题:当监控显示日本机房流量异常且接口超时,我应第一步做什么?
回答:立即切换到“边缘防护 + 备区流量”策略:1) 启用CDN/清洗服务的严格模式;2) 通过DNS故障转移或Global Accelerator把流量导向备援区域;3) 通知运维启动数据库只读保护并开启备机提升流程;4) 同时拉起应急沟通频道。
9.
问题:备援数据库提升会造成数据丢失,如何最低化RPO?
回答:优先使用异地半同步或GTID复制,定期做binlog备份;切换前冻结主写入(短暂停止写流量或排队写请求),做最后一次binlog确认,然后执行提升脚本并验证应用指向新主库;切换后以异步方式回填历史数据并记录差异。
10.
问题:日本机房恢复上线后如何安全回流流量与数据?
回答:按照“先读后写、先小规模后全量”原则:1) 先把日本机房置为读节点并开始接收同步数据;2) 小流量回流测试若无异常逐步放开写权限;3) 等数据同步完成并在观测期内稳定再切换主流量;4) 做完整复盘并更新演练SOP。