資訊專欄INFORMATION COLUMN
本著業(yè)務連續(xù)性運維，如果不了解業(yè)務，那就是聾子的耳朵--白搭。本文給大家?guī)砉P者日常工作中關于業(yè)務相關知識分享，以及在遇到問題后，如何基于平臺沉淀場景的過程。希望對大家的一體化運維有所幫助和啟發(fā)。
應急開機是當系統(tǒng)出現(xiàn)異常（例如繳費和開機積壓）終端用戶已正常繳費但仍然未復機情況下，強制生成開機工單給用戶快速開機，恢復用戶服務，以此保證客戶終端使用，避免造成大規(guī)模終端用戶投訴的一套程序。
應急開機涉及如下環(huán)節(jié)的檢查和監(jiān)控：
應急進程檢查：應急處理進程重啟和檢查；
應急模式調(diào)整：常規(guī)應急模式需要根據(jù)字典組判斷營業(yè)用戶狀態(tài)和停機鎖，無條件應急模式不判斷營業(yè)用戶狀態(tài)和停機鎖直接開機；
應急開機程序啟動：待開機用戶號碼的提取、處理，如提取指定時間段的繳費用戶、指定開機號碼集合、指定時間段服務開通側(cè)下發(fā)的停機指令用戶；
應急開機數(shù)據(jù)檢查：檢查應急開機掃描用戶數(shù)據(jù)及其處理情況。各種業(yè)務開機工單指令的執(zhí)行速度及積壓檢查，含語音、GPRS、VOLTE、非VOLTE、寬帶、和TV、IMS等業(yè)務。用戶開機是否成功，涉及MML(HLR)指令、SOAP協(xié)議(PROVISION平臺)指令檢查；
應急用戶狀態(tài)同步：用戶數(shù)據(jù)狀態(tài)同步，用戶的網(wǎng)絡側(cè)狀態(tài)、平臺側(cè)狀態(tài)、營業(yè)側(cè)狀態(tài)、賬務側(cè)狀態(tài)保持一致；
應急用戶強制信控：強制信控數(shù)據(jù)的生成，對于應該停機而被開機的用戶重新觸發(fā)強制信控進行停機。
以上各環(huán)節(jié)監(jiān)控，以前均是通過手工登錄對應主機或者物理庫執(zhí)行監(jiān)控腳本的形式進行檢查；監(jiān)控鏈條長，形式多樣，純手工操作容易形成顧頭不顧尾的局面，導致部分節(jié)點遺漏監(jiān)控，降低應急開機的及時性，使應急開機的效果大打折扣。
系統(tǒng)故障，需要馬上執(zhí)行應急開機，啟動應急開機程序后，按照常規(guī)監(jiān)控流程檢查了應急數(shù)據(jù)的處理及下發(fā)，以為下發(fā)完成后用戶全部開機完成了，但是遺漏了更下游環(huán)節(jié)的開機工單處理積壓情況，由于工單積壓導致用戶并未全部及時開機完成，類似情況易引起次生故障。
因為手工監(jiān)控耗時，所以故障處理時第一時間，每個人都只關注自己負責環(huán)節(jié)的數(shù)據(jù)處理情況，但是每個人自己所負責的環(huán)節(jié)數(shù)據(jù)處理完了不代表整個故障處理完了，不代表用戶服務恢復正常了，因此需要快速掌握從應急程序啟動到最終用戶服務恢復之間所有環(huán)節(jié)的處理情況。
因此有必要擯棄手工執(zhí)行監(jiān)控腳本的方式，引入自動化腳本或者可視化頁面的形式完成監(jiān)控及流程處理。
自動化運維平臺中的拓撲圖模塊完全具備使用拖拉拽節(jié)點的方式組合完整業(yè)務流程圖，并在節(jié)點上展示監(jiān)控數(shù)據(jù)，達到一站式展示應急開機程序啟動后各個環(huán)節(jié)處理情況的目的。
如下圖，展示的就是自動化運維平臺上應急開機流程圖：
該流程圖把應急開機各個環(huán)節(jié)全部以節(jié)點的形式展示出來，如用戶號碼從提取到處理到工單執(zhí)行到最終開機，并在節(jié)點上以指標和懸浮框的方式把監(jiān)控數(shù)據(jù)直觀展示出來，如處理進程的數(shù)量、應急模式是常規(guī)還是無條件、應急開機數(shù)據(jù)處理情況及處理量、工單積壓情況及處理量、已開機用戶量及隨機抽查的號碼，均可以在一張流程圖上顯示出來。
啟動應急程序后，不再需要根據(jù)應急流程各個環(huán)節(jié)手工執(zhí)行相應監(jiān)控腳本，只需要打開該流程圖即可清晰地看到各個環(huán)節(jié)處理情況，大幅節(jié)約了操作時間，更清晰地知道應急開機整體完成情況。
以平臺為依托，把各環(huán)節(jié)的固定監(jiān)控交給平臺，從繁多的手工監(jiān)控中抽身出來，更多關注業(yè)務層面的及時性，有效性，連續(xù)性以及故障的前因后果，持續(xù)將完整業(yè)務流程場景化可視化工作迭代下去。
以上是今天來自運營商業(yè)務的介紹分享，我們下次再見。
文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/130208.html
摘要：開放生態(tài)計劃，回饋社會阿里巴巴全球運行指揮中心掌門人沈乘黃首先分享了智能運維在阿里巴巴線上故障管理領域的應用經(jīng)驗。 摘要： 為響應馬老師家國情懷，世界擔當?shù)奶栒伲_放AI+生態(tài)計劃，將讓集團內(nèi)部服務過程中積累下的技術與經(jīng)驗更好地回饋社會，任何企業(yè)或合作伙伴均可以簡單方便的接入阿里巴巴智能故障管理平臺，通過對接入數(shù)據(jù)的訓練學習實時提供異常檢測、關聯(lián)分析、根因定位的能力，使原有的IT管理模...
摘要：今天，我們邀請阿里高級技術專家力君，為大家分享自動智能的客服調(diào)度系統(tǒng)。明確了客服調(diào)度的核心問題，也知道了難點，更看到了目前的現(xiàn)狀后，我們決定打造一款自動智能的客服調(diào)度系統(tǒng)。 小嘰導讀：提到調(diào)度，大家腦海中可能想起的是調(diào)度阿里云的海量機器資源，而對于阿里集團客戶體驗事業(yè)群（CCO）而言，我們要調(diào)度的不是機器，而是客服資源。今天，我們邀請阿里高級技術專家力君，為大家分享自動、智能的客服調(diào)度...
摘要：一，智慧園區(qū)建設的核心價值，三維可視化應用，未來智慧園區(qū)管理發(fā)展方向。，應急指揮預案可視化通過對應急預案的資源流程事件預案進行可視化管理，為園區(qū)重大危險事故提供高效調(diào)度指揮管理手段。獲取智慧園區(qū)三維可視化系統(tǒng)源碼 一，智慧園區(qū)建設的核心價值 1，三維可視化應用，未來智慧園區(qū)管理發(fā)展方向。 ?...
摘要：趨勢擴展到機器學習領域已經(jīng)成為容器編排的事實標準，它的領域也在不斷擴張，未來將成為機器學習技術棧的一部分。比如，發(fā)布了開源的，通過添加到集群中，擴展了的，使得機器學習的工作負載在中成為一等公民。 2018年對于微服務來說是非常重要的一年，這一年Service Mesh開始嶄露頭角，解決服務間復雜的通信問題，這一年很多國內(nèi)互聯(lián)網(wǎng)公司已經(jīng)有了較為成熟的微服務實踐案例，網(wǎng)易云主辦的微服務實踐...
摘要：數(shù)字孿生思考未來，實現(xiàn)智能可視。同期將舉行多場高端活動，共商物聯(lián)網(wǎng)行業(yè)發(fā)展大計，集商貿(mào)交易展示交流活動宣傳評優(yōu)推介為一體的國際化盛會。 優(yōu)锘科技作為互聯(lián)網(wǎng)IT可視化管理和物聯(lián)網(wǎng)IoT可視化管理領域的領導廠商，2019又將展開新系列市場活動，我們期待與業(yè)界專業(yè)人士共同探討及交流行業(yè)最前沿的技術與趨勢。showImg(https://segmentfault.com/img/bVbstwz...
摘要：明確了客服調(diào)度的核心問題，也知道了難點，更看到了目前的現(xiàn)狀后，我們決定打造一款自動智能的客服調(diào)度系統(tǒng)。對于社會化的云客服，我們可以做到，比如排隊數(shù)超過某值時，自動觸發(fā)云客服的應急放班。 背景 為什么客服需要調(diào)度？阿里集團客戶體驗事業(yè)群（CCO）目前承接了阿里集團以及生態(tài)體的客戶服務業(yè)務，我們的客戶通過各個渠道來尋求解決各類問題，每天的進線量巨大，而且經(jīng)常伴隨著突發(fā)性進線，比如天貓代金券...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
