IT系统优化和检查

前言

检查流程

收集问题

问题收集需要考虑IT系统的所有涉众，对于移动运营商，包括：IT支持中心、市场部、客户服务部，更全面的需要包括财务部、其他软件厂商。
收集问题需要包括：问题名称、描述、期望结果、提出人、问题解决反馈人。
问题收集后需要及时在小组内进行初步检查问题描述是否具体，对于笼统含糊的问题，需要进一步启发提出者进行更具体的描述。
收集问题不宜过多，耗费过长的时间。如果问题过多过杂，需要抓住重点的几个问题进行解决。

问题分析
对收集的问题进行分析。
去除重复问题。有一些问题的描述方式不一样，但是其本质所指问题为一个，可以考虑合并成一个问题。
对问题进行分类。首先按产品或子系统进行分类，在按问题类型分，一般问题类型分为：
1. 功能错误：在某种情况下，功能执行不正确，这类问题需要尽量进行重现。
2. 功能缺失：目前系统未包含功能，可以开发提供
3. 配置错误：由于业务参数配置错误
4. 性能：性能问题，需要明确时间、业务、业务量等信息。
5. 易用性：多于操作类错误等，都可以归纳为这类。
6. 稳定性。

系统检查
对IT软件的系统平台进行检查，以期发现
i.  程序问题
ii. 系统性能问题
iii. 系统配置不合理。
iv. 系统容量不足
   等各方面的问题。
系统平台的检查包括：
i.硬件平台及操作系统。包括：主机CPU使用、内存、磁盘阵列I/O效率、网络带宽等。
ii.数据库。包括：SQL语句效率、表空间大小以及热点表空间、热点表，索引使用等检查分析
iii.Tuxedo服务器。服务异常错误、服务排队情况、服务部署、超时服务检查
iv.Web应用服务器（Weblogic）。服务器内存使用，服务器配置、执行队列等检查

应用检查
从业务的视角进行检查。业务检查的目的是发现
i.应用系统的错误。
ii.业务流程性能、运行效率问题。
iii.不合理的实现。
对业务的检查，除了各个子系统外，对外部接口的检查也包含在内。业务检查可以通过分析业务日志和业务数据得到。业务检查更侧重在对各涉众所反映的问题分析上。

架构检查
架构检查包括应用系统的部署、应用系统的软件架构二方面。架构检查需要从企业架构的高度看企业当前的IT系统现状。
架构检查可以参考企业的架构框架，目前，国内企业很少有这方面的完备的定义，所以，架构检查应该基于一般性原则，对不符合的部份提出改进建议。中国移动和中国联通都有企业范围的技术标准和业务规范，是架构检查的重要依据。
但是对违背一般性原则的部份，改进起来具有一定的难度，同时也是比较容易指出的。在实际的环境中，架构方面的问题总是五花八门，如：没有统一的用户验证及授权系统、在电信企业中混乱的数据业务（新业务）的开通等。

检查报告
检查的最后一步，是提交最终的检查报告。
检查报告需详尽阐述问题，有可供选择的解决方案，并比较各种解决方案的优缺点。检查报告还需要给出系统优化及改进的渐进过程。

问题收集

问题调研提纲的编写
问题调研提纲是启发使用者回忆和总结系统可能存在的问题，以避免使用者提出的问题描述不准确或有遗漏。
 

功能	系统中缺少哪些功能，哪些工作需要人工处理？ 系统中哪些功能会出错？（由于业务规则限制） 系统中哪些功能几乎没有被使用？ 系统中哪些数据不能被查看？ 系统中哪些数据可能存在问题？ 系统中哪些数据不能被准确的核对或验证？
性能	什么功能、在什么时候会出现响应问题？ 什么功能在业务高峰时，会出现性能下降？ 是否有一些系统的接入（如：渠道）的性能存在问题？如：营业厅、WAP营业厅、Web自助服务、短信营业厅等。
容量	是否存在CPU资源、内存、磁盘空间、网络带宽的不足？
稳定性	描述系统出现过的故障？ 是否由于应用系统问题重启系统？
易用性	哪些应用的界面不好使用，易于出错？ 哪些功能需要频繁切换界面才能完成？
灵活性	哪些功能模块被频繁修改 哪些数据模型被频繁修改？ 哪些用户界面很类似？
架构	哪些接口经常出现错误？ 哪些接口经常需要升级？
维护	应用升级过程中存在哪些问题？ 需求变更的及时性如何？

