1.
概述与适用范围
- 目标:保障马来西亚运行的体彩核心服务(业务API、开奖服务、投注入口、数据库)在故障时可在既定RTO/RPO内恢复。
- 适用范围:海外云/机房、混合云节点、负载均衡与数据库复制拓扑。
- 输出:故障分级、联系人清单、切换流程、验证脚本与演练计划。
2.
风险评估与目标设定(RTO/RPO)
- 步骤:列出所有服务,按业务影响打分(高/中/低);为高影响服务设定RTO≤15分钟、RPO≤5分钟(示例)。
- 产出:故障分类表、依赖矩阵(缓存、支付网关、开奖引擎)。
3.
基础设施与冗余架构设计
- 网络:使用多出口公网链路、BGP或双线机房;在马来西亚选择至少两个可用区或不同机房。
- 计算:应用部署采用至少两台节点+负载均衡(VIP/浮动IP或云LB);数据库使用主从/主主复制并启用故障转移工具(如 Patroni/Keepalived)。
- 存储:定期磁盘快照与异地复制,关键文件使用版本化对象存储。
4.
监控指标与告警策略
- 指标:系统(CPU、内存、磁盘IO、网络)、进程(服务存活、线程数)、应用(TPS、响应码分布、队列长度)、数据库(延迟、复制Lag、事务提交速率)。
- 告警:分级告警(警告/严重/紧急),通过SMS/电话/钉钉或PagerDuty推送;关键告警需多人确认并触发应急流程。
5.
故障检测与快速切换机制
- 健康检查:LB做二次探活(TCP/HTTP),应用实现自检接口(/healthz),定时探测并记录到监控。
- 切换策略:自动化优先(如主库故障触发Promote脚本),手动确认路径(若牵涉支付或开奖)。控制DNS TTL为60s以便必要时DNS切换。
6.
应急操作:逐步实操指南
- 发现与确认:查看监控告警 → 登录主机(ssh user@ip)→ 执行 top / free -m / iostat / ss 检查资源。
- 日志定位:journalctl -u
-n 200 或 tail -n 500 /var/log/app.log;grep 错误关键词并标注时间窗口。
- 试验重启:systemctl restart ;若属容器:kubectl rollout restart deploy/,观察Pod重建与就绪。
- 数据库措施:检查复制状态(MySQL: SHOW SLAVE STATUS\G;Postgres: SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn();),若主库挂,按脚本 promote-replica.sh 提升从库并修改应用指向(更新LB或修改配置并重载)。
- 回滚与记录:若切换失败,按回滚步骤恢复原状态并详细记录每一步(时间、命令、输出)。
7.
数据备份与恢复操作步骤
- 备份策略:每日全备+每15分钟增量(WAL/binlog),并做异地复制;定期执行restore演练。
- 恢复步骤:从最近合格备份恢复到备用实例(示例:restore tar → 恢复WAL/binlog → 启动数据库 → 验证表行数与关键交易ID),并运行一致性校验脚本(比对订单总量、投注流水)。
8.
运维监控最佳实践(问:如何降低误报并加快定位?)
- 答:优化阈值与抑制窗口(短时间内同类告警合并),为关键路径打点链路追踪(分布式追踪如Jaeger),在告警中包含诊断命令和初步日志片段,便于值班人员快速判断。
9.
问:出现跨区网络抖动,如何保障开奖与投注一致性?(答)
- 答:对关键交易使用幂等设计与事务日志同步;在网络不稳定期间将写流量降级到本地缓冲队列并异步同步(确保RPO策略),并在稳定后按时间顺序回放并用唯一交易ID去重。
10.
问:如何定期演练与改进预案?(答)
- 答:设立季度演练(桌面+实操),演练包括故障注入(模拟主库/网络/LB故障)、演练报告与问题打回改进清单,所有演练步骤写成Runbook并纳入SOP。
来源:体彩服务器马来西亚故障应急预案与运维监控最佳实践