点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
本着业务连续性运维，如果不了解业务，那就是聋子的耳朵--白搭。本文给大家带来笔者日常工作中关于业务相关知识分享，以及在遇到问题后，如何基于平台沉淀场景的过程。希望对大家的一体化运维有所帮助和启发。
应急开机是当系统出现异常（例如缴费和开机积压）终端用户已正常缴费但仍然未复机情况下，强制生成开机工单给用户快速开机，恢复用户服务，以此保证客户终端使用，避免造成大规模终端用户投诉的一套程序。
应急进程检查：应急处理进程重启和检查；
应急模式调整：常规应急模式需要根据字典组判断营业用户状态和停机锁，无条件应急模式不判断营业用户状态和停机锁直接开机；
应急开机程序启动：待开机用户号码的提取、处理，如提取指定时间段的缴费用户、指定开机号码集合、指定时间段服务开通侧下发的停机指令用户；
应急开机数据检查：检查应急开机扫描用户数据及其处理情况。各种业务开机工单指令的执行速度及积压检查，含语音、GPRS、VOLTE、非VOLTE、宽带、和TV、IMS等业务。用户开机是否成功，涉及MML(HLR)指令、SOAP协议(PROVISION平台)指令检查；
应急用户状态同步：用户数据状态同步，用户的网络侧状态、平台侧状态、营业侧状态、账务侧状态保持一致；
应急用户强制信控：强制信控数据的生成，对于应该停机而被开机的用户重新触发强制信控进行停机。
以上各环节监控，以前均是通过手工登录对应主机或者物理库执行监控脚本的形式进行检查；监控链条长，形式多样，纯手工操作容易形成顾头不顾尾的局面，导致部分节点遗漏监控，降低应急开机的及时性，使应急开机的效果大打折扣。
系统故障，需要马上执行应急开机，启动应急开机程序后，按照常规监控流程检查了应急数据的处理及下发，以为下发完成后用户全部开机完成了，但是遗漏了更下游环节的开机工单处理积压情况，由于工单积压导致用户并未全部及时开机完成，类似情况易引起次生故障。
因为手工监控耗时，所以故障处理时第一时间，每个人都只关注自己负责环节的数据处理情况，但是每个人自己所负责的环节数据处理完了不代表整个故障处理完了，不代表用户服务恢复正常了，因此需要快速掌握从应急程序启动到最终用户服务恢复之间所有环节的处理情况。
因此有必要摈弃手工执行监控脚本的方式，引入自动化脚本或者可视化页面的形式完成监控及流程处理。
自动化运维平台中的拓扑图模块完全具备使用拖拉拽节点的方式组合完整业务流程图，并在节点上展示监控数据，达到一站式展示应急开机程序启动后各个环节处理情况的目的。
如下图，展示的就是自动化运维平台上应急开机流程图：
该流程图把应急开机各个环节全部以节点的形式展示出来，如用户号码从提取到处理到工单执行到最终开机，并在节点上以指标和悬浮框的方式把监控数据直观展示出来，如处理进程的数量、应急模式是常规还是无条件、应急开机数据处理情况及处理量、工单积压情况及处理量、已开机用户量及随机抽查的号码，均可以在一张流程图上显示出来。
启动应急程序后，不再需要根据应急流程各个环节手工执行相应监控脚本，只需要打开该流程图即可清晰地看到各个环节处理情况，大幅节约了操作时间，更清晰地知道应急开机整体完成情况。
以平台为依托，把各环节的固定监控交给平台，从繁多的手工监控中抽身出来，更多关注业务层面的及时性，有效性，连续性以及故障的前因后果，持续将完整业务流程场景化可视化工作迭代下去。
本文作者：崔京梦（上海新炬王翦团队）
本文来源：“IT那活儿”公众号
