事件管理流程手册

事件管理流程手册IncidentManagementFlowHandbook骏网快车IT外包服务中心（广州中育科技设备有限公司）文档控制描述文档名:事件管理流程手册文档号:版本号:定版日期:2006-6-28作者:公布人:詹俊权公布日期:2006-6-28版本控制版本日期修改人备注2007-2-14詹俊权增加涉及DLR有关重大问题对应子流程2007-02-27詹俊权修改维护子流程2007-詹俊权增加事件通报子流程2007-7-27詹俊权增加投诉解决子流程2007-08-06詹俊权增加应急预案制作规定及指导同意主题签订日期目录TOC\o"1-2"1 综述 4 设计目的 4 合用范畴 4 有关术语 42 事件管理流程设计 6 流程目的 6 流程重要内容 6 与其它流程的关系 7 流程范畴 7 流程执行原则 10 流程有关定义 12 流程概要设计 23 流程具体设计 27 事件状态迁移图 42 核心角色、职责定义 42 核心流程衡量指标 42 报表 423 附加流程 42 涉及DLR有关重大问题对应子流程设计 42综述设计目的《事件管理流程设计报告》是中国惠普公司和骏网快车IT外包服务中心(下列简称骏网快车)共同制订的事件管理的流程设计文档。通过制订该流程设计文档，能够协助骏网快车有效地解决IT环境的突发事件，提高IT系统和服务的质量，并为骏网快车此后进一步的完善事件管理提供指南。合用范畴本文档作为本次项目的事件管理流程具体设计的交付物，读者对象为与事件管理流程有关的全部技术与管理人员。有关术语ITIL（ITInfrastructureLibrary）是英国政府在1987年制订的有关IT服务管理的办法论，现已成为事实上的IT管理原则。协助台（ServiceDesk）协助台从根本上来说是提供了顾客和IT部门的唯一接口。此项功效常通过集中方式提供服务。协助台的根本目的是提供初始支持，并通过变通办法、解决方案或升级到一线、二线支持等手段协助顾客恢复到正常工作状态。事件管理（IncidentManagement）ITIL流程之一，事件管理负责解决全部的IT事件、问题和顾客请求。它的目的是尽快恢复被中断或受到影响的IT服务，因此它的特点往往是以解决表征现象为目的，而不在于查找根本因素。问题管理（ProblemManagement）ITIL流程之一，问题管理负责解决重大紧急事件或含有相似症状的一组事件。它的目的是找出事件的根本因素，并通过解除该根本因素从而避免类似事件的再次发生。同时问题管理流程也负责防止事件的发生。配备管理（ConfigurationManagement）ITIL流程之一，配备管理负责描述，跟踪和报告全部IT基础架构中的每一种设备或系统的管理流程。这些设备和系统被称为配备项(CI)。每一种CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。配备管理数据库（CMDB-ConfigurationManagementDatabase）是在配备管理流程中用于统计公司全部IT有关配备项信息及其互有关系而建立的数据库。变更管理（ChangeManagement）ITIL流程之一，变更管理通过控制和管理IT有关的变更，使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。事件管理流程设计流程目的事件管理流程的重要功效是尽快解决出现的事件，保持业务系统的稳定性，其目的涉及：在成本允许的范畴内尽快恢复IT服务快速响应服务请求（电话/Web/邮件等）顾客在线获得协助沟通事件解决的状态和客户确认事件的解决进行事件控制按规范统计事件就事件的优先级，影响度进行分类分析，诊疗，必要时进行升级监视并结束事件进行定时服务流程回忆提供IT管理信息人力资源运用状况故障解决状况支持效率流程重要内容事件管理流程始于事件的接受和报告，结束于事件的解决。该流程包含下述重要内容：事件接受和统计这个环节是事件管理流程的起点。全部顾客或系统报告的IT事件必须由此环节开始。此环节的目的是在事件发生时快速精确地发现，以协助事件的诊疗和解决并告知有关人员。在此环节中将会收集创立事件统计所需的信息。该环节的核心是信息的精确性和完整性。分类和在线支持事件能够是一种故障、告警、咨询等等，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决方法，该事件将分派给适宜的支持人员对此进行调查。该环节的核心是必要的问题库支持和对的的事件分派。调查和诊疗若支持人员无法解决事件，可运用问题库、诊疗工具等进行更加进一步的分析以找到恢复服务的临时方法，必要时可调用多名支持人员以谋求解决方法。解决和恢复支持人员实施事件的解决方案，并将解决完毕的事件转回协助台，由协助台告知顾客解决的成果，并得到顾客确实认。优先级为很紧要的事件（很紧要事件）和事件升级对于很紧要事件，协助台/一线应立刻提交给二线人员，由二线人员判断，上报给事件经理和有关的管理层，由事件经理决定很紧要事件的解决方式，确保其得到最快速的解决。当事件解决超出预期时限，将自动告知解决人员和对应管理层，以引发有关人员和管理人员的重视和参加。结束事件当顾客确认事件解决后，此时可结束该事件，并在必要时更新问题库。与其它流程的关系和问题管理流程的关系事件管理流程将提供事件的具体、精确的统计信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为很紧要的事件解决并恢复服务后做为问题进行进一步的分析和解决。和配备管理流程的关系需要从配备管理数据库中查询配备项的属性和配备项间的关联关系来定位故障和协助快速的恢复。和变更管理流程的关系协助台应理解变更管理流程中现在正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。流程范畴骏网快车事件管理范畴以下表格所示（以广州丰田为例）：分类（English）子类（Englishi）monitoringBeijingMonitoring(IDC)Singaporemonitoring(FTH/NQC/eKanban-G)TGNMonitoringTMCMonitoringMonitoringG-SCMprovidedbyTMCGPPS/PartsForecastG-ALC/VSM/G-CVTT-LMSe-KanbanPAMS/RUNDOWNOnline＆BatchFrameWorkBeijingIDCInfra（Server）BeijingIDCFireWall／FTHBeijingIDCServerH/W、M/WSMSprividedbyTMCSMS(car)SMS(ServiceParts)SMS-BRP-SMSSMS&P-SMS(Infra)otherssystemprovidedbyTMCG-YNSServivePartsPackagingforChinaSMMACSKBS/InternalKanbanALC_ESAddressRegistraionSystemProgressCounterTeiTeiSFTATSClocalsystemUnofficialNotificationSystemNQCDATAReceivingSystemReceiptIssuingSystemPruductionRecordSystemImport&EntrySystemGeneralFileTransferSystemFinance(exceptbasicparts)AccountingSystemUnitPriceforPaymentSystemHumanResourceSystemRecordManageSystemPassCertificateIssuingSystemCRSIMQSTaxSystemInventorySystemsalessystemTACTC-DISTTOPSSE-CRBmanagementprovidedbyTMCWARPFinance(basicparts)W-Cube/WAIS/TQ-NETnetworkLAN（exceptTGN）TGNRouterTGNGlobalBackbornTGNTMCpartsWAN（exceptG-YNS）G-YNSIDCSERVERH/W、N/WG-YNSIDCFIREWAREFTHserverLocalServer#1/#2/#3/BUG-ALC_ESServerKBS/InternalKanbanServerAddressRegistraionServerProcessCounterServerSMMACSServerTeiTeiServerFinance/ProcurementServerAccountingSystemServerHumanResourceServerRecordManageServerSMS-BRServerTACT/C-DISTServerTOPSSServerE-CRBServerPassCertificateIssueServerCRSIServerMQSServerMailServerDNSServerProxyServerActiveDirectoryServerAntiVirusServerUpdateServerPrintServerFireWall/FileServerotherssystemTelephoneFaxAirConditionerPrinter(OA)Others本领件管理范畴不涉及尚处在开发或测试环境的系统和应用引发的事件。流程执行原则常规原则全部IT科事件管理范畴内发生的事件，都由协助台人员统计在服务管理平台中，统计的信息应足够具体，涉及事件解决交互过程，具体的解决方案和对应的附件全部IT支持人员对优先级为很紧要和紧要的事件所采用的服务恢复行动，在比对其它行动的时候，将拥有优先解决级别应当定时产生每日和每月的事件管理报表。对重复发生的事件和变通办法解决的事件，应当举办定时的事件管理睬议对这些事件进行评定应当六个月对流程进行回忆，回忆内容涉及流程核心衡量指标、流程执行效率和流程支持工具的有效性，以改善事件管理流程流程关联原则和问题管理的关联全部优先级为很紧要的事件在恢复服务后，都应当创立问题单（问题单必须和事件单建立关联）一线支持在解决事件的过程中，能够通过问题统计查找对应的解决方案和变更管理的关联事件解决过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完毕后，继续事件单的解决很紧要事件（优先级为很紧要的事件，下同）的解决过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出很紧要变更请求，变更完毕后，补录很紧要变更单，并和很紧要事件单建立关联和配备管理的关联事件解决过程中，能够通过配备管理查询有关的配备项信息以及该配备项历史上发生的事件、问题或变更，来协助故障的定位事件解决过程中，如果能够将故障定位到某个配备项，则必须将事件单与该配备项关联全部权原则全部权原则用来确保每个事件在任何时段都有适宜的人员负责，协助台是事件的负责人。协助台员工是事件单的负责人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭再分派原则事件的再分派原则是确保事件在服务目的时段内解决和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单分派到个人，事件单的重分派次数不应当超出5次。协助台能够将事件单分派给协助台/一线支持，如果找不到适宜的协助台/一线支持，能够直接分派到二线支持协助台/一线支持能够将事件单重新分派给协助台，其它协助台/一线支持人员，二线支持二线支持能够将事件单重新分派给协助台/一线支持重复事件原则重复事件是指在一种较短时间段（普通30分钟内至1小时），由监控平台上报的同一种配备项上现象相似的事件或一人/多人申告的同一来源（系统、应用）现象相似的事件。当被报告的事件与某个已经创立且尚未解决的事件单相似，则该事件被认为是重复的。由于此时已创立的事件尚未解决，还没有采用修正方法来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，全部的重复事件单获得解决。监控平台应当自动过滤重复告警，避免将重复的告警发送到服务管理平台重复的事件信息必须被标记，并且不计入事件流程的核心衡量指标如果协助台/一线能够判断到重复事件，则由协助台对重复事件标记，否则由二线支持人员负责重复事件的解决关闭原则全部的事件单，关闭必须由协助台完毕，关闭之前需要与顾客和IT科担当确认。事件解决人员在解决完毕事件时，根据实际解决状况填写事件的结束代码，采用临时方法恢复服务时，结束代码为“变通办法解决”。协助台负责和IT顾客再次确认事件的解决。由IT顾客承认获得关闭的事件单的结束代码为“成功解决”关闭已解决的事件单如果没有得到IT顾客的承认，则首先关闭该事件单，结束代码修改为“不成功”，同时创立一种新的事件单重新分派到原解决人员继续解决已关闭的事件单不允许重开。如果事件重复发生，则创立一种新的事件单升级原则制订升级原则的目的是确保事件在规定的解决时限内能够及时告知有关技术人员和领导，引发更多的重视，提供适宜的资源，从而快速找到解决事件的方案。优先级为很紧要的事件，协助台应立刻升级到对应二线支持，由二线支持再次确认，如果确认了优先级为很紧要，则立刻升级到事件经理，并告知对应的管理层（通过服务管理平台），由事件经理启动很紧要事件解决流程各支持人员应及时响应和解决分派到自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和解决协助台/一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级解决流程有关定义事件信息项事件单必须包含以下事件信息项：序号信息项(中文)信息项(English)阐明1事件IDID事件单流水号（系统自动产生）2事件编号ISSUE_ID.原有事件ID的更新3请求人信息Requtesor事件申报人的信息，涉及：姓名、总部/分公司、部门、电子邮件、办公电话、手机（手工填写）4登记时间Registered在协助台生成事件统计的时间（系统自动产生）5地点Location事件发生的地点（手工填写）6事件发生时间OccurrenTime针对故障：指的是业务中断的实际时间（可能早于登记时间，需要手工填写）针对其它：缺省值等于登记时间7业务恢复时间RecoveryTime针对故障的业务恢复实际时间（手工填写）8事件性质Category参见“事件性质”定义9事件来源Medium参见“事件来源”定义10事件影响度Impact参见“事件影响度”定义11事件优先级Priority参见“事件优先级”定义12事件完毕期限Deadline对应每一种事件优先级，系统根据流程有关定义中“事件解决时限”自动设定最后的完毕期限（系统自动产生）13事件所属系统类型System参见“事件所属系统类型”定义14事件分类（因素定位）Classification参见“事件分类”定义15事件标题Description事件的简要描述（手工填写）16顾客现象描述Phenomenon对于整个事件内容的具体描述（手工填写）17事件解决人Solver事件的最后解决人（手工填写）18事件状态Status参见“事件状态”定义19分派对象Toperson被分派的技术支持组和人员（手工填写）20事件日志History反映事件信息项的变化历史，如一种事件在解决过程中事件状态变化的时间点等信息（系统自动产生）21解决方案Solution事件解决方案的描述（手工填写）22事件结束代码ClosureCode参见“事件结束代码”定义23与否重复事件RepeatTag标记为重复事件（手工填写）24解决与否超时OvertimeTag参见“解决与否超时”定义（系统自动产生）25事件解决人角色Solverrole参见“事件解决人角色”定义26实际开始时间ActualStart统计事件状态到XX解决中的时间（系统自动产生）27实际完毕时间ActualFinish统计事件已解决的时间（系统自动产生）28故障厂商Faultfactory统计故障厂商信息（手工填写）29关联配备项Configuration统计出现故障的配备项代码（手工填写）30审核描述Approvaldescription统计方案审批过程，同时把有关审批的手续（复印的签字文献或邮件等）31与否通过事件回忆产生Incidentreviewtag与否是过对已发生事件分析后重新创立的事件，布尔型，默认否32与否常见问题FAQ事件解决完毕后，与否形成完善的解决方案，布尔型，默认否33与否进行审核SolutionApprovaltag事件的变通办法或解决方案与否需要审核，布尔型，默认否34审核进度Approvalscheduler方案审核中不同级别的审核，涉及：IT担当审核、系长审核、科长审核、部长审核35审核状态Approvalstatus方案审核中的状态，涉及：审核提交、审核进行中、审核完毕36与否通过成果Approvalresult方案审核成果，通过或不通过37与否发送邮件Mailenabledtag事件与否按照定义的规则发送邮件，布尔型，默认是38与否补单DelayOperationTag事件单是事件解决完毕后填写的，布尔型，默认否39转发次数Forwardednum事件单在分派过程中，由于对事件因素不明确造成的转发次数，不得超出5次，第五次被分派的解决人员，不管事件与否是其管理范畴，将最后负责该事件的解决40变通办法Workaround事件临时方案的描述（手工填写）41OtherSDNo.OtherSDNo.其它协助台ID42代理厂商Agencyfactory统计代理厂商信息（手工填写）43与否影响业务BusinessImpactedTag与否影响业务（生产、销售、供应商）44现象分析Phenomena事件现象分析（手工填写）45因素具体描述DetailReason事件因素具体分析描述（手工填写）46表象Presentation事件外在表象（手工填写）47IT担当ITpeopleof事件归属的IT科担当48知识库编号FAQNo.知识库编号49知识库组FAQGroup知识库组50重复事件单号RepeatISSUE_ID统计之前重复的事件单号（手工填写）51服务工时ServiceTime解决人员解决事件实际耗费时间（手工填写）52接受时间ReceiveTime协助台/一线接受顾客请求或其它方式事件的时间事件性质根据骏网快车IT科的管理范畴和和管理规定，定义以下五类事件：编号代码(中文)代码(English)描述1故障Fault指IT系统错误或反映IT系统部分或全部功效不能正常使用的报障；监控管理平台上报的影响系统正常使用的告警2询问Inquire指对系统操作使用等方面的求助和询问3告警Alarm监控平台自动产生的没有影响到系统正常使用的告警，监控平台发送的严重告警、重要告警、普通告警等4需求Requirement电话安装、系统安装、功效需求等服务5维护Maintenance指运维人员的日常维护作业或临时进行的维护作业事件来源事件来源代码用来标明事件的提出方式，事件来源能够涉及下列几个：编号代码(中文)代码(English)描述1电话Phone顾客通过电话告知，由协助台手工录入（涉及口头描述）2邮件E-mail顾客通过邮件的方式发起，需要手工录入3监控系统MonitoringSystem由监控系统发现并产生的突发事件，可通过集成自动生成4日常检查ProactiveCheckingIT科和二线维护人员，在日常检查中发现问题，需要手工录入5公文Document纸质文献、FAX和传达文书等6WEBWEB通过web界面提交的事件事件所属系统类型(以广州丰田为例)根据现在骏网快车管理范畴内的系统和分类定义事件所属系统类型，当事件发生时，应当由协助台/一线支持初步定位是哪个系统及子类出现问题，由二线、三线进行进一步的明确。对没有覆盖到的系统用”其它”表达。类别编码系统(中文)系统(English)应用系统(ApplicationSystem)P-01P-SMSP-SMSP-02PartsForecasPartsForecastP-03NQC数据授受系统NQCDATAReceivingSystemP-04GPPSGPPSP-05G-ALC(HOST)G-ALC(HOST)P-05AVSMVSMP-06G-CONVERTERG-CONVERTERP-07分散ALCG-ALC_ESP-09内示表发行系统UnofficialNotificationSystemP-10P-11生产实绩系统PruductionResultSystemP-12G-YNSG-YNSP-13e-kanbane-kanbanP-14New-KBSNew-KBSP-15工程内e-KanbanInternale-KanbanP-16纳受领书.检收系统ReceiptIssuingSystemP-17T-LMS(G)T-LMS(G)P-18所番地AddressRegistraionSystemP-19进度统计ProgressCounterP-20PAMS/RundownPAMS/RundownP-21中国补给部品包装系统ServivePartsPackagingforChinaP-22输入通关系统Import&EntrySystemP-23SMMACSSMMACSP-24通用文献传送系统GeneralFileTransferSystemP-25盘点系统InventorySystemP-26NQCNQCP-27整车物流实绩管理系统ResultSystemforG-YNSP-28SMS-BRSMS-BRS-01TACTTACTS-02C-DISTC-DISTS-03TOPSSTOPSSS-04E-CRBE-CRBA-01财务会计AccountingSystemA-01A金蝶系统KingdeeSystemA-02WARPWARPA-03支付单价管理UnitPriceforPaymentSystemA-04品质W-Cube/WAISW-Cube/WAISA-05人力资源HumanResourceSystemA-06档案管理系统DocumentManageSystemA-07整车合格证系统VehicleCertificateIssuingSystemA-08CRSI(供应商索赔信息系统)CRSIA-09MQSMQSA-10金税系统TaxSystemA-11EIPEIPA-12A公司网站CorporationSiteA-12B产品网站ProductionSiteA-12C车主网站OwnerSiteA-13一卡通SmartCardSystemC-01SFTSFT网络(Net)N-01AD办公大楼网络ADofficeNetworkN-02SO办公大楼网络SOofficeNetworkN-03总装车间网络ShopANetworkN-04涂装车间网络ShopTNetworkN-05树脂车间网络ShopRNetworkN-06焊装车间网络ShopWNetworkN-07冲压车间网络ShopPNetworkN-08TGN网络ToyotaGlobalNetwoorkN-09供应商网络SupplierNetworkN-10销售店网络DealerNetworkN-11外围建筑AnnexbuildingNetworkN-12InternetInternetN-13G-YNS网络G-YNSNetwork基础(Infrastructure)B-01ServerRoomServerRoomB-02电话系统TelephoneSystemB-03邮件系统MailSystemB-04打印系统PrintSystemB-05基础域系统DomainB-06客户端系统ClientB-07OA其它OAOthersB-08操作系统OSB-09数据库系统DataBaseSystemB-10安全系统SafetySystemB-11备份系统BackupSystemB-12监控系统MonitoringSystem其它(Other)E-01其它Other事件分类事件分类代码用于标记故障或告警的具体因素，由支持人员在解决过程中填写。在制作统计报表时，能够通过和事件所属系统类型代码的结合来统计分析故障或申告。事件的分类层次设计普通不超出三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为“条目”。下表是两层划分。分类(中文)分类(English)子类(中文)子类(English)条目系统软件ApplicationSoftware进程Process数据Data参数Parameter代码Code接口Interface其它Others基础硬件InfrastructureHardware路由器Router网络交换机Switch小型机Mainframe服务器Unixserver存储光纤交换机SANFabricSwitch存储设备StorageDevice备份设备BackupDevicePCPC主板（Mainboard）内存（MEM）硬盘（Harddisk）键盘（Keyboard）鼠标（Mouse）电源（Power）显示屏（Display）电池（Battery）打印机Printer电话交换机PBX电话Telephone复印机Copier扫描仪Scanner传真机Fax其它Others基础软件InfrastructureSoftware操作系统OS数据库DB中间件Middleware集群软件Clusterware备份软件BackupSoftware系统管理软件SystemManageSoftware办公软件OfficeSoftware其它Others安全设施SecuritySystem防火墙FirewallIDS入侵监测系统IntrusionDetectionSystemIPS入侵防护系统IntrusionPreventionSystem防毒墙Viruswall安全软件SecuritySoftware其它Others配套设施AssociatedEquipment电源ElectricalPower耗材Consumables,supplies线路Cabling空调AirConditioner其它Others业务需求BusinessRequirements事件优先级优先级是事件管理的一种核心要素，优先级决定解决事件的次序及所需的资源，事件优先级可分为四级（很紧要、紧要、普通、不紧要）。编号优先级代码(中文)优先级代码(English)描述1很紧要Top故障造成生产停止，销售停止2小时以上2紧要High1级告警、故障(影响生产、销售业务正常运转且不能延时解决)3普通Medium重要需求、2-3级告警、及故障(影响业务正常运转但可延时解决)4不紧要Low询问、普通需求、4级(含)下列告警、维护、故障(不影响业务正常运转)事件响应时限和解决时限在事件解决过程中，对于一种事件有解决时间的限制和响应时间的限制，首先，需要各工程师协同合作，在解决事件的时候应当有时间的概念，同时，也规定事件经理必须实时地督促事件的解决，对于影响度为很重要或者重要的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超出了时限，需要通告事件经理，同时也要根据具体状况通告给其它有关管理人员。响应时限指的是事件状态从“已登记”到“协助台/一线解决中”通过的时间，如果协助台直接分派到二线支持，响应时限指的是事件状态从“已登记”到“二线解决中”通过的时间；解决时限指的是事件状态从“已登记”到“已解决”通过的时间；事件优先级对应的事件响应时限和解决时限参考下表：编号优先级代码响应时限规定解决时限规定1很紧要5分钟50分钟2紧要20分钟2小时3普通1小时16小时内（工作日）4不紧要4小时48小时内（工作日）超出响应时间的通告定义告知人员列表的用途：当服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信告知。优先级别告知人员列表事件响应时限很紧要傅四海、政本、万海涛、詹俊权5分钟紧要万海涛、詹俊权20分钟普通邱柏静、陈启添1小时不紧要邱柏静、陈启添4小时超出和即将超出解决时限的通告定义告知人员列表的用途：当服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信告知。优先级别告知时间告知人员列表事件解决时限很紧要30分钟万海涛、詹俊权50分钟50分钟傅四海、政本、万海涛、詹俊权紧要1小时万海涛、詹俊权2小时2小时傅四海、政本、万海涛、詹俊权普通8小时邱柏静、陈启添16小时内（工作日）16小时邱柏静、陈启添不紧要24小时邱柏静、陈启添48小时内（工作日）48邱柏静、陈启添事件影响度事件影响度用于衡量事件所影响业务的严重程度。严重程度普通通过事件所影响的人数、核心系统数以及服务故障所造成的损失来设定。定义事件影响度等级的因素有：与否影响了核心业务所影响的顾客数服务失效的影响范畴和时长事件影响度在事件的生命周期中是能够变化的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，因此事件的影响度应在事件得到解决（服务恢复）后重新确认。事件的响应时间、解决时限以及解决事件所需要引入的资源重要由事件的优先级决定。编号影响度代码(中文)影响度代码(English)描述1很重要VeryHigh2重要High3普通Medium4不重要Low事件状态事件状态代码表明事件所处的解决状态，事件状态以下：编号代码(中文)代码(English)描述1已登记Registered新开事件统计或事件已创立2分派到协助台/一线Assignedtohelpdesk/1st事件已分派给协助台/一线支持人员，尚未响应3分派到二线-IT科Assignedto2nd-IT事件已分派到二线IT科人员支持，二线IT科人员尚未响应4分派到二线-insideAssignedto2nd-inside事件已分派到二线inside人员支持，二线inside人员尚未响应5分派到二线-outsideAssignedto2nd-outside事件已分派到二线outside人员支持，二线outside人员尚未响应6分派到三线Assignedto3rd事件已分派到三线支持，三线尚未响应7协助台/一线解决中AcceptedByhelpdesk/1st协助台/一线支持人员已接手解决事件8二线解决中-IT科AcceptedBy2nd-IT二线IT科支持人员已接手解决事件9二线解决中-insideAcceptedBy2nd-inside二线inside支持人员已接手解决事件10二线解决中-outsideAcceptedBy2nd-outside二线outside支持人员已接手解决事件11三线解决中AcceptedBy3rd三线支持人员已接手解决事件12已解决Resolved/Readytobeclosed事件已解决13关闭Close事件已关闭事件结束代码事件结束代码阐明了事件是在何种状况下关闭的，结束代码以下：编号代码(中文)代码(English)描述1成功解决Resolved事件获得成功解决2临时解决workaround事件已通过变通办法或者临时方法获得解决，但是需要进行更进一步的本源分析3不成功Unresolved事件没有获得解决（顾客没有承认解决时使用）4消失Disappeared事件自行消失5误报Misinformation不属于IT科管理范畴的事件6可忽视Ignore如通过其它系统接口或监控系统提交的垃圾信息，经确认属于无效信息7撤销Cancelled顾客撤销事件8回绝Reject回绝不符合规定的事件事件解决人角色事件解决人角色用来标明该事件单最后解决的角色是协助台/一线还是二线、三线。编号代码(中文)代码(English)描述1协助台/一线Helpdesk/1st协助台/一线支持最后解决事件2二线-IT科2nd-IT二线支持IT科人员最后解决事件3二线-inside2nd-inside二线支持inside人员最后解决事件4二线-outside2nd-outside二线支持outside人员最后解决事件5三线3rd三线支持最后解决事件解决与否超时每个优先级别都对应理解决期限，“解决与否超时”用来标明事件的解决与否已超出理解决期限。编号代码(中文)代码(English)描述1未超时Ontime未超时2超时Overtime事件已超出规定的解决时限故障厂商用来在事件单中统计是哪个厂商的设备/系统。代码定义参见下表。编号厂商名称CiscoNECHPIBMMicrosoftOracleSUNDELLEMCEPSONAPCNortelBEAJuniperF5DENCOKingdee代理厂商用来在事件单中统计是代理厂商管理的设备/系统。代码定义参见下表。编号厂商名称KDDI-GZ广州灵通NECSLJOSTCSBMTSTMCNECHANDKINGDEEJSLAeroStrong知识库组用来在事件单中对形成的知识分类。代码定义参见下表。编号分类IE问题病毒问题打印问题生产系统问题销售系统问题邮件问题帐号问题流程概要设计事件管理概要设计流程图以下：事件管理概要设计流程阐明序号环节名称负责人阐明事件统计和分类协助台/一线支持协助台/一线支持对来自顾客和系统自动产生的事件进行具体统计，其中涉及故障/需求/询问/告警/维护协助台/一线支持负责在接受到事件后进行分类转发，维护转发到对应维护子流程解决，对故障/需求/询问/告警类事件进行分类转发，并告知对应的IT科担当对于初步判断为很紧要的事件立刻升级到二线人员解决，并告知对应的IT科担当对于非IT科维护职责范畴的事件直接关闭手工填写新的事件单初始支持协助台/一线支持属于协助台/一线支持技能范畴内能够解决的事件，协助台/一线支持应尝试解决，如果无法解决需及时升级到二线支持，并告知对应的IT科担当不属于协助台/一线支持职责范畴的事件，立刻分派到对应的二线支持，并告知对应的IT科担当二线尝试解决二线支持二线支持（IT科担当或供应商）人员在接受到由协助台派发的事件后，进行调查诊疗，尝试解决对于需要通过方案审核解决的事件，通过方案审核子流程审核变通办法或解决方案事件解决后，在事件管理平台统计事件解决方案并更新事件状态指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源不能解决的事件，可协调供应商（三线支持）提供方案配合解决不能解决的事件，如果需要三线支持解决，可转三线尝试解决（通过把事件单转发给协助台，由协助台重新分派）如果二线支持（IT科担当或供应商）解决完事件，让顾客在事件单上签字确认如果三线支持解决完事件，让顾客在事件单上签字确认三线尝试解决三线支持三线支持人员接受事件，进行调查诊疗，尝试解决方案对于需要通过方案审核解决的事件，通过方案审核子流程审核变通办法或解决方案事件解决后，在事件管理平台统计事件解决方案并更新事件状态指定时限内不能解决的事件，通告事件经理，由事件经理负责协调资源很紧要事件再确认二线支持二线支持人员（IT科担当或供应商）接受到来自协助台/一线支持的很紧要事件后，根据事件优先级别原则再次确认事件与否为很紧要事件如果优先级确实很紧要，则告知对应的管理层，并立刻升级到事件经理，转104很紧要事件解决子流程如不是，转二线（IT科担当或供应商）尝试解决，开始正常事件解决流程统计解决方案细节协助台一线支持二线支持三线支持在事件得到解决后，各线支持人员负责具体统计事件解决过程及方案并更新事件信息二线支持（IT科担当）检查事件解决状况（确认与否解决完毕，确认是变通办法还是解决方案），并在事件单上签字确认关闭事件协助台/一线支持二线支持三线支持协助台/一线支持与顾客确认事件与否已得到解决，如果解决，事件以成功解决或变通办法解决而关闭；否则，事件以不成功关闭，重新开事件统计，并与原统计做关联，分派到原解决人员继续解决与顾客确认方式涉及：顾客签字确认的事件单，电话或邮件与顾客确认与顾客和IT科担当都确认通过后，方可关闭事件事件解决的监控事件经理负责监控全部未关闭的事件的解决状况，对接受到的超时告警应及时关注，并负责协调资源，确保事件的最后解决当事件优先级为很紧要时，应按照很紧要事件解决子流程解决很紧要事件101维护子流程协助台/一线支持二线支持三线支持二线支持/三线支持根据日常的维护工作，制订对应的维护作业和计划协助台/一线支持根据维护计划或作业创立维护事件单，并分派到二线支持（IT科担当），二线支持（IT科担当）转发事件到对应的二线支持（供应商）/三线支持二线支持（供应商）/三线支持执行并统计执行成果协助台/一线支持关闭维护事件单102方案审核子流程协助台/一线支持二线支持三线支持二线支持/三线支持针对某特定事件，准备变通办法或解决方案、测试计划、实施计划、回退计划有关领导审核准备内容，如果可行，继续后续的事件解决；如果不通过，继续准备适合该事件解决的有关变通办法或解决方案、测试计划、实施计划、回退计划二线支持/三线支持整顿审核后方案，继续后续方案的执行工作103事件回忆子流程协助台/一线支持二线支持三线支持二线支持运维组组长（IT科担当）组织二线支持（供应商）对已发生事件（很紧要、重复、未解决、临时解决）定时回忆分析，找出需要重新解决的事件，提交给协助台/一线支持协助台/一线支持创立事件单，分派对应的IT科担当IT科担当分派给对应二线支持（供应商）找出根本因素和解决方案，并执行方案，转发到。104很紧要事件解决流程事件经理事件经理负责协调很紧要事件的解决，具体过程见很紧要事件解决子流程105事件通报子流程协助台/一线支持事件经理二线/三线支持顾客有关领导协助台/一线支持负责受理、统计和跟进事件事件经理负责事件判断和通报二线/三线支持负责事件解决支持和影响度判断顾客负责申报事件及理解事件解决进出有关领导负责事件整体状况理解及必要时介入解决及资源协调流程具体设计（）事件统计和分类流程描述以下：序号环节名称负责人输入输出阐明从任务队列中接受事件协助台/一线支持事件队列需要解决的事件事件任务队列的来源：监控系统自动发送的告警协助台/一线支持负责检查事件任务队列中的新事件单，开始解决：察看默认生成的信息，如：事件编号打印现在事件单，如需要派发给对应二线支持新建事件协助台/一线支持电话/OA/传真新建的事件统计属于IT科职责范畴，协助台/一线支持负责创立新的事件单，填写具体状况描述，不属于IT科解决的，直接电话回复。事件单填写的具体内容以下：报告人姓名、联系电话、邮件、部门事件标题和描述必要的附件事件发生时间和地点事件来源和事件性质进行事件分类设定事件状态为“已登记”打印现在事件单，如需要派发给对应二线支持如果是事件回忆子流程提交的事件，设立“与否事件回忆”为TRUE与否为IT科职责范畴协助台/一线支持事件单协助台/一线支持判断与否属于IT科职责范畴：是，进行事件分类的解决；否，转回复和关闭回复和关闭协助台/一线支持误报的事件单关闭的事件单联系申报顾客，阐明状况，将该事件单状态置为“关闭”，结束代码为“误报”，保存关闭与否为重复事件协助台/一线支持事件统计对应的解决流程协助台/一线支持根据重复事件原则，判断该事件单与否属于重复事件：是，转重复事件解决；否，事件分类的判断重复事件解决协助台/一线支持重复事件在重复事件单的“重复事件标记”中统计正在解决的事件单的流水号，状态置为“XX解决中”，保存退出。事件性质辨别协助台/一线支持事件性质对应的解决流程根据事件性质辨别不同的解决流程：如果是维护，走101维护子流程；其它事件，走事件影响度、优先级设定事件影响度、优先级设定协助台/一线支持事件统计拟定了影响度和优先级的事件根据上报的事件描述，判断对业务的影响程度，并对照优先级代码表，拟定事件的优先级，以及初始拟定的影响度如果是事件回忆子流程提交的事件，根据提交者（IT科担当）规定设立影响度和优先级优先级为很紧要吗协助台/一线支持事件优先级对应的解决流程协助台/一线支持根据业务的影响程度和事件优先级鉴定的条件，初步判断优先级别：优先级为很紧要，转很紧要事件再确认；其它优先级否，转初始支持（）初始支持流程描述以下：序号环节名称负责人输入输出阐明协助台技能能够解决吗协助台/一线支持事件统计解决方式协助台/一线支持根据事件分类和事件描述，判断解决职责与否在协助台：是，转尝试解决；否，转分派到二线支持（IT科担当）尝试解决协助台/一线支持事件统计协助台/一线支持运用FAQ和本身技能在规定的时限内尝试解决，将事件状态置为“分派到协助台/一线支持”，如果不能解决按照应及时将事件单分派到二线支持（供应商），并告知对应的IT科担当分派到二线支持协助台/一线支持事件统计分派到二线的事件单选择有关的二线解决组和解决人员分派，并将事件状态置为“分派到二线-inside”或“分派到二线-outside”手工填写纸质事件单，并派发给对应二线支持，并告知对应的IT科担当解决了吗协助台/一线支持将解决方案和顾客沟通，判断与否能够解决；能够解决，转统计解决方案细节无法解决，转分派到二线支持（供应商），涉及纸质事件单（）二线尝试解决流程描述以下：序号环节名称负责人输入输出物理流程描述接受事件分派二线支持事件统计二线解决中的事件单如属于分派错误或不能够解决，则转派回协助台/一线支持，由协助台/一线支持重新转派，，并告知对应的IT科担当如接受：二线支持（供应商）则将事件状态置为“二线解决中-inside”或“二线解决中-outside”二线支持（供应商）同时接受纸质事件单如果二线支持（IT科担当）能够解决该事件，设立状态为“二线解决中-IT科”，后续工作由二线支持（IT科担当）执行优先级为很紧要吗二线支持N/AN/A二线支持（供应商）根据预先定义的优先级鉴别原则（优先级映射表），再次拟定事件优先级与否为很紧要优先级为很紧要，转104很紧要事件解决流程优先级不等于很紧要，转尝试找出解决方案告知事件经理和管理层二线支持优先级很紧要的事件事件告知二线支持（供应商）将事件单的优先级别修改为“很紧要”，电话告知事件经理，由事件经理告知有关人员，同时服务管理平台自动将优先级为很紧要的事件邮件告知事件经理和管理层尝试找出解决方案二线支持事件统计解决方案二线支持（供应商）借助工具或运用自己技能尝试找出解决方案，在解决事件的过程中根据需要联系三线支持（供应商）共同参加制订解决方案供应商提供解决方案供应商事件统计解决方案三线支持（供应商）和二线支持共同研究解决方案，提供解决方案方案需要审核吗二线支持解决方案N/A二线支持（供应商）根据解决方案的内容判断与否需要发起方案审核子流程需要发起方案审核，准备实施计划、测试计划、回退计划，提交到方案审核子流程审核不需要发起方案审核，转应用解决方案应用解决方案二线支持解决方案解决方案三线支持（供应商）实施解决方案，实施解决方案的过程，需要和有关顾客共同确认解决方案与否有效解决了吗二线支持N/AN/A判断事件与否得到解决是，让顾客在纸质事件单上签字确认，转到统计解决方案细节否，判断与否需要分派到三线支持解决需要分派到三线支持吗二线支持N/AN/A判断事件与否需要分派到三线支持解决是，转到，分派事件到三线否，判断与否需要协调解决需要协调解决吗二线支持N/AN/A二线支持（IT科担当）和二线支持（供应商）共同根据事件的解决状况判断与否需要其它资源介入是，如二线支持（IT科担当）能够协调，直接由二线支持（IT科担当）协调，否则转到事件经理协调解决否，转到尝试找出解决方案事件经理协调解决事件经理事件统计解决方案事件经理负责将事件通报到管理层，通过高层谋求更多的资源介入，共同商讨和制订解决方案分派到三线支持二线支持事件统计N/A二线支持（供应商）填写解决过程二线支持（供应商）填写纸质事件单转到（）三线尝试解决流程描述以下：序号环节名称负责人输入输出物理流程描述接受事件分派三线支持事件统计三线解决中的事件单如属于分派错误或不能够解决，则转派回协助台/一线支持，由协助台/一线支持重新转派，，并告知对应的IT科担当如接受：三线支持把事件状态设立为“三线解决中”三线支持（供应商）同时接受纸质事件单尝试找出解决方案三线支持事件统计解决方案三线支持借助工具或运用自己技能尝试找出解决方案方案需要审核吗三线支持解决方案N/A三线支持根据解决方案的内容判断与否需要发起方案审核子流程需要发起方案审核，准备实施计划、测试计划、回退计划，提交到方案审核子流程102审核不需要发起方案审核，转应用解决方案应用解决方案三线支持解决方案解决方案三线支持实施解决方案，实施解决方案的过程，需要和有关顾客共同确认解决方案与否有效解决了吗三线支持N/AN/A与二线支持（IT科担当和供应商）共同判断事件与否得到解决是，让顾客在纸质事件单上签字确认，转到统计解决方案细节否，判断与否需要协调解决需要协调解决吗三线支持N/AN/A二线支持（IT科担当）和三线支持（供应商）共同根据事件的解决状况判断与否需要其它资源介入是，如二线支持（IT科担当）能够协调，直接由二线支持（IT科担当）协调，否则转到事件经理协调解决否，转到尝试找出解决方案事件经理协调解决事件经理事件统计解决方案事件经理负责将事件通报到管理层，通过高层谋求更多的资源介入，共同商讨和制订解决方案（）很紧要事件再确认流程描述以下：序号环节名称负责人输入输出阐明确认优先级二线支持事件统计确认很紧要的事件二线支持（IT科担当）和二线支持（供应商）根据该事件有关的业务或IT系统/设备的实际故障状况，并结合其它有关因素，再次拟定事件优先级优先级为很紧要吗二线支持N/AN/A判断优先级＝很紧要吗是，告知事件经理，由事件经理负责很紧要事件的解决，转104很紧要事件解决子流程否，转二线尝试解决告知有关管理层和事件经理二线支持很紧要事件事件告知通过服务管理平台告知（邮件、短信等）事件经理和对应的管理人员（）统计解决方案细节流程描述以下：序号环节名称负责人输入输出物理流程描述统计具体的解决方案协助台/一线支持二线支持三线支持事件统计更新的事件统计根据事件的解决状况填写事件信息项1．填写“解决方案”或“变通办法”2．拟定“事件分类”和“事件所属系统类型”与否对的3．设立“状态”为“已解决”4．对于故障，应填写“业务恢复时间”以及拟定“故障厂商”5．拟定“事件影响度”的等级与否对的6．根据自己所处岗位填写“事件解决人角色”7．对于故障和告警，应当明确是哪个配备项发生的，关联对的的配备项8．填写事件的“实际完毕时间”9．如果有自己解决的重复事件单，则简朴填写重复事件单的信息项，状态改为“已解决”10．如果事件解决完毕后填写事件单，设立“与否补单”TRUE事件单填写完毕后：事件单转回给协助台/一线支持，同时邮件告知对应的IT科担当与IT科对应担当确认解决成果，同时让IT科签字确认把纸质事件单递交到协助台/一线支持（）关闭事件流程描述以下：序号环节名称负责人输入输出阐明与顾客处确认事件解决协助台/一线支持顾客和IT科签字的纸质事件单或顾客反馈反馈成果从事件请求人处确认所提供的解决方案与否有效与否解决协助台/一线支持判断与否解决方案与否有效是，转否，转重开单解决更新事件状态及结束代码，关闭事件协助台/一线支持已解决的事件统计关闭的事件更新事件统计，状态为“关闭”，结束代码根据实际解决成果（顾客确认某些正常，IT科担当确认是临时解决还是成功解决）填写；如确认是成功解决，设立FAQ标记为TRUE如果该事件单有有关联的重复事件，应当将重复事件单一起关闭，重复事件的结束代码和该事件保持一致（如果系统能够自动关联关闭，此项可不操作）重开单解决协助台/一线支持未解决的事件统计新的事件统计协助台将该事件单的的结束代码置为“不成功”，关闭保存；创立一种新的事件单，事件信息能够复制，分派到原解决人员解决，新事件单状态“分派到协助台/一线”或“分派到二线-IT科”注：协助台应当和原解决人员沟通事件确实认成果和后续的解决方式（）事件解决的监控流程描述以下：序号环节名称负责人输入输出阐明事件队列的监控事件经理现在打开的事件单服务管理平台的超时告警事件经理能够从下列途径获取事件解决的信息服务台系统自动发送的告警告知查询服务台系统的现在解决中的事件列表需要介入吗事件经理事件经理根据解决时限和该事件对业务的影响程度，判断与否需要及时介入，协助协调资源解决需要介入，转不需要，则继续监控召集资源协商解决事件经理告警事件支持人员的电话告知解决方案由于解决不及时而可能造成顾客满意度下降的事件或疑难事件，事件经理负责召集对应二线专家，共同商讨并制订解决方案，并实施解决方案能够解决吗事件经理如果解决，转关闭事件无法解决，转升级到管理层解决升级到管理层解决事件经理升级的事件统计解决方案事件经理负责将升级事件通报到管理层，通过高层谋求更多的资源介入，共同商讨和制订解决方案通报到管理层事件经理很紧要事件很紧要事件的解决状况通报到管理层（101）维护子流程维护子流程用来描述日常维护工作内容的解决过程，规范IT维护作业。流程原则维护事件单的产生具体维护内容、维护计划在维护子流程启动前准备完毕；维护计划以重要IT设备（服务器、重要网络设备、生产用打印机、重要电话设备）、普通IT设备、IT系统为对象展开，并对计划进行编号（规则：M_大类_小类+同类编号；如：M_Infra_Server1）。每个维护计划编号下再展开该对象需要进行维护的具体内容，包含每天、每七天、每月、每年需要解决的作业内容；维护事件单和维护编号的关系为一对一关系，并以月度为单位，在每月初或维护作业执行前一种工作日，协助台/一线支持负责将接受到二线支持（运维组组长）下发的维护作业（维护计划）以事件单的形式，分派到对应的二线支持人员；维护事件（维护作业）的执行维有效的管理维护作业的质量，二线支持人员需要在执行维护作业同时填写登记“IT维护检查统计表”（该纪录表上统计了该维护作业内容和执行时间）；二线支持人员在解决完维护作业当天或第二个工作日将填写好的事件单和统计好的“IT维护检查统计表（通过IT担当确认）”一同返回协助台/一线；二线支持人员在解决维护作业中发现异常需要做好统计并报告协助台/一线及有关人员，按照事件管理流程解决；维护事件信息项的填写阐明序号信息项与否需要填写维护作业填写内容1事件ID是系统自动产生2事件编号是3请求人信息是4登记时间是系统自动产生5地点否6事件发生时间是维护作业的计划开始时间7业务恢复时间是实际维护作业的完毕时间，完毕后填写8事件性质是参见“事件性质”定义，选择‘维护’9事件来源是参见“事件来源”定义10事件影响度否11事件优先级否12事件完毕期限是维护作业的计划完毕时间13事件所属系统类型是参见“事件所属系统类型”定义14事件分类是参见“事件分类”定义15事件标题是维护作业内容简述16事件描述是维护作业内容具体描述17事件解决人是维护作业的完毕人18事件状态是参见“事件状态”定义19分派对象是维护作业的执行人20事件日志是系统自动产生21解决方案描述是维护作业的执行成果22事件结束代码是参见“事件结束代码”定义，选择‘成功解决’23重复事件标记否24解决与否超时是系统自动产生25事件解决人角色是参见“事件解决人角色”定义26实际开始时间是维护作业实际开始执行的时间，系统自动填写27实际完毕时间是维护作业事件状态变为‘已解决’的时间，系统自动填写28故障厂商否29关联配备项否30方案审核描述否31与否是事件回忆否32与否FAQ否33与否进行方案审核否34审核进度否35审核状态否36审核成果否37与否发送邮件是系统默认38与否补单否39转发次数否40变通办法否41OtherSDNo.否42代理厂商否43与否影响业务否44现象分析否45因素具体描述否46表象否47IT担当是48知识库编号否49知识库组否50重复事件单号否51服务工时是52接受时间是维护子流程阐明维护子流程阐明以下：序号环节名称阐明制订维护作业计划二线支持（IT科担当）组织有关人员，根据维护规定，制订对应的维护计划，涉及：维护内容，计划开始和结束事件，影响范畴，实施人员，维护方案等信息制订完毕维护计划后，二线组长即二线支持（IT科担当），提交维护计划给协助台/一线支持，转到协助台/一线支持创立事件单，参考维护作业填写阐明，填写有关信息，派发给二线支持，状态设立为“分派到二线”每月最后5个工作日，二线支持（IT科担当）确认调节（重要为时间调节和内容增加）下一月份的维护计划，并反映到一线统一下一月份的维护计划执行维护作业二线支持根据维护作业内容，执行维护作业统计执行成果二线支持在“IT维护检查统计表”具体维护作业成果，并最后反映到服务管理平台中体现维护告知发送子流程请参考《ITHelpDesk维护告知发送子流程》，告知后执行维护与否需要发送告知如果维护作业对顾客的业务产生影响或维护成果给顾客带来疑惑，则需要按照子流程发送维护告知，告知确认后执行维护作业。如果维护作业没有对顾客造成影响，则直接执行维护作业。发现异常吗如果在执行过程中发现异常，则转创立新事件统计执行成果完毕，转到维护作业统计关闭保存中协助台关闭事件时，需要提前与IT科担当确认维护计划整体分为定时计划和临时计划，定时计划又Infra部分和Appli部分，其中Infra部分又分为针对重要设备（服务器、重要网络设备、生产用打印机、重要电话设备）和普通设备两部分。维护计划的调节如果涉及内容删除需要通过系长确实认。（102）方案审核子流程方案审核子流程用来描述事件解决过程中，具体事件解决之前，对变通办法或解决方案的审核过程，重要目的是：通过对全部事件（变通办法或解决方案）的对的评定，能够维护IT生产环境的完整性审核过程得到对的统计，并提供审核统计减少或消除由于变通办法或解决方案实施准备不当等因素出现的对IT环境的破坏作用流程原则审核原则全部影响生产环境配备项的变通办法或解决方案都必须通过方案审核子流程审核全部的审核请求统计都应被统计和追踪方案审核内容普通涉及实施计划、测试计划、回退计划、配备项更新计划等方案审核子流程阐明业务解决子流程阐明以下：序号环节名称阐明方案风险分析，制订实施、测试和回退计划方案审核的输入来自3个方面：二线支持提交的方案审核三线支持提交的方案审核事件回忆子流程中，提交的方案审核二线支持或三线支持在提交方案审核前需要准备的工作：完善事件解决方案对解决方案的执行风险进行分析制订实施计划、测试计划和回退计划准备完毕后：以文档形式提交给有关领导方案审核有关领导审核方案方案通过吗方案通过，转到如果不通过（方案不通过，可能有多个因素：方案太完美，现在不含有条件；方案不够全方面，风险太大等等），转到继续重新制订新的方案。整顿审核后方案二线支持/三线支持按照领导批示整顿最后的方案把有关文档作为附件，加入现在事件中审核通过后，对应转到、、统计现在审核进度准备完毕后，方案提交前：设立“与否进行方案审核”为TRUE按照实际状况，可设立“审核进度”为：IT担当审核中、系长审核中、科长审核中、部长审核中设立“审核状态”为“审核提交”或“审核进行中”方案审核不通过：二线支持/三线支持设立“审核成果”为“不通过”方案审核通过后：设立“审核成果”为“通过”填写“方案审核描述”，如果有有关文献类的审批过程，能够复印后加入现在事件中（103）事件回忆子流程事件回忆子流程用来描述对已发生事件（很紧要、重复、未解决、变通办法解决）定时回忆分析，找出根本解决方案，避免这类事件再次发生的过程。目的是消除或减少生产环境中事件发生的数量和严重程度，从而为公司建立一种稳定的IT环境，提高IT服务的可用性。流程原则事件回忆原则事件回忆的发起者是IT科各个担当，由各个担当协调对应的供应商解决事件回忆原则上没有具体解决时间的限制，为加强监督，建议根据实际状况（人员、工作量）合理预估可行的解决时间事件回忆子流程阐明序号环节名称阐明定时分析事件二线支持（IT科担当）组织二线支持（供应商）/三线支持根据事件报表，定时分析事件根据分析成果，拟定重新解决的事件，以文档形式提交给协助台/一线支持创立事件单建议：最初每2周分析一次，每次取TOP10作为重要解决事件提交内容涉及：原有事件ID，事件描述，事件解决时间，事件解决人等信息六个月后，每月分析一次分派给对应二线支持二线支持（IT科担当）转发事件到对应二线支持（供应商），设立状态为“分派到二线-inside”或“分派到二线-outside”或“分派到三线”分析根本因素二线支持（供应商）/三线支持借助工具或运用自己技能尝试找出引发事件的根本因素制订解决方案二线支持（供应商）/三线支持基于根本因素制订根本的解决方案如需要方案审核，转到102审核方案，审核完毕后转如不需要方案审核，转到执行解决方案二线支持（供应商）/三线支持执行解决方案与二线支持（IT科担当）确认成功解决后，设立“与否FAQ”为TRUE，转到（104）很紧要事件解决子流程制订很紧要事件解决子流程的目的：当很紧要事件发生时，尽量采用方法减少对于业务带来的影响确保对很紧要状况的有效管理加紧很紧要事件的响应和解决速度对很紧要状况中的人员及采用的行动加强管理加强解决人员与顾客之间的沟通和反馈对很紧要状况妥善解决流程原则制订各系统应急解决预案为了确保系统发生重大故障时，能够尽快恢复业务，并充足调动技术力量，在最短时间内排除故障，各系统应当建立对应的应急解决预案，建议预案按照以下规定及指导制作：应急预案制作目的及分类应急预案目的为了确保在系统发送重大故障时，有关人员能参考应急预案中的解决环节，协调有关资源（技术力量、硬件支持、资金支持等），尽快从业务或技术上恢复，使故障对业务的影响降到最低。应急预案分类根据IT与业务的关系，建议将应急预案辨别业务与系统进行分类制作：业务应急预案系统应急预案应急预案内容规定预案概况此部分需要阐明此预案制作的目的、应急对应效果以及预案执行必须恪守的原则。预案对应的业务范畴及应急小组此部分需要阐明预案所对应支持的业务范畴以及应急小构组员（具体联系资料）。建议应急小构组员中包含对应的业务担当和系统担当。应急预案启动条件此部分需要具体定义问题故障级别以及应急预案启动的条件。应急预案响应及解决此部分需要考虑故障发生时，公布故障信息、信息公布对象、应急解决环节（必需环节清晰且可操作）以及应急结束确认。应急善后解决此部分需要考虑故障消失、应急解决完毕后，需要解决的善后工作，以确保能将应急解决中的业务作业与故障发生前，故障恢复后的业务作业顺利平稳连接。应急保障方法（人员、培训、演习、场地等）此部分需要阐明保障应急预案实施所需要的日常工作、有关工具以及演习计划等。很紧要事件上报为切实掌握很紧要事件状况，规定在很紧要事件发生时立刻上报，并在很紧要事件解决过程中的核心点将解决状况上报。很紧要事件解决子流程阐明很紧要事件解决子流程阐明以下：序号环节名称阐明召集应急小组，协调应急会议事件经理主持应急会议，并组织讨论、协调各方资源，分析很紧要事件解决方案，并将很紧要事件状况通报有关领导（根据预案，没有预案先报告到IT科科长一级）判断与否属于应急预案中的事件应急小组和有关厂商根据很紧要事件现象和影响程度，判断与否需要启动对应系统的应急预案如果没有应急预案，则进入组织有关厂商共同分析很紧要事件，制订解决方案并解决；如果有应急预案，则进入按照应急预案解决按照应急预案解决根据各系统制订的应急预案中的实施环节，解决很紧要事件组织有关厂商共同分析，制订解决方案并解决应急小组负责组织有关厂商共同分析很紧要事件，制订对应的解决方案，如果需要有关领导介入解决，则向有关领导申请介入；解决方案在实施前应得到应急小组和有关领导的承认；事件解决过程中如果方案需要审核，则需要提交奥到方案审核子流程进行审核。能够通过电话沟通等方式，加紧审核速度。很紧要事件解除确认在很紧要事件解决方案实施后，应急小组、有关厂商和有关部门对很紧要事件与否解除进行确认很紧要事件如果没有解除，则重新进入组织有关厂商共同分析很紧要事件，制订解决方案并解决；如果解除，则进入很紧要事件善后解决和总结分析善后解决和通报很紧要事件解除后，应急小组向顾客、公司有关领导简要报告很紧要事件解决过程，解决办法，事件解除时间，业务恢复状况很紧要事件的对应IT科担当，需要提交该事件到协助台，创立一种新事件，将很紧要事件解决过程的具体信息统计到事件单中，提交到事件回忆子流程解决，进行问题本源的分析（105）事件通报子流程流程目的当涉及生产、销售、供应等有关业务重大事件发生时，尽量快将问题影响、解决进度等信息告知到有关顾客、担当和领导；确保对重大事件的有效管理和对应，减低对业务的影响；流程原则重大事件判断原则生产：造成生产停止或（如不解决）即将造成生产停线；销售：销售店总量的10%不可操作同一系统业务且持续30分钟以上；供应：影响供应商产品供应管理：系统停止服务1天；网络：Internet断线（如不解决）基础：操作平台、硬件、消防事故等，造成生产停线、销售系统停止服务；其它：上述以外，引发顾客（领导）较大损失或影响，从而造成顾客（领导）投诉的严重事件；专人对应原则为了确保有关重大事件发生时，能够尽快的让ITHelpDesk及有关人员公布的有关告知，需要IT及顾客部门专门的窗口对应ITHelpDesk：及时对应原则为确保重大事件发生时，有关必须的信息能及时的告知到顾客、担当及领导，需要ITHelpDesk在接受到事件10分钟内和有关系统及业务担当确认与否为重大事件；在判断为重大事件后10分钟内将重大事件的有关信息（问题描述、影响范畴、解决进度以及趋势）告知有关顾客、IT担当及IT领导。有关顾客、IT担当及IT领导在规定时间内对未解决事件视影响判断与否进一步升级。有效的告知信息原则为了让业务顾客对IT问题清晰理解，ITHelpDesk发送的故障告知需要对问题进行通俗描述，使得非IT专业人士亦可读懂。考虑到ITHelpDesk告知各式的整体一致性，有关重大事件的告知告知也按照HelpDesk的一贯格式，邮件主题中包含以下字符串：“[重要故障告知]”。告知到位原则重大事件发生时，ITHelpDesk需要将有关信息告知到业务顾客、IT担当及IT领导。事件通报子流程阐明事件通报子流程阐明以下：序号环节名称阐明普通事件解决及通告流程判断为普通事件后，按照普通事件解决，并由事件经理定时向IT领导报告运维状况。重大事件确认紧要事件发生后由事件经理、系统担当、业务担当共同参考重大事件判断标精确认与否重大事件。未解决/严重事件经理根据事件与否解决及现在严重程度定时和IT科长报告状况，IT科长根据反映状况判断与否需要进一步升级。重大事件告知公布协助台/一线支持根据事件的影响向有关人员（顾客、担当、领导）发送重大故障告知（事件描述、影响等）。（106）投诉解决子流程流程目的当顾客对IT服务的问题提出投诉和建议时有关人员能根据流程快速解决顾客投诉并就顾客建议进行沟通理解；确保顾客投诉建议得到较好解决，提高顾客对IT服务的满意度；流程原则专人对应原则针对顾客的每个投诉，原则上由被投诉事件受理人负责；没有针对事件等特殊状况，由事件经理解决或指派人员解决。及时对应原则协助台在接受到顾客投诉建议，必须当天或4小时内联系顾客，开始对应。对应有效原则为了有效的对应顾客投诉建议，原则上投诉建议解决过程应当包含以下环节和方面：确认顾客投诉内容、问题点及每个问题点因素；针对每个问题点向顾客解释阐明或改善；投诉建议对应获得投诉顾客承认和理解；投诉解决子流程阐明投诉解决子流程阐明以下：序号环节名称阐明投诉受理登记并对应顾客的投诉由事件经理统一纪录并跟进，由对应投诉事件受理人或事件经理指定的人员负责，并执行解决；投诉内容沟通理解投诉解决人需要就顾客投诉建议的内容与顾客进行具体沟通，确认顾客真正要投诉建议的具体内容、问题点和因素；升级给事件经理及有关担当当投诉解决人投诉判断投诉不可控，需要将投诉内容升级给有关的IT担当及事件经理告知有关领导当投诉解决人投诉判断投诉不可控并且严重，需要将投诉内容升级给有关领导联系投诉有关二线人员确认当投诉解决人投诉