工作(服务)方案的先进性、创新性,技术、经济、质量指标等
2.1.工作（服务）方案的先进性、创新性，技术、经济、质量指标等2.1.1.运维标准及工作要求
LX科技提供的技术方案和技术服务将按下文所列标准及工作要求进行。
2.1.2.适用标准
《国家电网公司信息系统运行维护工作规范》
《ITIL 标准 BS ISO/IEC 20000-1&2 :2005》
《GB/T 8567-2006 计算及软件文档编制规范》
《国家电网公司信息化“SG186”工程安全防护总体方案》
《国家电网公司信息系统安全管理办法》
《关于印发《国家电网公司电网检修运维和运营管理成本标准（修订版）》的通知(国家电网财〔2011〕1820号)》
其他国家电网公司发布的业务和信息化相关标准
2.1.2.1.运维工作要求
1)根据项目的实际情况，建立有效的信息系统基础运维组织；
2)根据项目的实际情况，制定有效的信息系统基础运维方案以及运维管理制度；
3)在运维过程中履行工作票和工作许可制度；
4)在运维过程中遵守相关的法律法规；
5)在运维过程中遵守国家电网有限公司信息系统运行维护有关的规章制度与操作规
范；
6)制定有效的信息系统基础运维管理和故障管理制度；
7)制定有效的信息系统基础运维应急方案及其管理制度；
8)定期以书面、会议的形式将信息系统基础运维情况以及运维情况向国网征信有限
公司相关部门进行汇报；
9)如果所运维的信息系统出现重大故障，LX科技将在第一时间以书面或者其他方式
将重大故障以及重大故障的处理情况报告给国网征信有限公司相关部门。
10)在运维过程中所采取的任何措施都是为了信息系统稳定可靠的运行，并确保各应
用系统可靠率达到100%。
2.1.
3.系统运行综合指标
本项目涵盖电费核算驻场运维及技术支持服务等，运维综合指标应能够连续7×24小时不间断工作，系统运行可靠率达到100%。
系统运行可靠率=
%
100
)
60
24
365
1(⨯
⨯
⨯
-
∑故障时长
2.1.4.工作票及工作许可制
2.1.4.1.工作票
1、工作票定义
工作票制度指在本项目涉及的相关系统安全运行管理过程中涉及系统变更（如设备更换及扩容、参数调
整、应用程序变更、数据库变更、数据变更等）操作时，必须按要求认真填写工作票并通过审核后，方可按工作票填写工作内容、工作步骤完成系统维护工作。
工作票分为：第一种工作票和第二种工作票。第一种工作票：不需要中断营销业务的工作，第二种工作票：需要中断营销业务的工作（不论白天或夜间）。
2、内容及填写要求
第一种工作票内容需包含：工作票编号、填写日期、工作任务（包括工作类别、工作目的、工作内容及步骤、操作账号）、注意事项（应急恢复措施、检查项目）、工作单位、工作负责人、工作负责人签名、其他工作人员、计划开工时间、计划完工时间、工作单位意见及负责人签名、监督单位意见及监督人签名、签发单位意见及签发人签名、批准开始结束时间、实际开始结束时间、工作完成情况总结（对于大批量数据变更操作，总结中附上操作LOG 文件以备后审）及工作负责人签名、工作完成情况及确认人签名等。第二种工作票内容需包含：除第一种工作票包含内容外，还应包含：操作步骤、完工检查项目、许可开工时间及工作许可人等。
第一种工作票，每张只能用于一项调整工作的进行，可以涉及多个设备或系统软件。第二种工作票，可以用于多项调整工作的进行，可以涉及多个设备或系统软件。第二种工作票中由于涉及到业务中断，需要在工作票中描述明细的操作步骤及完工后的检查项目，在工作票执行过程中操作步骤不得颠倒顺序，
也不能增减步骤、跳步、隔步，如需改变应重新填写。在操作中每执行完一个操作项后，应在该项前面“执行”栏内划执行勾“√”。
有关操作步骤及完工后的检查项目应参照对应工作的操作规范进行填写，工作票签发人也应以操作规范为依据审查操作步骤及完工后检查项目是否完备。
工作票应用钢笔或圆珠笔填写一式两份，字迹应正确清楚。不得任意涂改。如有个别错、漏字需要修改，应使用规范的符号，字迹应清楚。
用计算机生成或打印的工作票应使用统一的票面格式。由工作票签发人审核无误，手工或电子签名后方可执行。
3、签发与使用
工作票由运维管理中心签发。
工作票一份交工作负责人，一份留存工作票签发人或工作许可人处。工作票应提前交给工作负责人。在工作期间，工作票应始终保留在工作负责人手中。
一张工作票中，工作票签发人和工作许可人不得兼任工作负责人。工作负责人可以填写工作票。
一个工作负责人一次只能发给一张工作票。
4、填写人员要求
工作票签发人应由熟悉人员技术水平、熟悉设备情况、熟悉本规程并具有相关工作经验的运维管理中心人员担任。
工作负责人（监护人）、工作许可人应由有一定工作经验、熟悉本规程、熟悉运维成员的工作能力、熟悉工作范围内的设备情况，并经运维管理中心书面批准的人员担任。
工作票签发人：工作必要性和安全性；工作票上所填完工检查项目是否正确完备；所派工作负责人和工作人员是否适当。
工作负责人（监护人）：正确安全地组织工作；负责检查工作票所列完工检查项目是否正确完备；严格执行工作票所列完工检查项目；
工作许可人：审查工作必要性，同意工作开始进行。
工作成员：明确工作内容、工作流程、安全措施、工作中的危险点，并履行确认手续。
2.1.4.2.工作许可制度
填用第二种工作票进行工作，工作负责人应在得到全部工作许可人的许可后，方可开始工作。
工作许可人应在明确所有使用单位都已通知到位，并监控所有业务操作都已经停止情况
下，方可许可进行工作。
填用第一种工作票进行工作时，不需要履行工作许可手续。
2.1.5.问题和故障管理
2.1.5.1.问题管理
问题管理是指对出现的本项目涉及的相关系统问题进行分析认定、登记建档、处理跟踪、解决核实、归档关闭等全过程管理。问题分为应用软件问题、系统平台软件问题。
应用软件问题分为数据类问题、功能缺陷、需求变更、业务咨询共四类，具体要求如下：
1、应用软件问题提出后应在1个工作日内进行分析认定，全面、准确的记录问题。需明确应用软件问题解决时限，对于重大问题应与厂商签写书面文件备案。
数据类问题应限在3天内解决、业务咨询类问题应限在当天解决。
功能缺陷和需求变更问题，应限在3天内提供解决方案。重大功能缺陷应在2-7天内解决（补丁包方式实现）。
注：需求变更类问题，通过运维项目统一归口受理，但工作量需要单独结算。
2、按问题解决时限要求，对软件开发商的应用软件问题处理进行全过程跟踪和督办。
3、问题解决反馈后，应在1个工作日内组织各方对问题进行解决核实，包括功能测试、变更文档资料核查等。问题核实后，按相关规定要求，做好软件发布更新工作。
4、跟踪观察系统运行情况，确认问题无反复，审查软件开发商提交资料完备后，应在1个工作日内将问题归档。
系统平台软件问题具体要求如下：
1、这两类问题在提出后应马上进行分析认定，并应尽量在次日正常业务开始前解决。
2、问题解决后，应及时分析问题出现的原因，提出整改措施，避免问题的再次发生。
2.1.5.2.故障管理
故障是指由于软件问题和操作失误等原因引起系统无法运行，导致系统中断并造成重大社会影响或者经济损失的问题，分为重大故障和一般故障。重大故障是指由于主机系统、网络系统、数据库、语音交换机等出现问题造成系统瘫痪，引起营销业务全面中断的故障，其他故障为一般故障。
故障的防范与处理原则是：预防为主、及时处理，力争把故障的损失降低到最小程度。
建立健全系统故障的防范对策，定期进行故障防范演习，针对薄弱环节不断改进完善。
系统运行出现故障时，应分析故障现象，结合应急预案制订解决方案，尽快处理。
发生系统故障后，应立即进行故障调查，提出书面调查报告，必要时可组织有关专家鉴定，确定故障的原因和责任，对调查中发现的技术薄弱环节，应积极整改，同时对没有对应应急预案的故障，要求立即补充编制应急预案。
2.1.6.沟通汇报
为确保沟通效率及信息准确，软件开发商和第三方厂商应指定专人与运维管理中心保持联系。联系人需保证通信联络随时畅通。
运维管理中心及开发商，需在规定时间以规定的周报、月报形式通报当前项目运维情况。
各单位在完成重大故障的处理后，应第一时间形成重大故障报告并在运维管理中心内部讨论改进措施。
2.1.7.运维服务流程
LX公司依据国家电网有限公司相关运维制度要求开展运维工作，根据ISO9001质量体系，制定并采用规范的服务流程。当系统用户发现技术问题并需要提供帮助时，将提供顺畅
的渠道和规范化的作业流程进行响应，并在此基础上延伸出更多细化的服务项（具体内容见7.7技术支持服务具体工作及职责），运维服务流程见下述四点。
2.1.7.1.事件管理
所有运维事件统一由事件管理流程管理。处理过程形成运维日志、知识库信息、管理工具信息，同时可跟进实际需要触发“重大事件处理”流程、“问题管理”流程、“变更管理”流程。
控制台：事件统一入口，包括电话、管理工具、邮件、企讯等其它交互方式；
准确性验证：事件接收人对事件进行确认，包括描述是否存在、说明情况是否属实等等；
事件记录：对已经验证的事件进行记录，并形成输出物“运维日志”，此文档作为输出物供其它流程使用；
运维日志：问题提出人、提出单位、业务类、分类、时间、处理人、是否解决、用时等内容，作为输出物供其它流程使用；可以使用其它工具代替，现场根据实际情况自行设定；
事件分析：对事件进行分析，区分咨询类、程序、配置、数据类和需求变更类的事件，对于程序、配置、数据类问题，需要分析出是否为重大事件；分为变更类时，需要整理出“变更请求”供“变更管理”使用。分析过程可以从“知识库”中取得类似问题处理方案；
主要技术经济指标
事件归类：根据事件分析结果流转对应流程；
变更管理：过分析问题，明确是否属于变更，并给出解决方案。
重大问题：由“事件分析”环节确定的是否重大问题在此分支；
问题管理：程序、数据、配置类问题，并且不是重大问题的；
重大事件处理流程：程序、数据、配置类问题，分析后认为是重大事件的；
答复用户：咨询类、重大事件临时或永久性处理完毕确认后答复用户；
知识库：对答复用户的处理办法录入知识库供分析使用；
管理工具：问题管理后统一录入到管理工具中，管理工具节点为“登记”、“确认”、“结束”；
结束：事件管理流程结束。
2.1.7.2.重大事件处理
由“事件管理”调用，处理事件分析后认为是“重大事件”的问题，分析需要各专家参与，进行分级处理，处理完毕后录入返回“事件管理”答复用户。
重大事件：分析为非常紧急的事件都可以归入此流程。
重大事件请求：由“事件管理”触发的请求；
事件分析：现场对重大事件进行分析；
需求协助：判断是否需要业务专家、系统集成专家协助分析；
业务专家分析：业务专家协助分析，由业务专家控制是否需要产品中心专家支持；
系统集成部分析：系统集成专家支持；
事件分级：根据事件分析，对事件的重要程度、优先级进行确定，预先定义的分析为三级，具体见“三级支持”（事件分级处理流程）；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。