Resource Guide
数据大屏上线运维、SLA、容灾与恢复清单
摘要：这份清单用于数据大屏、BI驾驶舱和经营看板上线后的持续维护。它不预设统一的服务时段、备份周期或恢复指标，而是帮助项目方逐项确认远程运维、现场支持、驻场服务、SLA时间口径、数据运行、容灾、备份恢复、权限、变更和责任边界。
这份清单适合什么时候使用
项目验收前，可用它确认上线后由谁维护数据、服务、账号和备份；进入日常运行后，可按业务时效安排每日、每周、月度或季度检查；接口、服务器、证书、人员和供应商发生变化时，应更新对应台账；发布新版本或处理故障前后，还应留下备份、回滚、恢复和复盘记录。
| 使用时点 | 重点核对 | 建议输出 |
|---|---|---|
| 上线与验收前 | 责任人、监控、备份范围、恢复手册、维护边界 | 运维台账和交接确认记录 |
| 日常与定期检查 | 数据更新时间、任务、服务、容量、证书、账号 | 检查状态、证据和待处理问题 |
| 版本变更前后 | 影响范围、测试、备份、回滚条件、上线验证 | 变更申请和发布记录 |
| 故障恢复后 | 影响、恢复过程、数据完整性、根因和改进项 | 故障记录和复盘清单 |
备份和恢复演练不是一回事
备份解决的是“有没有可用副本”，恢复演练解决的是“能不能用这些副本把系统恢复起来”。数据库备份文件存在，并不代表代码、配置、上传文件、任务依赖和运行环境都能匹配。建议在双方约定的周期内，选择可控制影响的环境执行恢复，并检查页面访问、账号登录、关键数据、接口、定时任务和版本是否一致。
RPO 用来描述业务最多能接受丢失多长时间的数据，RTO 用来描述故障发生后希望在多长时间内恢复。它们应结合业务影响、数据更新频率、备份能力和恢复步骤确定。清单提供填写位置，但不替项目方给出统一数值。
清单字段预览
| 类别 | 代表性检查项 | 需要留下的证据 |
|---|---|---|
| 数据运行 | 数据源、接口、刷新任务、数据新鲜度、指标版本 | 任务记录、抽核结果和口径变更记录 |
| 基础设施 | 服务、容量、日志、域名证书、第三方服务 | 监控记录、到期时间和联系人 |
| SLA服务响应 | 故障等级、响应渠道、服务时段、升级联系人 | 服务约定、工单记录和响应复核 |
| 服务方式 | 远程运维、现场支持、驻场服务和客户自运维 | 适用条件、人员时段、到场与差旅边界 |
| 容灾预案 | 服务器故障、数据源停更、第三方接口异常、临时展示方案 | 预案文档、备用入口和演练记录 |
| 备份 | 代码配置、数据库、文件、保留周期、异地副本 | 最近成功时间、存储位置和失败处理记录 |
| 恢复 | RPO、RTO、恢复手册、演练、恢复后核验 | 演练记录、耗时、验证结果和改进项 |
| 监控告警 | 可用性、任务、数据异常、通知渠道、升级机制 | 告警测试和接收确认记录 |
| 账号安全 | 账号台账、权限复核、离职回收、审计日志 | 权限清单和回收结果 |
| 变更发布 | 影响评估、测试备份、回滚方案、上线验证 | 版本号、发布记录和业务确认 |
| 服务边界 | 维护范围、SLA、第三方责任 | 书面约定、联系人和排除项 |
SLA和容灾怎么写进清单
SLA字段建议记录故障等级、服务时段、首次响应方式、处理目标、升级联系人和不在维护范围内的事项。容灾字段建议按场景填写，例如服务器不可用、数据库损坏、数据源停更、第三方地图异常、证书过期或现场网络中断，并记录对应的恢复步骤、备用入口和业务通知方式。
对展厅、指挥中心和重要汇报类大屏，还可以补充临时展示方案：最近一次静态快照、离线演示包、备用只读报表或人工汇总文件。临时方案需要标注数据时间和适用场景，避免被误认为实时系统已经恢复。
远程运维、现场支持和驻场服务怎么写
| 方式 | 常见事项 | 需要单独记录 |
|---|---|---|
| 远程运维 | 日志、配置、接口、发布和使用协助 | 安全连接、账号、服务窗口和操作授权 |
| 现场支持 | 现场网络、显示控制、硬件和封闭环境问题 | 派单条件、入场、到场时间、差旅和联系人 |
| 驻场服务 | 持续值守、巡检、协调和现场处置 | 岗位、人数、班次、工具、替补、范围和费用 |
| 客户自运维 | 日常巡检、账号审批、业务数据和内容维护 | 培训、文档、权限、升级路径和交接记录 |
SLA还应把首次响应、恢复、最终解决和关闭确认分开。首次响应不代表系统已经恢复；需要到场或依赖第三方时，到场调度、路途和第三方处理时间也要单独记录。7×24和驻场都需要明确人员与服务窗口，不能由“提供维护”自动推定。
项目方和维护方分别负责什么
项目方通常负责确认业务影响、指标口径、数据源责任人、账号审批、可接受的数据丢失范围和恢复目标；维护方通常负责按约定执行监控、备份、恢复、变更和故障处理。服务器、网络、云服务、第三方接口和现场硬件可能由不同团队维护，因此清单中应写明真实责任人和升级顺序，不宜只写“技术负责”。
敏感账号、令牌和私钥不要以明文写入 CSV。可以记录账号用途、持有人、权限范围和保管位置，具体密钥通过企业认可的受控渠道保存与移交。
怎么开始填写
第一次使用时，可以先完成“基础信息、数据运行、备份、恢复和服务边界”五类高优先级字段，再逐步补充监控、安全和变更记录。状态栏可以使用“待确认、正常、存在风险、处理中、已完成”等统一值；证据栏填写监控地址、文档位置、工单编号或截图存放位置，避免只留下口头结论。
常见问题
这份运维清单应该由谁填写？
建议由业务负责人、数据负责人、系统管理员和开发维护方共同确认。每一项都应标明负责人，避免把所有事项笼统交给某一个岗位。
备份任务显示成功，是否就代表可以恢复？
不能。备份成功只说明任务产出了文件或副本，还需要通过恢复演练确认文件可读、版本匹配、依赖齐全，并能在目标环境完成关键功能和数据核验。
RPO 和 RTO 应该怎么填写？
RPO 记录业务最多能接受丢失多长时间的数据，RTO 记录故障后希望在多长时间内恢复。两者应由业务影响、数据更新频率和恢复能力共同确定，不宜直接套用统一数值。
除了数据库，还需要备份什么？
通常还要检查源代码、发布包、配置模板、数据库脚本、上传文件、三维模型、证书说明、运行时版本、构建说明和恢复手册，具体范围以项目实际依赖为准。
账号和密钥可以直接写进清单吗？
不建议记录明文密码、令牌或私钥。清单应记录账号用途、持有人、权限、保管位置和受控移交方式，敏感值应存放在企业认可的密码或密钥管理位置。
维护和新增需求怎么区分？
可以按已确认需求和验收标准判断。已有功能未按约定运行通常属于缺陷；新增页面、数据源、业务规则或角色范围通常需要单独评估。边界应在维护服务开始前写清。
远程运维、现场支持和驻场服务怎么区分？
远程运维通过安全连接处理日志、配置、接口和发布问题；现场支持针对现场网络、显示控制、硬件或封闭环境安排到场；驻场服务是在约定地点和时段持续安排人员。三者的条件、时段、差旅、岗位和费用应分别记录。
SLA首次响应、恢复和最终解决是同一个时间吗？
不是。首次响应表示已接收并开始判断，恢复表示核心业务或替代方案重新可用，最终解决表示根因修复并完成复核。到场和第三方处理时间也应单独记录。
SLA和容灾预案应该写进同一张清单吗？
可以先写进同一张运维清单，便于把故障等级、响应方式、恢复目标、联系人、临时展示方案和演练证据放在同一处管理；成熟后再拆分为独立的应急预案和服务协议附件。
相关资料
继续查看 企业数据大屏上线后如何维护、数据大屏权限、安全与审计怎么做、数据大屏验收常见漏项 和 数据可视化大屏开发服务。