通信網(wǎng)banner.jpg)
為不斷保持和提高全省業(yè)務(wù)支撐網(wǎng)的運(yùn)營(yíng)維護(hù)和管理水平，江西移動(dòng)業(yè)務(wù)支撐系統(tǒng)部開展了一系列技術(shù)攻關(guān)活動(dòng)，并形成了獨(dú)特的“IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理”流程，在一定程度上提升了IT支撐工作的管理質(zhì)量。
一、實(shí)現(xiàn)“IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理”的理由
如圖1所示。
二、目標(biāo)設(shè)定
1．IT資源配置項(xiàng)目信息可根據(jù)IT基礎(chǔ)架構(gòu)（如主機(jī)設(shè)備）的類別、型號(hào)、主要應(yīng)用、物理位置等關(guān)鍵索引進(jìn)行分類瀏覽，實(shí)現(xiàn)服務(wù)流程管理平臺(tái)的統(tǒng)一。
2．IT資源配置管理界面可展現(xiàn)IT基礎(chǔ)架構(gòu)配置項(xiàng)的實(shí)時(shí)性能指標(biāo)，包括CPU利用率、內(nèi)存利用率、I/O等待率等，可通過工單提取最近一次設(shè)備重啟時(shí)間和健康檢查時(shí)間，并可進(jìn)一步查看工單的詳細(xì)信息，如當(dāng)前處理人等。
3．IT資源配置管理平臺(tái)產(chǎn)生的告警信息可實(shí)時(shí)、自動(dòng)地發(fā)送給維護(hù)人員，以便及時(shí)處理突發(fā)事件，建立用于故障評(píng)價(jià)和防范的歷史知識(shí)庫，減少系統(tǒng)停頓服務(wù)時(shí)間，加強(qiáng)系統(tǒng)可靠性和可維護(hù)性。
4.IT資源配置管理流程的職責(zé)劃分：設(shè)備管理員負(fù)責(zé)管理IT基礎(chǔ)架構(gòu)的基本信息，并實(shí)施具體的重啟、健康檢查、維修等各項(xiàng)操作；業(yè)務(wù)管理員負(fù)責(zé)分析IT基礎(chǔ)架構(gòu)的業(yè)務(wù)性能，并在接到設(shè)備管理員的核查工單請(qǐng)求后，實(shí)施相關(guān)業(yè)務(wù)的核查處理。
5.IT資源配置管理平臺(tái)可支持多種輸入方式，如動(dòng)態(tài)數(shù)據(jù)采集或手工數(shù)據(jù)錄入等，同時(shí)保留現(xiàn)有手工修改方式（暫時(shí)不考慮自動(dòng)修改配置信息），并支持多種查詢方式。
通過對(duì)現(xiàn)有流程不足之處的詳細(xì)分析，同時(shí)借鑒國(guó)內(nèi)外服務(wù)流程的成功經(jīng)驗(yàn)，我們有充分理由相信，設(shè)計(jì)一套符合江西移動(dòng)實(shí)際情況的IT基礎(chǔ)架構(gòu)資源配置動(dòng)態(tài)管理流程是完全可以實(shí)現(xiàn)的。
三、原因分析
通過運(yùn)用“頭腦風(fēng)暴法”，對(duì)IT基礎(chǔ)架構(gòu)的資源配置管理中存在問題的原因進(jìn)行關(guān)聯(lián)分析，結(jié)果如圖2所示。
四、要因確認(rèn)
通過分析論證，共找出13個(gè)末端因素。要因確認(rèn)如表一所示。
[table]
序號(hào) | 末端因素 | 確認(rèn)內(nèi)容 | 確認(rèn)方法 | 確認(rèn)標(biāo)準(zhǔn) |
1 | 200網(wǎng)站數(shù)據(jù)庫存放部分配置信息 | 配置信息是否存在于200網(wǎng)站數(shù)據(jù)庫 | 查閱200網(wǎng)站數(shù)據(jù)庫 | 200網(wǎng)站數(shù)據(jù)庫中存放了配置信息 |
2 | BOSS網(wǎng)管數(shù)據(jù)庫存放部分配置信息 | 配置信息是否存在于BOSS網(wǎng)管數(shù)據(jù)庫 | 查閱BOSS網(wǎng)管數(shù)據(jù)庫 | BOSS網(wǎng)管數(shù)據(jù)庫中存放了配置信息 |
3 | 未定期檢查資產(chǎn)配置狀況 | 查看上一次資產(chǎn)配置狀況記錄的內(nèi)容 | 調(diào)查對(duì)比 | 上一次資產(chǎn)配置狀況記錄的內(nèi)容與事實(shí)不符 |
4 | 未及時(shí)更新設(shè)備維修操作記錄 | 查看上一次設(shè)備維修操作記錄的時(shí)間 | 調(diào)查對(duì)比 | 上一次設(shè)備維修操作記錄的時(shí)間與事實(shí)不符 |
5 | 配置項(xiàng)目未展現(xiàn)實(shí)時(shí)性能指標(biāo) | 查看資產(chǎn)瀏覽模塊 | 有否實(shí)時(shí)KPI展現(xiàn) | 配置項(xiàng)未與KPI關(guān)聯(lián)展現(xiàn) |
6 | 設(shè)備重啟工單只能人工發(fā)起 | 分析設(shè)備重啟工單 | 查閱工單發(fā)起條件 | 只能通過人工發(fā)起設(shè)備重啟工單 |
7 | 健康檢查工單只能人工發(fā)起 | 分析健康檢查工單 | 查閱工單發(fā)起條件 | 只能通過人工發(fā)起健康檢查工單 |
8 | 出現(xiàn)告警時(shí)未自動(dòng)發(fā)送短信通知 | 查看短信通知平臺(tái) | 查詢短信發(fā)送條件 | 沒有通過短信平臺(tái)發(fā)送告警 |
9 | 指標(biāo)超過閥值時(shí)未自動(dòng)觸發(fā)應(yīng)用核查 | 分析告警是否觸發(fā)應(yīng)用核查工單 | 查閱工單記錄 | 根據(jù)告警證實(shí)未觸發(fā)應(yīng)用核查工單 |
10 | 沒有建立故障處理歷史知識(shí)庫 | 查看是否存在故障歷史知識(shí)庫 | 查閱系統(tǒng)數(shù)據(jù)庫 | 沒有歷史故障知識(shí)庫數(shù)據(jù) |
11 | 配置信息自動(dòng)調(diào)整的溝通渠道不暢 | 分析配置調(diào)整是否自動(dòng)觸發(fā)工單 | 查閱工單記錄 | 根據(jù)配置調(diào)整證實(shí)未自動(dòng)觸發(fā)工單 |
12 | 人員職責(zé)不清晰 | 查看工單的職責(zé)設(shè)計(jì) | 查閱工單 | 未明確說明人員職責(zé)分工 |
13 | 工單信息不詳盡 | 查看工單的包含信息 | 查閱工單 | 未包含足夠的流轉(zhuǎn)位置信息 |
對(duì)各要因進(jìn)行進(jìn)一步分析。
1．200網(wǎng)站數(shù)據(jù)庫存放部分配置信息
雖然200網(wǎng)站數(shù)據(jù)庫中存放了部分配置信息，但這并不影響實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程，并且還可以通過數(shù)據(jù)遷移的技術(shù)方式，與BOSS網(wǎng)管系統(tǒng)數(shù)據(jù)庫融合。不是要因。
2．BOSS網(wǎng)管數(shù)據(jù)庫存放部分配置信息
BOSS網(wǎng)管數(shù)據(jù)庫中存放了部分配置信息，但同樣這也并不影響實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程，并且還可以將200網(wǎng)站數(shù)據(jù)遷移至BOSS網(wǎng)管數(shù)據(jù)庫中，實(shí)現(xiàn)配置信息的整合。不是要因。
3．未定期檢查資產(chǎn)配置狀況
反映了配置信息日常的正確性檢查機(jī)制欠缺，但是資產(chǎn)配置狀況的更新頻度較小、范圍較窄，對(duì)實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程的影響較小。不是要因。
4．未及時(shí)更新設(shè)備維修操作記錄
反映了配置信息日常的正確性檢查機(jī)制欠缺，無法保證其準(zhǔn)確性，對(duì)實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程有較大影響。是要因。
5．配置項(xiàng)目未展現(xiàn)實(shí)時(shí)性能指標(biāo)
反映了配置信息偏重于靜態(tài)應(yīng)用，無法識(shí)別系統(tǒng)性能瓶頸，不能提出有針對(duì)性的系統(tǒng)優(yōu)化或擴(kuò)容實(shí)施方案，因此無法實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理。是要因。
6．設(shè)備重啟工單只能人工發(fā)起
設(shè)備重啟工單只能人工發(fā)起，使得配置信息的更新僅限于提交變更時(shí)，但該類工單較少更新IT基礎(chǔ)架構(gòu)的資源配置信息，對(duì)實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程的影響較小。不是要因。
7．健康檢查工單只能人工發(fā)起
情況與6相似。不是要因。
8．出現(xiàn)告警時(shí)未自動(dòng)發(fā)送短信通知
反映了系統(tǒng)缺乏自動(dòng)發(fā)送告警信息機(jī)制，極易造成突發(fā)事件處理響應(yīng)速度慢，嚴(yán)重影響了生產(chǎn)系統(tǒng)的平穩(wěn)運(yùn)行。是要因。
9．指標(biāo)超過閥值時(shí)未自動(dòng)觸發(fā)應(yīng)用核查
表明配置信息的數(shù)據(jù)維護(hù)能力不足，導(dǎo)致無法自動(dòng)提交給應(yīng)用人員進(jìn)行核查，對(duì)實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程有較大影響。是要因。
10．沒有建立故障處理歷史知識(shí)庫
表明系統(tǒng)尚未具備對(duì)問題原因進(jìn)行深入分析、總結(jié)和提煉的手段，但是歷史知識(shí)庫屬于靜態(tài)數(shù)據(jù)范疇，對(duì)實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程的影響較小。不是要因。
11．配置信息自動(dòng)調(diào)整的溝通渠道不暢
表明各專業(yè)組之間尚未形成有效的信息溝通渠道，且不能衡量配置信息處理流程的時(shí)效性，對(duì)實(shí)現(xiàn)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程有較大影響。是要因。
12．人員職責(zé)不清晰
人員職責(zé)不清晰雖然造成配置信息的處理過程不可控，無法衡量流程的時(shí)效性，但是并不對(duì)IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程產(chǎn)生實(shí)質(zhì)性的影響。不是要因。
13．工單信息不詳盡
情況與12相似。不是要因。
五、對(duì)策制定
根據(jù)確定的要因，我們制定以下對(duì)策措施。如表二所示。
[table]
序號(hào) | 要因 | 對(duì)策 | 目標(biāo) | 措施 |
1 | 未及時(shí)更新設(shè)備維修操作記錄 | 通過流程記錄設(shè)備維修操作 | 及時(shí)記錄設(shè)備維修情況 | 設(shè)計(jì)閉環(huán)、及時(shí)的設(shè)備維修操作記錄流程 |
2 | 配置項(xiàng)目未展現(xiàn)實(shí)時(shí)性能指標(biāo) | 添加配置項(xiàng)目的展現(xiàn)內(nèi)容 | 展現(xiàn)配置項(xiàng)的實(shí)時(shí)KPI | 修改配置項(xiàng)目展現(xiàn)界面，增加動(dòng)態(tài)KPI指標(biāo) |
3 | 出現(xiàn)告警時(shí)未自動(dòng)發(fā)送短信通知 | 在短信平臺(tái)中添加觸發(fā)條件 | 實(shí)現(xiàn)告警短信自動(dòng)發(fā)送 | 修改短信平臺(tái)發(fā)送條件的參數(shù)設(shè)置 |
4 | 指標(biāo)超過閥值時(shí)未自動(dòng)觸發(fā)應(yīng)用核查 | 系統(tǒng)自動(dòng)或人工發(fā)起超過閥值的工單 | 應(yīng)用核查確認(rèn)超過閥值是否影響運(yùn)行 | 設(shè)計(jì)能夠自動(dòng)觸發(fā)的應(yīng)用核查工單流程 |
5 | 配置信息自動(dòng)調(diào)整的溝通渠道不暢 | 通過流程實(shí)現(xiàn)各專業(yè)組之間的溝通 | 促進(jìn)配置信息自動(dòng)調(diào)整后的溝通 | 設(shè)計(jì)順暢的配置信息自動(dòng)調(diào)整的溝通流程 |
六、對(duì)策實(shí)施
1．設(shè)計(jì)閉環(huán)、及時(shí)的設(shè)備維修操作記錄流程
本流程的維修操作工單由對(duì)應(yīng)設(shè)備的設(shè)備管理員發(fā)起，填寫操作原由、操作內(nèi)容、計(jì)劃操作時(shí)間和業(yè)務(wù)配合人（一般情況下為該設(shè)備的業(yè)務(wù)管理員），提交至設(shè)備組組長(zhǎng)審核，若審核通過則進(jìn)行相關(guān)操作并記錄維修結(jié)果，同時(shí)業(yè)務(wù)配合人記錄業(yè)務(wù)應(yīng)用情況。審核通過后系統(tǒng)在將工單發(fā)送給設(shè)備管理員的同時(shí)，提醒業(yè)務(wù)配合人閱知。
應(yīng)用管理員可以為多個(gè)，需要所有業(yè)務(wù)管理員均核查同意后工單才可以終止。只要其中一個(gè)應(yīng)用管理員駁回，工單都會(huì)被駁回，重新進(jìn)入操作人員執(zhí)行狀態(tài)。
2．修改配置項(xiàng)目展現(xiàn)界面，增加動(dòng)態(tài)KPI指標(biāo)
IT基礎(chǔ)架構(gòu)的每個(gè)配置項(xiàng)目（CI）必須被有效管理、跟蹤和控制，以支持IT服務(wù)和基礎(chǔ)設(shè)施正常運(yùn)行。一般而言，傳統(tǒng)的資源管理方式偏重于靜態(tài)應(yīng)用，由于資源信息變更不及時(shí)，造成資源配置信息不準(zhǔn)確；而資源配置的動(dòng)態(tài)管理強(qiáng)調(diào)通過服務(wù)管理流程及時(shí)反映各類資源KPI（關(guān)鍵性能指標(biāo)）實(shí)時(shí)狀態(tài)。以主機(jī)設(shè)備為例，從配置項(xiàng)目展現(xiàn)界面中，可知當(dāng)前CPU利用率、內(nèi)存利用率、IO等待率等KPI的實(shí)時(shí)狀態(tài)。
3．修改短信平臺(tái)發(fā)送條件的參數(shù)設(shè)置
設(shè)計(jì)告警短信自動(dòng)發(fā)送的思路是：當(dāng)生產(chǎn)系統(tǒng)IT基礎(chǔ)架構(gòu)主要部件產(chǎn)生告警時(shí)，BOSS網(wǎng)管系統(tǒng)調(diào)用短信平臺(tái)的外部接口程序，并根據(jù)告警事件的分類進(jìn)行判斷，然后從數(shù)據(jù)庫中查找到相應(yīng)維護(hù)人員的手機(jī)號(hào)碼，最終成功發(fā)送短信通知。在系統(tǒng)中可以定義發(fā)送短信通知的告警級(jí)別以及修改接受短信人員的所屬組別和手機(jī)號(hào)碼，以便靈活調(diào)整。
4．設(shè)計(jì)能夠自動(dòng)觸發(fā)的應(yīng)用核查工單流程
本流程實(shí)現(xiàn)了系統(tǒng)一旦監(jiān)測(cè)到某一設(shè)備相關(guān)指標(biāo)達(dá)到閥值時(shí)，自動(dòng)觸發(fā)生成應(yīng)用檢查工單并自動(dòng)流轉(zhuǎn)至設(shè)備管理員的功能。設(shè)備管理員進(jìn)行初步核查后將該工單流轉(zhuǎn)至業(yè)務(wù)管理員，以便進(jìn)行業(yè)務(wù)應(yīng)用檢查，記錄檢查情況并提出建議。本流程也支持人為發(fā)起工單方式，相關(guān)人員對(duì)某臺(tái)設(shè)備進(jìn)行操作前，需要通知該設(shè)備的業(yè)務(wù)管理員知曉并確認(rèn)。應(yīng)用管理員可以為多個(gè)，在審核時(shí)，需要多個(gè)業(yè)務(wù)管理員都通過才能視為通過，流程才能進(jìn)入下一狀態(tài)。
5．設(shè)計(jì)順暢的配置信息自動(dòng)調(diào)整溝通流程
本流程為各業(yè)務(wù)組與設(shè)備組之間進(jìn)行有關(guān)設(shè)備配置信息調(diào)整提供溝通處理渠道。因應(yīng)用需要涉及設(shè)備資源信息變更和調(diào)整，必須手工發(fā)起需求調(diào)整工單，輸入設(shè)備IP地址、變更類型和具體需求主題、需求內(nèi)容后，再經(jīng)發(fā)起人所在組組長(zhǎng)審核通過后提交至設(shè)備組組長(zhǎng)進(jìn)行審核，如確認(rèn)可操作則指定具體操作人（一般情況下為設(shè)備管理員），由操作人記錄具體執(zhí)行情況。操作人員在執(zhí)行本次配置調(diào)整需求完畢后，必須通過配置管理模塊進(jìn)行相關(guān)資產(chǎn)信息的調(diào)整，確保IT基礎(chǔ)架構(gòu)資源配置信息的及時(shí)和準(zhǔn)確。需求類型包括：增加空間、增加用戶、賦予權(quán)限、調(diào)整參數(shù)和調(diào)整業(yè)務(wù)等。
如果需求工單為業(yè)務(wù)組人員發(fā)起，需要業(yè)務(wù)組長(zhǎng)審批通過方可發(fā)起審批，如果為設(shè)備組直接發(fā)起，則流程不需要業(yè)務(wù)組長(zhǎng)審批。業(yè)務(wù)組長(zhǎng)或設(shè)備組長(zhǎng)認(rèn)為變更不需要，也可以直接結(jié)束工單。
七、效果評(píng)估
本次活動(dòng)取得了良好效果：在IT基礎(chǔ)架構(gòu)的資源配置動(dòng)態(tài)管理流程保障下，實(shí)現(xiàn)了告警自動(dòng)短信通知，并改善了專業(yè)組之間配置信息溝通渠道，使得全省BOSS系統(tǒng)全年故障次數(shù)控制在預(yù)定目標(biāo)值以下；利用關(guān)鍵性能指標(biāo)的實(shí)時(shí)監(jiān)控界面，成功識(shí)別出系統(tǒng)性能瓶頸，并提出了系統(tǒng)優(yōu)化擴(kuò)容方案，使得全省BOSS系統(tǒng)全年優(yōu)化擴(kuò)容效果超過預(yù)定目標(biāo)值。并為下一步有效地建立其它IT服務(wù)管理流程打下了基礎(chǔ)。
----《通信世界》
