前言

檢查流程

收集問題

問題收集需要考慮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服務器等，提出升級調整建議：
檢查項：

應用系統
根據企業應用架構的原則，對應用系統提出調整、升級建議。
這些原則來自：

檢查項：

特殊檢查項：（來自某企業）

檢查報告