问题收集表格

序号	问题性质	问题类别	问题描述	改进要求和建议	提出人	优先级
	管理/技术	按调研问卷类别分

工作流程
发放问题调查、问题收集、故障清单收集、IT支撑相关用户投诉收集（最终用户，通过呼叫中心的统计表格收集）、问题初步确认、提交完整问题清单。

问题分析

对问题列表进行初步分析，明晰形成问题的原因，并提出初步的解决或改进方案。
在最终形成报告的过程中，需要对所有问题的方案进行汇总和整合，合并成相对完整的系统的解决方案。
由于IT系统的问题涉及面很广，对问题的分析更多的依赖分析者的专业知识和经验。不可能提供一个工具或者方法。
一般使用“头脑风暴法”，并使用因果图来寻找问题背后的真正原因。
对一些描述信息不足以判断原因的问题，可以通过测试系统或者在生产系统中使用测试数据，通过重现问题出现的情景来进行分析。
下表是一般常见的原因：

类型	问题	原因	方法提示
功能	功能错误	1.     需求理解问题 2.     业务概念和规则歧义 3.     操作错误 4.     后续升级功能影响	1.     整理需求和业务规则 2.     和使用者沟通简化界面操作
	数据不准确	5.     数据没有按合理粒度区分 6.     日志记录不全	3.     整理数据流及稽核图 * 检查
性能	偶发性能问题	7.     变更程序错误 8.     某些业务数据增加而导致的性能下降（如：产品数据等） 9.     应用平台问题，如：过多异常错误。 10.    系统平台问题，如：磁盘 I/O	4.     修改业务数据的查询算法等，避免其数据量变化影响性能
	业务高峰性能问题	11.    系统处理能力不足 12.    系统部署不合理，导致资源争用	5.     系统扩容 6.     部署调整
架构	接口频繁增加和修改	13.    接口协议不够抽象 14.    没有统一的接口规范	7.     制定接口规范
	数据模型修改	15.    业务模型不稳定	8.     结合新需求整合业务模型
	外围子系统增加	16.    原系统不够灵活，不能支持新的需求	9.     升级系统，终合化、专业化。

系统检查

操作系统检查

检查每台主机的CPU使用、内存变化、交换区、存储使用、I/O效率等情况。
方法：使用vmstat、sar、iostat、netstat、ps、top、df、ipcs、time、svmon等操作系统命令。各种操作系统也有自己的性能工具，如：HP-UX的glance、AIX的tprof等。
一般而言，CPU使用率长时间（连续30分钟至1小时）超过80%，则CPU资源存在不足。空闲内存根据内存使用情况看，建议大于1G的空闲内存。磁盘的检查需要结合磁盘阵列的管理软件，通常要求不要有明显的“热点”。
  可以使用Excel趋势线检查CPU等资源使用率的变动情况，如下图：
 

检查操作系统环境变量和核心参数
 操作系统环境变量和核心参数的设置，是由应用系统决定的。如：对于文件处理、网络连接比较多的应用需要较大的可打开文件句柄数，网络连接的相关参数、对于较多IPC的应用需要修改消息队列、共享内存、信号量等核心参数。

服务器类型	相关需调整核心参数
后台文件批处理	打开文件句柄数 , 异步 I/O ，
批量数据库服务器	共享内存
OLTP 数据库	共享内存
Tuxedo 服务器	消息队列、共享内存、网络
Web 服务器（ Weblogic ）	网络

注：特殊调整
LDR_CNTRL=NAMEDSHLIB=xxx,doubletext32（AIX5.3可设置，以避免共享库使用私有内存段）
  检查CPU资源消耗较多、内存使用较多、I/O频繁的进程
使用ps 或 top 命令检查CPU、内存消耗较多的进程。
并进一步使用dbx、gdb等调试工具检查程序运行的指令，或者使用svmon等检查内存的情况。
dbx 等调试命令，可以发现系统消耗资源较大的指令。但是只有在有调试选项的情况下的发布版本，才能显示具体的语言代码。
在AIX中，可以使用truss –p pid 检查系统调用。
svmon可以显示进程所占内存的细节信息。可以协助发现内存泄漏问题。

下面以AIX为例，说明svmon的用法：
 

