提高數(shù)字化辦公平臺用戶響應(yīng)速度

(水利部小浪底水利樞紐管理中心，河南 鄭州 450000)

1 引 言

互聯(lián)網(wǎng)的用戶心理調(diào)查報告指出，用戶最滿意的網(wǎng)頁打開速度通常在2～5s,如果等待時間延長一倍，幾乎所有用戶都會把頁面關(guān)閉。而對于一個水利電子政務(wù)類應(yīng)用系統(tǒng)——OA系統(tǒng)來說，用戶等待時間過長，會嚴重影響水利政務(wù)辦公的效率，使政令和調(diào)令無法準(zhǔn)確、高效的傳遞。

小浪底信息系統(tǒng)技術(shù)攻關(guān)QC小組成立后，運用科學(xué)的質(zhì)量管理控制手段對小浪底信息化建設(shè)、運維過程中產(chǎn)生的各類技術(shù)難點進行攻關(guān)。小浪底OA系統(tǒng)改造完成上線試運行后，用戶普遍反映系統(tǒng)頁面打開速度較慢或很慢，經(jīng)測試達4～15s，嚴重影響用戶正常辦公使用。因此，QC小組著力于提高數(shù)字化辦公平臺用戶響應(yīng)速度，于OA系統(tǒng)上線試運行的過程中同步開展活動。

2 現(xiàn)狀調(diào)查

QC小組成員在不同時間、不同地點、不同使用環(huán)境下，使用谷歌開發(fā)者響應(yīng)工具分別對用戶打開首頁、打開二級頁面和打開公文工作流的響應(yīng)速度做了量化測試。時間量化標(biāo)準(zhǔn)為“整個網(wǎng)頁的資源全部加載完畢”。

接下來，在不同時間段進行了20次測試，結(jié)果為首頁3.8～6.3s，二級頁面5～9.8s，工作流6.9～14.9s；在不同地點做了15次測試，結(jié)果為首頁4.2～5.6s，二級頁面5.3～7.2s，工作流7.1～11s；在不同使用環(huán)境下做了10次測試，結(jié)果為首頁4.6～7.5s，二級頁面5.3～10.8s，工作流7～16.1s?，F(xiàn)狀調(diào)查結(jié)果見表1。

表1現(xiàn)狀調(diào)查結(jié)果

根據(jù)以上調(diào)查結(jié)果可以發(fā)現(xiàn)，OA系統(tǒng)無論在何種情況下響應(yīng)均較緩慢，這初步排除了大規(guī)模的用戶因素，將問題重點收縮至系統(tǒng)自身。具體的癥結(jié)還需在接下來的步驟中進一步推敲。

3 設(shè)定目標(biāo)

經(jīng)過小組成員認真分析、討論，認為要做到讓小浪底OA系統(tǒng)用戶獲得較佳的訪問體驗，系統(tǒng)響應(yīng)時間不應(yīng)大于4s；若要讓用戶獲得最佳的訪問體驗，則打開時間最好在2s以內(nèi)。

結(jié)合小浪底OA系統(tǒng)的軟硬件架構(gòu)情況、網(wǎng)絡(luò)和機房環(huán)境情況、用戶計算機使用環(huán)境情況等多方面因素，OA系統(tǒng)的用戶響應(yīng)速度預(yù)設(shè)提高至打開首頁2s以內(nèi)，打開二級頁面、公文工作流3s以內(nèi)。

4 原因分析

軟件系統(tǒng)出現(xiàn)問題的可能因素眾多。通過采用頭腦風(fēng)暴法，QC小組成員提出了30余條可能影響OA響應(yīng)速度的原因。將這些原因中的要素進行信息關(guān)聯(lián)、分類聯(lián)想、系統(tǒng)判別后，初步整理為以下5個方面：用戶原因、網(wǎng)絡(luò)原因、服務(wù)器原因、應(yīng)用系統(tǒng)原因和數(shù)據(jù)庫原因。QC小組選用樹狀分析圖對這5個方面進行更深入的分析。

4.1 用戶導(dǎo)致的可能原因

