基础架构 · 备份 / 监控 / 审计详细设计文档

版本: v0.1
日期: 2026-07-06
归属: 基础架构 / 备份 / 监控 / 审计

1. 模块定位与目标

为试产期所有关键数据、服务和操作提供可恢复、可观测、可追溯的保障底盘。备份保证数据不丢，监控保证异常可感知，审计保证操作可追责。

目标	说明
数据不丢	核心数据库、代码仓、制品仓每日备份，RPO ≤ 1 小时，RTO ≤ 4 小时。
异常可感知	关键服务宕机 / 资源告警 5 分钟内推送飞书，On-Call 可介入。
操作可追责	生产变更、高危命令、权限变更全部有操作人、时间、结果审计。
合规可导出	审计日志支持按时间段导出，满足内部合规和外部审查需求。

2. 执行计划

阶段	时间	交付物	Owner	工作量
P0 备份策略	0–14 天	核心数据库 / GitLab / 配置备份策略落地，验证恢复	云运维	1人×2周
P1 监控基础	15–35 天	Prometheus + Grafana 部署，核心 Node/K8S/DB 指标接入	平台运维	1人×3周
P2 告警接入	36–50 天	AlertManager + 飞书 Webhook 告警，On-Call 轮值配置	平台运维	1人×2周
P3 审计汇聚	51–75 天	操作审计日志（堡垒机/K8S Audit/GitLab/IAM）汇聚到 ES	平台运维	1人×3周
P4 日志平台	76–105 天	ELK/Loki 业务日志接入，异常检索和告警联动	平台运维+研发	2人×4周
P5 演练优化	106–150 天	季度灾难恢复演练，备份/监控/审计合规报告	云运维+安全	1人×3周

3. 困难点与复杂度分析

困难点	复杂度	应对
多云(阿里云+AWS+内网)统一监控汇聚	高	Prometheus 各环境独立采集，Thanos / Victoria Metrics 做跨区汇聚；Grafana 统一展示。
RTO 4 小时的恢复演练落地	高	备份恢复流程文档化，每季度做真实演练（恢复到隔离测试环境），演练报告留档。
审计日志量大，存储和检索成本	中	热数据 ES（90 天），冷数据 OSS 归档（1 年+），检索仅针对热数据，按需解冻冷数据。
告警噪音多导致 On-Call 疲劳	中	分级告警（P0/P1/P2），P0 电话/飞书双通道，P2 只邮件；建立告警复盘机制。
GitLab 备份恢复复杂（含 LFS/CI 数据）	中	使用 GitLab 官方 backup-cron，分 repo/config/uploads 分类备份，定期恢复验证。

4. 核心流程

flowchart LR
  subgraph Backup["备份"]
    A1["定时备份任务"] --> A2["导出 DB Dump / Git Bundle"]
    A2 --> A3["加密上传 OSS / S3"]
    A3 --> A4["备份校验 + 告警"]
  end
  subgraph Monitor["监控"]
    B1["Prometheus 采集"] --> B2["AlertManager 规则评估"]
    B2 --> B3{告警级别}
    B3 -->|P0| B4["飞书电话 + 消息"]
    B3 -->|P1| B5["飞书消息"]
    B3 -->|P2| B6["邮件"]
  end
  subgraph Audit["审计"]
    C1["操作事件(堡垒机/K8S/IAM)"] --> C2["日志采集 Agent"]
    C2 --> C3["ES 热存储(90天)"]
    C3 --> C4["OSS 冷归档(1年+)"]
  end

5. 系统架构