其中：
pid:进程号
Command：进程命令
Inuse：RAM 中进程使用的页数加上属于终止进程但仍驻留在 RAM 中的持久页面数。这个值等于总内存大小减去空闲列表中的页数。
Pin:锁定在 RAM 的页面的数量。（一个锁定的页面就是一直驻留在 RAM 中而不能调出的页面）。 
PgSp: 描述调页空间使用情况的统计信息，以 4KB 大小的页显示。该数据只有当不使用 -r 标志时才会报告。报告的值是所使用的实际调页空间页面数，这表明这些页面调出到了调页空间中。它与 vmstat 命令的不同在于 vmstat 命令的 avm 一栏显示的是已访问但不一定调出的虚拟内存。
Virtual：在进程虚拟空间中分配的页数。 
Vsid：虚拟的段ID
Esid： 有效的段ID，ESid只有当段属于进程的地址空间时才合法 进程空间的段ID，从0X0-0XF,其中0X0:核心的代码和数据，为系统保留、0X1:用户代码、0x2:用户栈、数据 0x3-0xC:为shmat和mmap使用的、0xD:共享库代码、0xE：为shmat和mmap使用的、0xF:预处理共享库代码 注意：大内存模式下，0x2-0x6都为用户栈、数据
Type：Segment的类型分五种。
persistent Segments：用于操作文件及目录
working Segments：用户实现进程数据区及共享内存段
client Segments：用于实现象NFS/CD-ROM FS这样的文件系统
mapping Segments：用于实现文件在内存中的映射
real memory mapping Segments：用于从虚拟地址空间存取IO空间
 
如果一个进程有工作段（private working segment）的 Inuse、Pgspace 和 Address Range 值在不断增加：极可能是内存泄漏。

数据库检查
存储空间检查
检查各个数据库的各个表空间的存储空间的使用率、剩余空间。
根据业务量以及空间的变化历史分析存储空间的容量。此工作需要事先定时采集数据。

性能检查
可以从下面多个角度，对数据库性能进行分析。

进程分析
数据库的进程数是影响到数据库性能的一个重要因素，分析一个月来的总的进程情况和每天活动的进程情况，可以知道数据库的繁忙程度的趋势，如果某天的进程数异常，可以继续分析该表的数据，总结出哪台机器的连接数异常，并进而跟踪到应用进程的异常。

I/O使用分析
对各类表空间的物理读/写所消耗的I/O进行汇总分析，找出消耗I/O大的表空间类别，进而为这类表空间对应的业务应用优化提供依据。

空间分析
ORACLE 数据库中的表经过大量的插入操作后，表的高水位线（HWM）会不断的提高，并且在进行了删除操作后，虽然表中的数据减少了，但表的HWM并没有下 降，HWM不断的增高一方面浪费了存储空间，另外一方面造成了表存储结构的稀疏，在通过索引扫描或表扫描查找数据时，都会造成CPU资源和IO资源的浪 费；同样的情况也出现在索引的存储上，因此在数据库运行一段时间后，需要对表和索引的存储稀疏度进行分析，抽取出空间使用问题严重的表或索引，进行数据的 重组。

Top SQL分析
从shared pool中分别通过下面的SQL查询中最耗CPU及最耗物理IO的SQL，逐一进行分析如下：
--消耗CPU最多的SQL
SELECT hash_value,module,sql_text,round(buffer_gets/EXECUTIONS,1) "ratio(%)", buffer_gets,PARSE_CALLS,EXECUTIONS
  FROM v$sqlarea
  WHERE EXECUTIONS>100
 ORDER BY 4 DESC; 

--消耗物理读最多的SQL
SELECT hash_value,module,sql_text,round(disk_reads/EXECUTIONS,1) "ratio(%)", disk_reads,PARSE_CALLS,EXECUTIONS
  FROM v$sqlarea
  WHERE EXECUTIONS>100
 ORDER BY 4 DESC;

异常检查
分析数据库维护日志，发现数据库可能存在的问题，特别是不稳定、故障方面的问题，增加系统稳定性、降低故障风险。

Tuxedo服务器检查
服务部署检查
检查各个服务进程数是否合理? 避免有进程闲，有进程排队的情况
检查进程接收和发送队列配置是否合理？不要让过多的进程共享消息队列，一般建议不要超过20个
检查进程调用进程的配置是否合理? 
检查各个进程中的业务逻辑是否合理? 主要是把一些调用响应时间和频率不一致的业务逻辑分开部署。

问题检查
检查Tuxedo的ULOG，分析错误信息。