小浪底OA系統(tǒng)的用戶數(shù)量在1500個左右，每位用戶使用的計算機新舊程度不一、品牌型號分布廣泛，操作系統(tǒng)和瀏覽器也涵蓋多種版本。針對9條用戶方面的可能原因，通過下發(fā)調(diào)查問卷、采集日常運維信息、實地走訪用戶等方式，逐條歸納出該可能原因?qū)е碌暮蠊?，匯總統(tǒng)計出所占的用戶比例。結(jié)果發(fā)現(xiàn)，有4條可能原因的用戶數(shù)量占比較大(其中1條用戶數(shù)超過50%)、1條可能原因的流程總數(shù)較一般OA系統(tǒng)來得更多。其余4條可能原因被排除，詳見圖1。

圖1 用戶原因樹狀分析

4.2 網(wǎng)絡(luò)導(dǎo)致的可能原因

水利樞紐的建設(shè)特點決定了小浪底職工分布在幾塊地域工作生活，其間網(wǎng)絡(luò)結(jié)構(gòu)復(fù)雜、網(wǎng)間互聯(lián)距離較長、節(jié)點與路由眾多。QC小組針對3條用戶方面的可能原因，逐條進行技術(shù)排查，均未發(fā)現(xiàn)可影響OA用戶訪問速度的因素。故這3條可能原因被排除，詳見圖2。

圖2 網(wǎng)絡(luò)原因樹狀分析

4.3 服務(wù)器導(dǎo)致的可能原因

服務(wù)器是應(yīng)用系統(tǒng)運行的基礎(chǔ)平臺。小浪底OA系統(tǒng)2016年升級改造共使用5臺國產(chǎn)服務(wù)器、2臺磁盤陣列，其中兩臺應(yīng)用服務(wù)器使用Rose HA軟件實現(xiàn)高可用配置。QC小組針對6條服務(wù)器方面的可能原因，結(jié)合OA系統(tǒng)試運行期間的運維記錄逐條進行測試，發(fā)現(xiàn)有1條可能原因的參數(shù)配置會產(chǎn)生I/O系統(tǒng)問題。其余5條可能原因被排除，詳見圖3。

4.4 應(yīng)用系統(tǒng)導(dǎo)致的可能原因

小浪底OA系統(tǒng)為J2EE架構(gòu)，滿足SOA總線要求。前端使用國產(chǎn)CMS產(chǎn)品，后端使用國產(chǎn)工作流產(chǎn)品和權(quán)限管理平臺，整體使用SSM框架+輕量級UI構(gòu)建。PC前后端、移動端均通過國產(chǎn)SSO平臺實現(xiàn)統(tǒng)一登錄，并開放各類接口與其他系統(tǒng)交互。小浪底OA系統(tǒng)的二次開發(fā)量較大，所以是QC小組的重點檢查方向。針對12條可能原因，小組成員通過多種軟件測試方法進行逐一排查，發(fā)現(xiàn)其中4條可能原因所產(chǎn)生的數(shù)據(jù)指標(biāo)相比正常B/S結(jié)構(gòu)軟件產(chǎn)品有所不足(其中1條指標(biāo)較差)。其余8條可能原因被排除。詳見圖4。

圖3 服務(wù)器原因樹狀分析

圖4 應(yīng)用系統(tǒng)原因樹狀分析

4.5 數(shù)據(jù)庫導(dǎo)致的可能原因

小浪底OA系統(tǒng)使用Oracle 11g作為數(shù)據(jù)庫，使用同門產(chǎn)品Weblogic作為中間件。在一套應(yīng)用系統(tǒng)中，數(shù)據(jù)庫設(shè)計得好與壞，會直接影響到系統(tǒng)整體的響應(yīng)情況。QC小組在對8條數(shù)據(jù)庫方面可能原因的詳細檢查中，發(fā)現(xiàn)有5條存在問題(其中3條可能存在較為嚴重的問題)，影響了數(shù)據(jù)庫的查詢效率和響應(yīng)時間。其余3條可能原因被排除，詳見圖5。

5 確定主要原因

通過原因分析，QC小組得到了15條最可能的問題原因，見表2。

