项目质量保障方案

项目质量保障 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 目录第1章整体方案 41.1项目需求理解方案 41.1.1项目背景 41.1.2项目概述 41.1.2.1项目现状 4第2章质量保障方案 52.1技术和质量保障总体要求 52.2技术和质量保障总体方案 52.2.1质量保证目标 52.2.2质量保证 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 62.2.3质量保证角色与职责 72.2.4质量保证流程 82.2.5质量保证活动 82.2.5.1项目过程和产品检查 82.2.5.2质量保证工作总结 102.2.6质量保障措施 102.3云平台厂商质量保障方案 102.4技术支持方案 122.4.1技术支持方式要求 122.4.2技术支持方式 132.4.3问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 管理 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 142.4.3.1问题受理和一般问题处理规程 142.4.3.2问题回访与确认规程 172.4.3.3程序问题确认规程 192.4.3.4需求问题确认规程 222.4.3.5紧急问题处理规程 252.4.3.6重大配置变更规程 282.4.3.7系统资源优化规程 312.4.3.8现场支持规程 342.4.3.9应用系统运维培训规程 372.4.3.10问题协同解决规程 402.4.4服务质量保障 422.4.4.1服务标准流程 422.4.4.2信息保密制度 432.4.4.3客户投诉制度 432.4.4.4客户满意度调查 432.5风险及应急方案 442.5.1应急事件分类 442.5.2应急响应流程 452.5.3后期处置 522.6技术支持响应时间方案 522.7故障处理报告 53整体方案项目需求理解方案项目背景项目概述项目现状质量保障方案技术和质量保障总体要求项目建设期为签订合同后到项目最终验收完毕。我公司是质量保障的主要 责任 安全质量包保责任状安全管理目标责任状8安全事故责任追究制幼儿园安全责任状占有损害赔偿请求权 人，实际生产厂商是质量保障的实际提供人。在建设期内，我公司除提供设备的安装、云平台建设、数据层和应用层建设、维护支持、整体解决方案等实际生产厂商质量保障，还须提供不限于以下质量保障服务：在质量保障的实施过程中，如果需要实际生产厂商、云平台厂商等各方面的协助和合作时，由我公司负责组织协调。要求我公司必须能提供及时、高效的服务，确保工程能按设计方案的各项指标要求和实施计划顺利完成，并在工程验收合格后，能长期稳定运行。质量保障的范围包括本项目所涉及的所有软硬件产品。质量保障时间为项目建设期间，项目最终验收完毕之日结束。我公司应在达到以下要求的基础上，根据招标人的实际情况详细制定有针对性的质量保障方案。技术和质量保障总体方案我公司在软件行业的多年积累，沉淀和组织了非常先进的行业标准、项目管理和质量管理体系，在质量保证方面有非常成熟的管理理念和工具，形成了遵循相关规范和可执行的内部体系标准文件，并不断在完善和丰富。我公司派遣质量经理参与项目质量管理工作。质量经理负责对项目的所有活动进行质量监管。质量保证目标本项目质量保证目标为客户满意度达到95%以上。项目建设期为签订合同后到项目最终验收完毕。我公司是质量保障的主要责任人，实际生产厂商是质量保障的实际提供人。在建设期内，我公司除提供设备的安装、云平台建设、数据层和应用层建设、维护支持、整体解决方案等实际生产厂商质量保障，还须提供不限于以下质量保障服务：在质量保障的实施过程中，如果需要实际生产厂商、云平台厂商等各方面的协助和合作时，我负责组织协调。提供及时、高效的服务，确保工程能按设计方案的各项指标要求和实施计划顺利完成，并在工程验收合格后，能长期稳定运行。质量保障的范围包括本项目所涉及的所有软硬件产品。质量保障时间为项目建设期间，项目最终验收完毕之日结束。除满足本项目标书中明确要求的质量保障内容以外，根据招标人的实际需要，我公司还会详细制定有针对性的质量保障方案。质量保证标准我公司凭借多年从事系统集成工作的经验，总结实际工作的切身体会与正反两方面的经验教训，结合实际情况，针对本项目质量保障主要内容如下：1. 依据项目实施的里程碑确定项目的质量控制要点及措施等内容。本项目质量控制监控点包含方案确定、设备验货、设备安装检查、系统互联互通测试、系统性能测试、最终验收测试等；2. 配置管理计划、测试计划、验收计划、用户培训计划确保质量计划实施；3. 阶段评审和联合评审：根据质量保证计划设定重要的质量监控点，并在质量监控点处进行评审。由招标单位和总集成方双方共同决定联合评审；4. 配置管理：确保项目组成员使用最新、一致的设备配置，确保项目组的技术文件受到保护，增加项目的可视性；5. 制定配置管理计划并对配置项进行标识及跟踪，定期给出配置状态报告；6. 文档管理：确保按时生成文档，保护文档这一宝贵财富。按阶段、按角色生成项目技术文档。设立专职的文件资料员保管文件，并对文档进行编号管理；7. 更改控制：确保更改经过严格的程序并已通知到所有的有关人员。更改控制的四个必须步骤：更改申请审批——>更改实施——>更改验证——>更改传递；基本配置的更改必须进行更改控制。质量保证角色与职责 角色 职责 项目经理 （1）负责项目产生的软件和相关文档的质量（2）带动项目成员配合和支持质量保证活动（3）协商确定将要执行的质量保证活动，协助质量保证人员编写质量保证计划（4）评审和批准项目的质量保证计划（5）执行质量保证计划，遵守组织标准（6）跟踪和解决SQA提出的质量问题（7）收集和提供度量数据，以及质量保证检查所需的项目信息 质量经理 （1）协助项目组进行过程裁剪，参与软件项目计划的制订。（2）促进和推动软件项目各阶段的质量检查。（3）通过《项目周报》和《项目月报》、《里程碑报告》等收集项目信息，并进行总结和分析。（4）评审项目执行过程、审核工作产品，将审查结果记录在《过程检查表》和《产品检查表》中，较大偏差记入《问题跟踪表》，跟踪问题直至解决。（5）将在项目级不能解决的不符合问题汇报给项目总监，跟踪问题直至解决。（6）利用《QA工作周报》或《个人工作周总结》汇报QA活动的实际进展（7）参加项目例会。，介绍QA活动的状况，同时沟通问题、风险和变化（8）分析和指导使用度量数据 项目组成员 （1）评审质量保证计划（2）遵循项目标准过程，按照要求产生项目成果。（3）配合质量保证员的检查质量保证流程质量保证活动项目过程和产品检查 检查类别 检查活动 产出物 参考频率 检查人 产品检查 测试环境检查 测试环境检查表 分几次测试查几次 技术负责人 代码检查 代码检查表 不少于两次 技术负责人 上线环境检查 上线环境检查表 分几次上线查几次 技术负责人 测试用例检查 测试用例检查表 元测试用例一次+集成测试用例一次+系统测试用例一次 质量保证员 项目总体计划 项目总体计划检查表 计划时一次+计划变更次数 质量保证员 项目过程裁剪表检查 项目过程裁剪表检查表 过程裁剪时一次+过程裁剪变更次数 质量保证员 需求规格说明书检查 需求规格说明书检查表 编写完成时一次+变更次数 质量保证员 过程检查 产品发布检查 产品发布检查表 分几次上线查几次 质量保证员 系统上线检查 系统上线检查表 分几次上线查几次 质量保证员 决策分析检查 决策分析检查表 决策几次查几次 质量保证员 配置管理检查 配置管理检查表 计划时一次+配置审计次数 质量保证员 评审检查 评审检查表 评审几次查几次 质量保证员 项目过程裁剪检查 项目过程裁剪检查表 过程裁剪时一次+过程裁剪变更次数 质量保证员 项目计划检查 项目计划检查表 计划时一次+计划变更次数 质量保证员 度量分析检查 度量分析检查表 每个里程碑 质量保证员 风险管理检查 风险管理检查表 每个里程碑 质量保证员 里程碑检查 里程碑检查表 每个里程碑 质量保证员 项目监控检查 项目监控检查表 每个里程碑 质量保证员 需求开发检查 需求开发检查表 一次，当项目有迭代的阶段时，按迭代次数 质量保证员 需求管理检查 需求管理检查表 每个里程碑 质量保证员 系统设计检查 系统设计检查表 编写完成时一次+变更次数 质量保证员 系统测试检查 系统测试检查表 一次，当项目有迭代的阶段时，按迭代次数 质量保证员 项目结项检查 项目结项检查表 一次，当项目有迭代的阶段时，按迭代次数 质量保证员质量保证工作总结我公司质量保障人员定期向质量保障经理进行质量保障工作汇报，同时提交质量保障工作周报，质量保障工作月报，质量保障工作里程碑。质量保障经理定期汇总并做出总体工作总结。质量保障措施1.我公司有完善的质量保障服务体系，要求在项目实施单位所在城市设有分公司（或办事处、技术支持服务中心等），能够向设备所在地用户提供统一快捷的质量保障服务。我公司与招标人国家所在地北京是同一城市，能够向设备所在地用户提供统一快捷的质量保障服务。计划投入到本项目的质量保障服务主要人员请参见“技术力量一览表”。2.我公司向招标人提供一站式服务，必须负责全程跟踪服务。3.我公司在招标人事先告知的关键服务期，将增加技术力量投入、加大巡检频率、提升问题解决效率等，提供重点保障服务。4.我公司承诺按照税务系统运维体系的管理规定，利用新技术、不断创新，借鉴国内外先进的运维服务体系，不断调整和优化其运维服务的方式，确保满足税务系统运维管理的要求。5.以上质量保障内容在合同规定的建设期内不另行收费。云平台厂商质量保障方案针对本项目，云平台软件原厂商成立将安排专职人员在质量保障小组负责云平台的质量保障和支持，提供原厂级别7×24（即每周7个工作日，每天24小时，2小时内到达现场。）全天技术支持服务，并根据招标人的需要提供现场支持服务。具体服务时间由招标人需求决定。服务内容包括：1．健康检查云平台工程师定期（频率为每个月，根据用户需求可以增加检查频率）到用户现场，对云平台系统进行例行健康检查，并提交报告，根据健康检查的内容对云平台进行优化。检查的内容应包括但不限于以下内容：·容错检查，检查并分析系统运行日志及跟踪文件，发现并排除云平台及应用系统的错误隐患。·监控云平台性能、云平台运行状态、运行效率、是否存在安全隐患，发现并排除云平台系统错误隐患，提供系统健康检查报告。·检查云平台系统是否需要应用最新的补丁集。·检查云平台空间的使用情况，协助进行云平台空间的规划管理。·检查云平台备份的完整性，备份方式是否合理、备份数据是否可恢复。2．云平台及应用系统性能调优。云平台及应用系统的性能调整一般包括，但不局限于如下内容：·利用工具采集系统运行时的各项监控数据；·分析系统性能瓶颈，确定系统性能现状和性能调整的目标，测试瓶颈改进方案；·分析云平台各方面资源的使用情况；·为客户提供实施问题的解决方案；·现场紧急救援与灾难恢复。云平台宕机、数据块损坏等影响业务不能进行的问题时，只要用户认为必要，云平台厂商服务工程师应在接到通知后2小时内到达用户现场，并提出问题解决方案，在4小时内使应用恢复正常（根据故障级别不同，处理时间可酌情商榷）。·云平台厂商协助招标人完善云平台备份恢复策略，提供完整的备份恢复策略方案，在甲乙双方协商确定并进行实施。·出现灾难性故障时现场协助系统和数据的恢复工作,保障云平台系统的正常运行。·免费提供必要的云平台补丁升级安装服务。3．巡检服务：·在招标人事先告知的关键服务期，必须提供重点保障服务。·每季度一次例行巡检即预防性维护并提供例行巡检报告。·每季度一次健康性检查，全面进行容错检查，检查并分析系统日志及跟踪文件，发现并排除云平台及应用系统的错误隐患，并提供季度巡检报告，招标人签署后方可进行季度付款。·在维保期内如遇到云平台厂商不能解决的问题，招标人有权请其他公司进行解决，产生的费用全部由云平台厂商负担。·每半年并进行一次维护工作总结，并提交报告书；·所有的检查报告云平台厂商均按照招标人要求进行装订，并按规定时间内交送招标人负责人员。4．安装调试过程中接受用户技术人员的技术监督，听取合理意见。5．提供本地化的服务团队，负责解答招标人提出的问题，快速响应客户需求，7×24小时云平台维护及技术支持服务，必要时现场响应并及时解决。技术支持方案技术支持方式要求我公司和实际生产厂商必须向招标人免费提供电话、E-Mail和Internet网站技术支持方式，并应建立提供专门的服务号码和账户，实际生产厂商、云平台厂商必须向用户单位提供7×24小时授权工程师电话响应服务。能够在互联网站上查询、下载相关技术资料、提交问题并获得支持。E-MAIL最迟次日回复。用户需要时必须免费提供现场服务。技术支持方式·服务方式·电话支持·现场支持·网站支持·邮箱支持根据本项目需要，我公司和原厂商将建立专门的专门的服务号码和账户进行针对性的服务，向用户单位提供7×24小时授权工程师电话响应服务。互联网站上查询、下载相关技术资料、提交问题并获得支持。E-MAIL最迟次日回复。用户需要时必须免费提供现场服务。问题管理规范问题受理和一般问题处理规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 事件请求 用户 用户通过热线电话或总局运维网站形式提交事件。 2. 事件调查 现场应用运维岗 接受用户提交的事件，并作初步调查，判断是否为服务范围事件，非受理范围的事件进行退回。 3. 事件记录 现场应用运维岗 受理事件并在呼叫管理系统中对该事件的现象、操作流程、错误信息等进行记录。 《呼叫中心事件记录单》 4. 事件初步处理 现场应用运维 记录问题后，以事件的关键字搜索知识库中是否存在类同事件的知识。 5. 事件分析处理 现场应用运维岗 对事件进行分析、测试、确定事件原因、给出解决方案。 6. 是否解决 用户 用户对呼叫坐席支持岗提供的解决方案是否有效解决问题。若解决则跳转第9步，如无法解决则跳转第7步。 7. 升级事件 项目经理 若无法确认事件原因、恢复事件，则进行事件升级处理，进入高级支持处理。 8. 关联事件和问题 项目经理 将事件升级转入高级支持处理流程，并进行事件和问题关联记录，以便后期问题处理完毕后进行事件的关闭。 《呼叫坐席支持岗转出问题跟踪表》 9. 记录事件解决方案 项目经理 事件处理完毕，并获得用户确认后，将事件解决方案在呼叫管理软件中进行记录。 10. 关闭事件 项目经理 将该事件在呼叫管理系统中置为“关闭”状态。 11. 是否可做新知识 项目经理 根据自身经验、知识库历史记录、事件现象、原因和处理方法判断该事件是否需要作为备选知识进行整理。若需要则进入知识管理流程。 问题回访与确认规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 跟踪问题 项目经理 定时跟踪转出事件，确认其在问题管理流程中的状态。 《现场应用运维岗转出问题跟踪表》 2. 验证问题处理方案 现场应用运维岗 升级事件在高级支持处理流程中已处理完毕的移交到现场应用运维岗，现场应用运维岗验证问题处理方案的正确性。 3. 回访用户 现场应用运维岗 在验明正确性后，回访用户，告知用户该事件的处理方案。 4. 实施方案 用户 在用户环境进行实施，确认实施过程无问题。 5. 确认问题解决 用户 方案实施后，通过前台或后台的方式验证该事件是否已解决，并确保无其他衍生影响。 6. 用户是否满意处理方案 现场应用运维岗 明确用户在实施方案后，事件得到解决并且无任何衍生性问题产生。若方案存在任何问题，则直接将事件重新转回到问题管理流程，继续处理。 7. 更新转出问题跟踪表 项目经理 用户确认满意处理方案后更新《现场应用运维岗转出问题跟踪表》中该问题及事件状态为关闭。 8. 记录事件解决方案 现场应用运维岗 事件处理完毕，并获得用户确认后，将事件解决方案在ITSM中进行记录。 《现场运维事件记录单》 9. 关闭事件 现场应用运维岗 将该事件在ITSM系统中置为“关闭”状态。 程序问题确认规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交待确认程序问题 应用运维岗 问题处理岗将问题处理完毕后，将定位为程序bug导致的问题提交至问题审核岗。 《问题记录单》 2. 问题重现 问题审核汇总岗 问题审核岗接收待确认的程序问题后，在模拟环境将其进行重现。 3. 是否确认为程序问题 问题审核汇总岗 1）问题审核岗在应用开发岗的协助下判断其是否为程序问题。2）对于确认为程序bug的问题填写《应用系统问题转出报告》并提交至问题汇总岗。 《应用系统问题转出报告》 4. 退回问题 问题审核汇总岗 对于确认不是程序bug导致的问题，将其退回至问题处理岗重新定位处理。 5. 接收程序问题 问题审核汇总岗 问题汇总岗从问题审核岗处接收已确认为程序bug的问题。 《应用系统问题转出报告》 6. 是否为紧急问题 问题审核汇总岗 1）问题汇总岗从紧急程度和严重程度上判断是否为紧急问题。2）对于紧急问题，当天将其《应用系统问题转出报告》提交至问题审批转出岗转出。 《应用系统问题转出报告》 7. 按月汇总程序问题并提交转出 问题审核汇总岗 对于非紧急问题，按月汇总《XX月应用系统问题转出报告》提交至问题审批转出岗转出。 《应用系统问题转出报告》 8. 转出程序问题至应用处 应用系统负责人 应用系统负责人对接收到的《应用系统问题转出报告》或《XX月应用系统问题转出报告》进行审批，并转出至应用系统管理处。 《应用系统问题转出报告》 9. 接受转出程序问题 应用处 应用处相关接口人接收转出的程序问题。 10. 问题反馈 应用处 应用处相关接口人对接收的转出程序问题进行处理和反馈。 《应用系统问题转出报告》需求问题确认规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交待确认需求问题 应用运维岗 问题处理岗将问题处理完毕后，将定位为需求变更或新增需求的问题提交至问题审核岗。 《问题记录单》 2. 问题审核及确认 问题审核汇总岗 问题审核岗接收待确认的需求问题后，并联系用户进行需求确认。 3. 是否确认为需求问题 问题审核汇总岗 1）问题审核岗在用户的协助下判断其是否为需求问题。2）对于已确认的需求问题填写《应用系统问题转出报告》并提交至问题汇总岗。 《应用系统问题转出报告》 4. 退回问题 问题审核汇总岗 对于已确认的非需求问题，将其退回至问题处理岗重新定位处理。 5. 接收需求问题 问题审核汇总岗 问题汇总岗从问题审核岗处接收已确认的需求问题。 《应用系统问题转出报告》 6. 是否为紧急问题 问题审核汇总岗 1）问题汇总岗从紧急程度和严重程度上判断是否为紧急问题。2）对于紧急问题，当天将其《应用系统问题转出报告》提交至问题审批转出岗转出。 《应用系统问题转出报告》 7. 按月汇总程序问题并提交转出 问题审核汇总岗 对于非紧急问题，按月汇总《XX月应用系统问题转出报告》提交至问题审批转出岗转出。 《应用系统问题转出报告》 8. 转出需求问题至应用处 应用系统负责人 应用系统负责人对接收到的《应用系统问题转出报告》或《XX月应用系统问题转出报告》进行审批，并转出至应用系统管理处。 《应用系统问题转出报告》 9. 接受转出程序问题 应用处 应用处相关接口人接受转出的需求问题。 10. 问题反馈 应用处 应用处相关接口人对接受的转出需求问题进行反馈。 《应用系统问题转出报告》紧急问题处理规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交紧急问题处理请求 用户 如实对问题现象进行描述，同时按总局呼叫中心相关制度填写相应紧急问题请求表单。 《紧急问题请求单》 2. 问题处理评估 应用运维岗 问题评估岗对问题的处理时长与困难度进行预估。 3. 是否需要调工 应用运维岗 判断问题处理过程是否需要进行调工，如果需要，向应用系统负责人提出申请。 《调工单》 4. 调工 应用系统负责人 应用系统负责人进行外部资源协调申请。 5. 调工审批 处领导 处领导对调工申请进行审批。 6. 派工 项目经理 指派具体问题处理人对问题进行跟踪处理。 《派工单》 7. 系统是否宕机 项目经理 高级支持组长与用户进行沟通，确认系统是否宕机，是否影响关键业务功能。 8. 恢复系统 数据运维岗 问题处理人对系统进行紧急修复，使主要业务功能恢复使用。 9. 解决问题 数据运维岗 问题处理人对问题找出原因，并进行修复。 10. 分析原因及潜在隐患 数据运维岗 问题处理人对问题的现象进行根本原因分析、问题原因定位，并分析潜在原因。 11. 编写解决方案并给出运维建议 数据运维岗 根据问题分析的结果，编写问题解决方案，或给出运维建议。 《问题处理方案》 12. 问题跟踪处理 高数据运维岗 根据解决方案或运维建议，对问题解决情况进行跟踪。 13. 编写问题处理报告 数据运维岗 问题处理人对分析过程、处理步骤、操作日志进行详细记录。 《问题处理服务报告》、《高级技术支持服务返回单》 14. 核实问题解决情况 数据运维岗 问题处理人员对问题处理结果与用户进行相关沟通核实。并调用问题回访与确认流程。 15. 闭单 应用系统负责人 对问题进行关闭。同时问题处理人执行知识管理及维护流程。 重大配置变更规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交变更请求 用户 如实对变更内容进行描述，同时按总局呼叫中心相关制度填写相应表单。 《重大问题请求单》 2. 问题处理评估 应用运维岗 问题评估岗对问题的处理时长与困难度进行预估。 3. 是否需要调工 应用运维岗 判断问题处理过程是否需要进行调工，如果需要，向应用系统负责人提出申请。 4. 调工 应用系统负责人 应用系统负责人进行外部资源协调申请。 《调工单》 5. 调工审批 处领导 处领导对调工申请进行审批。 6. 派工 项目经理 指派具体问题处理人对问题进行跟踪处理。 《派工单》 7. 制定变更实施方案并评审 数据运维 编写相关变更实施方案，将变更的影响面进行透彻分析，给出解决问题的具体实施方案。并对实施方案进行评审工作，评审通过后才能进行实施。 《问题处理方案》 8. 制定变更计划 数据运维岗 问题处理人根据实际情况制定变更实施计划。 9. 变更实施及支持 数据运维岗 按照变更方案进行实施或实施支持 10. 跟踪并编写问题处理服务报告 数据运维岗 将问题的现象、分析过程、问题原因定位，以及处理步骤与日志进行详细的记录。并进行后期跟踪，如问题未能彻底解决，需重新进行问题分析。 《问题处理服务报告》、《高级技术支持服务返回单》 11. 变更验证及监控 数据运维岗 问题处理人员对变更结果与用户进行沟通，核实问题是否全部解决。并调用问题回访与确认流程 12. 闭单 应用系统负责人 对问题进行关闭。同时问题处理人执行知识管理及维护流程。 系统资源优化规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交系统资源优化申请 用户 如实对系统资源优化需求进行描述，同时按总局呼叫中心相关制度填写相应表单。 《重大请求审批单》 2. 问题处理评估 应用运维岗 应用运维岗对问题的处理时长与困难度进行预估。 3. 是否需要调工 应用运维岗 判断问题处理过程是否需要进行调工，如果需要，向应用系统负责人提出申请。 4. 调工 应用系统负责人 应用系统负责人进行外部资源协调申请。 《调工单》 5. 调工审批 处领导 处领导对调工申请进行审批。 6. 派工 项目经理 指派具体问题处理人对问题进行跟踪处理。 《派工单》 7. 制定资源优化方案并评审 数据运维岗 编写相关资源优化方案，将资源优化的影响面进行透彻分析，给出解决问题的具体实施方案。并对实施方案进行评审工作，评审通过后才能进行实施。 《问题处理方案》 8. 资源优化方案测试 数据运维岗 问题处理人对资源优化方案在测试环境下进行模拟测试。 9. 资源优化实施及支持 数据运维岗 按照资源优化实施方案进行实施或实施支持 10. 跟踪并编写问题处理服务报告 数据运维岗 将问题的现象、分析过程、问题原因定位，以及处理步骤与日志进行详细的记录。并进行后期跟踪，如问题未能彻底解决，需重新进行问题分析。 《问题处理服务报告》、《高级技术支持服务返回单》 11. 资源优化情况验证及监控 数据运维岗 问题处理人员对资源优化结果与用户进行沟通，核实问题是否全部解决。并调用问题回访与确认流程 12. 闭单 应用系统负责人 对问题进行关闭。同时问题处理人执行知识管理及维护流程。 现场支持规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交申请 用户 如实对现场支持需求进行描述，同时按运维相关制度填写相应表单。 《问题记录单》 2. 问题处理评估 应用运维岗 应用运维岗对问题的处理时长与困难度进行预估。 3. 是否需要调工 应用运维岗 判断问题处理过程是否需要进行调工，如果需要，向应用系统负责人提出申请。 4. 调工 应用系统负责人 应用系统负责人进行外部资源协调申请。 《调工单》 5. 调工审批 处领导 处领导对调工申请进行审批。 6. 派工 项目经理 指派具体问题处理人对问题进行跟踪处理。 《派工单》 7. 与用户沟通并进行现场时间计划 数据运维岗 问题处理人与用户进行沟通，确定到达现场时间，以及所需资源情况。 8. 现场情况分析 数据运维岗 现场对问题进行深入分析，排查问题原因。 9. 编写问题解决方案（可选） 数据运维岗 编写相关问题解决方案，将问题影响进行透彻分析，给出解决问题的具体实施方案。并与用户一起对实施方案进行评审工作，评审通过后才能进行实施。 《问题处理方案》 10. 现场问题处理及实施 数据运维岗 对问题分析的结果给出解决方法，并进行问题解决方法实施。 11. 编写现场实施确认单及问题处理服务报告 数据运维岗 将问题的现象、分析过程、问题原因定位，以及处理步骤与日志进行详细的记录。并进行后期跟踪，如问题未能彻底解决，需重新进行问题分析。 《问题处理服务报告》，《高级技术支持服务返回单》 12. 问题实施确认 用户 对问题处理结果进行确认，确认是否彻底解决问题。确认全部解决后填写现场支持确认单，并盖章。 《现场支持确认单》 13. 监控并核实问题解决情况 数据运维岗 问题处理人员对问题解决结果与用户进行沟通，核实问题是否全部解决。并调用问题回访与确认流程。 14. 闭单 应用系统负责人 对问题进行关闭。同时问题处理人执行知识管理及维护流程。 应用系统运维培训规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交培训请求 用户 用户提交培训需求由应用运维岗受理并提交项目经理审批。 《重大请求单》《问题记录单》 2. 受理 应用运维岗 对提交的培训请求进行受理。 3. 审批 应用系统负责人 对提交的培训请求进行最终的审批。 4. 制定培训计划 项目经理 对培训请求进行分析，确定培训需求的目的、范围、内容、规模、时间等主要信息，根据需求和当前岗位工作安排制定有效的培训计划。 《培训课程表》、《培训签到表》、《培训反馈表》 5. 编写培训材料 项目经理 针对培训需求的内容、范围编写培训教材。 《培训教材》 6. 编写培训幻灯片 项目经理 针对培训需求的内容、范围编写培训课件。 《培训课件》 7. 设计练习题 项目经理 针对培训需求的内容、范围编写培训练习题。 《培训练习题》 8. 出具考题 项目经理 针对培训需求的内容、范围编写培训考题。 《培训考题》 9. 下发培训通知 用户 运维管理岗或省级运维发布培训通知。 10. 准备培训环境 项目经理 在培训开始前准备好培训的软、硬件环境。 11. 培训实施 项目经理 按培训的计划实施培训。 12. 培训考试 用户 培训完成后就培训内容掌握情况进行考核。 13. 下发培训调查表 项目经理 对学员进行满意度调查，要求培训满意度不得低于93％。 14. 填写培训调查表 用户 学员对本次培训情况填写培训调查表。 15. 批改考试卷 项目经理 对学员的考试卷进行批改，以便了解学员对本次培训的实际掌握情况。 16. 总结培训 项目经理 对本次培训的总体情况进行总结。 问题协同解决规程活动说明： 序号 活动名称 涉及岗位 活动说明 提交物 1. 提交请求 用户 如实对问题现象进行描述，同时按运维相关制度填写相应表单。 《问题工单》 2. 问题处理 应用运维岗 按运维规范分析问题，若涉及其他系统问题，需要调工则告知组长。 3. 是否需要调工 项目经理 组长对问题进行判断是否需要调工，若需要则向应用系统负责人申请。 4. 调工 应用系统负责人 应用系统负责人进行外部资源协调申请。 《调工单》 5. 调工审批 处领导 处领导对调工申请进行审批。 6. 派工 项目经理 指派具体问题处理人对问题进行跟踪处理。 《派工单》 7. 协同处理 应用运维岗 首先接受到问题的系统处理人协调其他涉及系统的对应问题处理人共同对问题进行响应，与用户进行问题沟通，情况了解等工作。并对问题现象共同讨论、深入分析过程。 8. 共同出具方案 应用运维岗 复杂问题需撰写相关问题处理方案，将问题透彻分析，共同给出解决问题的具体实施方案。 《问题处理方案》 9. 方案测试 应用运维岗 根据问题实际情况或者问题处理方案在模拟环境进行测试。 10. 方案审核 应用系统负责人 对出具的方案进行最终审核。 11. 方案实施 应用运维岗 根据问题实际情况或者问题处理方案，对问题进行处理的具体实施过程。 12. 编写报告 应用运维岗 问题处理完成后，要进行后期跟踪，如问题未能彻底解决，需重新进行问题分析。并将问题的现象、分析过程、问题原因定位，以及处理步骤与日志进行详细的记录。 《问题处理服务报告》、《高级技术支持服务返回单》 13. 问题回访 应用运维岗 问题处理人员对问题处理结果与用户进行相关沟通核实。并调用问题回访与确认流程 14. 闭单 应用系统负责人 对问题进行关闭。同时问题处理人执行知识管理及维护流程。 服务质量保障服务标准流程公司关于技术支持与服务的ISO9001程序文件规定了支持服务（系统准备、安装、调试、培训、维护、升级）的质量控制方法和要求。我公司对于具体的项目实行项目经理负责制，在项目支持服务阶段为本项目专门设置了一个支持服务与技术支持经理。项目进入支持服务阶段，我公司将与客户方签订服务协议，明确项目服务内容和服务标准。我公司指定了专人值守热线服务电话，以保证及时与客户沟通，以最快的速度解决用户所遇到的问题。在支持服务期内为客户方提供7x24小时不间断的技术支持响应，对电话中无法解决的问题，根据客户需要提供现场技术支持并提出解决方案。我公司还会定期与客户沟通，主动给客户打电话，了解系统的运行情况。信息保密制度1、技术支持人员保证严格遵守客户方的保密要求，并签订保密协议。2、技术支持人员保证对于客户方提供的资料（包括业务资料、技术资料、相关数据等），不得以任何形式向第三方传播。3、技术支持人员保证不向外（指用户规定范围以外）泄漏任何与本项目相关的保密技术资料。4、保密期限不受本项目期限的限制，在本项目履行完毕后，技术支持人员继续承担保密义务。客户投诉制度1、客户投诉受理内容各用户单位若对我公司技术支持人员的工作态度、响应时间和服务结果表示不满或存在争执，可以向我方进行投诉，我方相关部门会迅速调查，尽快反馈解决结果。2、客户投诉的受理方式客户通过E-mail或电话向我方投诉热线或信箱进行投诉，我方将尽快受理调查该投诉，并在第一时间反馈调查处理结果。客户满意度调查根据ISO9001质量管理体系的要求，客户的满意是我们的目标。通过客户满意度调查及时了解客户对我们工作效率，服务质量的评价，进一步提高我们的工作效率，改善服务质量。同时也是对技术支持与服务人员技术水平以及工作态度客观评价的一种手段。风险及应急方案应急事件分类一、应急分类根据信息安全事件的发生原因、性质和机理，信息安全事件主要分为以下二类:（1）可控信息安全事件：指相关信息系统内部可以解决或有能力解决的信息安全事件，如信息系统因计算机病毒感染、计算机软硬件故障、人为误操作、非法入侵等导致业务中断、系统宕机、内部电力中断等情况。（2）不可控信息安全事件：指相关信息系统内部无法解决的信息安全事件，如因爆炸、火灾、雷击、地震、台风等外力因素导致信息系统损毁、外部电力中断，造成业务中断、系统宕机等情况。可控网络与信息安全事件一般包括：计算机病毒感染、计算机软硬件故障、人为误操作、非法入侵等导致业务中断、电力中断等。二、故障分级针对信息安全的特点，我们定义了四级故障事件，将按照以下的标准对故障进行分级：一级故障：现有的系统宕机，或遭到严重攻击、入侵冷战等行为，使业务系统无法正常提供服务、信息系统的正常业务运作产生重大影响，或严重影响到业务提供服务的服务质量的，造成大范围不良影响的重大事件。包括重大网络事件、应用事件等安全事件。二级故障：现有系统的操作性能严重降低，或由于网络性能失常或安全事件严重影响信息系统业务运作，持续小于4小时，造成一定范围的不良影响的事件。持续时间超过4小时则升级到一级事件。包括严重网络事件、严重应用事件等安全事件。三级故障：系统的操作性能受损，例如病毒在小范围内发作，或部分系统业务受到影响，但大部分业务运作仍可正常工作，持续时间小于4小时，造成较小范围不良影响的事件。持续时间超过4小时则升级到二级事件。四级故障：在服务器、存储设备、安全设备等的功能、安装、配置或日志分析方面需要信息咨询或技术支持。本级故障事件对数据中心的业务运作几乎无影响，或根本没有影响。一般定义，一级故障事件和二级故障事件属于重大应急事件，需要事件发现人立即向事件所属应用系统应急响应小组组长报告，应用系统应急响应小组组长向国家相关工作人员报告。三级故障事件由日常运维服务处理，但需要向应急响应小组组长报告，应急响应小重大组组长视情况报国家相关工作人员；四级故障事件属于日常运维服务范畴。应急响应流程成立应急事件处理小组主要职责：应用系统应急响应工作的总体指挥和组织领导；应用系统应急响应工作中重大事项的决策；应用系统信息安全目标和方针制定，应急预案的审批与发布；应用系统相关机构的沟通、协调负责向领导部门汇报重大事件处理情况应急事件的发现和上报；负责应急响应技术规划和准备工作；负责应急技术资料的整理和维护，包括系统和设备的型号及配置等详细信息、主要设备厂商信息、设备使用人员的详细信息等；负责相关系统的监控、维护、预警以及风险评估和安全加固等工作；负责组织对事件的定级/分类分析；负责组织技术力量对事件进行处理；应急事件的故障点追查以及备案等。一、确认事件等级为更好的针对应急事件在不同严重程度进行高效处理，在执行应急体系时，需要对应急事件进行分级，从而保证严重性高的应急事件能得到更快、更有效的处理。（一）应急事件确认1、接到各职能部门、值班人员汇报的紧急事件后，由应急响应小组人员初步判断应急事件类型。当无法确认时，立即联系信息安全应急领导小组和国家相关人员，由其负责进行协调、确认。2、事件类型确认后，即确定系统所属应急响应小组组长为应急事件响应负责人，带领应急响应小组成员展开工作。（二）事件等级确认事件所属系统应急响应小组组长立即组织相关人员分析事件的具体现象，确定是否属于应急事件。如果不属于应急事件，通报相关单位另做处理，事件关闭。如果为应急事件，则确定应急事件的等级，然后根据等级确定随后的处理步骤，确定需要调动那些资源，是否需要联系相关机构、合作伙伴等，并确定此事件的具体处理成员。（三）应急事件通告事件所属系统应急响应小组组长在确认事件等级后，向相关人员发送事件通告。一级故障事件和二级故障事件属于应急事件，需要事件发现人立即向应急响应小组组长报告，应急响应小组组长向信息安全应急领导小组和国家相关人员报告。三级故障事件由日常运维服务处理，但需要向应急响应小组组长报告，应急响应小组组长视情况报信息安全应急领导小组和国家相关人员；四级故障事件属于日常运维服务范畴。事件负责人填写《应急事件通报表》，发送至事件相关部门的人员等。应急事件通报表 系统名称 事件发现人 联系电话 技术支持性质 □现场□远程□其他 发现时间 年月日时分 事件描述 技术支持需求描述 备注 工程师签字 日期/时间 二、不同事件的处理方式（一）一级应急事件响应要求1、响应时间要求一级应急事件需要立即响应，高级工程师应在30分钟内做出响应，并按照紧急问题处理流程处理该问题。对灾难性问题，应及时进入问题分析处理阶段。2、参与人员一级应急事件响应，事件所属系统应急响应小组组长组建事件处理小组，同时视情况协调其他与事件相关的应急响应小组成员的参与。3、汇报层次一级应急事件应首先汇报给事件所属系统应急响应小组组长，事件所属系统应急响应小组组长需要在第一时间汇报给信息安全应急领导小组和国家相关人员，整个事件响应由信息安全应急领导小组和国家相关人员统一协调。4、事件处理执行业务系统恢复程序，启动备份重要业务数据，保证业务系统恢复正常；对业务重要系统实行警戒状态的访问控制授权机制；追查事件原因，并尽量挽救系统损失；（二）二级应急事件响应要求1、响应时间要求二级应急事件需要立即响应，高级工程师应在30分钟内做出响应，并按照紧急问题处理流程处理该问题。2、参与人员二级应急事件响应，事件所属系统应急响应小组组长立即组织相关应急响应小组成员进行应急处理，同时视情况协调其他与事件相关的应急响应小组成员的参与。3、汇报层次二级应急事件应首先汇报给事件所属系统应急响应小组组长，事件所属系统应急响应小组组长需要在第一时间汇报给信息安全应急领导小组和国家相关人员，整个事件响应由信息安全应急领导小组和国家相关人员统一协调。4、事件处理启动备份重要业务数据，保证业务系统恢复正常；对业务重要系统实行强化访问控制授权机制；追查事件原因，并尽量挽救系统损失；5、事件升级二级应急事件未在规定时间内解决，或者该事件多次发生，并有可能造成对业务的更大的不利影响时，二级应急事件将升级为一级应急事件，启动一级应急事件响应方案和处理流程。（三）三级应急事件响应要求1、响应时间要求三级应急事件需要及时响应，在半天内给出解决方案；对于重大问题，在２小时内给予及时响应。2、参与人员三级应急事件响应，事件所属系统应急响应小组组长立即组织相关应急响应小组成员进行应急处理，同时视情况协调其他与事件相关的应急响应小组成员的参与。3、汇报层次三级应急事件应首先汇报给事件所属系统应急响应小组组长，事件所属系统应急响应小组组长需要在第一时间汇报给信息安全应急领导小组和国家相关人员，整个事件响应由信息安全应急领导小组和国家相关人员统一协调。4、事件处理事件处理小组需要与用户充分沟通，快速进行事件处理。启动备份业务数据，保证业务系统恢复正常；追查事件原因，并尽量挽救系统损失；5、事件升级三级应急事件未在规定时间内解决，或者该事件多次发生，并有可能造成对业务的更大的不利影响时，三级应急事件将升级为二级应急事件，启动二级应急事件响应方案和处理流程。（四）四级应急事件响应要求四级故障事件属于日常运维服务范畴，事件处理应由事件所属系统应急响应小组内部处理，或由应急响应小组组织向相关技术人员咨询，并追查事件原因。在半天内给出解决方案；对于重大问题，在２小时内给予及时响应。三、应急事件（处理）流程在发生应急事故时，相关人员将立即处理并记录。三级以上事件，必须尽快联系所属系统应急响应小组组长，并且立刻联系故障涉及系统所属应急响应小组所有成员，组织技术力量按照下面步骤进行处理：1、识别事件·确定是否是应急事件及应急事件的等级；·在短时间内迅速组成应急事件处理小组去负责此事件；·注意保护可追查的线索；2、缩小事件的影响范围·组织队伍立即获得事件相关信息；·备份系统；·根除事件；·确定系统继续运行的风险如何，决定是否关闭系统；·相关应急事件处理工作人员与相关工作人员保持联系、协商；3、根除事件影响·确定事件的起因和症状；·增强防御；·进行漏洞分析；·删除事件的源头；4、恢复系统·决定什么时候恢复操作；·修复系统使系统正常；·监控系统。5、生成报告·拟定一份事件记录和跟踪报告·总结经验和教训6、系统防护在本次故障排除后，立即着手制定安全措施，并根据故障报告和故障排除方案，制定故障解决方案。报信息安全应急领导小组和国家相关人员审批，得到通过后，立即着手实施，防止同类故障再次发生。四、应急事件应急响应总结（总结汇报表）事件处理完毕，系统恢复正常运行后，要对整个事件进行分析，总结经验教训，并形成一个应急事件应急响应总结报告。报告中应详细记录应急响应事件的起因、处理过程、建议改进的应急方案，估计造成的损失等，备案做为内部参考，并逐步形成知识库，指导以后类似应急事件的响应。应急事件总结汇报表 系统名称 事件发现人 事件处理人 技术支持性质 □现场□远程□其他 发现时间 年月日时分 事件描述 事件处理情况 遗留问题 报告人 日期/时间 在报告中要求详细描述整个事件的经过，记录紧急响应事件的起因、处理过程等，说明所做的每一步工作，并把原始事件数据以附件方式附在报告后面。报告由应急响应小组交给信息安全应急领导小组和国家相关人员作为知识库的组成。五、后续补救措施1、对于系统缺陷导致的故障和应急事件，需要对系统提出改进措施：2、根据事件的处理情况，事件负责人整理产品改进建议，并根据事件的紧急情况，提出系统改进时间进度要求。3、根据系统修改方案以及进度要求，修改系统错误或缺陷，发布相应的升级包或补丁包。后期处置一、调查评估相关部门对信息安全事件的起因、性质、影响、责任、经验教训和恢复重建等问题进行调查和评估。1、责任确定。应急处置工作结束后，应当分析产生该次事件的原因，对事件进行调查，确定责任人。2、事件备案与归档。应急处置工作结束后，实施事件处置的过程和结果须备案。3、预案维护。应急处置工作结束后，需根据应急过程中暴露的问题和调查评估的结果，对预案进行相应的修改和维护。二、文档管理对于整个应急事件响应处理的所有过程，都需要有详细的文档记录，部分文档需要经过信息安全应急领导小组和国家相关人员的签字和审批。涉及到的应急事件应急记录文档包括以下内容，可根据应急事件类型选择生成部分文档：《应急事件通报》、《故障分析报告》、《故障解决报告》、《应急响应分析报告》。所有文档记录标明具体的日期和人员，并有明确的文档编号。所有文档按照事件和日期统一归档保存。技术支持响应时间方案根据本项目的要求，我公司和原厂商将加大技术服务的人员投入力度，在各地建设专门的技术支持团队、加强培训、知识库建设以保证用户能够得到及时的技术支持。电话服务请求的响应时间应少于半小时，对于由于坐席繁忙需要用户长时间等待的服务请求，电话将转接至技术支持经理或者其他高级支持人员，受理的所有请求实行“一站式”服务，即一点受理后负责全程跟踪服务。对于以各种理由让用户再找其他岗位人员处理的情况，采取处罚措施。硬件设备实际生产厂商、云平台厂商建立针对此项目的支持团队，在2小时内对使用单位所提出的维修要求作出实质性响应，满足下表对使用单位的故障报修的要求： 序号 故障级别（严重程度） 响应时间 到达现场时间 故障解决时间 1 系统瘫痪，业务系统不能运转的 报修后2小时内 报修后2小时内 报修后4小时内 2 系统部分出现故障，业务系统仍能运转 报修后2小时内 报修后4小时内 报修后8小时内 3 初步诊断为系统问题，只造成业务系统性能下降 报修后2小时内 报修后8小时内 报修后24小时内在解决故障时，保护好数据，作好故障恢复的文档，力争恢复到故障点前的业务状态。对于关系重大的故障，需要经过甲乙方相关负责人员同意后进行处理，包括但不限于涉及数据库操作等重大故障。故障处理报告针对系统出现的故障，我公司在故障问题解决后24小时内，提交问题处理报告，突出说明如下几点内容：·问题种类，根据甲、乙方约定的故障分类进行确定。·问题原因，对问题产生的原因进行深入分析，以发现故障产生的根源。·问题解决中使用的方法，需要提交根除问题的建议或方法，避免故障重现。·造成的损失等情况，客观给出造成的损失。1����标题�职能�阶段������1、事件请求����标题�职能�阶段�����职能�阶段������标题�职能�阶段����知识管理及维护流程�程序问题确认流程�需求问题确认流程�数据维护流程图�职能�阶段������标题�职能�阶段����知识管理及维护流程�程序问题确认流程�需求问题确认流程�数据维护流程图����标题�职能�阶段����紧急问题处理流程图�职能�阶段������标题�职能�阶段����重大配置变更流程图�系统资源优化流程图�系统迁移流程图�现场支持流程图�数据维护流程图�紧急问题处理流程图�职能�阶段������标题�职能�阶段����重大配置变更流程图�系统资源优化流程图�系统迁移流程图�现场支持流程图�数据维护流程图�紧急问题处理流程图�职能�阶段������标题�职能�阶段����重大配置变更流程图�系统资源优化流程图�系统迁移流程图�现场支持流程图�数据维护流程图�紧急问题处理流程图���标题�职能�阶段����������标题�职能�阶段��问题受理阶段问题分析阶段问题处理阶段问题关闭阶段1、提请请求