flowchart LR
  subgraph Sources["数据源"]
    DB["数据库"] 
    GITLAB["GitLab"]
    K8S["K8S Cluster"]
    BASTION["堡垒机"]
  end
  subgraph Collect["采集层"]
    PROM["Prometheus"]
    AGENT["Log Agent (Filebeat/Promtail)"]
    BACKUP_JOB["Backup CronJob"]
  end
  subgraph Store["存储层"]
    THANOS["Thanos / Victoria"]
    ES["ElasticSearch"]
    OSS["OSS / S3 (冷归档)"]
  end
  subgraph Present["展示 & 告警"]
    GRAFANA["Grafana Dashboard"]
    ALERT["AlertManager"]
    FEISHU_BOT["飞书 Bot"]
    KIBANA["Kibana / Grafana Loki"]
  end
  Sources --> Collect
  BACKUP_JOB --> OSS
  PROM --> THANOS --> GRAFANA
  PROM --> ALERT --> FEISHU_BOT
  AGENT --> ES --> KIBANA
  ES --> OSS

6. 关键技术决策

决策点	选择	理由
指标监控	Prometheus + Grafana	开源标准，K8S 原生支持，Exporter 生态成熟。
跨区指标汇聚	Thanos (首选) / VictoriaMetrics (备选)	Thanos 与 Prometheus 无缝集成，支持跨区 Query。
日志收集	Filebeat / Promtail	轻量，与 ES/Loki 集成成熟，支持多源日志。
日志存储	ElasticSearch (热) + OSS/S3 (冷)	ES 检索快，OSS 存储便宜；热冷分离控制成本。
备份存储	阿里云 OSS (国内) + AWS S3 (海外)	与各自云原生集成，备份异地存储满足容灾要求。
告警通道	AlertManager + 飞书 Webhook	团队已在飞书，告警直达，响应快。

7. 数据模型

模型	关键字段	说明
`BackupJob`	`id`、`target`、`type`、`schedule`、`retention`、`last_run_at`、`status`	备份任务定义。
`BackupRecord`	`id`、`job_id`、`size`、`checksum`、`storage_uri`、`verified`、`created_at`	备份执行记录。
`AlertRule`	`id`、`name`、`expr`、`level`、`channel`、`silence_period`	告警规则。
`AlertEvent`	`id`、`rule_id`、`triggered_at`、`resolved_at`、`notified_to`、`ack_by`	告警事件。
`AuditLog`	`id`、`actor`、`action`、`resource`、`result`、`ip`、`source`、`occurred_at`	统一操作审计。

8. 接口设计

接口	方法	说明
`/backups/jobs`	GET	备份任务列表及最近执行状态。
`/backups/records`	GET	备份记录查询，含校验状态。
`/backups/restore`	POST	触发恢复到测试环境（需审批）。
`/alerts/rules`	GET/POST	告警规则查询 / 创建。
`/alerts/events`	GET	告警事件查询及 ACK 状态。
`/audit/logs`	GET	审计日志查询，支持时间/actor/action 筛选。

9. 验收点

验收点	量化标准
备份覆盖	核心 DB / GitLab / 配置 100% 纳入备份，每日执行，校验通过。
恢复演练	每季度恢复演练，RTO ≤ 4 小时，RPO ≤ 1 小时，演练报告留档。
监控覆盖	核心服务 / Node / K8S / DB 指标 100% 接入 Prometheus。
告警时效	P0 告警 5 分钟内推送飞书，On-Call 确认 ≤ 15 分钟。
告警降噪	告警误报率 < 20%（按月统计），P2 以下不影响 On-Call 睡眠。
审计完整	生产变更 / 高危命令 / 权限变更 100% 有审计记录，可检索。

10. 风险与应对

风险	应对
备份未验证，恢复时发现损坏	每次备份后自动校验 checksum，每月抽样恢复验证，异常告警。
监控平台自身宕机（观测者失效）	监控组件高可用部署，另设心跳探测（外部 Uptime 工具）监控监控平台。
日志量爆炸导致存储费用失控	日志分级采集（ERROR 必采，DEBUG 按需），热数据 90 天 TTL 自动清理。
审计日志被篡改	审计日志写入后 append-only，不允许 update/delete，存储层权限最小化。