通過調(diào)查分析、現(xiàn)場驗證、實地測試和運用軟件工程中的白盒測試、回歸測試、卸載測試、壓力測試等方法，QC小組成員對15條最可能的原因依次枚舉驗證。以繪制直方圖、散布圖、推移圖等方式，最終得到7條下面逐條簡述這15條最可能原因的驗證分析過程。

圖5 數(shù)據(jù)庫原因樹狀分析

直接影響OA系統(tǒng)響應(yīng)速度的末端因素，詳見圖6。

圖6 確定主要原因

5.1 用戶瀏覽器版本過低

QC小組共訪問了近300位用戶，約2/3的用戶在使用IE9版本或更低版本，小浪底OA系統(tǒng)最低適配的IE內(nèi)核版本為9，過低的版本會造成頁面出現(xiàn)兼容性問題，導(dǎo)致卡頓。因此，急需將用戶瀏覽器都升級到一個較高的版本，此問題定為主要原因。

5.2 用戶瀏覽器支撐組件版本過低

與用戶瀏覽器版本同時進行的調(diào)查還包括小浪底OA系統(tǒng)的兩個核心支撐組件：RiseOffice控件和RiseWord控件。接近90%用戶的組件版本是V3，新的V5版本能更佳地適應(yīng)瀏覽器，同時避免頁面渲染時出現(xiàn)的奇怪問題。因此，急需將小浪底用戶瀏覽器支撐組件都升級到新版本，此問題定為主要原因。

5.3 用戶瀏覽器本身有問題或插件有沖突

在對用戶進行調(diào)查的過程中，QC小組遇到了各式各樣的瀏覽器或插件問題，但小組成員發(fā)現(xiàn)，大多數(shù)問題都可以通過“卸載有問題的插件”“重置瀏覽器”“升級瀏覽器到新版本”等方法快速解決。鑒于此問題大都可解，且解決方法與前述兩條原因有所重復(fù)，此問題定為非主要原因。

5.4 用戶使用了非IE內(nèi)核的瀏覽器

小浪底OA系統(tǒng)的主要支撐控件不支持非IE內(nèi)核瀏覽器(如谷歌、火狐等)，使用這類瀏覽器的用戶會遇到控件長時間卡頓、無法加載等問題。QC小組成員在調(diào)查過程中發(fā)現(xiàn)，此類用戶數(shù)量不多，并且在告知其“請使用IE瀏覽器打開OA系統(tǒng)辦公”時，大家都能理解和接受。此問題定為非主要原因。

5.5 用戶業(yè)務(wù)所需要的總工作流程過多

小浪底OA系統(tǒng)的工作流引擎需要在啟動時一次性將所有流程加載完畢。經(jīng)過QC小組統(tǒng)計，目前OA系統(tǒng)中共有177條在用流程、153條歷史流程，啟動后流程引擎占據(jù)了10.3GB內(nèi)存空間。為了確定這些流程對服務(wù)器整體響應(yīng)速度的影響，QC小組成員對流程引擎進行了由空載至滿載的加載測試。

測試結(jié)果表明：隨著工作流引擎加載流程數(shù)不斷增加，其內(nèi)存占用量基本成線性倍數(shù)增長，而服務(wù)響應(yīng)速度的變化趨勢不大，響應(yīng)時間均在可接受范圍內(nèi)，此問題定為非主要原因。

5.6 Linux文件系統(tǒng)參數(shù)配置不合理

為避免資源消耗過大，OA系統(tǒng)所使用的Linux操作系統(tǒng)對同一時間用戶、進程打開的文件數(shù)量有所限制。QC小組通過檢查發(fā)現(xiàn)，在當(dāng)前系統(tǒng)配置下，文件限制數(shù)為1024個，超限后偶爾會引發(fā)文件打開報錯。經(jīng)過模擬超限測試，QC小組確認此問題出現(xiàn)時不會影響到用戶的響應(yīng)速度，且通過簡單修改系統(tǒng)配置即可解決，此問題定為非主要原因。

5.7 同時間大量用戶并發(fā)訪問

