IT运营面面观
我们的IT系统在运营阶段，由于不断的变化的需求引起的应用程序调整，亦或平时维护中的不及时、不全面，都会引发系统逐步出现多种问题：
?IT系统的性能逐步下降。
?需求调整越发困难、改动涉及面增大、错误的发生更加频繁，对系统的负面影响也越来越大。
? 为及时满足生产部门的要求，在IT规划外增加了小型应用系统或功能，通过各种方式“挂接”到核心生产系统上，给IT系统持续的合理演进制造了障碍。
IT系统的维护，除了日常的维护工作，如：系统监控、数据清理、故障处理等外，需要在一段时间内，对其进行一次从系统平台、业务、应用架构三个层面进行全面的检查，根据检查的结果，提出进行
?系统优化、
?系统部署调整、
?程序和业务模型重构和修改、
?系统架构调整
的方案或者针对未来的IT规划的建议。
检查流程
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系统的问题涉及面很广，对问题的分析更多的依赖分析者的专业知识和经验。不可能提供一个工具或者方法。
一般使用“头脑风暴法”，并使用因果图来寻找问题背后的真正原因。
对一些描述信息不足以判断原因的问题，可以通过测试系统或者在生产系统中使用测试数据，通过重现问题出现的情景来进行分析。
对一些系统的数据之间存在核对关系等的，可以采用数据核对图来厘清数据之间的关系。
系统检查
操作系统检查
检查每台主机的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的应用需要修改消息队列、共享内存、信号量等核心参数。
下面以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资源的浪费；同样的情况也出现在索引的存储上，因此在数据库运行一段时间后，需要对表和索引的存储稀疏度进行分析，抽取出空间使用问题严重的表或索引，进行数据的重组。
异常检查
分析数据库维护日志，发现数据库可能存在的问题，特别是不稳定、故障方面的问题，增加系统稳定性、降低故障风险。
Tuxedo服务器检查
服务部署检查
检查各个服务进程数是否合理? 避免有进程闲，有进程排队的情况
检查进程接收和发送队列配置是否合理？不要让过多的进程共享消息队列，一般建议不要超过20个
检查进程调用进程的配置是否合理?
检查各个进程中的业务逻辑是否合理? 主要是把一些调用响应时间和频率不一致的业务逻辑分开部署。
问题检查
检查Tuxedo的ULOG，分析错误信息。
配置检查
由于程序变更，用户业务增加等原因，可能会导致本来合理的配置需要进一步调整。
可能涉及的参数包括：
MAXACCESS MAXSERVER WSL参数等。
如：在一个项目中，为支持无线接入，我们修改WSL（客户端侦听服务进程）参数压缩门限到10K。大大地提高了无线接入的速度。
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
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) 配置执行队列控制线程使用
保证关键应用/避免非关键线程影响/
创建执行队列
ListenPort="7001"
NativeIOEnabled="true"/>
...
分配Servlet和JSP到指定执行队列
JSP性能
1) 使用weblogic.jspc编译JSP
2) 确定一下参数配置
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的综合营销管理平台，独立成一个专业的系统。
架构检查
硬件平台
根据对系统的检查，提出硬件平台的调整建议。
检查项：
1.
1.硬件平台处理能力是否满足规划时期内的业务高峰能力要求？
2.硬件处理能力是否便于扩展？
3.是否存在单点故障？
4.是否存在安全性问题？
应用基础设施
对企业范围内的应用基础设施进行检查，如：Web应用服务器，LDAP服务器等，提出升级调整建议：
检查项：
1.
1.对照行业要求和技术发展，是否需要引进新的应用基础设施。如：BRMS，BPMS、LDAP、ESB等系统。
2.是否需要统一企业内的应用基础设施。避免多种不同协议、不同厂商的基础设施之间的集成成本。
应用系统
根据企业应用架构的原则，对应用系统提出调整、升级建议。
这些原则来自：
?
? 企业架构原则，如：中国移动等推出的企业内的应用系统业务技术规范。
? 业内最佳实践，如：电信行业，可参考的TMF的推荐。
? 最新技术进展。如：基于SOA进行架构。
检查项：
1.
1.不同的应用是否重复开发了业务功能？可以重新对子系统进行规划。
2.是否有业务功能没有被完全覆盖？ 可以规划新的子系统
3.是否可以把多种功能，进行整合成一个综合的系统？如：统一接口系统，综合服务开通系统。
4.是否可以把一个具有复杂的，多种功能的系统，按专业进行拆分，以追求更高稳定性和性能。
5.系统间是否具有过于复杂的接口关系？
6.不同的系统，是否具有相同的数据，如何保证这些数据一致。
7.面向第三方系统，是否具有标准的接口定义？
特殊检查项：（来自某企业）
1.
1.不同的展现渠道是否具有相同的业务逻辑？
2.系统必须统一认证和授权。
检查报告
检查报告的格式如下：
一、概述：
描述系统当前的现状，IT系统检查和优化的目的。
二、问题分析
1、系统资源分析：
分析系统的各种资源存在问题。
2、应用系统分析：
分析应用系统存在的问题。
3、问题分析：
分析收集的IT系统的问题
三、优化调整方案
对前面分析的解决方案。包括：
1、部署调整方案
2、应用调整设计方案
四、系统演进建议
对系统未来的演进提出建议
五、附录
分析过程中使用的各种数据、表格等。