企業大資料應用平台ETL系統運維實施技術方案
1項目服務方案
1.1日常維護方案
1.1. 1項目概述
背景介紹
為保障企業大資料應用平台的日常生産運維工作，保持運維工作的延續性，需由“經分背景XX、ETL等應用日常維護服務”提供相關的監控、維護工作。
服務目标
在確定企業經營分析系統運維工作順利開展，包括經分現網系統每日正在運作的上千項流程的日常運維、DACP流程排程、資料分發、進出口資料品質、ETL配置維護以及及時性監控、月生産維護、重點應用及時完成情況監控。
服務原則
例行服務必須按規定時間進行，服務響應時間必須在合同規定的時間内執行，故障應急必須迅速做出反應。準确無誤地完成所承諾的服務。要求避免服務過程中的失誤，避免服務過中影響局方的業務穩定。術業有專攻，提供專業的服務團隊為局方提供專業服務，保證服務品質。
符合局方相關維護規定，做好資訊安全保密工作。
1.1.2 故障響應和服務内容
故障等級和服務響應
| 故障級别定義 | 故障級别 | 故障定義 | 服務描述 |
| 一級故障 | 一經接口、重點應用相關接口故障或延遲；重點應用、重點模型排程故障或延遲 | 重點接口或程式延遲或故障。 | |
| 二級故障 | 基礎模型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次/月 |
| 系統軟體和應用軟體版本、更新檔檢查 | 不定期 | |
| 分析和優化 | 為配合新增要求的分析和優化任務。 | 按需 |
為保障系統的健康、高效運作，消除問題隐患，提供系統巡檢服務。
XX運維服務
- 工作概述：
- 保障DACP排程系統上YT機平台及MPP平台的程式正常運作；
- 工作重點：
- 每天全程監控重點流程：
夜間3次定時巡檢彙報：2點，5點，8點
白天2次重點監控彙報和多次巡檢排程系統：重點彙報11點，17點
- 根據流程的重要程度，按既定的時效及品質要求，及時監控、發現、并處理DACP排程系統中的各類異常問題；
- 重點監控并優化重點流程的排程情況，保障出數的及時性及準确性；
- 定期總結DACP排程中的系統、流程排程等問題，并及時進行主動優化或回報給開發人員進行優化，以保障DACP排程系統的穩健性及效率。
- 自動化告警腳本按需求閥值調整、優化。
- 工作内容：
XX運維服務主要包括了日常監控運維、月初運維任務等。具體維護内容如下：
日常監控運維
XX日常監控運維工作包括流程排程監控及維護、固定分發新增、臨時任務處理及跟蹤等。
XX重點流程監控及維護：
- 重點監控日程式
總數：1000 （個）監控時段：00:00-23:00 （每日）
- 重點監控月程式
總數：60（個）監控時段：00:00-23:00 （1号-7号）
- 重點監控分鐘程式
總數：10 （個）監控時段：00:00-23:00 （每日）
- 流程排程監控及維護
- 負責監控DACP平台；
- 負責監控及處理排程流程異常的問題，包括失敗，等待，長時間未觸發，流程依賴缺失，權限缺失等問題；
- 每天通過背景自動化監控腳本，對全量排程流程進行全方位監控，将日常遇到的失敗，延遲等問題進行定位分析并優化處理，程式問題及時協調開發人員及時進行處理；
- 對常見問題進行總結分析，歸納問題的發生頻率、影響面、共性等，針對性制定優化措施，以減低挂起量，提升出數及時性，提升日常運維效率。
- XX重點流程監控及維護
- 臨時任務處理
臨時任務包括各項臨時性、突發性、及專項任務等，諸如系統割接上線配合，因資料錯誤、程式問題等需要流程臨時排程、批量重跑後續，查找流程下線需要的詳細資訊以及流程下線，支撐經分側查證流程排程情況，重點應用重點支撐保障、固定分發問題查證等。
- 固定分發接口配置
由于經分生産所需或日常工單需求所需，XX維護人員對現有接口進行修改配置或新增配置。
1、維護突發事件處理
由于日常生産中遇到各類突發事件,例如資料庫當機、表空間滿、排程系統異常、4A平台異常等等。
月初運維任務
XX月初運維任務包括屬地化基站維表維護、賬單科目維表維護、主策劃維表、部分DWD月流程手工維護、月末DWD重點日流程手工維護、以及屬地化月表後置流程排程。
- 屬地化基站維表
每月月底最後一天完成屬地化基站檔案導入資料确認後，維護人員電話督促各屬地基站維護人員必須在1号完成基站維護，如遇不可控因素影響進度必須及時上報。
13個屬地完成基站維護後，維護人員完成相應的驗證工作，驗證完成後郵件通知後續維護人員。
2）賬單科目維表維護
每月初對賬單科目維表DIM_ACC_ITEM_CODE按要求進行更新個性化處理。
每月待客戶通知shfin.r_vr011表維護完成，XX确認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 | 一體機 | DwdSvcUsrOXXtateM |
| 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檢視程式依賴的接口以及判斷的分控表 |
| 依賴 | XX流程名查詢 | 以程式名或表名查找流程名稱 |
| 依賴 | 查詢表固定分發 | 當用到的表不是XX程式跑出的時候，以表名去分發控制表檢視表是否屬于分發，源庫是哪裡及分發情況 |
| 異常 | 運作超長時間流程查詢 | 速查一周内平均運作時間超長的流程清單發開發優化程式 |
| 異常 | 等待流程查詢 | 速查長時間等待運作的流程清單 |
| 異常 | 檢視接口裝載完成情況 | 以接口号去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點批次XX重要程式完成數告警 | 電話/短信 | 重要 | 每1小時 | |
| 16 | 正在運作的程式運作時長超過1小時告警 | 短信 | 重要 | 每1小時 | |
| 17 | 失敗程式告警 | 短信 | 重要 | 每1小時 | |
| 18 | 經分熱點未完成數告警 | 短信 | 重要 | 每1小時 | |
| 19 | 超過參考時間接口未完成告警（經分熱點及所有前置依賴的接口監控） | 電話/短信 | 非常重要 | 每1小時 | |
| 20 | dacp流程總體運作情況監控 | 日程式總數，程式執行成功數與參考完成數短信提示 | 短信 | 重要 | 每1小時 |
| 21 | 流程失敗個數 | 短信 | 重要 | 每1小時 | |
| 22 | 正在執行程式個數 | 短信 | 重要 | 每1小時 | |
| 23 | 等待前置程式個數 | 短信 | 重要 | 每1小時 | |
| 24 | 等代理程式個數 | 短信 | 重要 | 每1小時 | |
| 25 | 今日未觸發程式個數 | 短信 | 重要 | 每1小時 | |
| 26 | XX監控 | XX代理程序監控 | 短信 | 重要 | 每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環節的資料品質問題的查證工作；
- 按開發需求完成接口資料的重抽工作；
- 協助XX團隊對執行失敗、異常程式，程式運作緩慢等問題定位；
- 當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/boXXcdr/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分等，最後将打分進行加總平均，并且由其中一位被教育訓練者将最後的平均分填到XX日報教育訓練sheet頁裡。 |
| 5、在下次教育訓練時，由上次教育訓練主講者提前準備不同題目（不得提前公開），在教育訓練會上，對上次參加的被教育訓練人員進行逐一提問，答出來且基本正确的，則在XX日報的教育訓練頁的” 被教育訓練得分 “裡給予 4分 鼓勵，否則記0分。 |
新人教育訓練
新人入職後前2月強化教育訓練使其能夠快速融如入到日常維護工作中（掌握工作内容、操作制度、問題查證、常見問題處理方式等等）。
| XX&ETL新員工教育訓練計劃表 | |
| 教育訓練背景及目标 | 工作内容主要是對DACP、ETL排程平台完成程式排程的全程監控和日常維護操作 |
| 第一周 | |
| 教育訓練目标 | 熟練使用LINUX,VI基本操作指令，熟練SQL、shell； 了解企業資料倉庫整體架構； 了解維護制度，日常管理； |
| 教育訓練内容 | 1：發送教育訓練文檔以及常用sh腳本 2：講解企業資料倉庫整體架構圖以及我們維護的哪一子產品。 3：閱讀XX團隊維護守則講解維護制度、日常管理 |
| 第二周 | |
| 教育訓練目标 | 了解DACP；了解ETL； 了解日常維護工作内容； |
| 教育訓練内容 | 1：閱讀DACP平台使用者手冊，講解DACP系統大概組成架構； 2：講解DACP常用功能子產品的作用及操作示範； 3：閱讀XX維護五大項工作内容文檔； 4：閱讀ETL核心文檔，講解ETL系統大概組成架構； 5：講解ETL常用功能子產品的作用及操作示範； 6：閱讀ETL維護工作内容相關文檔； |
| 第三周 | |
| 教育訓練目标 | 熟悉日常維護項工作内容； 掌握每個腳本監控項的功能； 熟悉腳本中關聯的每張配置表的用途(提高後期查證報障問題的效率)； |
| 教育訓練内容 | 1：介紹XX日報每個sheet頁工作内容； 2：講解每個維護腳本SQL用途以及何時用； |
| 第四周 | |
| 教育訓練目标 | 掌握常用配置表的常用字段的描述、字段備注（提高後期查證報障問題的效率） |
| 教育訓練内容 | 結合資料字典講解常用配置表用途、常用字段資訊描述 |
| 第五周 | |
| 教育訓練目标 | 了解維護所有的監控項及告警方式、處理方式； 了解程式異常根據不同條線找對應的聯系人處理； 了解接口異常根據不同情況進行處理； |
| 教育訓練内容 | 1：結合sh腳本講解DACP告警類型以及查證、處理、部署方法； 2：閱讀XX團隊維護守則中維護事件更新規範； 3：結合sh腳本講解ETL告警類型以及查證、處理、部署方法； |
| 第六周 | |
| 教育訓練目标 | XX日常維護工作内容已初步了解并掌握DACP基本操作，開始處理每日失敗程式； ETL日常維護工作内容已初步了解并掌握ETL基本操作，開始處理每日失敗接口 |
| 教育訓練内容 | 由老員工帶着開始處理每日失敗程式，監控重點程式完成情況 由老員工帶着開始處理每日失敗接口，監控重點程式完成情況 |
| 第七周 | |
| 教育訓練目标 | 處理DACP日常維護工作；處理ETL日常維護工作； |
| 教育訓練内容 | 由老員工帶着開始處理日常維護工作 |
| 第八周 | |
| 教育訓練目标 | 配置固定分發，查證郵件報障，了解XX排程系統，ETL排程系統 |
| 教育訓練内容 | 講解配置固定分發步驟，問題查證，講解DACP排程系統基本操作與維護，講解ETL排程系統基本操作與維護 |
日常管理
人員管理
做好團隊建設工作，避免由于投入力量不足或能力不夠而引發維護及時性和品質問題；
- 確定維護團隊人員的技術能力和溝通能力，服從上級管理，一經管理方決定的任務，應立即遵守執行；確定工作的連續性、人員的穩定性，降低人員變動帶來的額外成本做好員工的人員教育訓練、入離職申請等工作；駐場人員必須保守客戶機關的機密，務必妥善保管所持有的文檔、檔案；駐場人員確定7*24小時全天待命；上班期間確定現場人員可随時實時處理問題；每日下班前A、B角互查确認XX維護結果；XX維護日報：日常維護交班需生成當班次（包括白班、夜班）工作明細報告；新員工入職一周後，由老員工負責收集新員工開通權限的各項資訊後且已郵件形式發送給局方對口人；
考勤管理
- 嚴格遵守客戶機關的辦公時間，不得遲到早退；如請假未得到客戶機關管理人員同意或未提出申請，按曠工處理；因特殊原因需要延長假期的，需得到客戶機關和公司準許，否則按曠工論處；駐場人員因病必須治療及修養時，憑市級以上醫院診斷書辦理請假手續；
安全管理
- 嚴格遵守并執行《資訊系統營運部工作現場安全守則》 ，定期安排生産安全宣貫演練，預防為主，提升人員、團隊的安全意識；確定各項工作遵照公司及中心資訊安全管理規定，做好帳号管理、敏感資訊查詢、生産環境通路、系統安全審計等資訊安全工作；在各類項目建設、系統維護工作中充分考慮資訊安全，確定通路控制、原始記錄、日志審計等符合資訊安全規範；
1.2服務支撐體系
1.2.1 服務組織
我司提供9人的團隊服務于本項目，服務組織機構如下：
- 項目經理職責：
1、與使用者讨論并确定最終項目範圍和實施方法；
2、負責制訂具體的項目計劃，包括教育訓練計劃；
3、把握項目各方面的程序；
4、指導業務流程重組和項目變更；
5、檢查及調控項目實施範圍；
6、向公司彙報項目狀況，提出建議及改進措施；
7、負責項目階段品質。
- 運維工程師職責：
1、負責本項目相關軟體的日常維護、更新以及軟體應用的二次開發工作。
2、負責面向決策層、管理層、應用層、系統維護層人員提供教育訓練。
3、負責系統維護以及相關技術支援工作。
4、提供系統內建方面的技術支援。
1.2.2服務流程
為保證現場服務實施的品質能夠穩定并不斷有所提升，保障客戶需求能夠得到有效滿足，保障現場服務實施團隊為客戶提供統一、标準化的服務支援，并為客戶設立專門的客戶服務專員，對進行全程跟蹤，提升服務實施專業性，制定服務流程：
1..2.3服務規範體系
1.3 品質控制能力
1.3.1 服務品質管理
品質管理體系标準
本項目實施應采用先進的品質管理模式和科學的品質管理體系和流程，并根據項目自身特點選用合适的品質控制規程。
目前，我司主要采用ISO9001品質标準和軟體成熟度模型（CMM）兩種控制規程。針對本項目，公司将采用ISO9001品質體系标準，在項目實施的過程中嚴格執行品質标準。
品質控制過程
本項目中，由項目經理制訂品質控制計劃，項目品質控制組進行稽核。稽核方面包括：品質控制措施是否足夠、各個成員的品質責任是否明确合理，測試方法是否适用。
品質評定計劃
為了加強項目品質管理和界定産品品質标準，本公司将制訂适應于項目的檢查驗收規定和品質評定标準，確定工程品質。
本項目中，應實行兩級檢查、兩級驗收制度。一級檢查、二級檢查和一級驗收由本公司實施小組組織完成；二級驗收由使用者組織實施。各級檢查驗收嚴格按項目實施中制訂的相應的檢查驗收規定和品質評定标準執行。對實施和驗收過程中出現的重大技術問題，将上報使用者協調處理，對一般品質問題的處理應予以書面記錄。
1.3.2 品質保障體系
我司将品質視為整個項目計劃的一部分。項目計劃書中的品質計劃部分明确了關鍵過程和最終結果的評估程式和衡量标準。品質計劃和客戶要求的品質相一緻，以確定項目達到客戶在功能、績效和品質等各方面要求。我們的品質保障包括以下幾個方面：
（1） 項目品質管理評估：在項目進行過程中，定期評估項目程序、客戶期望、品質問題和風險等；
（2） 資料管理和變革控制：界定所有與品質控制有關的資料和軟體資料的管理要求，包括各項計劃、過程、表單和标準等等；
（3） 确定流程（如開發流程、監控流程，評估流程和人員安排流程）的執行過程；
（4） 項目品質績效标準：包括目的、衡量方法和彙報方式。
1.3.3 品質管理措施
在項目實施過程中還将采取如下措施保障項目實施品質：
（1）在項目實施前後對網絡性能進行評估。
（2）在系統部署完成後要在實際環境中進行網絡連通性測試、安全政策驗證和應用系統測試。
（3）配合應用系統做好壓力測試，根據壓力測試結果調整系統配置。
（4）項目實施後要進行一定時間的試運作，在試運作期間要重點監控網絡環境的運作情況、安全政策的驗證和業務應用系統運作情況，若出現的問題要及時查找原因并加以修正。
（5）在試點實施過程中驗證方案的可行性和正确性。
1.3.4 項目教育訓練方案
技術教育訓練包括現場教育訓練和專業教育訓練，均有我司負責。采購方有權對我方提出的教育訓練方案和教育訓練計劃進行選擇和調整。
現場教育訓練
現場教育訓練由我司在項目實施現場進行。
我司承諾安排項目采購人認可的具有相關專業資格或者實際工作經驗的人員進行教育訓練；現場教育訓練貫穿于整個項目實施過程。
專業教育訓練
1、我司若中标，将制定詳細的人員教育訓練方案，教育訓練方案包括教育訓練目的、教育訓練時間安排、人數、教材編寫、教育訓練師資情況、教育訓練組織方式等。
2、教育訓練内容和教育訓練對象
（1）系統維護管理教育訓練
教育訓練内容主要包括系統的操作、配置、維護等，系統常見故障現象的診斷和處理，常見的問題及解決方案等。我司為所有被教育訓練人員提供教育訓練環境、文字資料和講義等相關用品。所有的資料用簡體中文書寫。
教育訓練時間：系統試運作期間，具體時間由采購人指定。
教育訓練對象為系統運作管理與維護人員。
（2）操作使用操作手冊
教育訓練内容包括系統組成、結構、功能、使用辦法等。我司承諾為所有被教育訓練人員提供教育訓練環境、文字資料和講義等相關用品。所有的資料用簡體中文書寫。
教育訓練時間：系統試運作期間，具體時間由采購人指定。
教育訓練對象為采購人指定的相關人員。
3、所有的教育訓練教員必須用中文授課，除非有其他的協定規定。
4、相關要求
（1）我司承諾選派具有一定資質和實踐經驗，且受過專門訓練的進階專業技術人員負責各分項的技術教育訓練工作。
（2）我司的教育訓練内容包括基本理論、系統的操作、運作管理、現場操作輔導等，教育訓練方式應應包括技術授課、操作示範、參觀學習和其他必須的業務指導和技術咨詢，確定教育訓練人員對系統基本理論、技術特性、操作規範、運作規程、管理維護等方面獲得全面了解和掌握。
（3）我司承諾在教育訓練開始前20天内将教育訓練計劃和教材送出采購人稽核，除上述教育訓練外，我司還須負責在現場組織對系統的操作，調試和運作技術示範和業務指導。
1.3.5 服務工作協同
我司将制定完整的項目溝通計劃，項目的溝通途徑主要包含以下種類：項目周報、項目例會、項目月報、項目評審報告、變更控制報告，主要的溝通頻率參加下表：
| 溝通方式 | 頻率 | 接收人 | 媒介 | 格式 | 傳遞時間 | 發送人 | 溝通模闆 |
| 項目周報 | 每周 | 使用者上司 | 郵件 | Word 檔案 | 每周一 13：00前 | 項目經理 | 見項目周報模闆 |
| 公司上司 | |||||||
| 項目組全體成員 | |||||||
| 項目周例會 | 每周 | 部門上司 | 會議、電話 | Word 檔案 | 每周 | 項目經理 | 見項目周報模闆 |
| 使用者上司 | |||||||
| 項目組全體成員 | |||||||
| 項目月例會 | 每月 | 部門上司 | 會議 | Word 檔案 | 月底前 | 項目經理 | 見項目月報模闆 |
| 使用者上司 | |||||||
| 項目組全體成員 | |||||||
| 項目月度 監測報告 | 每月 | 使用者上司 | 郵件 | Word 檔案 | 每月第一周前 | 項目經理 項目成員 | 見項目月報模闆 |
| 公司上司 | |||||||
| 項目組全體成員 | |||||||
| 項目每日例會 | 沒有 限制 | 使用者上司 | 會議 | 口頭 書面 | 沒有限制 | 無 | 見項目例會内容 |
| 項目組成員 |
項目周報
| 基本資訊 | ||
| 項目名稱 | 報告日期 | |
| 項目所處階段 | 報告批次 | |
| 項目負責人 | 稽核人 | |
| 任務與進度 | ||
| 人力資源 | ||
| 軟硬體資源 | ||
| 上周工作總結 | ||
| 本 周 主 要 工 作 内 容 | 負責人 | 參與人 |
| 項目風險分析 | ||
| 1、 | ||
| 需要協調事件 | ||
| 1、 |
項目月報
| 月度總結報告—第X月度 （ 年 月） | |||||
| 1、本月完成的主要任務 | |||||
| 序号 | 任務描述 | 相關責任人 | 實際完成日期 | 工作産品 | 備注 |
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 2、本月小結 | |||||
| 3、待解決問題 | |||||
項目例會
項目組應定期召開項目團隊内部例會、項目例會、裡程碑會議。項目例會是高效溝通的重要管道，每次會議前應及時釋出會議通知，明确會議的目的、時間、地點、參加人員、會議議程和議題，并下發會議資料，以便大家提前準備，有效地節約會議時間。會議中由專人做好會議紀要，會議結束前進行總結，重申會議決議。
| 項目組例會 | |||
| 一、基本資訊 | |||
| 項目名稱 | |||
| 會議地點 | |||
| 開始時間 | |||
| 結束時間 | |||
| 記錄人 | |||
| 二、項目現狀介紹 | |||
| 三、本周工作與本周計劃完成情況 | |||
| 人員 | 本周工作 | 完成情況 | |
| 四、上周問題（上周周會提出的問題、或計劃上周解決的問題，及解決情況） | |||
| 序号 | 問題 | 狀态 | 責任人 |
| 五、下周工作計劃 | |||
| 人員 | 計劃任務 | 說明 | |
| 六、本周待解決問題 | |||
| 序号 | 問題 | 方案 | 責任人 |
項目評審報告
| 評審報告 | ||||
| 1、基本資訊 | ||||
| 項目名稱 | 項目編号 | |||
| 評審地點 | 評審日期 | |||
| 審評人 | ||||
| 評審對象及其版本 | ||||
| 2、評審檢查項（可根據項目組的實際需要增加） | ||||
| 序号 | 檢查項 | 結果 | ||
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 3、評審記錄 | ||||
| 缺陷描述 | 計劃解決日期 | 驗證人 | 驗證日期 | 檢查項序号 |
變更控制報告
| 項目需求變更單-編号X | |
| 一、變更申請（客戶填寫） | |
| 項目名稱 | |
| 送出人 | |
| 送出日期 | |
| 變更類型 | |
| 變更原因 | |
| 變更描述 | |
| 二、變更初步評估（羅列并分析可選擇的方案）（PM填寫） | |
| 解決方案描述 | |
| 進度影響 | |
| 成本影響 | |
| 金額影響 | |
| 後續變動工作産品 | |
| 識别相關風險 | |
| 項目經理 | 簽字 日期： |
| 三、部門經理審批 | |
| 審批意見（寫明是否同意變更以及理由） | |
| 部門經理 | 簽名 日期： |
1.4 應急預案
1.4.1 應急響應方案
啟動應急流程
當服務主管收到服務台人員或助理送出的《運維工作單》，并判斷該問題屬于重大事故時，則啟動應急處理流程。重大事故包括以下幾種情況：
- 大範圍系統中斷
- 區域性系統崩潰
- 關鍵業務中斷
- 大範圍病毒爆發
- 系統嚴重破壞
- 資料嚴重破壞
根據重大事故的緊急程度和狀态不同，服務主管可采取以下方式啟動應急流程：
- 當緊急事件發生時，我司的運維人員首先要進行故障分析，确定故障的範圍和程度，确認為緊急故障的，在查找原因和解決問題的同時，要同步将故障解決情況通報給部門上司、及向客服中說明事件發生的狀況。如需其他部門協助的，需要請求相關部門共同盡快解決故障。
- 對于病毒突發事件，當病毒大面積地感染終端，我司的現場服務人員将已感染的終端從區域網路中斷開，投标人的運作人員将第一時間收集病毒資訊，并向現場人員提供有針對性的應急方案；如果應急方案沒有效果，要立即和防毒軟體廠方聯絡，由雙方共同協同提供有效的應對措施。
- 對于網絡中斷事件，我司的運維人員首先要判斷中斷原因，如果是區域網路本地裝置或線路造成的，依網絡運作處理流程優先快速處理；如果是電信服務提供商造成的，要立即聯絡電信技術部門解決問題。
- 對于系統故障事件，我司的運維人員首先要啟用備用系統，再判斷故障類型：硬體損壞、作業系統故障、軟體故障。硬體損壞的情況，首先向伺服器供應商報障；作業系統故障多數情況都和硬體故障同時出現，處理方式相同；軟體故障如果是由購買的軟體造成的，立即向軟體廠商尋求技術支援；如果是公司自行開發的軟體，立即向相關人員聯系并排除故障。。
- 對于自然災害性事件，運作管理人員要盡可能将裝置轉移到安全地帶，将損失降低到最少。
- 對于電力中斷事件，由于機房多采用UPS防止斷電帶來的系統停機現象，在UPS還能供應電力期間恢複供電，對系統使用不會有影響；但遇到特殊情況導緻供電部門在短期内不能恢複供電時，如有備用發電裝置要啟用備用發電裝置供電，否則要關閉所有裝置，確定突然斷電造成裝置損壞。
- 在故障排除之後，運作管理人員要填寫故障記錄，如果故障是由于項目實施中存在的隐患造成的問題，具體操作請參見上層檔案《網絡系統維護管理指引》。故障記錄彙總到“系統運作故障記錄表”，重大事故由故障處理人填寫故障報告。
成立應急小組
《啟動應急流程申請單》獲準許後（包括口頭準許），由主管部門負責組建應急小組。應急小組由多方人員組成，例如資訊中心代表、運維部代表、服務主管、客戶代表、供應商代表以及其他第三方人員等。
應急小組對發生的重大事故進行讨論分析并制定應急處理方案。
運維小組會根據實際人員需求情況從公司本部調配足夠人員加入到應急小組。
運維小組會根據實際需求情況從公司本部調配足夠的資金以保障事件處理經費需求。
應急處理過程
根據應急小組制定的應急處理方案具體實施應急處理活動，并将實施過程和結果記錄在《應急處理過程記錄》中。涉及到客戶現場服務的應取得客戶的簽字确認。
應急處理實施過程中涉及需要協調配合的工作由服務主管填寫《資源申請單》，說明需要獲得的資源、需要協調配合的工作等，經應急小組審批通過後由相關人員代表配合實施。
應急處理實施過程中涉及需要采購的，由服務主管填寫《資源申請單》，說明需要采購的産品名稱、型号/規格/功能、廠商/供應商、費用等。《資源申請單》經應急小組審批通過後由運維工程師實施采購，并将采購過程和結果記錄在《資源申請單》中，應急小組對采購結果進行确認。
應急處理實施過程中涉及需要變更的，由服務主管填寫《變更請求表》，說明變更内容、變更原因、變更方案等，經應急小組準許後直接由運維工程師根據《變更請求表》中的變更方案實施變更，并将變更過程和結果記錄在《變更日志》中。
所有應急處理活動均應記錄在《應急處理過程記錄》中。
具體涉及到網絡緊急故障處置，我們以恢複使用為第一目标。
在确認裝置故障情況下，将第一時間采用備機備件恢複網絡功能；
在鍊路故障情況下，啟動備用鍊路進行通訊恢複，并積極配合鍊路營運商恢複鍊路；
在大面積病毒爆發情況下，利用趨勢病毒爆發阻止功能，首先阻止網絡病毒傳播途徑，阻止病毒源，并積極聯系廠商擷取最新病毒碼對全網進行病毒處置。
應急處理結果評估
應急處理過程完成後，服務主管向應急小組送出應急處理過程相關表單，包括《啟動應急流程申請單》、《應急處理過程記錄》、《資源申請單》、《變更請求表》、《變更日志》等。應急小組對應急處理結果進行評估和确認，并在《應急流程評估單》中填寫評估意見。
如果應急小組評估意見為達到要求（即問題得到解決并恢複服務），則應急流程結束。
如果應急小組評估意見為未達到要求，則由應急小組讨論分析原因，根據分析結果可采取以下措施：
- 如果需要繼續進行應急處理，則由應急小組提出應急處理方案，進行應急處理過程；
- 如果不需要繼續進行應急處理：
- 如果有新的問題産生，則由服務主管填寫《運維工作單》，轉【問題管理】流程處理；
- 如果有新的變更需求，則由服務主管填寫《變更請求單》，轉【變更管理】流程處理；
- 否則應急流程結束。
應急流程結束時，由服務主管在《運維工作單》中記錄應急處理結果及關聯表單編号。配置管理者對應急處理結果進行檢查，登記新的配置項或更改後的配置項。
統計和報告
每月或每季度對應急流程情況進行統計，形成《應急流程管理報告》，并送出給服務主管。《應急流程管理報告》内容包括：啟動應急流程次數（不同類别的次數）、原因分析、影響分析、完成情況、所需時間、各項資源利用情況、費用情況、意見和建議等。
《應急流程管理報告》經項目經理确認後送出客戶主管。
1.4.2下重點保障方案
運維項目組制定了詳盡的應急處理預案，整個流程嚴謹而有序。但在服務維護過程中，意外情況将難以完全避免。我們将對項目實施的突發風險進行詳細分析，并且針對各類突發事件，設計了相應的預防與解決措施，同時提供了完整的應急處理流程。
方案實施流程
重點保障政策
（1）值班人員平時應做好重點事件的監控工作，對于重點事件應認真分析、準确判定故障發生的資料域，負責跟蹤該事件直至其結束。對于不在運維中心的故障，應在第一時間内通知負責人去現場處理，密切關注事件流程及進展情況，并做好登記工作上報上司。
（2）正常情況下，要求值班人員在10分鐘内進行事件确認。如果屬于一般事件則按照事件流程進行分派處理，否則應迅速啟動《重點保障預案》，并嚴格按照《重點保障預案》所規定的步驟快速實施應急處置，及時彙報上級上司，掌握實時處理情況。
（3）在處理過程中，如需其他部門去現場增援處理，應及時向上級上司部門彙報，協調溝通，盡快聯系技術工程師或廠家技術支援趕赴現場援助處理。