|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
事故管理包括对引起服务中断或可能导致服务中断、质量下降的事件的管理，这包括了用户提交或由监控工具提交的事故。事故管理不包括与中断无关的正常运营指标或服务请求信息。事故管理的主要目标是尽快恢复正常的服务运营，并将对业务的影响降到最低，从而尽可能保证服务质量和可用性要求。
|
|
|
|
事故管理的流程包括事故识别和记录、事故分类和优先级处理、初步支持、事故升级、调查和诊断、解决和恢复、事故关闭等。事故管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）事故识别和记录。通过对所有组件的监控，及时准确地检测出故障或潜在故障，尽可能在未对客户造成影响之前启动事故管理流程。事故记录包含事故基本描述、事故状态、事故类型、事故影响度、事故优先级等信息。
|
|
|
|
（2）事故分类和优先级处理。事故的分类通常采用多层次结构，一个类别包括多个子类。分类时将事故归入某一类别或某一子类中。分类时可以按事故发生的可能原因分类，也可按相关支持小组进行分类。当同时处理若干事故时，必须设定优先级。优先级通常用数字来表示，通常根据紧急度和影响度确定。其中，紧急度指在解决故障时，对用户或业务来说可接受的耽搁时间；影响度是指其所影响的用户或业务数量和大小而言，事件偏离正常服务级别的程度。
|
|
|
|
（3）初步支持。初步支持是指服务台在与用户协商并达成解决时限后，依据自己职责和能力优先尝试解决事故。如果用户满意解决结果，则服务台关闭事故；如果无法解决事故或用户不满意，则应执行事故升级，转交给二线或三线支持处理。在初步支持过程中，可借助知识库提供帮助。
|
|
|
|
（4）事故升级。事故升级是指当前支持人员在规定的时间内不能解决或没有解决某个事故时，便转交给更有经验或更权威的其他人员处理，包括职能性升级和结构性升级两类。职能性升级又称水平升级，是指当前技术人员无法在规定时间内解决事故时，需要具有更多时间、专业技能或访问权限的技术人员参与解决事故；结构性升级又称垂直升级，是指当机构的级别不足以保证事故能及时、满意地得到解决时，需要更多的高级别机构参与进来。
|
|
|
|
（5）调查和诊断。事故在提交给指定的支持小组后，支持人员应该对事故进行调查和诊断工作。具体活动包括确定事故发生的位置及用户需要的帮助；确认事故导致的所有影响，包括影响到的用户数量和规模；识别出由此事故触发的其他事件；通过搜索当前事故／问题记录、已知错误数据库、厂商／供应商错误日志或知识库等，整合相关知识。
|
|
|
|
（6）解决和恢复。通过对事故的调查和诊断，支持人员制定相关解决方案，并在对该方案进行必要的测试之后提交实施。根据事故性质的不同，实施的行为也有所不同，通常包括指导用户在他们的桌面或远程设备上实施解决方案；服务台实施解决方案，或是远程使用软件控制用户桌面实施解决方案；专业的支持小组实施恢复方案；供应商或厂商解决方案。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
问题管理包括诊断事故根本原因和确定问题解决方案所需要的活动，通过相应控制过程，确保解决方案的实施。问题管理还将维护有关问题、应急方案和解决方案的信息，以减少事故的数量和降低影响。问题管理流程的目标是通过消除引起事故的深层次根源以预防问题和事故的再次发生，并将未能解决的事故影响降到最低。
|
|
|
|
问题管理的流程包括问题检测和记录、问题分类和优先级处理、问题调查和诊断、创建已知错误记录、解决问题、关闭问题、重大问题评估等。问题管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）问题检测和记录。问题检测的方法包括：服务台和事故管理等提交的事故需要进一步查明潜在原因；技术支持小组在日常维护工作中发现有尚未对业务产生影响的潜在问题存在；自动化的事件／告警检测工具检测出IT基础设施或应用存在问题；供应商或承包商通告其产品或服务存在的问题；主动问题管理通过趋势分析提交潜在的问题。问题记录包含问题描述、问题状态、问题类型、服务信息和设备信息等。
|
|
|
|
（2）问题分类和优先级处理。问题的分类原则与事故管理中事故的分类相同。问题优先级处理与事故管理中事故的优先级处理方法相同。
|
|
|
|
（3）问题调查和诊断。问题调查的技术包括借助于配置管理数据库定义问题的影响级别并调查故障点；问题匹配技术和故障重现技术。问题分析和诊断的常用方法包括时序分析法、KT决策法、头脑风暴法、石川图法、帕累托分析法等。
|
|
|
|
（4）创建已知错误记录。针对调查和诊断的结果及解决方案创建已知错误记录，并将其存放在已知错误库中，以方便下次发生同样问题时能够快速匹配出已知错误。
|
|
|
|
（5）解决问题。根据制定出的解决方案，问题管理者组织问题处理人员实施方案。如果解决方案需要对基础设施进行变更，则必须首先提交变更请求，启动变更管理流程。
|
|
|
|
（6）关闭问题。当变更完成并且解决方案成功实施使得问题解决之后，可正式关闭问题记录，更新已知错误库，将问题状态置成“已解决”。
|
|
|
|
（7）重大问题评估。重大问题解决之后应当召开重大问题评估会议，需探讨的问题包括工作中的经验和教训、改进方案、预防措施、第三方责任等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
政府信息系统以电子政务为主要形式，是指政府机构在其管理和服务职能中运用现代网络技术打破传统行政机关的时间、空间和部门分隔的制约，使各级政府的各项监管更加严密，服务更加便捷，涉及政府机关、各团体、企业和社会公众，主要包括机关办公政务网、办公政务资源网、公众信息网和办公政务信息资源数据库几个部分。
|
|
|
|
（1）安全级别高。政务信息数据中，有些关乎国家、政府部门、地方政策和利益，比个人或商务信息更为敏感；有些属于大规模的基础设施，比如档案、城建数据；有些具有服务特性，比如医保、社保、公积金、房屋交易等信息；加之电子政务行使政府职能的特点易导致政府信息系统受到各种攻击，包括黑客组织、犯罪集团和信息战时期的信息对抗等国家行为的攻击，因此，其安全问题尤其是数据安全应被重点关注。
|
|
|
|
（2）业务的不间断运维需求高。政府信息系统面向社会提供外部服务，如出入境审批系统、身份证申领系统等，都必须在故障出现后以最短的时间恢复业务运行，否则导致业务受理停止，大量人员等待，大量紧急任务无法处理，影响政府办事效率和形象。
|
|
|
|
（3）例行运维亟须加强。我国政府部分信息系统存在管理松散，制度不严明，执行乏力现象，包括内部信息外泄，个人下载或运行游戏、炒股、聊天、视频软件，甚至非法修改IP地址，卸载杀毒软件，不仅严重违反纪律，更易影响到关键应用的性能质量，因此，日常运维管理亟须加强。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样的处理，直到事务的开始标志。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
|
|
|
|
|
|
|
|
|
|
|
|
|
