免責聲明
本文引用的參考文獻搜集于網際網路，非原創，如有侵權請聯系小編删除！
請勿将該文章用于任何商業用途，僅供學習參考，違者後果自負！
資料下載下傳方式
完整版文檔已上傳至知識星球“無憂智庫-新基建智慧城市圈子”（星球号53232205）平台。
以下是方案全文：
目 錄
1 項目服務方案 3
1.1 日常維護方案 3
1.1.1 項目概述 3
1.1.2 故障響應和服務内容 4
1.2 服務支撐體系 45
1.2.1 服務組織 45
1.2.2 服務流程 46
1.2.3 服務規範體系 47
1.2.4 團隊穩定性方案 56
1.3 品質控制能力 62
1.3.1 服務品質管理 62
1.3.2 品質保障體系 63
1.3.3 品質管理措施 63
1.3.4 項目教育訓練方案 64
1.3.5 服務工作協同 65
1.4 應急預案 72
1.4.1 應急響應方案 72
1.4.2 重點保障方案 77
項目服務方案
日常維護方案
項目概述
背景介紹
為保障企業大資料應用平台的日常生産運維工作，保持運維工作的延續性，需由“經分背景SS、ETL等應用日常維護服務”提供相關的監控、維護工作。
服務目标
在確定企業經營分析系統運維工作順利開展，包括經分現網系統每日正在運作的上千項流程的日常運維、DACP流程排程、資料分發、進出口資料品質、ETL配置維護以及及時性監控、月生産維護、重點應用及時完成情況監控。
服務原則
例行服務必須按規定時間進行，服務響應時間必須在合同規定的時間内執行，故障應急必須迅速做出反應。準确無誤地完成所承諾的服務。要求避免服務過程中的失誤，避免服務過中影響局方的業務穩定。術業有專攻，提供專業的服務團隊為局方提供專業服務，保證服務品質。
符合局方相關維護規定，做好資訊安全保密工作。
故障響應和服務内容
故障等級和服務響應
| 故障級别定義 | 故障級别 | 故障定義 | 服務描述 |
| 一級故障 | 一經接口、重點應用相關接口故障或延遲；重點應用、重點模型排程故障或延遲 | 重點接口或程式延遲或故障。 | |
| 二級故障 | 基礎模型DWD、中間層模型DWA的相關接口或程式故障或排程延遲 | 基礎、公共層模型或程式故障或延遲 | |
| 三級故障 | 條線主題公共層DWA模型故障或排程延遲 | 主題公共層模型故障或延遲 | |
| 四級故障 | 非重點應用層程式故障或排程延遲。 | 非重點應用故障或延遲 |
| 服務響應時間 | 故障級别 | 電話響應時間 | VPN撥入時間 | 人員到場時間 | 故障恢複時間 |
| 一級 | 3次内 | 15分鐘 | 2小時内 | 2小時内 | |
| 二級 | 3次内 | 15分鐘 | 2小時内 | 2小時内 | |
| 三級 | 3次内 | 30分鐘 | 4小時内 | 4小時内 | |
| 四級 | 3次内 | 60分鐘 | 4小時内 | 6小時内 |
重點值守：
在局方的要求下，主要是在重要通信保障或國定節假日期間，根據保障等級要求，提供
現場或遠端VPN值守服務，根據服務品質進行考核。
突發情況響應
面對突發情況或突發事件，應提供應急響應，要求按照故障等級和響應時限到達現場處理。如有同類故障的處理預案，立即進行業務恢複。否則更新至遠端技術支撐中心，同時通報各相關廠商請求提供技術支援服務。同時，現場支援服務工程師将到達現場，實施或配合進行業務恢複和故障處理。
服務滿意度保障
空中選号系統服務確定及時、有效的解決服務中出現的問題，不造成各類故障預警，使空中選号系統達到服務滿意度名額考核要求。
具體工作：1、對空選系統進行維護；2、确認系統情況合理更新系統版本；3、相關應用配置按需調整；4、對相關應用特征進行及時更新。根據要求，對流量政策進行調整，并對裝置系統進行安全漏洞掃描，及時更新系統更新檔，避免系統隐患。
生産安全
維護人員需遵守局方的人員進出、機房管理與安全生産規定。
資訊安全
維護人員需遵守局方資訊安全相關保密規定。系統安全服務包括系統安全保障、資訊安全支援服務。系統安全保障是根據相關方要求，定期檢查空選系統安全設定，防止一些未經允許的通路影響系統的安全。資訊安全支援服務是根據集團資訊安全規範和工信部資訊安全按要求，确定支援服務作業計劃，定時進行系統和應用安全性檢查，定期進行系統密碼回收和檢查，定時對系統的更新檔、漏洞等進行檢查，對發現或受理的問題進行預防性的維護作業，消除故障隐患。根據不同時期的不同要求，經過協商确認後，系統安全服務作業計劃具體内容項目可以定期或不定期的調整。
優化建議
積極主動對系統營運提出性能或功能上的優化建議，與局方人員一起，進行實施，評估能否取得明顯效果。
臨時任務：
有承擔局方臨時交辦任務的義務，并根據具體情況，承諾相應的服務品質。
服務内容
7X24小時電話支援服務
提供7X24小時電話支援，受理報障，咨詢和遠端技術支援服務。撥打報障電話3次内有人應答
正常巡檢
正常巡檢月為機關，範圍包括：
| 正常巡檢作業項目 | 作業周期 | |
| 例行檢查 | 監控結果檢查、記錄 | 4次/月 |
| 系統例行檢查、記錄 | 4次/月 | |
| 軟體檢查 | 業務量檢查 | 4次/月 |
| 業務性能耗時檢查 | 4次/月 | |
| 日志檢查 | 檢查日志中的錯誤 | 4次/月 |
| 系統軟體和應用軟體版本、更新檔檢查 | 不定期 | |
| 分析和優化 | 為配合新增要求的分析和優化任務。 | 按需 |
為保障系統的健康、高效運作，消除問題隐患，提供系統巡檢服務。
SS運維服務
- 工作概述：
- 保障DACP排程系統上YT機平台及MPP平台的程式正常運作；
- 工作重點：
- 每天全程監控重點流程：
夜間3次定時巡檢彙報：2點，5點，8點
白天2次重點監控彙報和多次巡檢排程系統：重點彙報11點，17點
- 根據流程的重要程度，按既定的時效及品質要求，及時監控、發現、并處理DACP排程系統中的各類異常問題；
- 重點監控并優化重點流程的排程情況，保障出數的及時性及準确性；
- 定期總結DACP排程中的系統、流程排程等問題，并及時進行主動優化或回報給開發人員進行優化，以保障DACP排程系統的穩健性及效率。
- 自動化告警腳本按需求閥值調整、優化。
- 工作内容：
SS運維服務主要包括了日常監控運維、月初運維任務等。具體維護内容如下：
日常監控運維
SS日常監控運維工作包括流程排程監控及維護、固定分發新增、臨時任務處理及跟蹤等。
SS重點流程監控及維護：
- 重點監控日程式
總數：1000 （個）監控時段：00:00-23:00 （每日）
- 重點監控月程式
總數：60（個）監控時段：00:00-23:00 （1号-7号）
- 重點監控分鐘程式
總數：10 （個）監控時段：00:00-23:00 （每日）
- 流程排程監控及維護
- 負責監控DACP平台；
- 負責監控及處理排程流程異常的問題，包括失敗，等待，長時間未觸發，流程依賴缺失，權限缺失等問題；
- 每天通過背景自動化監控腳本，對全量排程流程進行全方位監控，将日常遇到的失敗，延遲等問題進行定位分析并優化處理，程式問題及時協調開發人員及時進行處理；
- 對常見問題進行總結分析，歸納問題的發生頻率、影響面、共性等，針對性制定優化措施，以減低挂起量，提升出數及時性，提升日常運維效率。
- SS重點流程監控及維護
- 臨時任務處理
臨時任務包括各項臨時性、突發性、及專項任務等，諸如系統割接上線配合，因資料錯誤、程式問題等需要流程臨時排程、批量重跑後續，查找流程下線需要的詳細資訊以及流程下線，支撐經分側查證流程排程情況，重點應用重點支撐保障、固定分發問題查證等。
- 固定分發接口配置
由于經分生産所需或日常工單需求所需，SS維護人員對現有接口進行修改配置或新增配置。
1、維護突發事件處理
由于日常生産中遇到各類突發事件,例如資料庫當機、表空間滿、排程系統異常、4A平台異常等等。
月初運維任務
SS月初運維任務包括屬地化基站維表維護、賬單科目維表維護、主策劃維表、部分DWD月流程手工維護、月末DWD重點日流程手工維護、以及屬地化月表後置流程排程。
- 屬地化基站維表
每月月底最後一天完成屬地化基站檔案導入資料确認後，維護人員電話督促各屬地基站維護人員必須在1号完成基站維護，如遇不可控因素影響進度必須及時上報。
13個屬地完成基站維護後，維護人員完成相應的驗證工作，驗證完成後郵件通知後續維護人員。
2）賬單科目維表維護
每月初對賬單科目維表DIM_ACC_ITEM_CODE按要求進行更新個性化處理。
每月待客戶通知shfin.r_vr011表維護完成，ss确認shfin.r_vr011表從mpp已成功分發至一體機SHFIN.RPT_VR011。（注：select * from all_objects where object_name like'%RPT_VR011%'确認分發一體機成功）手工排程以下程式。
| 步驟等級 | 平台 | 程式 | 備注 |
| 1 | 一體機 | DimAccItemCode | 重做後續 |
| 2 | 一體機 | DimEvtIvrNode | 确認程式運作成功 |
| 一體機 | DimEvtCsrSkill | ||
| 一體機 | DimAccWmsNavtreemap |
3）主策劃維表
每月初對主策劃維表按要求進行更新個性化處理；同時打上相應的完成辨別。
每月甲方通知資料表維護完成。
4）部分DWD月流程及月末DWD重點日流程
對于部分需要手工幹預的DWD月流程及部分月底的DWD日流程進行前置判斷驗證，并及時進行手工排程并跟蹤過程、及完成情況。
每月當出賬那邊出完賬驗完資料之後，甲方通知一體機和24庫資料都已到位，可以執行以下操作。
| 步驟等級 | 平台 | 程式 |
| 1 | 一體機 | DwdMergeBillM |
| 1 | 一體機 | DwdMergeBillProdM |
| 1 | 一體機 | DwdMergeBillItemM |
| 1 | 一體機 | DwdMergeBillDtl4M |
| 2 | 一體機 | DwdAccFinItemDtlM |
| 3 | 一體機 | DwdAccPrepaySplitedM |
| 3 | 一體機 | DwdSvcGrpMemProdM |
| 3 | 一體機 | DwdSvcGrpSrvAttrM |
| 3 | 一體機 | DwdSvcUsrOsStateM |
| 3 | 一體機 | DwdPrtyGrpInfoM |
| 3 | 一體機 | DwdAccWriteoffRecM |
| 3 | 一體機 | DwdAccAdjustBusiRecDmM |
| 3 | 一體機 | DwdAccPocketM |
| 3 | 一體機 | DwdAccSumBillM |
| 3 | 一體機 | DwdAccPocketM |
| 3 | 一體機 | DwdAccSumBillM |
| 3 | 一體機 | DwdAccGrpAdjustM |
| 3 | 一體機 | DwdAccGrpOweInfoM |
| 3 | 一體機 | DwdAccOweM |
| 4 | mpp | DwdMergeBillDtl4M_MPP |
在以上程式運作成功後
| 步驟等級 | 平台 | 程式 |
| 1 | 一體機 | DwdMergeRcBillDtlD |
| 1 | 一體機 | DwdMergePromBillD |
| 1 | 一體機 | DwdMergeSrvcDtl1D |
| 1 | 一體機 | DwdMergeDailyBillD |
| 1 | 一體機 | DwdMergeUsageBilltD |
| 1 | 一體機 | DwdMergeBillDtl3D |
| 2 | 一體機 | DwdAccItemDtlD |
| 2 | 一體機 | DwdAccFinItemDtlD |
| 3 | 一體機 | DwdAccPrepaySplitedD |
5）屬地化月表後置流程排程
每月月初在使用者屬地化表已經生成驗證通過的情況下，對于依賴該表的後置流程進行手工幹預發起排程，并跟蹤過程及完成情況。
屬地化資料驗好後，待甲方郵件通知結果表已分發到MPP庫：
确認分發表分發完成；
分發完成後将DACP排程（MPP任務）強制通過，監控後續程式排程情況。
自動化維護及監控措施
1) 模闆化輔助維護手段
| 類别 | 模闆化輔助手段 | 用途 |
| 系統 | yt，mpp總體運作情況 | 監控DACP排程系統是否正常運作、今日總程式完成數 |
| 系統 | yt，mpp的DWD程式運作情況 | 監控基礎層程式完成數 |
| 依賴 | 程式血緣分析 | 檢視程式排程所用到的表，生成的目标表。 |
| 依賴 | 後置依賴查詢 | 批量查找任意流程的所有後置流程，排程流程影響分析 |
| 依賴 | 前置依賴查詢 | 批量查找任意流程的所有前置流程，排程流程依賴的條件 |
| 依賴 | 事件觸發程式執行條件查詢 | 如果事件觸發流程沒有觸發就根據流程flowid檢視程式依賴的接口以及判斷的分控表 |
| 依賴 | SS流程名查詢 | 以程式名或表名查找流程名稱 |
| 依賴 | 查詢表固定分發 | 當用到的表不是ss程式跑出的時候，以表名去分發控制表檢視表是否屬于分發，源庫是哪裡及分發情況 |
| 異常 | 運作超長時間流程查詢 | 速查一周内平均運作時間超長的流程清單發開發優化程式 |
| 異常 | 等待流程查詢 | 速查長時間等待運作的流程清單 |
| 異常 | 檢視接口裝載完成情況 | 以接口号去ETL分控表查詢出接口裝載狀态根據情況接口、程式跟蹤處理 |
| 異常 | 建立程式實時監控列出YT和MPP | 直接查詢表即可統一處理不同平台的所有失敗程式 |
| 2個平台所有失敗程式、失敗原因更新到日志表裡 | ||
| 異常 | 列出YT和MPP哪些接口沒好 | 查出今日dacp顯示沒有通過的接口以及影響的程式 |
| 異常 | 熱點通報（重點保障）完成情況清單 | 查重點保障程式及依賴的所有前置該完成還沒完成的程式清單 |
| 異常 | 熱點通報及依賴沒完成 | 快速定位重點保障程式及前置未完成的最終依賴原因 |
| 的大緻原因 | ||
| 異常 | 一經前置日程式哪些沒跑 | 單獨監控這個組的所有程式完成情況（重點保障） |
| 異常 | 查程式未運作原因 | 定位程式延遲未觸發的最終依賴原因 |
| 異常 | 監控日流程沒跑的 | 監控所有日程式今日還沒運作成功的清單 |
| 異常 | 超過1天未完成清單 | 查延遲1天還未運作的程式并分類處理 |
| 異常 | 超過2天未完成清單 | 查延遲2天還未運作的程式并分類處理 |
| 異常 | 查重點接口延遲清單 | 單獨監控重點保障程式依賴的所有接口該完成還未完成的接口 |
| 異常 | 監控月流程沒跑的 | 監控所有月程式該完成還沒運作成功的清單 |
| 異常 | 監控程式依賴失效的 | 查因依賴配置問題導緻未觸發的程式 |
| 異常 | 60庫，判斷接口裝不裝YT機， | 查因依賴接口配置問題導緻未觸發的程式 |
| 瞞足3張配置表都要有記錄 | ||
| 異常 | 查程式延遲大緻原因 | 輔助分析程式比昨天完成時間晚的原因 |
| （今日資料，分析前置完成時間是否有延遲） | ||
| 異常 | 查詢程式中存在死循環的程式 | 查因依賴配置問題導緻未觸發的程式 |
| （即互相依賴） |
2) 自動化監控措施
| 序号 | 告警分類 | DACP監控項 | 告警形式 | 告警級别 | 監控頻率 |
| 1 | dacp系統監控 | 檢查程式發送至agent狀态超過10分鐘，疑似代理僵死監控 | 電話/短信 | 非常重要 | 每1小時 |
| 2 | dacp15分鐘内無任何程式跑出告警 | 電話/短信 | 非常重要 | 每1小時 | |
| 3 | YT機表空間監控 | 電話/短信 | 非常重要 | 每1小時 | |
| 4 | 代理程序數、長時間不寫日志監控 | 電話 | 非常重要 | 實時 | |
| 5 | rabbit@YP-DACP-01程序監控 | 電話 | 非常重要 | 實時 | |
| 6 | server程序長時間不寫日志監控 | 電話 | 非常重要 | 實時 | |
| 7 | dacp流程監控 | 基礎話單明細檢查 | 電話/短信 | 重要 | 每1小時 |
| 8 | 漫入話單明細檢查 | 電話/短信 | 重要 | 每1小時 | |
| 9 | 小話單明細檢查 | 電話/短信 | 重要 | 每1小時 | |
| 10 | 2點批次dwdayrun完成數告警 | 電話/短信 | 重要 | 每1小時 | |
| 11 | 3點批次dwdayrun完成數告警 | 電話/短信 | 重要 | 每1小時 | |
| 12 | 4點批次dwdayrun完成數告警 | 電話/短信 | 重要 | 每1小時 | |
| 13 | 6點批次dwdayrun完成數告警 | 電話/短信 | 重要 | 每1小時 | |
| 14 | dwdayrun程式失敗告警 | 電話/短信 | 重要 | 每1小時 | |
| 15 | 7點批次SS重要程式完成數告警 | 電話/短信 | 重要 | 每1小時 | |
| 16 | 正在運作的程式運作時長超過1小時告警 | 短信 | 重要 | 每1小時 | |
| 17 | 失敗程式告警 | 短信 | 重要 | 每1小時 | |
| 18 | 經分熱點未完成數告警 | 短信 | 重要 | 每1小時 | |
| 19 | 超過參考時間接口未完成告警（經分熱點及所有前置依賴的接口監控） | 電話/短信 | 非常重要 | 每1小時 | |
| 20 | dacp流程總體運作情況監控 | 日程式總數，程式執行成功數與參考完成數短信提示 | 短信 | 重要 | 每1小時 |
| 21 | 流程失敗個數 | 短信 | 重要 | 每1小時 | |
| 22 | 正在執行程式個數 | 短信 | 重要 | 每1小時 | |
| 23 | 等待前置程式個數 | 短信 | 重要 | 每1小時 | |
| 24 | 等代理程式個數 | 短信 | 重要 | 每1小時 | |
| 25 | 今日未觸發程式個數 | 短信 | 重要 | 每1小時 | |
| 26 | ss監控 | ss代理程序監控 | 短信 | 重要 | 每20分鐘 |
ETL運維服務
- 工作概述：
- 保障雲化ETL平台、話單合并伺服器的正常運作；
- 實時監控雲化ETL平台的接口運作情況、及時處理因各種故障原因導緻失敗的接口，確定平台的資料采集、預處理、傳輸、入庫、庫内處理的及時性和準确性；
- 定期分析雲化ETL平台接口各個環節的運作情況、相關程式記憶體使用率、ODS表空間使用率等資料進行分析，設計合理的優化措施來保障平台系統的穩健性及生産效率。
- 保證重點大接口在規定時間之内完成。
日常ETL維護
- 雲化ETL平台的日常運維
- 基本資訊
- 日接口1600個左右，月接口1200個左右，小時接口逾40*24個左右；
- 涉及外圍資料庫約 35台；
- 涉及各類外部業務平台約50個；
- 日常運維包括：
- 及時處理各種原因導緻的資料抽取、裝載失敗接口（如ETL平台本身軟硬體故障、源檔案缺失、源表表結構變化、源資料庫連接配接異常等）；
- 按需求工單要求新增抽取庫、新增外部資料接入、新增接口配置等；
- 按需求工單要求對存量接口進行修改；
- etl排程計劃、優先級等例行優化；
- 完善各類告警配置；
- 實行7*24專人值班制度，每日例行巡檢工作（白天：8:00、12：00、17:00；晚上：05:00、21：00，）：
巡檢内容：
- 5：00通報今日重點接口的完成情況詳情；
- 5：00通報截止目前ETL接口總體情況報告（當日接口任務量，截止目前接口完成總數，失敗總數，待排程總數，終止總數）；
- 21:00-8:30全程監控并及時處理網管電話告警；
- 21:00通報當日話單接口各個小時總體情況
- 8:00、12:00、17:00 針對Jobtracker，Taskertracker，話單合并等程式進行巡檢，及時對各類異常問題進行查證處理，并保持跟蹤直至問題解決。
- 日常維護過程有13個接口為重點關注對象,要保證這些接口完成的及時性。
- 話單裝載保障工作
涉及話單接口主要有GPRS、語音、短信、物聯網以及各類漫入話單；
維護工作包括：
- 話單原始檔案的采集、合并、傳輸以及最終入一體機和MPP資料庫全過程的監控和問題處理；
- 因資料倉庫故障，需人工處理故障期間失敗話單接口；
- 因話單伺服器故障，需人工處理故障期間話單分發，合并，上傳程式；
- 配合各類對話單資料品質驗證的工作；
- 目前有如下話單，其中第一類話單：10003、10010、10025為大資料量話單，是計費側主動推送，其餘均為第二類話單，資料量較小的話單,也是計費側主動推送。
- 第一類大資料量話單 10003、10010、10025的裝載流程圖如下：
- 其餘第二類話單的流程裝載流程圖如下：
- VGOP類接口的保障工作
- VGOP類接口180個左右
- 配置VGOP日接口依賴小時VGOP接口工作流程；
- 應開發需求對現有接口配置修改（如：接口排程時間，接口優先級，添加一體機）；
- 應開發需求配置VGOP接口個性化監控；
- 及時回報需求人員因源檔案缺失導緻接口長期失敗的狀況，并協同需求人員拟定處理方案；
- VGOP主要分為兩種類型，一種為一級vgop，另外一種為二級VGOP，他們的裝載流程分别如下，他們的主要差別為DL2環節需要通過中轉機到集團主機采集VGOP資料檔案和校驗檔案。
- 日常etl 各類問題的查證及臨時工作
- 協助開發部門，完成etl環節的資料品質問題的查證工作；
- 按開發需求完成接口資料的重抽工作；
- 協助SS團隊對執行失敗、異常程式，程式運作緩慢等問題定位；
- 當etl系統出現問題，可以借助背景程序的日志資訊來查找異常問題所在：
- 配合審計工作的曆史資料抽取
- 應審計要求完成新增配置；
- 應審計要求對重新抽取曆史資料（重抽接口數量、資料周期往往非常大）；
- 審計期間協助審計人員進行資料品質驗證相關工作；
- 來自審計方面的需求每年一般在2-3 次，每次持續1-2個月；
- 每天ETL系統每個時間段抽取的數量如下圖：
- 每個源資料庫中抽取的資料量統計圖如下：
- ETL系統告警
基本情況：當系統程序出現異常情況,或者接口運作過程中逾時未完成等異常情況時,系統就會發送告警資訊.當告警級别較高時,如程序異常就會有人工撥打告警電話給值班工程師.
- 告警級别一般時,隻會收到告警短信,如下圖所示:
- 當告警級别較高時,如程序異常就會有人工撥打告警電話給值班工程師.如下圖所示:
ETL平台相關的維護工作
基本情況：
平台涉及應用伺服器：18台
平台涉及各類監控、預處理、庫内處理、接口特殊處理shell和python腳本：50個
包括：
- 平台涉及的伺服器的各類空間維護，包括ETL使用的檔案系統的維護清理和壓縮、表空間的維護清理、資料生命周期的管理、超級大表的維護管理，MPP資料庫資料傾斜問題的處理、MPP資料庫事務日志問題的簡單處理
- 不定期對核心腳本進行優化完善和各類維護
- ETL資料源庫切庫操作
基本情況：少數接口的切庫直接在前台操作即可，接口配置管理中選擇接口進行修改，但涉及接口較多的庫需要利用sql語句批量修改，操作如下：
- 背景批量切庫操作（在背景修改配置表務必做好備份工作，以便恢複）；
- 配置表修改範圍
| 序号 | 表描述 | 備注 |
| 1 | se_s_comp_ins_para | 資料源 |
| 2 | se_s_flow_def | 用于前台展示 |
| 3 | st_b_task | 用于前台展示 |
- 備份資料庫表的操作（模拟接口04882，原抽取庫為shcrmbcv3改為shdd21）
- 修改背景表
- 更新para_value（資料源）
- 更新para_value（連接配接字元串）
- 更新src_db字段，值：shdd21
- 更新src_db字段，值：shdd21
- 結果驗證
檢視接口配置：如圖：
- 批量排程該接口較早周期，觀察實際抽取庫資訊，如圖：
- ETL系統Mpp庫并發數調整
- 背景檢視日志觀測資料庫連接配接情況
- 擴大MPP連接配接數操作
- 重新開機 datasource 程序：
- 檢視日志；db2_mpp_pro連接配接數是否已調整
- ETL系統批量修改排程時間
案例描述：新客服庫例行維護，維護時間段0-2點，3點恢複
解決思路：需要把排程時間在0-3點時間段的接口完後延
- 前台修改
若少量接口的時間排程，直接在前台修改即可。
注：修改完成後，要将該接口執行一次下上線操作；
- 背景修改
若涉及接口較多，需要在背景修改，提高效率
- 操作步驟：
- 備份相關表：
- 更改表 st_b_task(任務排程配置表)
- 更改表 ST_B_TASK_TRIGGER（任務排程時間配置表）
- 次日觀察排程時間是否已修改，next_trigger_time是否改變
- ETL系統loadmp，inmp
- 第一步（前台修改），進入 “主機管理”界面；
- 第二步（背景修改），進入資料庫（51）執行以下SQL。
- 夜間值班常見問題以及處理辦法
- 話單問題之一: 裝載一直為執行狀态
案例: 今日話單告警為10010接口，2019021821批次LOADYT一直為執行狀态，并且沒有生成臨時表；
處理方法：前台界面，重跑一體機入庫節點，恢複正常
- 話單問題之二：沒有原始小檔案
案例：2：00—5：00 之間沒有 原始小檔案，導緻一體機和mpp 庫裝載失敗。
處理方法：
- 聯系計費側，确認原始話單小檔案沒有送達etl 的原因
- 建立空檔案（對應目錄：/etlfile1/bosscdr/etlloadfile/話單類型/周期）
在失敗批次的校驗檔案裡中插入對應的空檔案記錄
（校驗檔案）
- 建立好後，進入前台界面點選重跑該批次接口
- 接口在LOADYT環節出現僵死
特殊情況下，一體機臨時表裝載完成後，沒有傳回成功狀态，導緻LOADYT元件狀态一直處于執行中。
| 案例 | |||
| 接口 | 04113 | 周期 | 20190110 |
| 描述 | 裝載一體機時間過長，導緻網管告警 |
- 分析
判斷LOADYT環節是否僵死，登入到該接口（LOADYT環節）執行主機确認主機上的sqlldr程序是否存在(ps -ef | grep接口号)；
- 程序存在：說明該接口仍處于LOAD狀态，如果LOAD的時間比往常要久需從其他層面分析原因；
- 程序不存在：登入ORACLE資料庫判斷臨時表select count(1) from SHODS.LD_04113_20190110存在并确認資料量是否與MPP庫一緻。當确認資料無誤時；可進行下步操作；
- 處理方法：程序存在：判斷是單個接口裝載入庫慢還是所有接口入庫慢(判斷視圖:etl_YT_two_day)，評估下影響面，緊急需要在經分群告知下（注意語言表達）；
- 程序不存在,而且資料已經裝載臨時表完畢：
- 首先将臨時表rename為正式表
- 正式表進行賦權
- 先在前台找到該接口執行個體号，如圖：
- 再修改背景執行個體節點表，把該接口LOADYT狀态置成功
- ETL系統中tasktracker程序僵死或程序掉線了
問題描述：執行機tasktracker僵死，無法向Jobtracker請求任務。
處理方式：根據告警查詢或觀察前台頁面執行機完成任務數。
- 第一步：找出哪台執行機程序僵死或掉了
- 第二步 ：先根據sql來判斷哪台執行機程序僵死；
通過“【網管】Tasktrakc超過60分鐘未擷取任務，請查證”這條告警資訊，在all_ monitor.sh中查出對應sql并執行。
- 第三步：觀察前台頁面
- 第四步：重新開機對應執行機上的tasktracker程序，
- ETL配置庫連接配接池上限
問題描述：Tasktracker接口初始化失敗。
失敗原因：Tasktracker連接配接配置庫的線程數到達最大值。
處理方式：把失敗的接口手工排程一次；
- ETL系統查詢當天有系統BUG導緻失敗的接口
- ETL系統新增一類話單
- ETL系統新增一台執行機
- 查找前台展示資訊對應的背景SQL的方法
- 預處理，庫内處理浮動IP設定
- 執行程序因 fetchsize崩潰快速止損
ETL月維護任務
- 月接口維護
月接口的維護時間一般從每月1日到10日；
月接口總數逾1200
主要包括：
- 跟蹤當月月接口完成情況，及時對因各種原因導緻的失敗接口進行故障原因分析、定位和處理；
- 配合開發人員對當月資料品質異常接口查證處理；
- 每月根據實際情況完善月接口監控，對輔助腳本進行完善，出具月度ETL工作報告等；
- 模拟出帳
根據開發部門需求每月中旬以後做2-3次相關模拟出賬資料的抽取，以確定正式抽取時，資料的準确性，工作内容：
- 待模拟庫準備好後，人工把相關接口調整到模拟庫進行抽取；
- 接口成功後，通知相關人員接口已成功，如接口期間出現突發狀況，及時通知各環節負責人員，并一同協助解決故障問題；
- 出賬範圍
| 接口描述 | 接口總數 |
| 正常出賬 | 29 |
| 物聯網出賬 | 17 |
- 操作步驟
| 序号 | 描述 |
| 1 | 登入伺服器，執行以下指令 |
| 2 | nohup /etlfile/shells/month_init.sh mc_new &（模拟出賬） |
| 3 | nohup /etlfile/shells/month_init.sh mc_wlw &（物聯網模拟出賬） |
- 前台觀察模拟出賬與物聯網模拟出賬
- 每月2次的例行維護工作
- 因源庫維護工作需将接口排程時間進行推遲，且全程跟進涉及接口運作情況直至接口成功，資料品質驗證無誤為止；
- 處理因MPP、一體機資料庫維護導緻的話單裝載中斷、失敗等故障，驗證資料品質無誤為止；
- 每個月末最後一天切換正式庫與BCV庫
- 每個月末最後一天23點前手工把CRM庫（正式），ZW庫（正式）訂單庫（正式），PUB庫（正式）置成切換到BCV庫，且把正式庫和BCV庫狀态置為待緒。
- 每月1日把上面切換的資料庫庫還原。
分發平台維護
1.分發平台維護内容
分發接口總數約為3000左右：
- MPP庫-集市庫：353個左右
- MPP庫-TD庫：200個左右
- MPP庫-VGOP庫：50個左右
- MPP庫-前台庫：890個左右
- 一體機-集市庫：275個左右
- 一體機-MPP庫：740個左右
- 一體機-TD庫：120個左右
- 一體機-前台庫：60個左右
1）分發平台的配置、監控、維護、和問題處理
- 根據開發部門需求配置新增分發接口；
- 根據每日接口運作情況不定期調整各個時間段接口完成情況總數的閥值；
- 每日多次定時對接口完成情況進行巡檢；
- 及時處理各類失敗和僵死的接口，如發現外部原因導緻的問題，及時與相關負責人聯系并解決；
2）分發平台本身的維護
- 對固定分發程序進行監控檢查，程序主要包括分發總控程序，分發出庫程序，分發入庫程序等
- 分析定位程序異常原因，處理各類程序異常問題。
- 分發平台的環境維護，包括各類空間告警、清理、維護等。
- 及時處理各類失敗和僵死的接口，如發現外部原因導緻的問題，及時與相關負責人聯系并解決；
3）出具月度分發平台的巡檢報告
每月7号提供上月分發平運作報告，内容包括：
- 截止7号分發接口總數，失敗總數；
- 當月存在的問題接口，接口是否已經處理完畢；
- 各個庫每小時完成接口總數的情況。
4）分發程序的啟停
- 初始化任務程序啟停
| 停：ps -ef | grep dsDispatch.sh | awk '{print $2}' | xargs kill |
| 啟：nohup /bin/bash /home/etla/disp/dsDispatch.sh> /dev/null & |
- 出庫控制程式啟停
| 停：ps -ef | grep dsExpCtl.sh | awk '{print $2}' | xargs kill |
| 啟：nohup /bin/bash /home/etla/disp/dsExpCtl.sh> /dev/null & |
- 入庫控制程式啟停
| 停：ps -ef | grep dsImpCtl.sh | awk '{print $2}' | xargs kill |
| 啟：nohup/bin/bash /home/etla/disp/dsImpCtl.sh> /dev/null & |
- 分發初始化任務程序的應急切換步驟
初始化程序目前隻部署在248、250上，假定248 伺服器出現硬體故障，需将248的初始化程序切換到250上，切換步驟如下：
- 250上，進入/home/etla/disp/目錄下
- 執行初始化任務程序啟動腳本
nohup /bin/bash /home/etla/disp/dsDispatch.sh> /dev/null &
- 觀察任務是否能正常下發
- 分發AGENT的應急切換步驟
目前有A/B/C台伺服器, 假定A 伺服器出現硬體故障, 需要将 A上的分發任務切換到 B/C , 切換步驟如下:
- 将A上的分發配置表進行備份，以便于A恢複後，重新恢複分發任務
Create table DISP_EXP_CFG_20181015 like DISP_EXP_CFG;
Insert into DISP_EXP_CFG_20181015 select * from DISP_EXP_CFG;
入庫配置表備份方式同上
- 将配置在A上的任務全部切換到C上，
update DISP_EXP_CFG set agent_name='AGENT_C' where agent_name='AGENT_A';
- 将當日已經在A上運作，且未運作成功的接口全部切換到C上
Update disp_export_ctl set deal_stat=0,agent_name='AGENT_C' where agent_name='AGENT_A' and deal_stat<>99 and deal_stat<>'-100';
Update disp_import_ctl set deal_stat=0,agent_name='AGENT_C0' where agent_name='AGENT_A' and deal_stat<>99 and deal_stat<>'-100';
- 檢測切換任務後，任務是否能正常分發
- 分發情況快速查詢
- 當天分發進度 (disp_today)
說明：
庫名：指分發中的入庫名稱
5點：指0：00~5：00期間
參考值：最近一個月完成接口累計完成數的平均值
完成量：當天接口的接口累計完成數
偏移比：完成量相對于參考值的增長率
- 正在執行的接口量(disp_execute)
說明：
入庫等待量：超過10分鐘，沒有開始入庫的接口量（數值較大，一般是出現了問題，如程序僵死）
- YT出庫完成量（disp_export_ytinfo）
說明：
每小時YT出庫完成量
監控範圍：0-9點
- MPP出庫完成量（disp_export_mppinfo）
說明:
每小時MPP出庫完成量
監控範圍：0-9點
- MPP入庫完成量（disp_import_mppinfo）
說明：
每小時MPP出庫完成量
監控範圍：0-9點
2.重點值守保障
在局方的要求下，主要是在重要通信保障或國定節假日期間，根據保障等級要求，提供現場或遠端VPN值守服務，根據服務品質進行考核。
3.突發情況響應
面對突發情況或突發事件，應提供應急響應，要求按照故障等級和響應時限到達現場處理。如有同類故障的處理預案，立即進行業務恢複。否則更新至遠端技術支撐中心，同時通報各相關廠商請求提供技術支援服務。同時，現場支援服務工程師将到達現場，實施或配合進行業務恢複和故障處理。
4.服務滿意度保障
空中選号系統服務確定及時、有效的解決服務中出現的問題，不造成各類故障預警，使空中選号系統達到服務滿意度名額考核要求。
具體工作：1、對空選系統進行維護；2、确認系統情況合理更新系統版本；3、相關應用配置按需調整；4、對相關應用特征進行及時更新。根據要求，對流量政策進行調整，并對裝置系統進行安全漏洞掃描，及時更新系統更新檔，避免系統隐患。
5.生産安全保障
維護人員需遵守局方的人員進出、機房管理與安全生産規定。
6.資訊安全保障
維護人員需遵守局方資訊安全相關保密規定。系統安全服務包括系統安全保障、資訊安全支援服務。系統安全保障是根據相關方要求，定期檢查空選系統安全設定，防止一些未經允許的通路影響系統的安全。資訊安全支援服務是根據集團資訊安全規範和工信部資訊安全按要求，确定支援服務作業計劃，定時進行系統和應用安全性檢查，定期進行系統密碼回收和檢查，定時對系統的更新檔、漏洞等進行檢查，對發現或受理的問題進行預防性的維護作業，消除故障隐患。根據不同時期的不同要求，經過協商确認後，系統安全服務作業計劃具體内容項目可以定期或不定期的調整。
7.優化建議
積極主動對系統營運提出性能或功能上的優化建議，與局方人員一起，進行實施，評估能否取得明顯效果。
8.臨時任務
有承擔局方臨時交辦任務的義務，并根據具體情況，承諾相應的服務品質。
其他内容
按時總結DACP、 ETL、分發維護技能及經驗，定期組織安排教育訓練，共享維護經驗，提升維護品質及效率。
教育訓練安排
日常教育訓練
每月安排兩次教育訓練，按入職先後順序進行輪換（内容包括工作經驗分享、技能提升、日常工作中各類問題處理等等）。
| 日常教育訓練 |
| 1、每月安排兩次教育訓練，按入職先後順序進行輪換 |
| 2、每次教育訓練盡量安排人數有n-1時進行，若按正常輪班一個月湊不出兩天有n-1人數的， 則請進行手工調整人員的調休安排，以確定每月有2次的教育訓練！ |
| 3、每次教育訓練前，由教育訓練主講者發郵件出來說明教育訓練主題、教育訓練時間、地點， 此郵件必須每次抄送謝翰威； |
| 4、教育訓練結束後，由被教育訓練人給教育訓練主講人進行匿名打分，打分原則是，滿分10分，教育訓練效果感覺一般、還行的，預設都給5分，效果感覺不錯，看得出主講人做過系統化整理準備的， 則可以打7分、8分等，最後将打分進行加總平均，并且由其中一位被教育訓練者将最後的平均分填到SS日報教育訓練sheet頁裡。 |
| 5、在下次教育訓練時，由上次教育訓練主講者提前準備不同題目（不得提前公開），在教育訓練會上，對上次參加的被教育訓練人員進行逐一提問，答出來且基本正确的，則在ss日報的教育訓練頁的” 被教育訓練得分 “裡給予 4分 鼓勵，否則記0分。 |
新人教育訓練
新人入職後前2月強化教育訓練使其能夠快速融如入到日常維護工作中（掌握工作内容、操作制度、問題查證、常見問題處理方式等等）。
| SS&ETL新員工教育訓練計劃表 | |
| 教育訓練背景及目标 | 工作内容主要是對DACP、ETL排程平台完成程式排程的全程監控和日常維護操作 |
| 第一周 | |
| 教育訓練目标 | 熟練使用LINUX,VI基本操作指令，熟練SQL、shell； 了解企業資料倉庫整體架構； 了解維護制度，日常管理； |
| 教育訓練内容 | 1：發送教育訓練文檔以及常用sh腳本 2：講解企業資料倉庫整體架構圖以及我們維護的哪一子產品。 3：閱讀SS團隊維護守則講解維護制度、日常管理 |
| 第二周 | |
| 教育訓練目标 | 了解DACP；了解ETL； 了解日常維護工作内容； |
| 教育訓練内容 | 1：閱讀DACP平台使用者手冊，講解DACP系統大概組成架構； 2：講解DACP常用功能子產品的作用及操作示範； 3：閱讀SS維護五大項工作内容文檔； 4：閱讀ETL核心文檔，講解ETL系統大概組成架構； 5：講解ETL常用功能子產品的作用及操作示範； 6：閱讀ETL維護工作内容相關文檔； |
| 第三周 | |
| 教育訓練目标 | 熟悉日常維護項工作内容； 掌握每個腳本監控項的功能； 熟悉腳本中關聯的每張配置表的用途(提高後期查證報障問題的效率)； |
| 教育訓練内容 | 1：介紹SS日報每個sheet頁工作内容； 2：講解每個維護腳本SQL用途以及何時用； |
| 第四周 | |
| 教育訓練目标 | 掌握常用配置表的常用字段的描述、字段備注（提高後期查證報障問題的效率） |
| 教育訓練内容 | 結合資料字典講解常用配置表用途、常用字段資訊描述 |
| 第五周 | |
| 教育訓練目标 | 了解維護所有的監控項及告警方式、處理方式； 了解程式異常根據不同條線找對應的聯系人處理； 了解接口異常根據不同情況進行處理； |
| 教育訓練内容 | 1：結合sh腳本講解DACP告警類型以及查證、處理、部署方法； 2：閱讀SS團隊維護守則中維護事件更新規範； 3：結合sh腳本講解ETL告警類型以及查證、處理、部署方法； |
| 第六周 | |
| 教育訓練目标 | SS日常維護工作内容已初步了解并掌握DACP基本操作，開始處理每日失敗程式； ETL日常維護工作内容已初步了解并掌握ETL基本操作，開始處理每日失敗接口 |
| 教育訓練内容 | 由老員工帶着開始處理每日失敗程式，監控重點程式完成情況 由老員工帶着開始處理每日失敗接口，監控重點程式完成情況 |
| 第七周 | |
| 教育訓練目标 | 處理DACP日常維護工作；處理ETL日常維護工作； |
| 教育訓練内容 | 由老員工帶着開始處理日常維護工作 |
| 第八周 | |
| 教育訓練目标 | 配置固定分發，查證郵件報障，了解ss排程系統，ETL排程系統 |
| 教育訓練内容 | 講解配置固定分發步驟，問題查證，講解DACP排程系統基本操作與維護，講解ETL排程系統基本操作與維護 |
日常管理
人員管理
做好團隊建設工作，避免由于投入力量不足或能力不夠而引發維護及時性和品質問題；
- 確定維護團隊人員的技術能力和溝通能力，服從上級管理，一經管理方決定的任務，應立即遵守執行；確定工作的連續性、人員的穩定性，降低人員變動帶來的額外成本做好員工的人員教育訓練、入離職申請等工作；駐場人員必須保守客戶機關的機密，務必妥善保管所持有的文檔、檔案；駐場人員確定7*24小時全天待命；上班期間確定現場人員可随時實時處理問題；每日下班前A、B角互查确認SS維護結果；SS維護日報：日常維護交班需生成當班次（包括白班、夜班）工作明細報告；新員工入職一周後，由老員工負責收集新員工開通權限的各項資訊後且已郵件形式發送給局方對口人；
考勤管理
- 嚴格遵守客戶機關的辦公時間，不得遲到早退；如請假未得到客戶機關管理人員同意或未提出申請，按曠工處理；因特殊原因需要延長假期的，需得到客戶機關和公司準許，否則按曠工論處；駐場人員因病必須治療及修養時，憑市級以上醫院診斷書辦理請假手續；
安全管理
- 嚴格遵守并執行《資訊系統營運部工作現場安全守則》 ，定期安排生産安全宣貫演練，預防為主，提升人員、團隊的安全意識；確定各項工作遵照公司及中心資訊安全管理規定，做好帳号管理、敏感資訊查詢、生産環境通路、系統安全審計等資訊安全工作；在各類項目建設、系統維護工作中充分考慮資訊安全，確定通路控制、原始記錄、日志審計等符合資訊安全規範；
服務支撐體系
服務組織
我司提供9人的團隊服務于本項目，服務組織機構如下：
- 項目經理職責：
1、與使用者讨論并确定最終項目範圍和實施方法；
2、負責制訂具體的項目計劃，包括教育訓練計劃；
3、把握項目各方面的程序；
4、指導業務流程重組和項目變更；
5、檢查及調控項目實施範圍；
6、向公司彙報項目狀況，提出建議及改進措施；
7、負責項目階段品質。
- 運維工程師職責：
1、負責本項目相關軟體的日常維護、更新以及軟體應用的二次開發工作。
2、負責面向決策層、管理層、應用層、系統維護層人員提供教育訓練。
3、負責系統維護以及相關技術支援工作。
4、提供系統內建方面的技術支援。
服務流程
為保證現場服務實施的品質能夠穩定并不斷有所提升，保障客戶需求能夠得到有效滿足，保障現場服務實施團隊為客戶提供統一、标準化的服務支援，并為客戶設立專門的客戶服務專員，對進行全程跟蹤，提升服務實施專業性，制定服務流程：
服務規範體系
運維規範
現今，随着計算機技術，特别是網絡技術的飛速發展，對于許多行政機關，許多企業而言，IT技術越來越深入到核心業務，影響政策制定和企業的發展。進而對IT環境的可靠性，可用性和快速适應性提出了越來越高的要求，與此同時，IT環境(包括軟/硬體及相關技術)卻變得越來越複雜。是以，對于一個機關而言：
- 如何把有限的IT資源最有效的作用于核心業務的發展
- 如何最快地擷取專業的支援能力
- 如何實作對系統的完善管理，提高系統的可靠性和可用性
- 如何提高使用者的工作效率，增加最終使用者滿意度
- 如何跟上IT技術的發展，及時更新相關技術
- 如何提高對IT系統利用的靈活性
- 如何更好地管理IT營運成本
- 以提高服務能力，将會是機關可能面臨的問題。
IT服務管理（ITSM）是一套幫助企業對IT系統的規劃、研發、實施和營運進行有效管理的方法，是一套指導IT服務的方法論。ITIL是英國國家電腦局（CCTA）于八十年代開發的一套IT業界的服務管理标準庫，它把業界在IT管理方面最好的方法歸納起來，形成規範，旨在為企業的IT部門提供一套從計劃、研發、實施到運維的标準方法。它一經提出，便被歐洲各大公司紛紛采納，随後在澳洲，美洲和亞洲流行開來，目前已成為IT服務管理事實上的标準。
通過參考這些标準，我們可以充分借鑒國際化标準的IT服務管理最佳經驗，使我們“站在巨人的肩膀上”來設計、規劃及運維IT服務，盡可能少走彎路，有效提高IT服務的品質。
ITIL架構圖
ITIL是基于流程的方法論。IT部門可用其檢查是否用一種可控的和可訓練有素的方法為最終使用者傳遞所需的IT服務。ITIL合并了一套最佳的實踐慣例，可适用于幾乎所有IT組織，無論其規模大小，或采取何種技術。
ITIL對IT服務管理實踐中涉及的許多重要問題進行了系統的分析，包括全面的檢查清單、任務、程式、責任等與任何IT服務組織密切相關的問題。這些概念的定義也涵蓋了大多數IT服務組織的主要行為。IT服務組織可以借助ITIL的指導建立和拓展自己的IT服務流程。
我司學習ITIL、ITSS與ISO9001等國内外先進标準，運維管理規範采用ISO9001模式編寫，涵蓋服務管理體系、服務級别管理、服務台管理流程、突發事件管理、問題管理、變更管理、釋出管理、配置管理等方面，如下圖所示：
如上圖所示，是一個金字塔結構。處于最高層的，是《客戶滿意度指引》，一切服務均以“保證客戶最大滿意度”為前提展開。與之同級的還有服務管理體系檔案與總體檔案，用以與服務管理體系相結合，并且維持服務管理規範的改良性原則。處于中層的，是ITIL核心的11個标準流程，均根據實際情況進行了修訂和優化，以確定在實際工作中能夠得到實際應用，運維管理規範是各種操作指南與巡檢制度，包括日常管理制度等，確定提供給客戶的服務，是統一形象的規範化标準服務。巡檢制度的建立，為企業系統“提高系統可用性、提高系統健壯性、提高各級人員技能素質”的“三提高”目标奠定了堅實的基礎。
突發事件管理
突發事件管理流程緻力于解決突發事件，并快速恢複服務供應。突發事件被記錄下來，并且事件記錄的品質決定了相關的其它流程的效力。
服務台接近于突發事件管理流程和問題管理流程，并處于它們之間。如果沒有适當的控制，變更有可能引入新的突發事件。是以需要建立有效途徑對變更進行跟蹤。這是為什麼建議持續不斷地将突發事件記錄在同一個CMDB中，并分類為“問題”，“已知錯誤”，“變更記錄”等資訊，以促進服務台界面的資訊溝通能力，簡化事件調查和報告。
突發事件的優先權及其更新需要作為服務級别管理流程中的一部分進行協商，并在SLA中備案。
突發事件管理的目标：
突發事件管理的目标是盡可能迅速地根據SLA中定義的普通服務級别作出反應，使産生問題後對業務行為及組織和使用者的影響最小。突發事件管理也應該保留對事件的有效記錄，以便于衡量和改進流程，并向其它流程彙報。
突發事件流程如下圖所示：
問題管理
對于突發事件有兩種處理方法，一種是對其做出服務快速響應，盡快恢複其正常運作，另一種是鑒别和解決問題根源。這兩種方法之間存在微妙的差別，而且經常被互相混淆。對其做好區分具有重要意義。
如果問題被懷疑存在于IT架構内部，問題管理流程将會瞄準其潛在的根源。一個問題可能是被突發事件暴露出來的，但是顯然，問題管理的目标是解決問題根源，預防其可能産生的幹擾，而不是迅速恢複系統運作。
當問題被識别後(被識别的問題通常稱之為已知錯誤)，通常需要進行一個業務決策，決定是否采取永久性措施改進系統架構，以預防再次發生新的突發事件。如果需要，送出一個變更請求來實作改進。
為了有效和高效地識别突發事件背後的問題根源及其發展趨勢，問題管理流程需要準确全面的突發事件的記錄。問題管理流程同樣需要和可用性管理流程密切聯絡，以确定這些趨勢并明确補救措施的重要性。
流程：
配置管理
配置管理緻力于控制一個變化中的IT架構(标準化和狀态監控)，鑒别配置項目(清冊，互相關聯，稽核與注冊)，收集和管理有關IT架構的文檔，為所有其它流程提供IT架構的相關資訊。
配置管理是所有其它服務管理流程不可分割的一部分。擁有目前架構中所有部件的最新的，準确的，全面的和詳細的資訊，并管理其變更，使這些資訊有效而高效地支援其它流程運作。變更管理可以與配置管理內建。至少，建議在配置管理系統中控制變更的登入和實施，并自在配置管理系統的幫助下對變更影響做出評估。是以所有變更請求應該被輸入配置管理資料庫(CMDB)，并随着變更請求的進展随時更新記錄，直至其實施。
配置管理系統識别一個變更項目和架構中其它部件的關系，将這些部件的所有人召集到影響評估流程中來。不管一個變更是否在架構中實施，互相關聯的配置管理記錄應該在CMDB中得到更新。最好在變更發生時，使用內建工具自動地更新記錄。
CMDB應該開放給整個服務支援組，使所有人了解部件失效可能的原因，進而使突發事件和問題可以被更容易地解決。CMDB還應當被用來把突發事件及問題記錄和其它記錄聯系起來，比如失效的配置項目(ConfigurationItem-CI)和使用者之間的聯系。如果缺少了配置管理流程的內建，釋出管理将難以實作，并可能錯誤連連。
服務傳遞流程同樣依賴于CMDB中的資料。例如：
服務級别管理需要識别互相結合在一起的部件，并在此基礎上設定支援協定，傳遞服務。
IT财務管理需要知道每個業務部門使用的IT架構部件，尤其是對于收費的項目。
IT服務持續性和可用性管理需要識别部件，用于問題風險分析和部件失效影響分析。
下圖顯示了配置管理和其它服務管理流程之間的關系：
圖：能力管理，變更管理，配置管理和釋出管理之間的關系
變更管理
變更管理專注于對IT架構實施可控的變更。此流程的目标是确定所需的變更，并決定這些變更如何在對IT服務産生最小的不利影響的範圍内得以實施。同時確定其變更是可追溯的，而且是經過整個組織内部有效地磋商和協調的。在客戶組織送出變更請求後，由配置管理流程監控其狀态，與問題管理和若幹其它流程進行協調。變更實施履行一特定的路徑，包括定義，計劃，建立，測試，接受，實施，和評估。
變更管理流程依賴于配置資料的準确性，以確定獲知所有實行變更造成的影響。是以變更管理與配置管理之間有密切的聯系。
變更流程的詳細内容應在SLA中存檔，確定使用者知道送出變更申請的程式，項目目标及時間，以及實施變更造成的影響。
變更的詳細内容需要通知服務台。即使變更經過了全面測試，仍然很有可能存在實施變更的過程中發生各種困難，這些困難可能緣于變更沒有按需求或預期運作，或者對變更對功能造成的影響産生質疑。
變更咨詢會議(ChangeAdvisoryBoard-CAB)由可向變更管理小組提供專家意見的人員組成。這個會議很可能由來自于所有領域的IT及業務機關的人參與。
釋出管理
釋出是指一組配置項目(ConfigurationItems–CI)經過測試被引入處于活動狀态的環境中。釋出管理的主要目标是確定釋出資訊被成功地公布，包括歸納綜合，測試與存檔。
釋出管理確定隻有經過測試和正确授權的軟硬體版本才能提供給IT運作環境。釋出管理與配置管理和變更管理的行為密切相關。真實的變更實施經常通過釋出管理行為得以貫徹。
變更的結果可能經常來自于新硬體，新版本軟體，以及新的文檔(自行建立，或購買而來)等。對它們進行控制，并打包和頒發。有關存檔安全和公布程式應該和變更管理和配置管理流程緊密內建。釋出的程式也可能作為突發事件管理和問題管理流程中不可分割的一部分，同時還和CMDB密切相連，以維護及時更新的記錄。
團隊穩定性方案
人員管理原則
1、配置設定的工作要适合他們的工作能力和工作量
人崗比對是配置員工追求的目标，為了實作人适其崗，需要對人員和崗位進行分析。每個人的能力和性格不同，每個崗位的要求和環境也不同，隻有事先分析、合理比對，才能充分發揮人才的作用，才能保證工作順利完成。
通過四種方法來促進人崗比對：第一，多名進階經理人同時會見一名新人員，多方面了解他的興趣、工作能力、工作潛能；第二，公司除定期評價工作表現外，還有相應的工作說明和要求規範；第三，用電子資料庫貯存有關工作要求和人員能力的資訊，及時更新；第四，通過“委任狀”，由進階經理人推薦到重要崗位的候選人。
2、論功行賞
人員的貢獻受到諸多因素的影響，如工作态度、工作經驗、教育水準、外部環境等，雖然有些因素不可控，但最主要的因素是人員的個人表現，這是可以控制和評價的因素。其中一個原則是——人員的收入必須根據他的工作表現确定。人員過去的表現是否得到認可，直接影響到未來的工作結果。論功行賞不但可以讓人員知道哪些行為該發揚哪些行為該避免，還能激勵員工重複和加強那些有利于公司發展的行為。是以，在工作表現的基礎上展現工資差異，是建立高激勵機制的重要内容。此外，巴斯夫還根據員工的表現提供不同膳食補助金、住房、公司股票等福利。
3、通過基本和進階的教育訓練計劃，提高人員的工作能力，并且從公司内部選拔有資格擔任上司工作的人才。
為人員提供廣泛的教育訓練計劃，由專門的部門負責規劃群組織。教育訓練計劃包括一些基本的技能教育訓練，也涉及到高層的管理教育訓練，還有根據公司實際情況開發的教育訓練課程，以幫助人員成長為最終目标。組織結構的明确，每個人員都知道自己崗位在公司中的位置和作用，還可友善地了解到有哪些升遷途徑，并可擷取相關的資料。巴斯夫在晉升方面有明顯的内部導向特征，更趨向于從内部提拔管理人員，這為那些有志于發展的人才提供了升職機會。
4、不斷改善工作環境和安全條件
适宜的工作環境，不但可以提高工作效率，還能調節人員心理。根據生理需要設計工作環境，可以加快速度、節省體力、緩解疲勞；根據心理需要設計工作環境，可以創造愉悅、輕松、積極、活力的工作氛圍。對工作環境進行人性化的改造。
安全是對工作條件最基本的要求，但卻是很多企業難以實作的隐痛。建立了一大批保證安全的标準設施，由專門的部門負責，如醫務部、消防隊、工廠進階警衛等，負責各自工作範圍内的安全問題。向所有的勞工提供定期的安全指導和防護設施。還可以建立各種安全制度，如大樓每一層都必須有一名經過專門安全訓練的員工輪流值班。除設施和制度的保障外，還以獎勵的方式鼓勵安全生産，那些意外事故發生率最低的工廠中的房間可以得到安全獎。
5、實行抱合作态度的上司方法
在上司與被上司的關系中，強調抱合作态度。
上司者在上司的過程中，就如同自己被上司一樣，在互相尊重的氛圍中坦誠合作。巴斯夫的上司者的任務是商定工作名額、委派工作、收集情報、檢查工作、解決沖突、評定下屬職工和提高他們的工作水準。其中，最主要的任務是評價下屬，根據工作任務、工作能力和工作表現給予公正評價，讓下屬感受到自己對企業的貢獻、認識到在工作中的得失。評價的原則是“多贊揚、少責備”，尊重員工，用合作的方式幫助其完成任務。任務被委派後，上司必須親自檢查，員工也自行檢驗中期工作和最終工作結果，共同促進工作順利完成。
人員激勵方案
實施人員激勵的意義
員工是企業一切活動的核心，企業的發展離不開員工才能的發揮，而激勵是員工努力工作的動力源泉。于是，如何對員工實施恰當的激勵便成為企業關注的首要問題。
制定激勵方案的指導思想
1、人的行為受兩大動力體系的驅動。一是自我動力，二是超我動力。這兩大動力的平衡關系，決定了人的行為方向。組織中對人的管理，就是想辦法将兩大動力維持在較高的水準并共同指向組織目标。
2、“自我動力”的啟動，主要靠個人利益的吸引。具體方式就是提供三個激勵：報酬激勵、成就激勵、機會激勵。
3、“超我動力”的啟動，主要靠組織目标、事業理想、企業精神、核心理念與價值觀。
4、公司員工因為受到的教育程度較高，是以，其自我和超我強度要高于一般員工。針對知識員工的激勵政策必須适應這種較高的自我與超我動力。
激勵體系與激勵作用
1、激勵體系
| 分 類 | 短 期 | 長 期 |
| 精 神 | 1、授權 2、業績競賽 3、目标任務溝通 4、群策群力 5、表揚 6、短期教育訓練 | 1、員工職業生涯規劃。 2、長期教育訓練 3、員工晉升 4、工作使命 5、企業願景 6、公司内部人文環境 |
| 物 質 | 1、薪酬 2、福利 3、損耗獎勵 | 1、利潤分享 2、股份 3、期權 |
2、激勵作用
激勵措施
（一）完善福利
1、為員工上社保。
2、為辛苦工作的員工提供帶薪休假。
3、節假日分别為員工發放過節費。
4、教育訓練
季度教育訓練需求分析，并根據教育訓練需求調查每月制定教育訓練計劃。将教育訓練作為員工的一項福利，作為公司的企業文化來發展，通過教育訓練來建立學習型企業。
（二）成就激勵制度
1、授權
（1）上司對下屬适當放權，提高員工的責任感；增強每個員工工作的挑戰性。
（2）研究證明，即使你隻是讓員工有權力調整辦公室燈光明暗度，這種小權力都會讓他們更有工作動力。企業員工渴望能夠在工作中自由地展示他們的才華，發揮其聰明才智，這意味着上司不應告訴員工去做什麼，而是在員工“迷途”時給予支援和指導。
（3）這項工作在确定崗位說明書時與各部門協商進行。
2、業績競賽
（1）對部門員工的表現用資料顯示成績和貢獻，進行排名，并逐一表揚優秀員工。
（2）公司設立“業績競賽”專欄，張貼每季度的競賽結果，公布優秀的前5名。
（3）用資料顯示成績和貢獻，能更有可比性和說服力地激勵員工的進取心。
3、目标任務溝通
（1）在項目、任務實施的過程中，經理應當為員工出色完成工作提供資訊。
（2）這些資訊包括公司的整體目标任務，需要專業部門完成的工作及員工個人必須着重解決的具體問題。
（3）每周召開一次辦公會，每月第一周周一召開辦公會，各個經理溝通公司當月的整體目标任務，以及需要各部門完成的工作。
4、群策群力
做實際工作的員工是這項工作的專家。是以，經理必須聽取員工的意見，邀請他們參與制定與工作相關的決策。坦誠交流不僅使員工感到他們是參與經營的一分子，還能讓他們明了經營政策。如果這種坦誠交流和雙向資訊共享變成經營過程中不可缺少的一部分，激勵作用更明顯。
5、表揚員工
（1）當員工出色完成工作時，經理當面表示祝賀。這種祝賀要及時，要說得具體。
（2）如果不能親自表示祝賀，經理應該寫張便條，贊揚員工的良好表現。書面形式的祝賀能使員工看得見經理的賞識，那份“美滋滋的感受”更會持久一些。
（3）項目成功後，公司要開會慶祝，鼓舞士氣。慶祝會不必隆重，隻要及時讓團隊知道他們的工作相當出色就行了。
（4）經理還應該公開表彰員工，引起更多員工的關注和贊許。
對于表現不佳的員工，有時候主管必須做的是幫助他們建立信心，給予他們較小、較容易的任務，讓他們嘗到成功的滋味，并給予他們正面的回饋。之後再給予他們較重要的任務，以逐漸引導出好的表現。
（5）隻重結果，不重過程。
管理者在對員工進行鼓勵時，應該鼓勵其工作成果，而不是工作過程。有些員工工作很辛苦，管理者可以表揚他的這種精神，但并不能作為其他員工學習的榜樣。否則，其他員工就可能會将原本簡單的工作複雜化，甚至做一些表面文章，來顯示自己辛苦，擷取表揚。從公司角度而言，公司更需要那些在工作中肯動腦子的員工，是以，公司應該鼓勵員工用最簡單的方法來達到自己的工作目标。總之，工作成果對公司才是真正有用的。
6、将績效評估和員工發展緊密結合
将工作态度、表現和績效與個人薪資、晉升挂鈎，成正比關系。
（四）機會激勵
1、人力資源部和各經理根據員工的工作技能，把員工安排到相應的崗位，一是做好員工隊伍建設，培養後備幹部；二來也是對員工職業生涯的規劃。
2、員工職業生涯規劃管理這一激勵措施是基于組織與員工共同成長、共同發展和共存共榮的觀念的，是人本管理思想的最佳實作方式。它具有深層次的激勵效應。
3、人力資源部制定和實施教育訓練計劃，增加員工學習的機會。
品質控制能力
服務品質管理
品質管理體系标準
本項目實施應采用先進的品質管理模式和科學的品質管理體系和流程，并根據項目自身特點選用合适的品質控制規程。
目前，我司主要采用ISO9001品質标準和軟體成熟度模型（CMM）兩種控制規程。針對本項目，公司将采用ISO9001品質體系标準，在項目實施的過程中嚴格執行品質标準。
品質控制過程
本項目中，由項目經理制訂品質控制計劃，項目品質控制組進行稽核。稽核方面包括：品質控制措施是否足夠、各個成員的品質責任是否明确合理，測試方法是否适用。
品質評定計劃
為了加強項目品質管理和界定産品品質标準，本公司将制訂适應于項目的檢查驗收規定和品質評定标準，確定工程品質。
本項目中，應實行兩級檢查、兩級驗收制度。一級檢查、二級檢查和一級驗收由本公司實施小組組織完成；二級驗收由使用者組織實施。各級檢查驗收嚴格按項目實施中制訂的相應的檢查驗收規定和品質評定标準執行。對實施和驗收過程中出現的重大技術問題，将上報使用者協調處理，對一般品質問題的處理應予以書面記錄。
品質保障體系
我司将品質視為整個項目計劃的一部分。項目計劃書中的品質計劃部分明确了關鍵過程和最終結果的評估程式和衡量标準。品質計劃和客戶要求的品質相一緻，以確定項目達到客戶在功能、績效和品質等各方面要求。我們的品質保障包括以下幾個方面：
（1） 項目品質管理評估：在項目進行過程中，定期評估項目程序、客戶期望、品質問題和風險等；
（2） 資料管理和變革控制：界定所有與品質控制有關的資料和軟體資料的管理要求，包括各項計劃、過程、表單和标準等等；
（3） 确定流程（如開發流程、監控流程，評估流程和人員安排流程）的執行過程；
（4） 項目品質績效标準：包括目的、衡量方法和彙報方式。
品質管理措施
在項目實施過程中還将采取如下措施保障項目實施品質：
（1）在項目實施前後對網絡性能進行評估。
（2）在系統部署完成後要在實際環境中進行網絡連通性測試、安全政策驗證和應用系統測試。
（3）配合應用系統做好壓力測試，根據壓力測試結果調整系統配置。
（4）項目實施後要進行一定時間的試運作，在試運作期間要重點監控網絡環境的運作情況、安全政策的驗證和業務應用系統運作情況，若出現的問題要及時查找原因并加以修正。
（5）在試點實施過程中驗證方案的可行性和正确性。
項目教育訓練方案
技術教育訓練包括現場教育訓練和專業教育訓練，均有我司負責。采購方有權對我方提出的教育訓練方案和教育訓練計劃進行選擇和調整。
現場教育訓練
現場教育訓練由我司在項目實施現場進行。
我司承諾安排項目采購人認可的具有相關專業資格或者實際工作經驗的人員進行教育訓練；現場教育訓練貫穿于整個項目實施過程。
專業教育訓練
1、我司若中标，将制定詳細的人員教育訓練方案，教育訓練方案包括教育訓練目的、教育訓練時間安排、人數、教材編寫、教育訓練師資情況、教育訓練組織方式等。
2、教育訓練内容和教育訓練對象
（1）系統維護管理教育訓練
教育訓練内容主要包括系統的操作、配置、維護等，系統常見故障現象的診斷和處理，常見的問題及解決方案等。我司為所有被教育訓練人員提供教育訓練環境、文字資料和講義等相關用品。所有的資料用簡體中文書寫。
教育訓練時間：系統試運作期間，具體時間由采購人指定。
教育訓練對象為系統運作管理與維護人員。
（2）操作使用操作手冊
教育訓練内容包括系統組成、結構、功能、使用辦法等。我司承諾為所有被教育訓練人員提供教育訓練環境、文字資料和講義等相關用品。所有的資料用簡體中文書寫。
教育訓練時間：系統試運作期間，具體時間由采購人指定。
教育訓練對象為采購人指定的相關人員。
3、所有的教育訓練教員必須用中文授課，除非有其他的協定規定。
4、相關要求
（1）我司承諾選派具有一定資質和實踐經驗，且受過專門訓練的進階專業技術人員負責各分項的技術教育訓練工作。
（2）我司的教育訓練内容包括基本理論、系統的操作、運作管理、現場操作輔導等，教育訓練方式應應包括技術授課、操作示範、參觀學習和其他必須的業務指導和技術咨詢，確定教育訓練人員對系統基本理論、技術特性、操作規範、運作規程、管理維護等方面獲得全面了解和掌握。
（3）我司承諾在教育訓練開始前20天内将教育訓練計劃和教材送出采購人稽核，除上述教育訓練外，我司還須負責在現場組織對系統的操作，調試和運作技術示範和業務指導。
服務工作協同
我司将制定完整的項目溝通計劃，項目的溝通途徑主要包含以下種類：項目周報、項目例會、項目月報、項目評審報告、變更控制報告，主要的溝通頻率參加下表：
| 溝通方式 | 頻率 | 接收人 | 媒介 | 格式 | 傳遞時間 | 發送人 | 溝通模闆 |
| 項目周報 | 每周 | 使用者上司 | 郵件 | Word 檔案 | 每周一 13：00前 | 項目經理 | 見項目周報模闆 |
| 公司上司 | |||||||
| 項目組全體成員 | |||||||
| 項目周例會 | 每周 | 部門上司 | 會議、電話 | Word 檔案 | 每周 | 項目經理 | 見項目周報模闆 |
| 使用者上司 | |||||||
| 項目組全體成員 | |||||||
| 項目月例會 | 每月 | 部門上司 | 會議 | Word 檔案 | 月底前 | 項目經理 | 見項目月報模闆 |
| 使用者上司 | |||||||
| 項目組全體成員 | |||||||
| 項目月度 監測報告 | 每月 | 使用者上司 | 郵件 | Word 檔案 | 每月第一周前 | 項目經理 項目成員 | 見項目月報模闆 |
| 公司上司 | |||||||
| 項目組全體成員 | |||||||
| 項目每日例會 | 沒有 限制 | 使用者上司 | 會議 | 口頭 書面 | 沒有限制 | 無 | 見項目例會内容 |
| 項目組成員 |
項目周報
| 基本資訊 | ||
| 項目名稱 | 報告日期 | |
| 項目所處階段 | 報告批次 | |
| 項目負責人 | 稽核人 | |
| 任務與進度 | ||
| 人力資源 | ||
| 軟硬體資源 | ||
| 上周工作總結 | ||
| 本 周 主 要 工 作 内 容 | 負責人 | 參與人 |
| 項目風險分析 | ||
| 1、 | ||
| 需要協調事件 | ||
| 1、 |
項目月報
| 月度總結報告—第X月度 （ 年 月） | |||||
| 1、本月完成的主要任務 | |||||
| 序号 | 任務描述 | 相關責任人 | 實際完成日期 | 工作産品 | 備注 |
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 2、本月小結 | |||||
| 3、待解決問題 | |||||
項目例會
項目組應定期召開項目團隊内部例會、項目例會、裡程碑會議。項目例會是高效溝通的重要管道，每次會議前應及時釋出會議通知，明确會議的目的、時間、地點、參加人員、會議議程和議題，并下發會議資料，以便大家提前準備，有效地節約會議時間。會議中由專人做好會議紀要，會議結束前進行總結，重申會議決議。
| 項目組例會 | |||
| 一、基本資訊 | |||
| 項目名稱 | |||
| 會議地點 | |||
| 開始時間 | |||
| 結束時間 | |||
| 記錄人 | |||
| 二、項目現狀介紹 | |||
| 三、本周工作與本周計劃完成情況 | |||
| 人員 | 本周工作 | 完成情況 | |
| 四、上周問題（上周周會提出的問題、或計劃上周解決的問題，及解決情況） | |||
| 序号 | 問題 | 狀态 | 責任人 |
| 五、下周工作計劃 | |||
| 人員 | 計劃任務 | 說明 | |
| 六、本周待解決問題 | |||
| 序号 | 問題 | 方案 | 責任人 |
項目評審報告
| 評審報告 | ||||
| 1、基本資訊 | ||||
| 項目名稱 | 項目編号 | |||
| 評審地點 | 評審日期 | |||
| 審評人 | ||||
| 評審對象及其版本 | ||||
| 2、評審檢查項（可根據項目組的實際需要增加） | ||||
| 序号 | 檢查項 | 結果 | ||
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 3、評審記錄 | ||||
| 缺陷描述 | 計劃解決日期 | 驗證人 | 驗證日期 | 檢查項序号 |
變更控制報告
| 項目需求變更單-編号X | |
| 一、變更申請（客戶填寫） | |
| 項目名稱 | |
| 送出人 | |
| 送出日期 | |
| 變更類型 | |
| 變更原因 | |
| 變更描述 | |
| 二、變更初步評估（羅列并分析可選擇的方案）（PM填寫） | |
| 解決方案描述 | |
| 進度影響 | |
| 成本影響 | |
| 金額影響 | |
| 後續變動工作産品 | |
| 識别相關風險 | |
| 項目經理 | 簽字 日期： |
| 三、部門經理審批 | |
| 審批意見（寫明是否同意變更以及理由） | |
| 部門經理 | 簽名 日期： |
應急預案
應急響應方案
啟動應急流程
當服務主管收到服務台人員或助理送出的《運維工作單》，并判斷該問題屬于重大事故時，則啟動應急處理流程。重大事故包括以下幾種情況：
- 大範圍系統中斷
- 區域性系統崩潰
- 關鍵業務中斷
- 大範圍病毒爆發
- 系統嚴重破壞
- 資料嚴重破壞
根據重大事故的緊急程度和狀态不同，服務主管可采取以下方式啟動應急流程：
- 當緊急事件發生時，我司的運維人員首先要進行故障分析，确定故障的範圍和程度，确認為緊急故障的，在查找原因和解決問題的同時，要同步将故障解決情況通報給部門上司、及向客服中說明事件發生的狀況。如需其他部門協助的，需要請求相關部門共同盡快解決故障。
- 對于病毒突發事件，當病毒大面積地感染終端，我司的現場服務人員将已感染的終端從區域網路中斷開，投标人的運作人員将第一時間收集病毒資訊，并向現場人員提供有針對性的應急方案；如果應急方案沒有效果，要立即和防毒軟體廠方聯絡，由雙方共同協同提供有效的應對措施。
- 對于網絡中斷事件，我司的運維人員首先要判斷中斷原因，如果是區域網路本地裝置或線路造成的，依網絡運作處理流程優先快速處理；如果是電信服務提供商造成的，要立即聯絡電信技術部門解決問題。
- 對于系統故障事件，我司的運維人員首先要啟用備用系統，再判斷故障類型：硬體損壞、作業系統故障、軟體故障。硬體損壞的情況，首先向伺服器供應商報障；作業系統故障多數情況都和硬體故障同時出現，處理方式相同；軟體故障如果是由購買的軟體造成的，立即向軟體廠商尋求技術支援；如果是公司自行開發的軟體，立即向相關人員聯系并排除故障。。
- 對于自然災害性事件，運作管理人員要盡可能将裝置轉移到安全地帶，将損失降低到最少。
- 對于電力中斷事件，由于機房多采用UPS防止斷電帶來的系統停機現象，在UPS還能供應電力期間恢複供電，對系統使用不會有影響；但遇到特殊情況導緻供電部門在短期内不能恢複供電時，如有備用發電裝置要啟用備用發電裝置供電，否則要關閉所有裝置，確定突然斷電造成裝置損壞。
- 在故障排除之後，運作管理人員要填寫故障記錄，如果故障是由于項目實施中存在的隐患造成的問題，具體操作請參見上層檔案《網絡系統維護管理指引》。故障記錄彙總到“系統運作故障記錄表”，重大事故由故障處理人填寫故障報告。
成立應急小組
《啟動應急流程申請單》獲準許後（包括口頭準許），由主管部門負責組建應急小組。應急小組由多方人員組成，例如資訊中心代表、運維部代表、服務主管、客戶代表、供應商代表以及其他第三方人員等。
應急小組對發生的重大事故進行讨論分析并制定應急處理方案。
運維小組會根據實際人員需求情況從公司本部調配足夠人員加入到應急小組。
運維小組會根據實際需求情況從公司本部調配足夠的資金以保障事件處理經費需求。
應急處理過程
根據應急小組制定的應急處理方案具體實施應急處理活動，并将實施過程和結果記錄在《應急處理過程記錄》中。涉及到客戶現場服務的應取得客戶的簽字确認。
應急處理實施過程中涉及需要協調配合的工作由服務主管填寫《資源申請單》，說明需要獲得的資源、需要協調配合的工作等，經應急小組審批通過後由相關人員代表配合實施。
應急處理實施過程中涉及需要采購的，由服務主管填寫《資源申請單》，說明需要采購的産品名稱、型号/規格/功能、廠商/供應商、費用等。《資源申請單》經應急小組審批通過後由運維工程師實施采購，并将采購過程和結果記錄在《資源申請單》中，應急小組對采購結果進行确認。
應急處理實施過程中涉及需要變更的，由服務主管填寫《變更請求表》，說明變更内容、變更原因、變更方案等，經應急小組準許後直接由運維工程師根據《變更請求表》中的變更方案實施變更，并将變更過程和結果記錄在《變更日志》中。
所有應急處理活動均應記錄在《應急處理過程記錄》中。
具體涉及到網絡緊急故障處置，我們以恢複使用為第一目标。
在确認裝置故障情況下，将第一時間采用備機備件恢複網絡功能；
在鍊路故障情況下，啟動備用鍊路進行通訊恢複，并積極配合鍊路營運商恢複鍊路；
在大面積病毒爆發情況下，利用趨勢病毒爆發阻止功能，首先阻止網絡病毒傳播途徑，阻止病毒源，并積極聯系廠商擷取最新病毒碼對全網進行病毒處置。
應急處理結果評估
應急處理過程完成後，服務主管向應急小組送出應急處理過程相關表單，包括《啟動應急流程申請單》、《應急處理過程記錄》、《資源申請單》、《變更請求表》、《變更日志》等。應急小組對應急處理結果進行評估和确認，并在《應急流程評估單》中填寫評估意見。
如果應急小組評估意見為達到要求（即問題得到解決并恢複服務），則應急流程結束。
如果應急小組評估意見為未達到要求，則由應急小組讨論分析原因，根據分析結果可采取以下措施：
- 如果需要繼續進行應急處理，則由應急小組提出應急處理方案，進行應急處理過程；
- 如果不需要繼續進行應急處理：
- 如果有新的問題産生，則由服務主管填寫《運維工作單》，轉【問題管理】流程處理；
- 如果有新的變更需求，則由服務主管填寫《變更請求單》，轉【變更管理】流程處理；
- 否則應急流程結束。
應急流程結束時，由服務主管在《運維工作單》中記錄應急處理結果及關聯表單編号。配置管理者對應急處理結果進行檢查，登記新的配置項或更改後的配置項。
統計和報告
每月或每季度對應急流程情況進行統計，形成《應急流程管理報告》，并送出給服務主管。《應急流程管理報告》内容包括：啟動應急流程次數（不同類别的次數）、原因分析、影響分析、完成情況、所需時間、各項資源利用情況、費用情況、意見和建議等。
《應急流程管理報告》經項目經理确認後送出客戶主管。
重點保障方案
運維項目組制定了詳盡的應急處理預案，整個流程嚴謹而有序。但在服務維護過程中，意外情況将難以完全避免。我們将對項目實施的突發風險進行詳細分析，并且針對各類突發事件，設計了相應的預防與解決措施，同時提供了完整的應急處理流程。
方案實施流程
重點保障政策
（1）值班人員平時應做好重點事件的監控工作，對于重點事件應認真分析、準确判定故障發生的資料域，負責跟蹤該事件直至其結束。對于不在運維中心的故障，應在第一時間内通知負責人去現場處理，密切關注事件流程及進展情況，并做好登記工作上報上司。
（2）正常情況下，要求值班人員在10分鐘内進行事件确認。如果屬于一般事件則按照事件流程進行分派處理，否則應迅速啟動《重點保障預案》，并嚴格按照《重點保障預案》所規定的步驟快速實施應急處置，及時彙報上級上司，掌握實時處理情況。
（3）在處理過程中，如需其他部門去現場增援處理，應及時向上級上司部門彙報，協調溝通，盡快聯系技術工程師或廠家技術支援趕赴現場援助處理。