目录
核心价值
目标
通过完整的SLA保障体系，确保数据平台的高稳定性和高可靠性，让业务部门放心使用数据进行决策。
- SLA承诺 - 明确的可用性、延迟、恢复目标
- 监控体系 - 三层监控指标 (业务/系统/资源)
- 告警规则 - 具体的告警规则与响应标准
- 应急流程 - P0级别的完整应急响应流程
- 故障恢复 - RTO/RPO设计与多层容灾方案
- 持续改进 - 事后总结与SLA评分卡
关键指标:
- 系统可用性: ≥99.5% (月故障<3小时)
- 数据延迟: <5分钟
- P0故障RTO: <2小时
- P1故障RTO: <1小时
- 故障恢复点: <1小时数据丢失
SLA定义与承诺
1.1 核心系统的SLA承诺
scss
┌────────────────────────────────────────────────────────────┐
│ 核心系统 SLA 承诺表 │
├────────────────────────────────────────────────────────────┤
│ │
│ 系统 可用性 数据延迟 故障恢复 优先级 │
│ (Available) (Latency) (RTO) │
│───────────────────────────────────────────────────────── │
│ Doris集群 99.5% <5分钟 <2小时 P0 │
│ (数据仓库) ≥2.88h/月 (99%时间) (RTO) │
│ 故障允许 (P95<3m) │
│ (P99<10m) │
│ │
│ Flink ETL 99.0% <5分钟 <1小时 P0 │
│ (流式处理) ≥4.32h/月 实时告警 (自动恢复) │
│ 故障 │
│ │
│ Kafka消息队列 99.5% 0延迟 <30分钟 P0 │
│ ≥2.88h/月 (消息持久化) │
│ 故障 │
│ │
│ POS API接口 99.0% <30秒 <1小时 P0 │
│ (业务系统) ≥4.32h/月 (超时告警) (与POS方协调) │
│ 故障 │
│ │
│ MySQL元数据库 99.5% <1秒 <30分钟 P1 │
│ (配置库) ≥2.88h/月 (本地缓存) (主从切换) │
│ 故障 │
│ │
│ Prometheus监控 99.0% <1分钟 <1小时 P1 │
│ (告警系统) ≥4.32h/月 (数据保留) (历史恢复) │
│ 故障 │
│ │
│ Grafana看板 99.0% <5秒 <1小时 P2 │
│ (可视化) ≥4.32h/月 (缓存) (UI切换) │
│ 故障 │
│ │
└────────────────────────────────────────────────────────────┘
注解:
可用性计算:
├─ 99.5% = 月可用时间 720小时 × 0.995 = 716.4小时
├─ 故障允许时间 = 720 - 716.4 = 3.6小时 ≈ 2.88小时
└─ 即: 每月允许故障不超过2小时58分钟
优先级定义:
├─ P0: 极严重，影响多个门店或财务数据，需立即处理
├─ P1: 严重，影响单个门店或部分功能，1小时内处理
├─ P2: 中等，影响用户体验但不影响业务，4小时内处理
└─ P3: 轻微，不影响主业务，无紧急处理要求1.2 服务等级界定
makefile
P0 - 紧急事件 (Severity: Critical)
定义:
├─ Doris无法查询 (整个集群宕机)
├─ POS数据无法采集 (24小时+)
├─ 财务数据错误 (与财务对不上)
├─ 用户数据泄露 (严重安全事件)
└─ 数据一致性破坏 (不可修复)
响应时间:
├─ 感知时间: 0秒 (自动告警)
├─ 响应时间: 5分钟内 (CDO、Tech Lead到场)
└─ 初步诊断: 15分钟内
恢复目标:
├─ RTO (Recovery Time Objective): <2小时
├─ RPO (Recovery Point Objective): <1小时
└─ 通知范围: CEO/CFO/CTO + 全体研发 + 业务方
─────────────────────────────────────────────────
P1 - 高优先级 (Severity: High)
定义:
├─ 单个查询性能下降 (>30秒)
├─ 数据延迟超过5分钟
├─ 部分BI报表不可用
├─ Flink任务故障 (1小时内修复)
└─ 告警不能正常推送
响应时间:
├─ 感知时间: 5分钟内 (自动告警)
├─ 响应时间: 30分钟内 (主要责任人+支持)
└─ 初步诊断: 1小时内
恢复目标:
├─ RTO: <1小时
├─ RPO: <30分钟
└─ 通知范围: CDO + 技术团队 + 相关业务方
─────────────────────────────────────────────────
P2 - 中等优先级 (Severity: Medium)
定义:
├─ 某个BI看板响应慢 (但能访问)
├─ 某个报表有小bug (数据基本正确)
├─ 告警延迟1-2小时
├─ 文档更新有误
└─ 用户体验问题 (但不影响功能)
响应时间:
├─ 响应时间: 4小时内
├─ 优先安排修复
└─ 可在工作时间内处理
恢复目标:
├─ RTO: <4小时
└─ 通知范围: 相关技术人员 + 提出者
─────────────────────────────────────────────────
P3 - 低优先级 (Severity: Low)
定义:
├─ UI布局小问题
├─ 文档笔误
├─ 功能优化建议
├─ 性能微小改进
└─ 用户界面美化
响应时间:
├─ 响应时间: 1周内
├─ 可统一收集后批量处理
└─ 列入下一个迭代计划
恢复目标:
├─ 无严格时间要求
└─ 通知范围: 产品/技术团队监控与告警体系
2.1 监控指标体系
erlang
┌────────────────────────────────────────────────────────────┐
│ 监控指标的"三层金字塔" │
├────────────────────────────────────────────────────────────┤
│ │
│ 第一层: 业务指标 (Business Metrics) │
│ └─ 最终用户关心的 KPI │
│ │
│ ┌─ 数据新鲜度 (Data Freshness) │
│ │ ├─ 最后更新时间 (Last Update Time) │
│ │ ├─ 数据延迟 (Data Latency) │
│ │ │ └─ 告警: >5分钟 (P1) │
│ │ └─ 实时数据覆盖率 │
│ │ │
│ ├─ 数据准确性 (Data Accuracy) │
│ │ ├─ DQ规则通过率 (%) │
│ │ │ └─ 告警: <95% (P1) │
│ │ ├─ 与源系统对账差异 (%) │
│ │ │ └─ 告警: >0.1% (P1) │
│ │ └─ 缺失数据率 (%) │
│ │ └─ 告警: >1% (P2) │
│ │ │
│ └─ 查询服务可用性 (Query Availability) │
│ ├─ 查询成功率 (%) │
│ │ └─ 告警: <99.5% (P1) │
│ └─ 平均响应时间 (ms) │
│ ├─ P95: 告警 >5000ms (P2) │
│ ├─ P99: 告警 >10000ms (P2) │
│ └─ Max: 告警 >30000ms (P1) │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ 第二层: 系统指标 (System Metrics) │
│ └─ 系统层面的性能与健康指标 │
│ │
│ ┌─ Doris集群健康 │
│ │ ├─ FE节点状态: Online/Offline │
│ │ │ └─ 告警: FE故障 (P0) │
│ │ ├─ BE节点状态: Healthy/Unhealthy │
│ │ │ └─ 告警: BE数 <副本数 (P0) │
│ │ ├─ 副本不健全表数量 │
│ │ │ └─ 告警: >0 (P1) │
│ │ └─ 存储容量使用率 │
│ │ ├─ 黄色: >80% │
│ │ ├─ 红色: >90% (P1) │
│ │ └─ 预留: 至少100GB可用空间 │
│ │ │
│ ├─ Flink任务健康 │
│ │ ├─ 任务状态: RUNNING/FAILED │
│ │ │ └─ 告警: FAILED (P0) │
│ │ ├─ Checkpoint成功率: (%) │
│ │ │ └─ 告警: <95% (P1) │
│ │ ├─ 背压指标 (BackPressure) │
│ │ │ └─ 告警: >0.5 持续1分钟 (P2) │
│ │ └─ 处理延迟 (Processing Latency) │
│ │ └─ 告警: >60秒 (P1) │
│ │ │
│ └─ Kafka集群健康 │
│ ├─ Broker状态: Leader/Follower │
│ │ └─ 告警: Broker故障 (P0) │
│ ├─ 副本数不足的分区 │
│ │ └─ 告警: >0 (P1) │
│ ├─ 消费延迟 (Consumer Lag) │
│ │ └─ 告警: >1000条消息 (P1) │
│ └─ 磁盘容量 │
│ └─ 告警: >85% (P2) │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ 第三层: 资源指标 (Resource Metrics) │
│ └─ 基础设施层面的资源使用 │
│ │
│ ┌─ CPU (处理器) │
│ │ ├─ 使用率 (%) │
│ │ │ ├─ 黄色: >70% │
│ │ │ └─ 红色: >90% (P2) │
│ │ └─ 上下文切换次数 (context switches) │
│ │ └─ 告警: 异常高 (P2) │
│ │ │
│ ├─ 内存 (RAM) │
│ │ ├─ 使用率 (%) │
│ │ │ ├─ 黄色: >80% │
│ │ │ └─ 红色: >95% (P1) │
│ │ ├─ GC频率 │
│ │ │ └─ 告警: Full GC >3次/分钟 (P1) │
│ │ └─ GC暂停时间 │
│ │ └─ 告警: >2秒 (P1) │
│ │ │
│ ├─ 磁盘 (Disk) │
│ │ ├─ 使用率 (%) │
│ │ │ ├─ 黄色: >80% │
│ │ │ └─ 红色: >95% (P1) │
│ │ ├─ I/O延迟 │
│ │ │ └─ 告警: 读/写 >50ms (P2) │
│ │ └─ 剩余可用空间 │
│ │ └─ 告警: <10GB (P1) │
│ │ │
│ └─ 网络 (Network) │
│ ├─ 带宽使用率 (%) │
│ │ └─ 告警: >80% (P2) │
│ ├─ 网络延迟 (Latency) │
│ │ └─ 告警: >50ms (P2) │
│ ├─ 数据包丢失率 (%) │
│ │ └─ 告警: >0.1% (P2) │
│ └─ 连接数 │
│ └─ 告警: 接近限制 (P2) │
│ │
└────────────────────────────────────────────────────────────┘2.2 告警规则示例
makefile
告警规则1: 数据延迟超标
告警名: data_latency_exceeded
严重级: P1
条件: (now() - max(last_update_time)) > 300秒
评估周期: 1分钟
继续期: 持续5分钟后触发
通知方式:
├─ 钉钉: @数据团队 "数据延迟超过5分钟"
├─ 短信: 发给Tech Lead
├─ 邮件: 数据团队和CDO
└─ 工单: 自动生成P1级别工单
────────────────────────────────────────────
告警规则2: 查询响应时间高
告警名: query_response_time_high
严重级: P2
条件: histogram_quantile(0.95, query_duration) > 5s
评估周期: 5分钟
继续期: 持续10分钟后触发
通知方式:
├─ 钉钉: @数据团队 "查询响应缓慢"
├─ 邮件: 数据团队和CDO
└─ 工单: 自动生成P2级别工单
可能原因:
├─ 大查询并发 → 检查: 当前查询队列数
├─ Doris节点故障 → 检查: BE节点状态
├─ 存储压力 → 检查: 磁盘I/O延迟
└─ 网络问题 → 检查: 网络延迟、带宽
────────────────────────────────────────────
告警规则3: 数据质量检查失败
告警名: data_quality_check_failed
严重级: P1
条件: dq_rule_pass_rate < 0.95
评估周期: 1小时
继续期: 持续2小时后触发
通知方式:
├─ 钉钉: @数据质量负责人 "数据质量告警"
├─ 邮件: 数据团队、业务方
└─ 工单: 自动生成P1级别工单，包含:
├─ 失败的DQ规则
├─ 失败数据量
├─ 失败的表
└─ 建议的处理方案
────────────────────────────────────────────
告警规则4: 业务异常
告警名: sales_anomaly_detected
严重级: P2
条件: (current_sales - 7day_avg) / 7day_avg > 50%
或 (current_sales - 7day_avg) / 7day_avg < -30%
评估周期: 1小时
通知方式:
├─ 钉钉: @运营团队 "销售异常预警"
├─ 邮件: 运营总监、CDO
└─ 自动分析: 提供可能原因
├─ 客流变化?
├─ 客单价变化?
├─ 新活动影响?
└─ 系统故障?应急响应流程
3.1 P0级别应急响应 (极严重故障)
r
┌────────────────────────────────────────────────────────────┐
│ P0 应急响应流程 (极严重故障处理) │
│ 目标: 0-2小时恢复 │
├────────────────────────────────────────────────────────────┤
│ │
│ T+0min ⏰ 触发告警 │
│ │ │
│ ├─ 自动触发: 告警规则判定 │
│ ├─ 手动触发: 人工发现问题 │
│ │ │
│ └─ 立即启动: │
│ ├─ 钉钉群大消息 @所有人 + 电话通知 │
│ ├─ 创建应急工单 (自动) │
│ ├─ 启动应急会议 (立即开启视频会) │
│ └─ 通知: CEO/CFO/CTO/CDO/Tech Lead │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ T+5min ⏱️ 故障定位 │
│ │ │
│ ├─ 组织: 现场指挥 (CDO) + 技术调查员3-4人 │
│ │ │
│ ├─ 快速诊断: │
│ │ ├─ 收集基础信息 │
│ │ │ ├─ 故障开始时间? │
│ │ │ ├─ 影响范围? (所有店/部分店/某个模块) │
│ │ │ ├─ 现象是什么? │
│ │ │ └─ 最近有什么变更? │
│ │ │ │
│ │ ├─ 收集日志数据 │
│ │ │ ├─ Doris: 查看FE/BE日志 │
│ │ │ ├─ Flink: 查看任务日志 │
│ │ │ ├─ 应用: 查看应用日志 │
│ │ │ └─ 系统: 查看系统日志 (CPU/内存/磁盘) │
│ │ │ │
│ │ └─ 快速假设与验证 │
│ │ ├─ 假设1: Doris崩溃? → 检查集群状态 │
│ │ ├─ 假设2: 网络问题? → 检查网络连接 │
│ │ ├─ 假设3: 磁盘满? → 检查磁盘空间 │
│ │ └─ 假设4: 内存溢出? → 检查内存使用 │
│ │ │
│ └─ 报告: T+5min时给出初步诊断 │
│ "故障原因: XXX, 正在采取措施" │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ T+15min 🔧 应急修复 │
│ │ │
│ ├─ 故障类型1: 硬件故障 │
│ │ ├─ 立即: 启动故障转移 (failover) │
│ │ ├─ 监控: Doris从3副本→1副本降级运行 │
│ │ ├─ 修复: 更换故障硬件 (IT部门) │
│ │ └─ 恢复: 副本恢复后恢复正常 │
│ │ │
│ ├─ 故障类型2: 软件故障 (Doris/Flink) │
│ │ ├─ 立即: 尝试重启故障服务 │
│ │ ├─ 监控: 重启后的健康状态 │
│ │ ├─ 如果还是故障: 回滚上次更新 │
│ │ └─ 检查: 更新中引入的bug │
│ │ │
│ ├─ 故障类型3: 数据问题 │
│ │ ├─ 立即: 隔离坏数据 │
│ │ ├─ 恢复: 从备份点恢复 (RTO <2小时) │
│ │ └─ 验证: 恢复后数据一致性 │
│ │ │
│ └─ 故障类型4: 应用问题 │
│ ├─ 立即: 发布hotfix或回滚上次发布 │
│ ├─ 验证: 测试修复 │
│ └─ 上线: 灰度上线或直接全量 │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ T+30min ✅ 恢复验证 │
│ │ │
│ ├─ 功能验证: │
│ │ ├─ 数据查询: 随机选几个查询验证 │
│ │ ├─ 实时采集: 检查数据延迟 │
│ │ ├─ BI看板: 检查报表刷新 │
│ │ └─ 告警: 测试告警通知 │
│ │ │
│ ├─ 性能验证: │
│ │ ├─ 查询性能: P95<5s │
│ │ ├─ 系统负载: CPU<70%, 内存<80% │
│ │ └─ 网络延迟: <50ms │
│ │ │
│ ├─ 数据验证: │
│ │ ├─ 数据完整: 对账无差异 │
│ │ ├─ 数据准确: DQ规则全部通过 │
│ │ └─ 时间性: 数据延迟<5分钟 │
│ │ │
│ └─ 报告: T+30min给出恢复确认 │
│ "系统已恢复正常，各项指标已验证" │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ T+1h 📊 故障总结 │
│ │ │
│ ├─ 立即通知: │
│ │ ├─ 钉钉: 故障已解决，影响时间¥xxx分钟 │
│ │ └─ 邮件: 详细事后报告将在24小时内发送 │
│ │ │
│ ├─ 后续工作: │
│ │ ├─ 持续监控: 接下来8小时加密监控 │
│ │ ├─ 应急日志: 记录所有操作和时间点 │
│ │ └─ 初步总结: 根本原因是什么? │
│ │ │
│ └─ 安排: 24小时内组织事后总结会 (postmortem) │
│ ├─ 参加人: 所有参与者 + 相关方 │
│ ├─ 内容: Timeline + Root Cause + Actions │
│ └─ 输出: 改进计划 (预防同类故障) │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ T+24h 📋 详细事后报告 │
│ │
│ 报告内容: │
│ ├─ 故障时间: 起始时间 & 持续时间 │
│ ├─ 影响范围: 几家店? 哪些功能? │
│ ├─ Root Cause: 根本原因分析 (5个Why) │
│ ├─ Timeline: 关键时间点 & 行动 │
│ ├─ Actions: 短期/中期/长期改进方案 │
│ ├─ 责任人: 每个action的owner和deadline │
│ ├─ 学到的经验: Lessons Learned │
│ └─ 附件: 日志、监控图表、诊断数据 │
│ │
│ 分发: CEO/CFO/CTO/CDO/相关业务方 │
│ 归档: Wiki知识库，便于查阅 │
│ │
└────────────────────────────────────────────────────────────┘3.2 应急响应的角色与职责
vbnet
┌────────────────────────────────────────────────────────────┐
│ 应急响应中的关键角色 │
├────────────────────────────────────────────────────────────┤
│ │
│ 现场指挥 (Incident Commander, IC) │
│ └─ 由CDO担任 (或CDO授权的Tech Lead) │
│ ├─ 职责: │
│ │ ├─ 宣布应急状态开始/结束 │
│ │ ├─ 组织人员和资源分配 │
│ │ ├─ 每15分钟汇报进展 │
│ │ ├─ 做出关键决策 (恢复方案选择) │
│ │ └─ 与高管和业务方沟通 │
│ │ │
│ └─ 权力: │
│ ├─ 可以打断任何人做其他事 │
│ ├─ 可以要求任何资源 │
│ ├─ 可以做"最高速度修复"的决定 │
│ └─ 所有人都必须听命令 (军事化管理) │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ 技术调查员 (Technical Lead) │
│ └─ 3-4名来自不同岗位的工程师 │
│ ├─ Doris/Kafka工程师 (集群与存储) │
│ ├─ Flink工程师 (流式处理) │
│ ├─ 应用工程师 (业务逻辑) │
│ ├─ 系统工程师 (基础设施) │
│ │ │
│ └─ 职责: │
│ ├─ 按分工收集诊断信息 │
│ ├─ 提出可能的原因和验证方法 │
│ ├─ 尝试修复方案 │
│ └─ 定期向IC汇报进展 │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ 沟通官 (Communications Lead) │
│ └─ 由PM或CDO的助理担任 │
│ ├─ 职责: │
│ │ ├─ 定期更新所有利益相关方 │
│ │ ├─ 维护应急通讯 (钉钉群、视频会议) │
│ │ ├─ 记录所有关键时间点 │
│ │ ├─ 向高管定时汇报 │
│ │ └─ 恢复后对外沟通 (道歉+说明+承诺) │
│ │ │
│ └─ 通讯模板: │
│ ├─ 故障确认: "我们发现了XXX问题，正在处理" │
│ ├─ 中期更新: "进展: 已找到原因，正在修复" │
│ ├─ 恢复通知: "系统已恢复，持续监控中" │
│ └─ 事后总结: "根本原因是XXX，已采取措施防止" │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ 备选角色 (On-Call) │
│ └─ 关键故障时的值班人员 │
│ ├─ 工程师On-Call: 周一值班表 │
│ │ └─ 24/7待命，可远程响应 │
│ │ │
│ ├─ CDO On-Call: 周一值班表 │
│ │ └─ 可以做关键决策 │
│ │ │
│ └─ 激励机制: │
│ ├─ On-Call补贴: ¥2000/周 │
│ ├─ 需要出动时额外奖金: ¥500/次 │
│ └─ 故障结束可申请compensatory time off (补休) │
│ │
└────────────────────────────────────────────────────────────┘故障恢复与容灾
4.1 RTO/RPO的设计
makefile
RTO (Recovery Time Objective) - 恢复时间目标
定义: 在发生故障时，系统从故障点到恢复到正常可用状态需要的最长时间
Doris数据仓库:
├─ 目标: RTO < 2小时
├─ 设计:
│ ├─ 快速故障转移 (3副本 → 2副本 → 可继续运行)
│ ├─ 自动告警 & 人工干预 (30分钟内)
│ ├─ 恢复脚本 & 自动化 (30分钟内完成)
│ └─ 验证 & 回滚 (30分钟内)
└─ 验证: 每月演练一次 (故障转移测试)
Flink流处理:
├─ 目标: RTO < 1小时
├─ 设计:
│ ├─ Checkpoint持久化 (状态恢复)
│ ├─ 任务自动重启 (YARN/K8s)
│ ├─ 告警通知 + 人工确认 (10分钟)
│ └─ 从checkpoint恢复 (20分钟)
└─ 验证: 每周人工触发任务故障，测试恢复
POS数据采集:
├─ 目标: RTO < 1小时
├─ 设计:
│ ├─ 本地缓存 (POS服务器本地数据缓冲)
│ ├─ Kafka持久化 (消息队列保留7天)
│ ├─ 快速切换备用采集源 (10分钟)
│ └─ 数据重传 & 对账 (30分钟)
└─ 验证: 模拟POS宕机，测试缓存和重传
───────────────────────────────────────────
RPO (Recovery Point Objective) - 恢复点目标
定义: 在发生故障时，可以接受的最大数据丢失量
Doris数据仓库:
├─ 目标: RPO < 1小时
├─ 设计:
│ ├─ 实时副本 (3份副本，任何时刻任意2份一致)
│ ├─ 定期备份 (每天凌晨2点完整备份)
│ ├─ 增量备份 (每小时增量备份)
│ └─ 备份位置: HDFS/NAS (异地存储)
└─ 验证: 每周验证备份可恢复
Flink流处理:
├─ 目标: RPO < 30分钟
├─ 设计:
│ ├─ Checkpoint间隔: 60秒
│ ├─ 保留最近3个checkpoint
│ ├─ Checkpoint存储: HDFS (高可用)
│ └─ 恢复: 从最新checkpoint恢复 (丢失<1小时数据)
└─ 验证: 定期测试checkpoint恢复
POS数据采集:
├─ 目标: RPO < 1小时
├─ 设计:
│ ├─ Kafka消息保留: 7天
│ ├─ 采集失败本地缓存: 24小时
│ ├─ 定期对账: 小时级
│ └─ 遗漏数据修复: T+1日
└─ 验证: 模拟消息丢失，测试恢复
───────────────────────────────────────────
多层容灾设计:
第1层: 应用层容灾
├─ 多副本存储 (3份副本)
├─ 自动转移 (检测故障自动切换)
└─ 故障隔离 (故障部分不影响整体)
第2层: 数据层容灾
├─ 每小时全量备份
├─ 增量日志保留 (支持1小时内任意恢复点)
└─ 异地备份 (与主集群不同机房)
第3层: 网络层容灾
├─ 多条网络链路 (主用+备用)
├─ 自动转移 (主链路故障自动切换备用)
└─ 故障检测 (心跳检测)
第4层: 基础设施层容灾
├─ 多数据中心部署 (可选, 后期)
├─ 硬件冗余
└─ 电力 & 网络冗余 (UPS, 双网络接入)4.2 备份与恢复流程
makefile
备份流程:
天级备份 (Daily Full Backup)
├─ 时间: 每天凌晨2:00-4:00
├─ 对象: Doris全量数据 + 元数据
├─ 目的地: /backup/doris_full/yyyymmdd/
├─ 保留策略: 保留最近7天全量备份 + 最近4个月月度备份
├─ 验证: 备份完成后自动校验 (checksum验证)
└─ 通知: 成功/失败通知运维团队
小时级增量 (Hourly Incremental)
├─ 时间: 每小时执行一次
├─ 对象: 上个小时新增/修改的数据
├─ 目的地: /backup/doris_incremental/hhmm/
├─ 保留策略: 保留最近7天的增量
└─ 用途: 支持任意时间点恢复
Checkpoint备份 (Flink & Kafka)
├─ Flink: 每分钟自动checkpoint
│ ├─ 存储: HDFS /flink/checkpoints/
│ ├─ 保留: 最近10个checkpoint
│ └─ 恢复: 任务故障后从最新checkpoint自动恢复
│
└─ Kafka: 消息持久化
├─ 保留: 7天消息历史
├─ 副本: 3份副本
└─ 恢复: 消费者可重置offset重新消费
───────────────────────────────────────────
恢复流程:
场景1: 单个表数据损坏
步骤1: 故障诊断 (5分钟)
├─ 识别受影响的表
├─ 确定损坏的时间范围
└─ 确定恢复点 (最近的好数据时刻)
步骤2: 备份选择 (10分钟)
├─ 如果<1小时: 从增量备份恢复
├─ 如果<1天: 从天备份恢复
└─ 如果>1周: 恢复困难，可能需要重新导入
步骤3: 恢复执行 (30分钟)
├─ 创建临时表存放恢复数据
├─ 从备份恢复数据到临时表
├─ 验证临时表数据
└─ 与原表切换 (原子操作)
步骤4: 验证与通知 (15分钟)
├─ 数据对账验证
├─ 查询测试
├─ 通知业务方恢复完成
总耗时: <1小时
───────────────────────────────────────────
场景2: Doris整个集群故障
步骤1: 故障诊断 (15分钟)
├─ 检查所有FE/BE节点状态
├─ 检查网络连接
├─ 查看错误日志
└─ 判断故障类型
步骤2: 应急恢复 (60分钟)
├─ 选项A: 重启故障节点
│ ├─ 如果节点重启后恢复 → 完成
│ └─ 如果仍然故障 → 选项B
│
├─ 选项B: 降级运行
│ ├─ 停用故障节点
│ ├─ 集群在2副本模式下运行 (降级但可用)
│ ├─ 派遣运维人员现场排查
│ └─ 同时购买或更换硬件
│
└─ 选项C: 从备份完全恢复
├─ 准备新的BE节点
├─ 从备份导入数据 (可能需要2-4小时)
├─ 副本构建 (1-2小时)
└─ 验证通过后上线
总耗时: 1-4小时 (取决于选择的方案)
───────────────────────────────────────────
场景3: 数据中心故障 (机房断网/断电)
现象: 整个Doris集群无法访问
应急措施 (此情况下RTO可能>2小时):
├─ 立即通知所有用户数据暂时不可用
├─ 启动容灾方案 (如有其他IDC的备份集群)
├─ 从异地备份恢复 (需要4-8小时)
├─ 恢复后的数据会丢失<1小时 (根据备份策略)
└─ 对用户进行赔偿 & 说明
预防措施:
├─ 多IDC部署 (后期规划, 初期可用NAS备份)
├─ 数据同城多份备份
└─ 异地备份 (至少一份)持续改进机制
5.1 事后总结会 (Postmortem)
makefile
每次P1及以上故障后，必须在24-48小时内召开事后总结会
会议组织:
组织方: CDO (负责组织与主持)
参加人:
├─ 故障处理的所有参与者 (技术/运维)
├─ 相关业务方负责人
├─ CDO/Tech Lead/PM
└─ 轮流邀请团队其他成员学习 (知识分享)
时间: 1.5-2小时
地点: 线上视频会议 (便于录制)
────────────────────────────────────────
会议议程:
1. Timeline回顾 (15分钟)
└─ 展示故障发生的完整时间线:
├─ 14:30 告警触发
├─ 14:35 人员集合
├─ 14:50 原因确认
├─ 15:20 修复执行
└─ 15:45 完全恢复
2. 事实陈述 (20分钟)
└─ 故障发生的客观事实:
├─ "发生了什么" (不是"为什么")
├─ 影响范围与影响时间
├─ 采取的应急措施
└─ 最终如何解决
3. Root Cause分析 (30分钟)
└─ 用"5个Why"分析根本原因:
├─ Why1: "系统故障了" 为什么?
│ 答: "内存溢出"
│
├─ Why2: "为什么内存溢出"
│ 答: "某个查询没有优化"
│
├─ Why3: "为什么没有优化"
│ 答: "在code review中没被发现"
│
├─ Why4: "为什么code review没发现"
│ 答: "reviewer不了解这个模块的性能影响"
│
└─ Why5: "为什么reviewer不了解"
答: "缺少性能测试和文档" ← ROOT CAUSE
└─ 最终认定: 根本原因是"缺少性能测试"
4. 行动项 (20分钟)
└─ 制定改进措施:
├─ 短期 (立即):
│ ├─ 优化该查询
│ ├─ 清理过期数据
│ └─ 增加内存
│
├─ 中期 (1周内):
│ ├─ 建立性能测试流程
│ ├─ 增加code review checklist
│ └─ 培训团队性能优化
│
└─ 长期 (1个月内):
├─ 建立自动化性能测试
├─ 建立性能基准
└─ 定期性能评审
└─ 每个Action必须有:
├─ 具体描述 (清晰、可测量)
├─ Owner (谁负责)
├─ Deadline (什么时间完成)
└─ Success Criteria (完成标准是什么)
5. 学到的经验 (15分钟)
└─ 讨论积极的方面:
├─ "响应速度很快，5分钟内集合了所有人" 好!
├─ "自动告警工作很好，及时发现了问题" 好!
├─ "团队协作很紧密，很快找到了原因" 好!
└─ "恢复流程清晰，不到1小时恢复" 好!
└─ 目的: 强化好的做法，提升团队信心
────────────────────────────────────────
输出物:
1. 事后报告 (Postmortem Report)
├─ 发给: 所有stakeholders + 归档Wiki
├─ 包含:
│ ├─ Executive Summary (1页概述)
│ ├─ Timeline & Facts (完整时间线)
│ ├─ Root Cause Analysis (5个Why + RCA)
│ ├─ Action Items (改进计划)
│ ├─ Lessons Learned (学到的经验)
│ └─ 附件 (日志、监控图表、代码diff等)
│
└─ 发送: 邮件通知所有人
"本周一14:30故障的事后报告已发送，请查收"
2. Action Items跟踪
├─ 记录在项目管理系统 (Jira/Trello)
├─ 每周进度跟踪 (在周会上报告)
├─ Deadline到期后验证完成情况
└─ 归档并标记为"Completed"
────────────────────────────────────────
注意事项:
✅ 正确的Postmortem:
├─ 不指责任何人 ("为什么这样做"而不是"你干了什么蠢事")
├─ 事实为基础 (而不是猜测和假设)
├─ 有具体的改进行动
├─ 有owner和deadline
├─ 后续会追踪完成情况
└─ 基调是学习而不是惩罚
❌ 错误的Postmortem:
├─ "是XX工程师的错" (指责个人)
├─ "应该防止这种故障" (没有具体方案)
├─ 没有行动项 (开会讨论完就没了)
├─ 没有owner (责任不清)
├─ "这种故障以后不会发生" (不现实)
└─ 只有惩罚，没有改进5.2 SLA监控与评分
erlang
月度SLA评分卡 (Monthly SLA Scorecard)
每月15日发布上个月的SLA评分:
┌──────────────────────────────────────────────────────┐
│ 2025年11月 数据平台SLA评分 │
│ │
│ 数据可用性 99.7% ✓ 目标: ≥99.5% │
│ 数据延迟 <5m ✓ 目标: <5分钟 │
│ 查询响应时间 P95<4s ✓ 目标: P95<5s │
│ 数据准确率 99.95% ✓ 目标: ≥99% │
│ 告警准确率 94% ⚠️ 目标: ≥95% (需改进) │
│ │
│ 总体评分: 95.2/100 (A级) │
│ │
│ 故障统计: │
│ • P0故障: 0次 (目标: 0次) ✓ │
│ • P1故障: 2次 (目标: <3次) ✓ │
│ └─ 11月5日 Kafka延迟 (30分钟内恢复) │
│ └─ 11月18日 查询卡顿 (1小时内恢复) │
│ • P2故障: 5次 (目标: <5次) ✓ │
│ • 平均MTTR: 42分钟 (目标: <1小时) ✓ │
│ • 平均MTTF: 3.2天 (目标: >3天) ✓ │
│ │
│ 改进方向: │
│ 1. 告警准确率需提升 (1pp差距) │
│ - 原因: 某个告警规则参数设置不合理 │
│ - 改进: 本周微调告警规则 │
│ │
│ 2. 查询性能仍有优化空间 │
│ - 某些复杂查询还是较慢 │
│ - 计划: 下月优化5个关键查询 │
│ │
│ 目标: 12月冲刺99分,争取S级评分 │
│ │
└──────────────────────────────────────────────────────┘
评分等级:
│ 等级 │ 分数 │ 定义 │ 对应奖励 │
├──────┼────────┼──────────────┼─────────────────────────┤
│ S │ 99-100 │ 优秀 │ 全队¥5000奖金 │
│ A │ 95-98 │ 良好 │ 全队¥3000奖金 │
│ B │ 90-94 │ 及格 │ 无奖金，但无扣分 │
│ C │ 80-89 │ 需改进 │ 每人扣¥500（激励改进）│
│ D │ <80 │ 严重不达标 │ 进行部门调查 │
└──────┴────────┴──────────────┴─────────────────────────┘