IT运营面面观

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
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) 配置执行队列控制线程使用
保证关键应用/避免非关键线程影响/
创建执行队列
 Name="examplesServer"
 ListenPort="7001"
 NativeIOEnabled="true"/>
 
  ThreadCount="15"/>
 
  ThreadCount="4"/>
 ...

分配Servlet和JSP到指定执行队列

   MainServlet
   /myapplication/critical.jsp
  
      wl-dispatch-policy
      CriticalAppQueue
  
JSP性能
1) 使用weblogic.jspc编译JSP
2) 确定一下参数配置


precompile
false


pageCheckSeconds
-1


 
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、应用调整设计方案
四、系统演进建议
 对系统未来的演进提出建议
五、附录
 分析过程中使用的各种数据、表格等。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25714550/viewspace-757224/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/25714550/viewspace-757224/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值