OA系統(tǒng)的并發(fā)訪問量是重要的性能參數(shù)，QC小組選用Stress Testing壓力測試工具作為并發(fā)訪問量測試工具。測試結(jié)果顯示，隨著用戶并發(fā)量從0增加至500，系統(tǒng)響應(yīng)時間也隨之成平穩(wěn)線性增長，沒有突然的指數(shù)性爆發(fā)。這說明用戶的并發(fā)量增加不會導(dǎo)致OA系統(tǒng)出現(xiàn)嚴重響應(yīng)拖延。

5.8 多數(shù)用戶頻繁請求特定資源

當(dāng)用戶訪問應(yīng)用系統(tǒng)時，頁面資源按需加載到用戶瀏覽器中。若同一時間請求某個較大資源的用戶數(shù)過多，反復(fù)加載的過程會造成服務(wù)器性能下降。QC小組對大小超過300kb的公用資源進行了1h內(nèi)同時被調(diào)用的次數(shù)最大值統(tǒng)計，結(jié)果顯示，各類公用資源在用戶加載頁面時幾乎都會調(diào)用，且加載次數(shù)相差不大，沒有出現(xiàn)某個資源明顯多于其他對系統(tǒng)響應(yīng)影響較大的情況，確定OA系統(tǒng)單一資源同時調(diào)用169次屬正常情況，此問題定為非主要原因。

5.9 頁面布局不合理

當(dāng)Web頁面布局設(shè)計不合理時，用戶端瀏覽器引擎會付出額外的開銷來修正到正確的顯示狀態(tài)，或者出現(xiàn)渲染錯誤，導(dǎo)致卡頓。

QC小組將OA首頁中所有大型資源逐個除去，再將CSS樣式調(diào)整到最簡狀態(tài)，每次都進行頁面渲染時間測試。結(jié)果表明，資源去除干凈后，首頁渲染時間與CSS最簡狀態(tài)的時間之差已經(jīng)很小，頁面布局對OA響應(yīng)速度的影響已可忽略不計，此問題定為非主要原因。

5.10 頁面動態(tài)資源和元素過多

如今越來越復(fù)雜的動態(tài)頁面給服務(wù)器造成了越來越大的資源開銷壓力。QC小組成員首先測試了OA系統(tǒng)不同頁面的動態(tài)資源請求次數(shù)，發(fā)現(xiàn)“資訊中心”的請求數(shù)最多，然后，又進行了一組針對性的“動態(tài)資源卸載與系統(tǒng)響應(yīng)時間”對比實驗。結(jié)果清晰表明，隨著動態(tài)資源的卸載，資訊中心單頁面的訪問速度有了質(zhì)的飛躍，從9.6s飛躍至1.6s。這說明了兩點：?資訊中心頁面的動態(tài)化程度太高，已經(jīng)使服務(wù)器產(chǎn)生了較重負載；?去除不必要的動態(tài)資源，是提高頁面訪問速度的有效方法之一。此問題定為主要原因。

5.11 Oracle數(shù)據(jù)庫連接數(shù)上限設(shè)置不足

數(shù)據(jù)庫系統(tǒng)對同時訪問某個實例的連接數(shù)不應(yīng)限制得太小，QC小組首先檢查了OA系統(tǒng)當(dāng)前的Oracle數(shù)據(jù)庫連接數(shù)，數(shù)值為150，然后QC小組模擬了在不同用戶并發(fā)操作下，這個限制對SQL語句執(zhí)行帶來的影響。結(jié)果表明，當(dāng)用戶并發(fā)操作超過150時，超出部分即進入等待隊列；且隨著時間延長，部分等待的連接已超時丟失。小浪底OA系統(tǒng)目前用戶數(shù)已過千人，按15%～20%并發(fā)計算，此限制確實會導(dǎo)致用戶出現(xiàn)問題。此問題定為主要原因。

5.12 數(shù)據(jù)表沒有建立索引或索引字段不對