配置检查
由于程序变更，用户业务增加等原因，可能会导致本来合理的配置需要进一步调整。
可能涉及的参数包括：
MAXACCESS MAXSERVER WSL参数等。
如：在一个项目中，为支持无线接入，我们修改WSL（客户端侦听服务进程）参数压缩门限到10K。大大地提高了无线接入的速度。
  
WSL   SRVGRP = GRPWSL   SRVID = 150 CLOPT = "-A -t -- -n //10.238.12.104:46000 -H //10.238.26.65:46000 -m20 -M30 -x10 -c10240000 -T3 -t 30"
//CLOPT：命令行参数
//  -A：提供所有服务。
//  -t：1可以和Tuxedo7.1前的WSH互操作
//  -n：WSL的侦听地址，格式为：//hostname:port_number或//#.#.#.#:port_number
//  -H：外部网络地址，WSH供客户端使用的地址，一般在有路由器时使用。
//  -m -M：最少的和最多的WSH进程，-m在[0-256] -M[-m，4096]
//  -x：每个WSH能支持的客户端数
//  -c：buffer压缩门限
//  -T：客户端空闲时间（单位分钟）
//  -t：2客户端初始化tpinit的允许的时间为此值*SCANUNIT
// [-p minwshport] and [-P maxwshport]：WSH可用的端口范围 

Weblogic检查
配置检查
JVM参数调整
JVM Heap size 和GC
1) 如果Heap Size大，则GC比较少，但是慢。反之，GC比较多，但是快
2) 如果Heap Size过小，会出现java.lang.OutOfMemoryError
3) 可以通过控制台配置Low Memory GCThreshold以发现低内存情况。
4) 收集GC信息
AIX: 
% java -Xms256m -Xmx1792m  –verbosegc -Xverbosegclog:verbosegclog -classpath $CLASSPATH
-Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\bea"
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.management.server=%ADMIN_URL%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server
使用AIX的JDK，推荐-xms –xmx配置大小不一致
其他JDK-xms –xmx大小一致 
HPUX使用下列选项:
-Xverbosegc:file=/tmp/gc$$.out

5) GC信息分析
GC不应超过3-5s
Heap 如果85% Free，需要减少Heap Size。
6) 在多CPU的机器上使用并行的垃圾收集算法，以减少垃圾收集的暂停时间。 

Weblogic参数调整
1) 设置Java参数
set JAVA_HOME=C:\bea\jdk141_03
"%JAVA_HOME%\bin\java" -hotspot -Xms512m -Xmx512m -classpath %CLASSPATH% -
 
2) 尽量使用“Native IO”性能包
检查Config-〉Tuning页
3) 调 整执行队列的线程数，为了设置理想的执行队列的线程数，我们可以启动管理控制台，在域（如：mydomain）> 服务器> server实例（如：myserver）> 监视> 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数，据此确定理想的数值。
配置在config.xml
<ExecuteQueue
NameName="String"
NotesNotes="String"
QueueLengthQueueLength="number"
ThreadCountThreadCount="number"
ThreadsIncreaseThreadsIncrease="number"
ThreadsMaximumThreadsMaximum="number"
/>
一般值：Execute queue threads count = CPU counts + stuck threads count
不要把Stuck Thread Max Time 和 Stuck Thread Time Interval 设置得过低，以至于在处理高峰期间，常规请求被误认为是卡住得线程。 
Socket Reader，ThreadPoolPercentSocketReaders缺省设为33，1/3的线程用于Socket Reader。         
4) JDBC连接池
InitialCapacity
MaxCapacity
设置Statement Cache
推荐1个cpu 配置 25-30连接

5) 调优TCP连接缓存数
    WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。
推荐8192
6) 调整日志输出级别
如：mydomain）> 服务器> server实例Logging

Weblogic应用调整
1) 配置执行队列控制线程使用
保证关键应用/避免非关键线程影响/
创建执行队列
<Server
 Name="examplesServer"
 ListenPort="7001"
 NativeIOEnabled="true"/>
 
<ExecuteQueue Name="default"
  ThreadCount="15"/>
 
<ExecuteQueue Name="CriticalAppQueue"
  ThreadCount="4"/>
 ...
</Server>
分配Servlet和JSP到指定执行队列
<servlet>
   <servlet-name>MainServlet</servlet-name>
   <jsp-file>/myapplication/critical.jsp</jsp-file>
   <init-param>
      <param-name>wl-dispatch-policy</param-name>
      <param-value>CriticalAppQueue</param-value>
   </init-param>
