系统应用全方面评估维度,全面评测一个系统。
Posted liuxiaoddd
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了系统应用全方面评估维度,全面评测一个系统。相关的知识,希望对你有一定的参考价值。
主要涵盖以下层面,全方面评价一个系统的稳健性。
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的情况? |
应用可用性 | 应用连接设计高可用 | 收取报文的过程是单线程还是多线程? 处理报文的过程是单线程还是多线程? 收取报文和处理报文的是否使用了两个单独的线程池或进程池,两个池之间的处理是同步还是异步? |
应用可用性 | 应用连接设计高可用 | 连接池是否存在不释放引发资源占用 |
以上是关于系统应用全方面评估维度,全面评测一个系统。的主要内容,如果未能解决你的问题,请参考以下文章