1. 交付目标与范围界定
Redis实时数据平台交付的第一个动作，不是装Redis、不是调参数，而是把"交付什么、不交付什么、做到什么程度算完成"这三件事写清楚。很多项目后期扯皮、验收卡壳，根源都在这一步：甲方以为包含双活容灾，乙方只报了单机房主从；甲方以为要对接全部业务系统，乙方只承诺三个核心场景。范围一旦模糊，工期、成本、责任都会失控。因此本章的核心产出是一份交付范围说明书，它同时约束甲乙双方，也是后续所有设计、部署、测试、验收工作的基准线。
一、交付目标：从业务价值倒推技术目标
交付目标不能写成"部署一套Redis集群"这种技术动作，而要从业务价值出发，再落到可度量的技术指标。以某电商实时数据平台为例，其业务诉求是"大促期间商品详情页的库存、价格、销量必须秒级一致，且不能因缓存故障导致页面不可用"。由此倒推出三层目标：
- 业务目标：支撑峰值 8 万 QPS 的读请求，库存扣减结果在 1 秒内对全站可见，缓存层可用性不低于 99.95%。
- 技术目标：Redis 集群读写延迟 P99 小于 5ms，主从切换在 30 秒内完成，热点 Key 不引发单分片过载。
- 交付目标：完成 3 套环境（开发、预发、生产）部署，输出部署文档、监控看板、应急预案，并通过压测与故障演练验收。
这三层目标必须逐级对齐。如果业务只要求"可用性 99.9%"，却按 99.99% 去设计双活，就是过度交付，成本会翻倍；反之，业务要求"资金类数据强一致"，却只做异步主从，就是交付不足，上线即事故。目标定得准，范围才收得住。
二、业务边界：哪些场景进，哪些场景不进
业务边界回答的是"这套平台服务谁、服务哪些业务"。建议用一张场景清单来界定，每个场景标注数据特征、访问模式、一致性要求和优先级。以下是一个示例清单（数据为教学假设，非实测）：
| 业务场景 | 数据特征 | 访问模式 | 一致性要求 | 优先级 |
|---|---|---|---|---|
| 商品库存扣减 | 热点写、强一致 | 读写混合，写占比高 | 强一致 | P0 |
| 商品详情缓存 | 读多写少、可容忍短暂旧值 | 高并发读 | 最终一致 | P0 |
| 用户会话 Session | 读写均衡、有 TTL | 随机读写 | 最终一致 | P1 |
| 排行榜/计数器 | 写密集、允许近似 | 高频自增 | 最终一致 | P1 |
| 订单流水归档 | 持久化要求高 | 批量写 | 强一致 | P2 |
边界之外要明确写出"不纳入本期"的内容，例如：不承载订单主库、不做跨地域双活、不替代消息队列、不负责业务侧缓存穿透治理。把这些写进说明书，比写"包含哪些"更能减少后期争议。
三、技术边界：能力范围与约束条件
技术边界界定平台"能做什么、不能做什么、依赖什么"。它通常包含四类约束：
- 部署形态：本期采用 Redis Cluster 三主三从，单机房部署，暂不跨机房。
- 数据规模：总内存上限 192GB，单 Key 不超过 10KB，单分片不超过 64GB。
- 接口协议：仅提供 Redis 原生协议与统一 SDK，不额外封装 HTTP 网关。
- 依赖条件：依赖现有监控体系（Prometheus + Grafana）、依赖 CMDB 提供机器信息、依赖网络团队开通 6379 与集群总线端口。
技术边界还要写清"责任分界"。例如：Redis 平台团队负责实例可用性与性能，业务团队负责 Key 设计、TTL 设置与缓存穿透防护；网络延迟由网络团队保障，平台只做监控告警。责任不清，故障时就会互相推诿。
四、验收标准：可量化、可复现、可判定
验收标准是范围说明书的"牙齿"。它必须可量化、可复现、可判定，避免"运行稳定""性能良好"这类无法验证的表述。建议从功能、性能、可靠性、可运维性四个维度定义，每条都给出验证方法。下图展示了从交付目标到验收判定的完整关系：
以性能验收为例，不能只写"性能达标"，而要写成：在预发环境使用 redis-benchmark 模拟 8 万 QPS、读写比 7:3、Value 平均 2KB 的负载，持续 30 分钟，采集 P99 延迟，要求小于 5ms，且无节点内存超过 80%。可靠性验收则写成：手动 kill 主节点，观察哨兵或集群自动切换，记录从故障发生到新主可写的时间，要求小于 30 秒，且切换后数据条数与切换前一致。每条标准都对应一个可执行的验证动作，验收时逐条打勾即可。
五、交付范围说明书的结构
把上述内容固化成一份文档，建议包含以下字段，可直接作为模板使用：
交付范围说明书（示例结构）
1. 项目背景与业务诉求
2. 交付目标（业务/技术/交付三层，含量化指标）
3. 业务边界
3.1 纳入场景清单（场景、数据特征、一致性、优先级）
3.2 排除事项清单
3.3 责任分界表（平台方 / 业务方 / 网络方）
4. 技术边界
4.1 部署形态与拓扑
4.2 数据规模与Key约束
4.3 接口协议与依赖条件
5. 验收标准
5.1 功能验收项与验证方法
5.2 性能验收项与压测方案
5.3 可靠性验收项与演练方案
5.4 可运维验收项与检查清单
6. 变更管理：范围变更需双方书面确认
7. 双方签字确认
完成本章工作后，你应当得到一份经双方确认的交付范围说明书，其中每个目标可度量、每条边界有清单、每项验收有方法。它是后续容量规划、集群部署、监控建设、压测演练的起点，也是项目结束时判定"是否交付完成"的唯一依据。范围清，则全程稳；范围糊，则步步险。