</servlet>

JSP性能
1) 使用weblogic.jspc编译JSP
2) 确定一下参数配置
<jsp-descriptor> 
<jsp-param> 
<param-name>precompile</param-name> 
<param-value>false</param-value> 
</jsp-param> 
<jsp-param> 
<param-name>pageCheckSeconds</param-name>
<param-value>-1</param-value> 
</jsp-param>
</jsp-descriptor> 
 
pageCheckSeconds和servlet-reload-check-secs 这两个参数要么设置为-1，要么设大一点，如180s
  EJB检查
       weblogic-ejb-jar.xmls
         initial-beans-in-free-pool
max-beans-in-free-pool
max-beans-in-cache
     
weblogic 控制台检查一下信息：
      Pool Miss Ratio：
所有 bean 实例都在使用中，因为请求的数量很多。在这种情况中，空闲池中没有可用实例来响应新的请求。这就导致产生一次请求池失败，检查原因是否需要增加max-beans-in-free-pool
 Pool Timeout Ratio：
池 超时率过高意味着池没有根据调用数量恰当调整。随着请求数量不断增加， EJB 容器创建更多的实例，直到其达到 maximum-beans-in-free-pool 值。如果所有的实例都处于活动状态，并且已经达到最大空闲池大小，则新的方法请求必须等待，直到实例返回到池中。等待期间就是池的超时值，它与为无状态 EJB 配置的事务超时值相同。可以降到超时时间设置或者增加max-beans-in-free-pool
max-beans-in-cache:
容 器在交易中第一次装载bean时是从数据库调用的，此时bean也被放在缓存中。如果缓存的空间太小，有些bean就被滞留在数据库中。这样，如果不考虑 前面提到的前两种特殊情况的话，这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用 setEntityContext()。如果bean的关键（主）键是组合域或者比较复杂，也能省却设置它们的时间。

n 问题检查
1) 检查weblogic日志，分析错误信息。
2) 检查weblogic是否 hang
java weblogic.Admin -url t3://localhost:7001 -username weblogic -password        weblogic PING
    3) cluster启不来
检查一下网络是否能ping通
   检查udp是否通 multcasttest
  

应用检查

应用功能正确性
核对业务数据。核对数据的方法有：

检查异常数据。如：检查超时订单、错误订单数。

业务流程效率
检查应用系统中的业务流程和系统处理流程，评估流程合理性和各个处理环节的性能。
对业务流程和处理流程进行重组，提高流程效率。
流程重组一般包括：

应用系统演进
应用系统由于不断的维护，增加或者修改功能实现，需要定期对系统进行重构，以更好支持应用系统未来的灵活性。
应用系统演进形式一般为：

功能整合
功 能整合有二种情况，一种是整合多个相似的功能，形成融合的抽象的功能，如：在电信支撑系统中，支持了VPN业务的受理、又支持了企业邮箱业务的受理等，随 着企业客户的业务种类的增多，必须抽象出一个集团业务受理的功能，能够定制各种集团业务的受理，而不是每个集团业务进行一次受理功能的开发。另一种是整合 相关功能。如：在数据业务开通中，有时需要进行基本功能的开通，而基本功能的开通由原业务开通系统完成，而数据业务开通由另外补充的功能实现，因此，需要 把这些功能整合成一个综合的业务开通系统。

功能独立
由于企业管理理念的进步，IT系统功能的不断完善，原有的很多系统逐步完善，可以逐渐独立成专业的应用系统。
如： 资源管理，原本只是业务管理的一个模块，由于业务发展，资源管理流程的精细化、资源种类的增加等原因，逐步独立成资源管理系统。营销管理，原系统只是一些 简单的营销的资料管理，随着系统发展，逐步独立成一个集合营销自动化，分析型CRM的综合营销管理平台，独立成一个专业的系统。

架构检查

硬件平台
  根据对系统的检查，提出硬件平台的调整建议。
  检查项：

应用基础设施
对企业范围内的应用基础设施进行检查，如：Web应用服务器，LDAP服务器等，提出升级调整建议：
检查项：

应用系统
根据企业应用架构的原则，对应用系统提出调整、升级建议。
这些原则来自：

检查项：

特殊检查项：（来自某企业）

检查报告