數(shù)據(jù)表的索引若出現(xiàn)錯誤或沒有建立，會大大影響庫表查詢操作效率。QC小組經(jīng)過仔細檢查，發(fā)現(xiàn)從原OA系統(tǒng)遷移過來的數(shù)據(jù)表，索引還使用的是老字段，目前已經(jīng)不起任何作用。此部分表數(shù)量約占新OA系統(tǒng)的20%左右。通過SQL操作耗時記錄可以看出，單表查詢和多表聯(lián)合查詢耗時均遠超正常SQL語句執(zhí)行時間。此問題定為主要原因。

5.13 連接池設(shè)計不合理，連接不能及時關(guān)閉

Oracle等大型數(shù)據(jù)庫使用連接池技術(shù)以增加數(shù)據(jù)庫連接的復(fù)用性、可靠性和效率。但若應(yīng)用開發(fā)者對連接池的設(shè)計不合理，就可能導(dǎo)致程序在使用完連接池中的資源后，無法及時關(guān)閉、歸還資源，使連接池中的資源慢慢泄露，最后導(dǎo)致數(shù)據(jù)庫拒絕任何新的連接請求。

QC小組對OA系統(tǒng)經(jīng)過檢查調(diào)試，發(fā)現(xiàn)了一個連接池問題。經(jīng)修復(fù)后，證實此問題與OA系統(tǒng)的響應(yīng)速度沒有直接關(guān)系。此問題定為非主要原因。

5.14 SQL語句編寫、優(yōu)化不到位

SQL語句是任何應(yīng)用信息系統(tǒng)的靈魂。一個好的SQL語句能大大提升數(shù)據(jù)的增刪改查速度；反之，一個冗余的、含有隱性錯誤的SQL語句能將系統(tǒng)拖入消耗資源的泥潭中不能自拔。QC小組選用Oracle Automatic Workload Repository工具(自動工作負載信息庫)進行資源消耗的Top10分析。經(jīng)過仔細檢查，找到6條執(zhí)行時間大大超過正常狀態(tài)的SQL語句。每一次的執(zhí)行延遲加在一起，給系統(tǒng)響應(yīng)速度帶來了巨大的影響。經(jīng)討論，此問題定為主要原因。

5.15 單一表空間過大

若一張數(shù)據(jù)庫表的體積太大，則對其進行SQL操作的耗時將成倍增加。對這些過大的表進行分區(qū)優(yōu)化處理，是一種提高SQL執(zhí)行效率的有效方法。QC小組成員對OA系統(tǒng)數(shù)據(jù)庫中的表大小進行了仔細的梳理，發(fā)現(xiàn)從原OA系統(tǒng)中遷移過來的一張經(jīng)常訪問的附件表，體積已經(jīng)高達10.5GB，執(zhí)行聯(lián)合查詢的耗時遠超正常水平。經(jīng)討論，此問題定為主要原因。

6 對策實施

6.1 最壞風(fēng)險處置對策

一個應(yīng)用信息系統(tǒng)的程序、模塊、數(shù)據(jù)庫等部分之間具有緊密的聯(lián)系，對其進行任何更新、改造等活動，都有造成系統(tǒng)癱瘓的風(fēng)險，且此類風(fēng)險很難完全避免。因此，在對策實施前，QC小組首先采用PDPC圖工具對實施過程中可能遇到的最壞風(fēng)險進行了處置過程預(yù)估。詳見圖7。

對于OA系統(tǒng)來說，最壞的可能風(fēng)險是在實施過程中出現(xiàn)OA系統(tǒng)癱瘓。當(dāng)出現(xiàn)此類嚴重問題時，首先應(yīng)盡快判斷問題所屬的分類，其次通過PDPC圖中對應(yīng)的流程模塊針對出現(xiàn)問題的分類進行后續(xù)檢查和處理。當(dāng)問題處理妥當(dāng)，流程進入綠色區(qū)域時，即可認為OA系統(tǒng)癱瘓問題已成功解決；當(dāng)流程最終進入紅色區(qū)域時，應(yīng)及時做好災(zāi)難應(yīng)對和解釋上報，停止后續(xù)對策實施工作，查明原因并拿出切實有效的預(yù)防措施后再行繼續(xù)。

6.2 主要問題對策實施

