系统应用全方面评估维度，全面评测一个系统。

Posted 2021-09-07 liuxiaoddd

主要涵盖以下层面，全方面评价一个系统的稳健性。

1、联机交易系统性能
2、批处理系统性能
3、容量估计
4、应用扩展能力
5、应用可用性
6、交易数据一致性
7、应用可靠性
 

部分指标如下表，全面评价的下载链接为：

https://download.csdn.net/download/liuxiaoddd/21357478

二级分类	指标	技术风险评估检查项
联机交易系统性能	应用处理性能	交易高峰期的成功率是否有明显下降趋势？
联机交易系统性能	应用处理性能	交易高峰期的平均响应时间是否存在明显增长的趋势？
联机交易系统性能	应用处理性能	交易的平均响应时间是否存在持续增长的趋势？
联机交易系统性能	应用处理性能	是否会进行压力测试（新建交易系统、交易系统对热点功能的修改、重要功能）
联机交易系统性能	应用处理性能	对于存在批量处理的系统（包括日终批量、联机批量），是否已经考虑对联机交易的影响？
联机交易系统性能	应用处理性能	系统内部处理是否采用异步框架，每一个处理阶段是否设置了不同的线程池？
联机交易系统性能	应用处理性能	对于大结果集的操作是否具备分页或条数控制机制？
联机交易系统性能	应用处理性能	对大数据量查询，是否具备必输项限制、模糊查询消除/控制机制？
联机交易系统性能	应用处理性能	对大数据量查询，是否具备联机批量返回机制？
联机交易系统性能	应用处理性能	是否缺乏对大数据量查询重复提交的控制手段？
联机交易系统性能	应用处理性能	是否使用了连接池机制访问数据库
联机交易系统性能	应用处理性能	数据导入或修改是否会因锁的原因等影响联机业务处理
联机交易系统性能	应用处理性能	是否进行了热点资源识别，对其并发操作进行预估，对代码进行分析.如账号、流水号、红包
联机交易系统性能	应用处理性能	是否存在大对象输出
联机交易系统性能	数据库性能	是否存在索引与数据表共用表空间的情况？
联机交易系统性能	数据库性能	是否存在直接关联2个及以上大数据量（百万记录以上）表查询的情况？（特别是在日间处理中）
联机交易系统性能	数据库性能	是否未分离系统联机业务数据和历史数据？（例如分表、分库、分实例、物理分离）
联机交易系统性能	数据库性能	是否存在历史数据和实时数据未分离的情况？
联机交易系统性能	数据库性能	对于大数据量表是否存在未建索引或者无效的索引（主要查询条件与索引列不匹配），导致全表扫描？
联机交易系统性能	数据库性能	是否没有定期进行数据库的统计更新？
联机交易系统性能	数据库性能	是否存在主要交易查询或更新条件与数据库表的索引设置不一致？
联机交易系统性能	数据库性能	应用程序是否支持可以同时打开两个或两个以上周期的文件，按日期使用对应的文件，避免使用一个文件时的重复打开、关闭。（使用周期文件机制的，适用此要求）
联机交易系统性能	数据库性能	是否使用分区、分片、拆分为周期文件等策略优化大数据量表/文件的存储？单张表数据量超过500万行时可考虑分区或分表，超过1000万行时须分区或分表。
联机交易系统性能	数据库性能	对频繁更新的数据库表，是否建立了多个索引？
联机交易系统性能	数据库性能	大数据、多表的sql语句是否经过语句执行分析和调优
联机交易系统性能	数据库性能	数据库操作尽量少使用多表关联，原则上不超过三张表关联
联机交易系统性能	数据库性能	禁止物理删除数据记录
联机交易系统性能	其它性能	对历史数据是否采取分级存储策略？
联机交易系统性能	其它性能	对第三方产品（中间件,OS，DB等）是否直接采用默认参数，未根据实际情况进行调整？（例如JVM、数据库连接池等）
联机交易系统性能	其它性能	应用日志是否存在“DEBUG”或"Info"或"Warning"等多个模式？日常交易处理期间，是否考虑到合适的日志级别，减少日志量太大对正常交易的影响？
联机交易系统性能	其它性能	系统是否对日志文件大小进行限制？日志文件是否可按大小或日期进行自动切换？
联机交易系统性能	其它性能	是否采用异步方式记录日志文件？
联机交易系统性能	其它性能	是否采用内存/缓存技术提高应用的处理效率
联机交易系统性能	硬件资源利用率
批处理系统性能	批处理时间窗	批量作业（日终及日间）是否存在可采用并发处理机制而未使用的情况？
批处理系统性能	批处理时间窗	是否存在批处理时间超出时间窗口限制而影响关联系统交易的情况？
批处理系统性能	批处理时间窗	是否存在批处理时间超出时间窗口限制而影响联机交易的情况？
批处理系统性能	批处理时间窗	批处理作业是否考虑到重做、异常中断、断点续作等设计？
批处理系统性能	批处理时间窗	批处理调度机制是否具有并发度以及优先级设置、流程编排、作业运行监控、异常警示等基本功能？
批处理系统性能	批处理时间窗	是否采用内存/缓存技术提高应用的处理效率
批处理系统性能	批处理时间窗	是否采取分批方式，避免超时
容量估计		循环体的设计是否已经考虑层次和繁忙程度，避免循环体内部查询数据库、打开文件、获取外部链接等操作
容量估计		数据字段的定义是否已经参考《db2开发规范》
容量估计		应用服务器是否具备清晰地目录体系、容量规划考虑到未来一年的业务增长需求？
容量估计		应用系统的配置参数是否设计成参数化、可动态调整？（例如进程数、数据库连接数、客户端连接数、打开文件数、IPC参数、TCP参数、文件系统参数等）
容量估计		关键参数是否已接近配置的最大值？如进程数、数据库连接数、网络连接数、文件句柄、记录数预设值等
容量估计		目录下文件数量、大小是否进行控制，或定期备份清理
容量估计		热点资源是否进行分区设计，如流水号
应用扩展能力		在资源充足的情况下，应用是否具备线性扩展能力，比如通过增加线程或进程而增加处理能力
应用可用性	应用部署高可用	应用系统所有节点是否采用了集群、热备等至少一种高可用技术？
应用可用性	应用部署高可用	整个应用系统内部是否存在单点进程？ 单点进程是否有“进程异常”监控机制和自动重启机制？
应用可用性	应用部署高可用	整个应用系统内部是否存在单个消息队列？是否有Q的高可用性方案？消息队列是否有“队列满”的监控机制。从队列中取出数据后，在本地处理过程中发生异常，应用系统要考虑异常处理机制，比如补偿、对账等
应用可用性	应用部署高可用	集群节点要做到严格自治，确保集群节点之间无状态。（对于有状态的情况，要特殊说明，专门评审）
应用可用性	数据高可用	数据库节点是否采用了高可用设计？ 数据库节点是否独立于应用层部署？
应用可用性	数据高可用	对于使用HADR实现高可用的系统，是否使用了load、alter table等不记日志操作
应用可用性	数据高可用	数据层设计中，是否将热点表/数据访问的资源与普通表/数据访问资源进行隔离？
应用可用性	数据高可用	对数据的定时和批量处理是否存在单点？ 批处理是否独立于应用部署？
应用可用性	应用连接设计高可用	在对外通信时，是否存在长连接的情况？如何考虑长连接的高可用性？（除银联前置等特殊系统外，一般均不应采用长连接的方式）
应用可用性	应用连接设计高可用	是否有负载均衡机制？ 负载均衡机制是否能够自动识别故障服务器？并能够将流量转移至监控服务器？
应用可用性	应用连接设计高可用	通讯进程僵死后，是否存在自动检测、重连和告警机制？
应用可用性	应用连接设计高可用	在大并发场景下，如果使用socket通信，是否存在大量time wait或close wait的情况？
应用可用性	应用连接设计高可用	收取报文的过程是单线程还是多线程？ 处理报文的过程是单线程还是多线程？ 收取报文和处理报文的是否使用了两个单独的线程池或进程池，两个池之间的处理是同步还是异步？
应用可用性	应用连接设计高可用	连接池是否存在不释放引发资源占用