system_detail_design
1. 概述
1.1 术语
1.2 需求背景
1.3 目标
2. 系统业务分析
2.1 业务主流程
2.2 总体功能用例图
3. 模块详细设计
3.1 模块一
3.1.1 操作界面
3.1.2 用例图及描述
3.1.3 流程图或者时序图
3.1.4 类图
3.1.5 实现方案描述
3.1.6 涉及的表及存储结构
3.1.7 性能分析
3.1.8 测试分析及测试用例
4. 数据库设计
5. 现有系统影响分析
【可选，描述本次功能之外可能会有影响的功能点。这里是测试的一个关注点】
6. 系统间关系和影响
【可选】
6.1 公司对外部服务接口变更影响分析
【可以从以下方面进行分析：
公司对外提供的接口有没有变化，是否影响原来的客户？是否遵守原来的契约？这一点非常重要！
是否需要发布新的官方接口文档，规范，或SDK，Demo
外部接口新增加的内容如果被原有不需要的客户使用是否会有风险？
公司对外提供的接口将来可以撤销吗，有没有生命周期结束的时候？
项目的改造对原有接口的安全性有没有新的要求？
等等
】
6.2 系统之间服务变化影响分析
【可以从以下方面进行分析：
接口变更向前兼容吗？
服务提供的数据向前兼容吗？
变更的服务的稳定性有何要求？
】
6.3 系统之间依赖变化影响分析
【描述完成本系统要实现的功能时，它需要哪些外部系统提供的服务。
本系统整个系统会产生哪些影响。从业务访问量，事务量，数据库资源消耗，网络资源消耗等多个方面进行考虑。
描述本系统提供的那些服务正在被外部系统使用？此次是否会涉及到服务接口、服务规则的升级？外部系统如何适应这些变化？外部系统如何升级？，
描述本系统即将提供那些服务供外部系统使用？这些服务的完整性如何保证。
可以从以下方面进行分析：
服务之间的依赖有变化吗？是否合理
ESB的消息依赖是否有变化，是否合理？
ESB消息的处理是否能正确支持重试，是否合理？
可确保ESB的处理是否能正确支持重试，是否合理？
系统release的Jar包依赖是否有变化，是否合理？
依赖第三方jar包是否有重大变化，是否安全?
】
6.4 间接影响的系统
【本项目所影响的系统有没有发现间接被影响的系统？可能是支付宝的其它系统，也可能是合作伙伴，淘宝，阿里软件等兄弟公司的系统】
6.5 各产品线特有影响分析
【各个产品线或各个系统的相关人员可以整理各自的影响CheckList，加入到系分模板中，要求系分一定要做出检查，例如：
项目是否影响发送到积分营销系统的数据
项目是否影响发送到收费系统的数据
项目是否影响账务日切
项目是否影响给用户的邮件
等等
】
7. 运维分析
【可选】
7.1 数据库影响分析
【至少可以从以下方面进行分析，并通知dba：
新增表或库的数据量和io，事务数评估
原有表的数据量或io，事务数变化评估，有时候一个很不起眼的修改，甚至是页面上一个链接位置的调整都有可能导致最终某个表io，事务数的很大变化，不要忽视这一块，我们的数据库快受不了了。建议一个大表的io或数据量，事务数变化可能到达20%以上一定要事先告知dba并达成一致同意。
有没有影响历史数据迁移，有没有新的历史数据迁移计划
有没有导数据的计划
有没有初始化数据的计划
有没有上线前数据订正的计划
有没有停机维护的计划
】
7.2 网络硬件等影响分析
【至少可以从以下方面分析：
是否需要新的硬件投资，请和运维达成一致
是否需要新的运维配置新的域名，共享目录，端口，ftp服务等设置
是否对现有机房内网网络流量造成很大变化
是否对机房对外网网络流量造成很大变化
是否会对网络连接session数造成很大变化
是否需要防火墙策略等新的运维安全控制策略
是否需要新的jboss, jdk ,apache等支撑环境变化
是否对负载均衡有新的要求
是否对存储有新的要求，占用存储是否会有很大的变化
等等
】
7.3 发布期间影响分析
【至少可以从以下方面分析：
系统发布期间服务是否正常可用，
系统发布期间对用户有没有影响，
系统发布期间新老系统共存产生的数据有没有影响
各个系统发布顺序有没有要求
系统发布期间的兼容性是否建议专门测试
】
7.4 系统监控
【至少可以从以下方面分析：
系统发布和运行期间是否要对什么特殊有系统日志做监控
系统发布和运行期间是否要对原有业务做监控，以便知道影响
有没有制定新的一些重要的监控指标
系统是否在特定情况下需要一些报警，请和运维协商，运维需要特殊的处理吗
系统有没有考虑以后方便的扩充监控
监控发现严重问题是否有方法来得及挽回损失
】
7.5 业务监控
【至少可以从以下方面分析：
系统发布和运行期，是否需要对业务数据做监控
系统发布和运行期，是否需要对原有业务的数据做监控, 以便知道影响
有没有制定新的一些重要的监控指标
有没有影响支付宝大盘监控
】
7.6 系统日志
应用日志保证遵循《支付宝标准应用日志规范》，满足故障处理以及监控数据收集的需求。
如果有新增日志或已有日志的存储计划需要变更，请参考《日志存储规范》进行日志存储计划制定和日志名设定，详见http://www.alisoup.net/日志存储规范。
列出需要变更的日志名：
例如：cif-service.log
【其他方面可以从以下方面分析：
是否有新的需要长期归档的日志，请遵守命名规范
日志的量有没有明显变化
那些业务需要从日志中进行分析，以方便进行监控或排错，是否需要考虑
作为外部交互凭据的日志是否有归档，并和其它日志分开
公共的性能，摘要，错误日志是否有重大变化和影响
】
7.7 灾备要求
【至少可以从以下方面分析：
系统是否支持在灾难时在灾备机房运行，有没有影响，是否需要特殊配置
平时在灾备机房是否需要跑定时任务
系统有没有对灾备远程日志产生影响，是否需要新的灾备远程日志
灾难发生时，如果数据有部分丢失，可能会造成多大的损失，有没有补救措施，有没有措施可以减少损失和防止损失的扩大
系统和公司外部交互是否在灾备机房记录凭证
系统内部重要业务凭证或流水日志是否在灾备机房记录
】
8. 非功能性分析
【可选】
8.1 业务平衡检查分析
【至少可以从以下方面分析：
系统内部业务数据之间是否可以有合适的平衡检查机制
系统内外部凭证之间时候可以有合适的平衡检查机制
如果系统出现不平衡的数据，是否有方法可以检查可能的原因，有没有办法恢复
】
8.2 出错数据订正分析
【有时候会出现数据错了之后无法评估错误面，无法获得正确数据进行订正的情况，
本项目有没有考虑相关问题，至少可以从以下方面分析：
关键业务数据如果出错有没有办法根据日志或外部凭证评估影响
关键业务数据如果出错有没有办法根据日志或外部凭证获取要订正的数据
关键业务数据如果出错数据订正是否可以马上进行还是要等数据库不繁忙或等数据仓库能够提供支持的时候才可以进行
】
8.3 性能分析
【从业务的角度分析对性能的需求
对事务的响应时间（平均、最长）
吞吐量（例如每秒处理的事务数）
容量（例如业务所能容纳的客户或事务数）
资源利用：雇员数量、系统的存储容量等。
性能及容量必须符合《支付宝应用上线规范v1.0》标准。
[在性能分析的时候，通常关注业务链路的起点、连接点、受限制的资源点；此时要考虑单个请求的性能要求，要考虑群体情况下（并发情况下）的性能要求（在某一单个性能指标下的容量问题），要考虑该业务所占据整个系统业务容量的最大百分比。
在这个地方，我们最好指出那些点是影响系统性能的，原因是什么，场景是使那么？
大部分系统性能都是从使用者体验角度来衡量的。
】
8.3.1 响应的要求
【有没有具体的指标或要求？
有没有可能影响现有系统?
】
【避免使用统一的指标要求所有业务，可能各个系统use case，或各个业务有不同的性能要求，应该要分别描述。
】
8.3.2 业务吞吐量
【有没有具体的指标或要求？
有没有可能影响现有系统?
】
【避免使用统一的指标要求所有业务，可能各个系统use case，或各个业务有不同的性能要求，应该要分别描述。
】
8.4 并发访问控制分析
【至少可以从以下方面分析：
有没有资源需要并发访问控制？
有没有资源在并发控制出错的情况下会造成损失？
并发访问控制会不会造成性能瓶颈
】
8.5 可测性分析
【至少可以从以下方面分析：
系统依赖的外部环境是否可以测试，是否需要开发专门的mock系统
系统依赖的时间因素是否可以测试，是否需要开发专门的配合工具进行测试
系统依赖的时间，环境，权限等因素是否可以预发布确认，是否需要特别的准备才可以预发布确认。
系统依赖的特殊因素如果不能很好的测试或预发布确认，是否需要试运行策略？
】
8.6 强壮性分析
【此处应说明对组织可靠性的需求（从业务主角的角度来看）。建议如下：
精确度 – 指出输出中所需的精密度（分辨率）和精确度（按照某一已知的标准）。
用户量的变化对系统带来的影响
】
8.7 系统容错分析
可以从以下方面进行分析：
一、 系统所依赖的外部系统发生一些错误的时候，系统有没有相应的容错机制
例如，cif的cache不能使用的时候，cif能否正常运行，
收费不能使用的时候，交易能否继续进行
外部传入错误的数据的时候业务收到什么影响，
二、 系统所依赖的硬件网络等基础设施发生故障，系统有没有相应的容错机制
由于所选择的通信，存储等方面的不可确定的因素，以及在某一个临界点处导致的质变，需要我们在此处指出可能存在的风险以及解决方案。
通信层面常出故障：带宽太小，例如拨号系统。此处需要考虑传输的数据质量（大小问题）。
防火墙的限制，某些防火墙可能会过滤一些信息，导致数据不完整。
文件系统：文件系统损坏。
文件系统容量。
文件系统每个目录所能容纳的目录、文件数量的限制。
文件系统同时打开的句柄数的限制，间接影响并发行。
文件自身的损坏。
】
8.8 可用性要求分析
可用性 – 指出可用时间百分比 ( xx.xx%)、预期的使用小时数等。
【有没有指标可以分析可用性】
9. 技术风险评估
【必选】
9.1 资损风险评估
【可以从以下方面进行分析：
是否有金额处理的节点，包括前端和后端
是否有存在配置引起的资损风险
是否有外部异常引起的资损风险
是否有资金核对机制
】
9.2 安全风险评估
【可以从以下方面进行分析：
是否有合理的内部工作流程和权限保证公司内部业务操作
是否有机制保证客户敏感隐私数据不被内部泄漏：例如DBA不能看到明文的支付密码，信用卡信息等
是否有合理的设计保证内部关键操作不被误解和误操作
是否有合理的措施保证内部关键操作可以审计和监控，至少有日志
业务数据的机密性，关键业务数据、敏感业务数据，在WEB展示，传输过程中涉及到隐私和机密性，需要找出来，采取对应的措施予以解决
】
9.3 稳定性风险评估
【可以从以下方面进行分析：
是否有中间件异常引起的风险
是否有外部依赖系统异常的引起风险
是否有DB异常引起的风险
】
9.4 应急方案设计
【可以从以下方面进行分析：
是否有业务熔断开关
是否有细粒度的业务管控开关，防止风险蔓延
是否有异常的快速检测机制
】