針對已得到的7條主要原因末端因素，QC小組按照5W1H的原則，經(jīng)過討論，按技術(shù)要求將原因分為3組，分別制定了目標(biāo)和措施，并將每項措施落實到專人，同時規(guī)定了起止時間和活動地點。

6.2.1 用戶瀏覽器版本過低

通過前面的活動過程，QC小組成員經(jīng)過討論，對此問題設(shè)立的目標(biāo)是：將用戶瀏覽器的版本升級至IE11。針對此目標(biāo)，最有效的對策是通過逐級、分批地下載、安裝來升級用戶IE內(nèi)核瀏覽器版本到Ver 11。根據(jù)小浪底OA系統(tǒng)用戶分布地域廣泛的特點，該對策在兩地分幾個批次實施，最終達到覆蓋全用戶的目的。

2017年11月5—30日，由QC小組成員牽頭在鄭州生產(chǎn)調(diào)度中心對用戶進行了逐屋排查，共排查116位，發(fā)現(xiàn)問題用戶47位；11月5—30日，由QC小組成員牽頭在小浪底水利樞紐管理區(qū)對用戶進行了逐屋排查，共排查422位，發(fā)現(xiàn)問題用戶201位。以上均予以解決。

本次對策實施結(jié)果將小浪底各用戶的IE瀏覽器版本統(tǒng)一為IE11。升級后的用戶瀏覽器，打開OA系統(tǒng)沒有再出現(xiàn)原來的各類奇怪問題和兼容性問題，沒有卡頓和等待，用戶使用體驗得到了提升。

6.2.2 用戶瀏覽器支撐組件版本過低

通過前面的活動過程，QC小組成員經(jīng)過討論，對此問題設(shè)立的目標(biāo)是：將用戶瀏覽器支撐組件的版本升級至Ver5。針對此目標(biāo)，最有效的對策是通過U盤拷貝安裝程序的方式逐級、分批地升級用戶瀏覽器RiseOffice和RiseWord支撐組件版本到Ver 5.0.1.2。根據(jù)小浪底OA系統(tǒng)用戶分布地域廣泛的特點，該對策同樣在兩地分幾個批次實施，最終達到覆蓋全用戶的目的。

因本條對策實施過程與“用戶瀏覽器版本過低”對策類似，都需要對所有用戶進行走訪以及對用戶瀏覽器進行維護操作，在技術(shù)上具有相似性，在時間和所耗精力上具有重復(fù)性。為了使本次QC活動具有更佳的經(jīng)濟性，經(jīng)QC小組仔細分析討論，決定本條對策與“用戶瀏覽器版本過低”同人、同時實施。

5．獨有的特異類寶石。昌樂不僅產(chǎn)出了世界公認的極品類型的藍寶石，而且產(chǎn)出了大量珍貴的多彩藍寶石，其中不乏國寶級珍品。如半為黃色半為藍色的鴛鴦藍寶石為世界獨有，具有極高的文化價值和收藏價值。另外，部分昌樂藍寶石中含有奇特的包裹體，不少有奇異的活光效應(yīng)，形成了各式各樣的精美圖案。如“西天取經(jīng)”“魚探龍宮”“一帆風(fēng)順”均屬世界罕見珍品，價值連城。

經(jīng)過在鄭州生產(chǎn)調(diào)度中心排查116位，發(fā)現(xiàn)問題用戶69位；在小浪底水利樞紐管理區(qū)對排查422位，發(fā)現(xiàn)問題用戶280位。以上均予以解決。

本次對策實施結(jié)果將小浪底各用戶的IE瀏覽器支撐組件版本統(tǒng)一為Ver5。升級后的用戶瀏覽器，打開OA系統(tǒng)沒有再出現(xiàn)原來的各類奇怪問題和兼容性問題，沒有卡頓和等待，用戶使用體驗得到了提升。

6.2.3 頁面動態(tài)資源和元素過多

通過前面的活動過程，QC小組成員經(jīng)過討論，對此問題設(shè)立的目標(biāo)是：用戶訪問資訊中心頁面時，加載的資源和元素不超過20個。要想達到此目標(biāo)，需要盡可能減少資訊中心頁面的動態(tài)化程度。針對此問題，有兩種解決方案：

a.將大的動態(tài)頁面拆分成幾個小的頁面，同時加載，提高用戶端體驗。但此方法仍無法免除服務(wù)器端重負載問題。

b.將動態(tài)頁面通過技術(shù)手段轉(zhuǎn)換成靜態(tài)化頁面，提供給用戶訪問。這種方式具有效率極高的特點，且靜態(tài)化后頁面的安全程度有較大提升，是當(dāng)前IT界廣泛采用的方式。

QC小組經(jīng)過分析研討，認為最有效的對策是將資訊中心的頁面進行靜態(tài)化處理，讓用戶訪問靜態(tài)化之后的頁面，免除動態(tài)資源加載的耗時。2017年12月10日在鄭州生產(chǎn)調(diào)度中心開始對OA系統(tǒng)資訊中心頁面實施逐步靜態(tài)化處理。至12月26日，該項對策比計劃工期提前4天實施完畢。

在實施該對策的過程中，OA項目開發(fā)組接到了關(guān)于在資訊中心開發(fā)公司頁面上增設(shè)欄目和圖像的需求。經(jīng)過需求分析和小組討論，QC小組及時將此項對策的目標(biāo)修改為：用戶訪問資訊中心頁面時，加載的資源和元素不超過30個。

6.2.4 Oracle數(shù)據(jù)庫連接數(shù)上限設(shè)置不足

通過前面的活動過程，QC小組成員經(jīng)過討論，對此問題設(shè)立的目標(biāo)是：將數(shù)據(jù)庫連接數(shù)上限值提高至1000。針對此目標(biāo)，最有效的對策是通過停止數(shù)據(jù)庫實例、修改數(shù)據(jù)庫連接數(shù)限制值，將其改動到目標(biāo)值。

2017年12月12日在鄭州生產(chǎn)調(diào)度中心辦公樓開始調(diào)整數(shù)據(jù)庫。至12月15日處理完畢。經(jīng)過查詢，確認已將Oracle數(shù)據(jù)庫連接數(shù)上限調(diào)整至1000。經(jīng)Stress Testing工具進行壓力測試，并發(fā)100～500用戶時均能保持穩(wěn)定的服務(wù)狀態(tài)，隊列很快就全部接入連接池。

6.2.5 SQL語句編寫、優(yōu)化不到位

通過前面的活動過程，QC小組成員經(jīng)過討論，對此問題設(shè)立的目標(biāo)是：使重新編寫的SQL語句執(zhí)行效率至少提高10倍。針對此目標(biāo)，最有效的對策是針對小浪底用戶業(yè)務(wù)邏輯和系統(tǒng)實際情況，對SQL語句進行重構(gòu)和深度優(yōu)化，重新編寫高效率的SQL語句并測試生效。

2017年12月16日開始對SQL進行分析和優(yōu)化。至12月30日，6條執(zhí)行時間過長的SQL語句全部優(yōu)化完畢。對包含這幾條SQL語句的頁面及功能進行測試后，發(fā)現(xiàn)打開前端信息頁面和后端公文頁面的時間都有較大幅度縮短。

QC小組成員查看該頁面對應(yīng)的有效SQL語句，發(fā)現(xiàn)查詢耗時和Cost值(查詢開銷)已降至個位數(shù)。此時的效率與優(yōu)化前相比，已產(chǎn)生5000倍以上的提升，大大超越目標(biāo)值。

6.2.6 數(shù)據(jù)表沒有建立索引或索引字段不對

通過前面的活動過程，對此問題設(shè)立的目標(biāo)是：使數(shù)據(jù)表訪問速度比目前至少提高20倍。針對此目標(biāo)，最有效的對策是檢查所有數(shù)據(jù)表，刪除無效和錯誤的表字段索引，重建該表主鍵與索引并驗證。

2018年1月1日開始進行對策實施。至1月10日，所有索引無效或出錯的數(shù)據(jù)表均已處理完畢。

通過對占數(shù)據(jù)表總數(shù)近20%的問題表進行索引重建，這些數(shù)據(jù)表的查詢效率得到極大的提升。QC小組選擇其中一張熱點數(shù)據(jù)表進行驗證，其Cost值降至個位數(shù)，效率和未重建索引前相比提升3000多倍，大大超越目標(biāo)值。

6.2.7 單一表空間過大

通過前面的活動過程，對原OA系統(tǒng)中遷移來的熱點附件表體積過大導(dǎo)致查詢效率低下問題而設(shè)立的目標(biāo)是：使針對該表的查詢效率至少提高5倍。針對此目標(biāo)，最有效的對策是新建分區(qū)表空間，將原表切割后分塊遷移至新表內(nèi)，再重建分區(qū)索引，對表空間進行優(yōu)化后驗證。

2018年1月10日開始進行對策實施。至1月15日，所有過大的數(shù)據(jù)表均已分區(qū)遷移完畢。在對遷移表中最大的10.5GB附件表進行分區(qū)重建表空間、優(yōu)化分區(qū)索引等對策實施后，該表的Cost值降低了一半。

但這個結(jié)果沒有達到本條對策實施的目標(biāo)要求。QC小組成員通過交流討論得知，對于體積過大的單一數(shù)據(jù)表，目前已經(jīng)做完所有可用的優(yōu)化操作；若還想使其更快，只能改變數(shù)據(jù)庫本身架構(gòu)(如采用分布式或內(nèi)存式數(shù)據(jù)庫等)。這已經(jīng)脫離了本次OA系統(tǒng)升級改造項目的范疇，無法予以實施。因此，QC小組經(jīng)過慎重討論，決定將此對策的目標(biāo)修改為：使針對該表的查詢效率至少提高2倍。

7 效果檢查

7.1 活動效果

綜合不同時間、不同地點、不同使用環(huán)境3種情況，對OA系統(tǒng)響應(yīng)速度進行了復(fù)測統(tǒng)計。統(tǒng)計結(jié)果見表3。

表3活動效果復(fù)測統(tǒng)計

表3中綠色數(shù)值為達標(biāo)數(shù)值。通過此次QC小組活動，已將小浪底OA系統(tǒng)的用戶響應(yīng)速度很好地控制在目標(biāo)范圍以內(nèi)。本次小組活動目標(biāo)成功實現(xiàn)。

7.2 社會效益

因為OA系統(tǒng)響應(yīng)速度的提升，使小浪底用戶的辦公效率得到極大提升，水利政令和調(diào)令的上傳下達變得準(zhǔn)確、高效，水利公文事務(wù)的流轉(zhuǎn)也變得及時、通暢，用戶主動辦公的意愿得到了較大提升，OA系統(tǒng)也得到了用戶的一致好評。

本次活動的成功為其他水利電子政務(wù)和水利信息化系統(tǒng)的建設(shè)、運維和調(diào)整優(yōu)化提供了切實可行的經(jīng)驗。

8 鞏固措施

為了進一步鞏固此次活動成果，小組成員根據(jù)對策實施結(jié)果和小浪底OA系統(tǒng)用戶實際情況，制定了以下鞏固措施：

a.提高用戶終端運維頻次和水平。目前已對用戶終端的運維頻次和方法進行了量化，所形成的指標(biāo)和要求已寫進《小浪底信息化系統(tǒng)用戶終端運維規(guī)范》中，后續(xù)會加強執(zhí)行。

b.定期對OA系統(tǒng)數(shù)據(jù)庫進行優(yōu)化。在活動結(jié)束后，小組將每年對OA系統(tǒng)數(shù)據(jù)庫進行優(yōu)化的頻次、方式方法等匯總成報告，上報公司領(lǐng)導(dǎo)進行審批，確保數(shù)據(jù)庫能不斷以最優(yōu)的性能狀態(tài)給程序提供可靠服務(wù)。

c.加強對服務(wù)器等硬件設(shè)備的維護。目前已將對服務(wù)器等硬件設(shè)備加強巡檢和維護的方法和指標(biāo)寫進“日巡檢表”“周巡檢表”和“月巡檢表”等文檔，下一步將會加強監(jiān)督、檢查，確保執(zhí)行落地、到位。