智能化数据中心运维项目-实施与售后方案

1、 智能化数据中心运维项目实施与售后方案目 录 TOC o 1-3 h z u HYPERLINK l _Toc528136487 1项目概述 PAGEREF _Toc528136487 h 3 HYPERLINK l _Toc528136488 1.1现状分析 PAGEREF _Toc528136488 h 3 HYPERLINK l _Toc528136489 1.2需求分析 PAGEREF _Toc528136489 h 3 HYPERLINK l _Toc528136490 2总体方案 PAGEREF _Toc528136490 h 6 HYPERLINK l _Toc528136491

2、 2.1平台逻辑架构 PAGEREF _Toc528136491 h 6 HYPERLINK l _Toc528136492 2.2平台部署架构 PAGEREF _Toc528136492 h 8 HYPERLINK l _Toc528136493 3项目实施方案 PAGEREF _Toc528136493 h 9 HYPERLINK l _Toc528136494 3.1项目实施方法 PAGEREF _Toc528136494 h 9 HYPERLINK l _Toc528136495 3.2项目人员安排 PAGEREF _Toc528136495 h 10 HYPERLINK l _Toc

3、528136496 3.2.1项目组织架构图 PAGEREF _Toc528136496 h 11 HYPERLINK l _Toc528136497 3.2.2项目成员职责说明 PAGEREF _Toc528136497 h 12 HYPERLINK l _Toc528136498 3.3项目实施内容 PAGEREF _Toc528136498 h 13 HYPERLINK l _Toc528136499 3.4项目实施计划 PAGEREF _Toc528136499 h 16 HYPERLINK l _Toc528136500 4项目管理 PAGEREF _Toc528136500 h 1

4、8 HYPERLINK l _Toc528136501 4.1工作方式 PAGEREF _Toc528136501 h 18 HYPERLINK l _Toc528136502 4.2项目管理 PAGEREF _Toc528136502 h 18 HYPERLINK l _Toc528136503 4.2.1范围管理 PAGEREF _Toc528136503 h 18 HYPERLINK l _Toc528136504 4.2.2沟通管理 PAGEREF _Toc528136504 h 19 HYPERLINK l _Toc528136505 4.2.3问题管理 PAGEREF _Toc52

5、8136505 h 20 HYPERLINK l _Toc528136506 4.2.4质量管理 PAGEREF _Toc528136506 h 23 HYPERLINK l _Toc528136507 4.2.5变更管理 PAGEREF _Toc528136507 h 23 HYPERLINK l _Toc528136508 4.3风险管理 PAGEREF _Toc528136508 h 24 HYPERLINK l _Toc528136509 4.3.1风险管理办法 PAGEREF _Toc528136509 h 25 HYPERLINK l _Toc528136510 4.3.2项目风险

6、 PAGEREF _Toc528136510 h 28 HYPERLINK l _Toc528136511 4.4项目验收计划 PAGEREF _Toc528136511 h 32 HYPERLINK l _Toc528136512 4.4.1验收测试计划 PAGEREF _Toc528136512 h 32 HYPERLINK l _Toc528136513 4.4.2问题严重程度定义 PAGEREF _Toc528136513 h 33 HYPERLINK l _Toc528136514 4.4.3验收 PAGEREF _Toc528136514 h 34 HYPERLINK l _Toc

7、528136515 4.5项目文档资料 PAGEREF _Toc528136515 h 34 HYPERLINK l _Toc528136516 4.5.1项目成果文档清单 PAGEREF _Toc528136516 h 34 HYPERLINK l _Toc528136517 4.5.2项目管理资料清单 PAGEREF _Toc528136517 h 35 HYPERLINK l _Toc528136518 5培训计划 PAGEREF _Toc528136518 h 37 HYPERLINK l _Toc528136519 5.1培训方式 PAGEREF _Toc528136519 h 37

8、 HYPERLINK l _Toc528136520 5.2课程列表 PAGEREF _Toc528136520 h 38 HYPERLINK l _Toc528136521 6售后服务 PAGEREF _Toc528136521 h 40 HYPERLINK l _Toc528136522 6.1技术支持及服务体系 PAGEREF _Toc528136522 h 40 HYPERLINK l _Toc528136523 6.1.1服务质量 PAGEREF _Toc528136523 h 40 HYPERLINK l _Toc528136524 6.1.2补丁更新服务 PAGEREF _Toc

9、528136524 h 41 HYPERLINK l _Toc528136525 6.1.3损坏产品介质的更换 PAGEREF _Toc528136525 h 41 HYPERLINK l _Toc528136526 6.1.4快速响应现场服务 PAGEREF _Toc528136526 h 41 HYPERLINK l _Toc528136527 6.1.5热线服务 PAGEREF _Toc528136527 h 41 HYPERLINK l _Toc528136528 6.1.6Internet服务 PAGEREF _Toc528136528 h 42 HYPERLINK l _Toc52

10、8136529 6.1.7服务响应时间 PAGEREF _Toc528136529 h 42 HYPERLINK l _Toc528136530 6.2对服务承诺 PAGEREF _Toc528136530 h 43 HYPERLINK l _Toc528136531 6.2.1热线服务 PAGEREF _Toc528136531 h 44 HYPERLINK l _Toc528136532 6.2.2Internet服务 PAGEREF _Toc528136532 h 44 HYPERLINK l _Toc528136533 6.2.3补丁更新服务 PAGEREF _Toc528136533

11、 h 45 HYPERLINK l _Toc528136534 6.2.4现场服务 PAGEREF _Toc528136534 h 45 HYPERLINK l _Toc528136535 6.2.5定期巡检服务 PAGEREF _Toc528136535 h 45 HYPERLINK l _Toc528136536 6.2.6服务响应时间 PAGEREF _Toc528136536 h 45项目概述现状分析运维平台经过多年建设，形成了较为完整的监管控体系架构，在各管理领域使用了多种专业工具，此种方式优势在于管理平台专业性强，实现对各领域的深度管控。但造成了运维平台结构复杂，异构性强，数据分散

12、，指标不统一，不易管理，无效告警过多，同时当前系统使运维人员无法直观有效的了解整体业务、应用、网络、系统等整体运行的状态，缺少有效的跨领域的故障诊断手段，在判断故障根源时耗费时间较高，另外监控作为整体运维管理平台的一部分，无法与流程、自动化等系统进行有效集成。具体问题表现在以下几个方面：监控范围有限、管理分散缺乏事件关联分析、故障根源定位速度慢缺少全面直观的运维管理视图缺乏有效的统一资源及配置管理缺乏统一的运维管理平台，难以适应主动管理、集中管理要求需求分析针对需求和运维现状，本项目旨在实现一体化的IT运维管理，建立整体的运维平台体系，从而实现从系统、应用到业务的端到端运行状态的全面管控，实现

13、跨技术领域的运维数据处理和关联分析，提高故障定位的效率。通过此次项目建立统一的运维平台体系，综合反映整个业务系统运行状况，有效的管理内部的IT资源运行情况、性能状况等，使各级管理人员和技术人员能迅速了解系统架构及运行状态，聚焦所关心的问题，满足不同层次人员对系统的运维管理需求。实现面向业务服务的IT管理，提高整体的IT运维效率和水平。具体目标：有效整合分散的运维数据、资源和信息当前运维数据包括告警数据，性能数据和状态数据。资料信息包括各种运维文档。项目将通过技术手段将告警数据、性能数据、状态数据以管理对象为核心，进行有效整合，实现统一的数据管理。同时，建立资料信息搜索机制，提升各类运维信息的使

14、用效率和运维价值。统一资源配置管理资源管理对使用的专业工具提供的运维数据及资源配置信息，进行统一管理。并提供方便灵活的配置方式以便与运维平台数据结构进行有效衔接。同时，实现配置数据与可视化运维场景的无缝整合。围绕运维场景建立管理模型，达到快速定位故障，提升故障诊断效率的目的利用统一的监控指标管理与管理，实现面向不同的被监控领域的事件的汇总、重复事件压缩、事件的相关性处理；通过可视化系统实现统一的业务、应用和系统架构状况的实时监控和展现；输出故障关系图提高定位故障的效率使生产支持更快地做出反应，解决故障；建立端到端运维全景视图，对业务、应用、系统、基础设施等各层面进行统一管理，整合运维数据为了更

15、加直观的展示运维整体情况，此项目将采用业界领先的可视化技术，构建基于配置和资产信息的一体化立体运维模型，在可视化场景中将业务、应用、中间件、数据库、服务器、存储和网络，直到硬件所部属的位置进行统一展现，帮助运维人员了解整体运行状态。并通过灵活的接口与监控系统进行有效整合，集成告警和性能信息，联动自动化运维工具，形成闭环的运维处理过程。统一架构，实现运维视图的自助生产和共享根据需求分析，当前运维系统缺少有效地管理工具，统一管理系统架构和各类管理视图，无法使运维数据信息进行有效共享，同时，架构视图与实际运维数据脱节，不能反映真实的系统环境，更无法通过关系自动生成管理视图。因此，统一运维平台将搭建自

16、助式的架构管理平台，实现运维视图的自由创建、分享和积累，管理内容包括各类运维关系图，配置数据和相关系统资料。通过此项目中的统一运维门户达到关系图在线编辑，信息快速发布并进行高效检索。将整个运行中心的数据进行有效发布与交互。在发生故障时为运维人员提供大量的有价值的数据进行分析，有效预防故障产生，加快解决故障效率。基于策略的跨领域故障处理策略，提升故障处理能力通过分析告警事件所关联的场景，利用运维数据处理平台提供的事件处理引擎，定制告警关联规则，实现对于告警的关联分析功能，并提供友好的交互界面是策略制定简单化，透明化。减少无效告警的发生。同时，通过告警分析规则的积累，构建起可扩充的故障分析库和应急

17、处理预案。总体方案平台逻辑架构一体化运维平台，包含数据接口、运维数据处理、运维数据仓库、外部接口和统一运维门户5部分。其中：数据接口平台：作为统一运维管理平台的主要数据入口，对接运行环境中孤立的管理工具，整合分散的运维数据，包括配置数据、性能数据、报警数据、流程数据以及业务数据等其他相关的IT管理数据。运维数据处理平台：负责运维数据的实时分析处理，主要包括运维数据集成处理、监控指标分析处理以及核心的统一事件处理引擎，将多维度的运维数据通过管理对象统一管理，并根据不同维度数据的特征，提供专业的处理引擎，并将处理结果存储在运维数据仓库中。运维数据仓库：存储了IT运维中涉及的对象/关系、监控指标、报

18、警事件、流程工单、用户以及运维场景等多维度的运维信息，并通过统一的管理对象标识，实现逻辑融合。针对运维数据不同的类型和运算特征，选择业界领先的数据库技术组合，提供稳定、高性能、高扩展性的运维数据仓库，并通过接口封装提供标准的数据服务。外部接口平台：处理与外部系统的交互，包括自动化工具调用、消息通知、流程工单同步等主要工具接口，提供统一的管理功能，控制调用过程，记录调用结果。统一运维管理门户：为系统用户和外部系统提供统一的交互平台，用户可以通过该门户，统一访问运维信息，调用运维管理接口，并创建和发布适用于日常运维的可视化管理场景，基于运维场景，执行日常所需的数据分析和运维管理任务。统一运维门户基

19、于业界领先的图形专利技术，并提供了自助式的管理场景创建、发布、订阅等可视化管理功能，赋予用户更灵活的运维管理能力，显著提升管理工具价值和运维效率，并促进专家经验的积累，和整体运维管理能力建设。平台部署架构针对一体化运维平台在日常工作中的业务关键性，本项目在物理架构设计中考虑系统高可用性、可扩展性和性能需求，具体设计如下：集成接口平台：利用3台集成接口服务器，部署uAPI接口模块，构建高可用、可扩展的集成接口集群，负责与外部系统交互，执行数据同步、动作调用等任务，并将过程数据发送至数据处理平台和运维数据仓库。数据处理平台：本期项目，利用3台应用服务器，部署uEP分析处理模块，接收集成接口平台采集

20、的运维数据，执行实时处理，同时，系统具备横向扩展能力，在长期运行过程中，可根据负载增长，灵活的对系统进行扩容。运维数据仓库：本期项目，部署3台数据库服务器，构建高可用集群，运维数据仓库组合多种数据库技术，实现多台数据库服务器的数据同步和负载均衡，确保系统处理性能和数据的安全性。运维门户：部署2台web服务器，通过负载均衡构建高可用负载均衡集群。各部署模块间不存在运行时冲突，因此，在项目建设一期，可以考虑将集成接口平台、运维数据仓库和数据处理平台实现多组件的合并部署。项目实施方案项目实施方法运维平台系统实施过程包含了咨询和系统建设两个阶段，实现高度的结构化和标准化，每个阶段均由整合了多领域知识和

21、多年项目经验的工具和文档体系支撑，保证系统交付的质量。uinnova ITA实施分为以下阶段：模型设计：通过收集分析不同团队、不同角色对业务影响模型的需求，统一模型建设的方法和原则，划定应用系统业务服务模型的系统边界，经过初步信息采集，构建起应用系统业务服务的概念模型，与相关团队进行系统细分颗粒度、以及关联关系定义的确认，并集中运维团队进行模型推广，形成数据精细化梳理过程的基础。数据整理：从概念模型产出到精细化数据梳理，要经过对象框架搭建，细分对象识别以及关联关系梳理3个数据整理阶段，将初步的、概念性的图形模型，转化为精确的、格式规整的数据模型。数据转换：经过由概念模型至数据模型的梳理，IT架

22、构模型由初步的概念设计逐步精确到明晰的分类、属性和关系数据，形成IT全景模型。模型生成：只需将梳理完成的数据导入基于uITA/IT架构可视化平台，便可自动生成自业务服务至IT基础设施的立体层次模型。运维数据集成分析：通过定制化的集成接口，与外部运维工具平台对接，实时交互，形成面向多种运维场景的专业化管理功能。业务场景构建和发布：用户根据需要构建面向业务场景的数据、视图、功能集合，并发布至整个运维组织共享使用。业务功能深度定制：对于各管理场景中独特的运维管理功能，采取深度定制的方式实现，最终构成运维平台系统。项目人员安排运维平台系统的建设过程，需要咨询顾问团队和项目实施技术团队共同参与，实现业务

23、与技术的紧密结合。项目组织架构图项目组织架构设计思路：由项目经理，架构师和咨询顾问共同负责项目整体目标、范围以及建设进度的把控，并在必要时进行调整。项目主体由顾问团队、实施团队和开发团队三部分构成，由统一的项目管理制度协调调度，各部分设置负责人，负责管控该团队的日常工作管理。开发人员和实施人员由开发负责人和实施负责人进行日常工作管理，避免出现外行指挥内行的弊端，开发负责人和实施负责人与整体管理的监控项目经理和咨询项目经理的管理要求保持一致。成立项目核心小组负责整体的项目管控和重大问题决策。核心小组成员由项目经理、咨询顾问、架构师、开发和实施负责人构成。项目成员职责说明序号项目角色角色职责项目经

24、理负责整体项目的沟通、协调和管控，参加项目组主要会议项目顾问参与整体咨询组的系统整体架构、运维管理体系设计，并对整体项目的咨询成果和咨询成果落地过程中的问题负责。所有咨询团队的交付成果必须通过其审核，才可以进行发布架构师参与整体咨询组的系统架构设计、运维管理体系设计，并对整体项目的系统架构设计和平台实施过程中的设计系统架构的问题负责。所有架构方面的结论和变更必须通过其审核咨询顾问负责咨询服务、运维平台的实施服务、数据模型建设等的项目管理工作实施项目经理实施组安排一名实施项目经理，负责组内实施人员的管理，其管辖的成员与咨询项目经理的管理为矩阵式管理方式，实施项目经理的管理整体上要服从于咨询项目经

25、理的要求实施项目专家根据各小组的工作安排，承担各平台的实施工作实施工程师根据各小组的工作安排，承担各平台的实施工作开发项目经理负责各小组的开发工作的管理，其管辖的成员与监控项目经理、咨询项目经理的管理为矩阵管理方式，开发项目经理的管理整体上要服从于实施项目经理和咨询项目经理的要求开发工程师根据各小组的工作安排，承担各平台的开发工作项目实施内容运维平台一期项目的实施内容包括：项目模块项目实施任务任务描述工具调研及现状分析报警事件及接口调研调研现有事件管理平台，事件数据模型、事件同步接口、对象映射规则、当前事件量峰值等基础信息调研监控信息及接口调研调研现有监控系统，监控指标设计、数据同步接口、对象

26、映射规则调研，以及同步机制和间隔、数据量估算讨论配置和资产信息接口调研调研现有配置管理系统，配置分类、配置属性、配置关系建模，以及配置信息的获取机制和更新机制流程管理及接口调研流程管理系统，流程信息同步规则，以及同步机制和间隔，反向同步规则通知系统及接口调研通知系统接口，内容及格式调研自动化工具接口调研调研一键巡检和一键启停相关的自动化动作定义数据结构和接口，以及动作触发接口统一用户和认证系统及接口调研统一用户信息、同步接口和单点登录机制调研原型搭建及需求确认端到端监控可视化原型针对业务、应用、系统、基础设施等多层次管理对象，完成端到端层次模型设置，通过模拟数据，显示多维度信息面板，按照初始业

27、务需求，定义动作触发按钮和外部页面链接数据中心管理原型针对主数据中心，建立资产、容量、动力环境等管理模型，实现数据中心一体化运维运维管理门户原型根据初始业务需求和模拟数据，完成运维管理门户搭建，综合展示事件管理、场景管理、协同平台、运维数据分析等管理功能协同编辑平台原型根据初始业务需求，搭建协同编辑平台，并针对实际应用系统，进行运维管理场景创建集中事件管理原型搭建集中事件管理平台原型，提供事件控制台，事件策略处理等功能业务影响分析原型根据初始业务需求和模拟数据，完成业务影响分析模型搭建和故障根源诊断原型搭建系统架构设计数据结构及规范设计数据结构规划和接口规范设计系统功能架构设计业务流程和功能架

28、构、模块设计系统技术架构设计技术架构设计及模块规划业务运维模型设计运维业务模型总体设计本期项目业务影响模型需覆盖从物理机房、基础设施、资源平台、业务应用和交易的各层管理对象，整合静态的描述信息和动态的运行信息，从不同纬度维度、不同层次反映数据中心的实时运行情况和历史发展趋势。总体上呈现由业务服务、应用系统、平台实例、IT基础实施，物理环境等层次构成的立体全景运维对象体系设计本期业务影响模型的对象体系将参考CMDB结构，并补充来自业务和交易监控系统的CI，同时，对于没有自动数据源的模型对象，具备人工调整能力，实现运维模型的灵活性和可扩展性运维对象关系体系设计通过关系设置决定影响分析算法的实现，本

29、期业务影响模型的影响关系体系将参考CMDB已有结构，并补充来自业务和交易监控系统的端到端交易关系，实现运维数据关联分析运维对象映射设计设计运维管理对象与各个管理子系统中的管理主体间的映射规则，实现多维数据模型的搭建接口规范制定及开发报警事件同步接口报警事件接口规范设计，接口开发和对接测试监控数据同步接口监控信息接口规范设计，接口开发和对接测试用户信息同步接口用户信息接口规范设计，接口开发和对接测试运维工具同步接口运维工具接口规范设计，接口开发和对接测试通知系统接口通知推送接口功能设计，接口开发和对接测试配置数据同步接口配置数据接口规范设计，接口开发和对接测试页面链接接口根据外部运维系统，开发动

30、态URL生成规则，并与对端系统配合完成链接跳转整合功能定制开发端到端监控针对确定需求，定制开发端到端监控可视化，多维度信息展示，动作触发等功能数据中心管理针对确定需求，定制开发数据中心管理，资产、容量、动力环境监控、报警等功能运维管理门户针对确定需求，定制开发运维管理门户，包括运维视图、统一用户、场景管理，后台管理等功能协同编辑平台针对确定需求，定制开发应急预案关联展示，应急状态跟踪等功能集中事件管理针对确定需求，定制开发集中事件管理深度定制功能业务影响分析针对确定需求，定制开发业务影响和故障根源诊断功能系统集成测试业务场景测试针对完整的业务场景，完成端到端的业务流程测试接口联调测试综合测试外

31、部数据、服务、页面链接接口系统部署系统平台安装配置安装配置调试系统平台，开通网络链接和接口系统内容初始化选定典型业务系统，加载初始化数据，组织架构视图等，完成模板系统的初始化系统用户和权限初始化开放系统用户和权限试运行使用流程设置定义使用流程用户操作培训制定操作手册，完成用户培训试运行推广及跟踪制定推广计划，设定跟踪指标，并试运行项目实施计划考虑运维平台项目的复杂性，业务咨询和技术平台搭建将同步展开，由项目顾问带领负责团队进行需求分析和原型搭建，以明确和细化业务目标；由架构师带领开发实施团队进行环境和接口调研，完成技术平台的搭建和接口规范的确认。由顾问团队和技术团队共同完成系统架构设计，并进入

32、主体实施和开发阶段。项目组综合考虑项目复杂度和资源情况，预计：在自合同签订之日起五个月内完成项目的所有设计、开发、实施工作，6个月后进入试运行阶段。并按照技术需求文档按阶段交付相关模块。待本项目相关系统成功上线运行之日起，支持系统平台试运行6个月，并提供一年的系统运维技术支持。项目管理工作方式公司充分理解科技发展有限公司对本次项目的工作方式要求，也认可这种工作方式的必要性，公司会完全按照招标书的要求来进行项目的建设。公司对科技发展有限公司运维平台一期项目建设的产品、技术、质量、进度等负责，招标人积极配合。项目建设过程中，所需的开发人员，集成人员由公司提供。公司自行解决吃住等生活、工作和安全问题

33、。运维平台一期项目实施团队由系统实施组、定制开发组、顾问组共同组成。运维平台一期项目在前期充分研究和测试的基础上，整体设计，一次性推广实施，计划自签署合同起项目整体开发与实施时间计划6个月。系统实施组负责项目实施部分，定制开发组负责针对用户定制化需求进行定制开发，顾问组负责解决实施中遇到的技术问题与架构问题。项目管理范围管理范围管理保证项目包含了所有要做的工作而且只包含要求的工作，它主要涉及定义并控制哪些是项目范畴内的，哪些不属于本项目范围。对这个项目，范围管理主要管理以下内容：需求收集、定义范围、范围分解、范围核实、控制范围等等。 定义范围将通过访谈、问卷调查、研讨会和原型法等形式收集项目的

34、需求。针对用户的需求，有限公司和科技发展有限公司的项目团队根据需求的理由、需求的优先级、需求的来源、需求实现的可行性进行讨论，确定项目的范围，最终制定项目范围说明书。恰当的范围定义对项目成功十分关键，当范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。范围分解项目实施本身是一个复杂的过程，明确了大的范围，并不意味着能把项目做好，我们必须采取分解的手段把主要的可交付成果分成更容易管理的单元，最终得出项目的工作分解结构（WBS）。我们将以项目进度为依据划分WBS，第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分直观，时间感

35、强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。控制范围在项目实施过程中，范围不进行任何变更几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。变更并不糟糕，糟糕的是缺乏规范的变更管理过程。范围变更的原因是多方面的，比如用户要求增加产品功能而导致设计方案修改而增加施工内容。项目经理在管理过程中必须通过监督绩效报告、当前进展情况等来分析和预测可能出现的范围变更，在发生变更时遵循变更程序来管理变更。 沟通管理项目沟通的主要方式为提交项目状态报告和举行例会，具体建议见下面的描述。另外，为了使项目顺利，正常的进行，在项目中鼓励项目组内进行充分的沟通，采取的方式主要有：项目例会项目周报

36、项目月报面对面交流电话E-mail项目状态报告：文档名/描述频率项目管理报告每月项目周报每周项目例会：会议类型参加人频率项目启动会议所有项目组成员，项目管理委员会成员1次，项目开始时周例会有限公司项目组成员每周，建议为周五上午月例会有限公司和科技发展有限公司的项目管理委员会成员和项目经理每月，每月的最后一天质量复审会议质量复审人，项目经理每4周问题管理问题管理问题管理流程的目的是保证所有问题被发现，记录，清楚地定义，和项目干系人沟通，被跟踪直到结束。 下面是问题管理流程：识别项目问题建立问题跟踪机制评估该问题升级重要问题决定问题解决办法升级导致变更的问题 执行问题解决办法结束该问题识别项目问题

37、任何问题都会对项目的执行和结果带来负面影响，所以必须识别出来，尤其是问题的根源。建立问题跟踪机制源自不同方面的问题需要被记录和监控。采用问题跟踪表记录识别出的问题，并跟踪解决的全过程。评估发现的问题评估问题影响的范围，发现问题的原因。 当初步的问题识别和评估完成，项目经理会对问题设定重要程度和处理的优先级。优先级：高需要马上解决中需要立即讨论，安排解决时间低需要确定讨论和解决的时间升级重要的问题为保证能平稳和及时解决问题，任何重要问题都需要升级到更高的管理层。在本项目中，重要问题有下面的特征：潜在的和合同条款有冲突威胁到项目继续下去的问题资源的效能或可用性导致实现项目目标的可能性下降。成本或进

38、度与计划的不一致超出可接受的极限潜在的和项目需求不一致为做避险准备或未识别出的风险发生了或要发生。被识别出的问题超出预计时限还没有解决决定解决办法项目经理负责审核问题的建议和解决办法，并保证有可接受的解决办法前，不会分派项目资源。对于小问题，可能只是和负责的个人进行简短的讨论。对重要问题，就需要详细的行动计划。重要的一点是确定完成的时间。项目经理这时需要决定是实施问题解决办法，或是升级，以做进一步的评估。如果解决问题的建议被接受，就会安排相应人员，并及时通报最新情况。升级导致项目变更的问题解决办法的实施导致项目成本、进度、项目基准计划、交付物变更的，需要走项目变更流程。项目变更流程保证对项目各

39、方面进行详尽的影响评估，使得所有需要变更的部分都被识别出来，并且在整个项目周期中被监控。实施解决办法 依据问题范围的不同，对于简单问题，最后可能是一个简单的解决报告；对复杂问题，可能是举行定期的进展沟通会议。结束该问题 在问题解决结束时，相关信息需要通知所有相关各方，确保问题的确是解决了，并拿到正式确认。升级流程升级流程是为了保证问题能被有效、及时、真正地管理和解决。升级流程提供沟通机制，使高级管理层注意到没有解决的那些问题。有限公司和科技发展有限公司的项目组成员都可以提出项目中存在的问题。开始时，问题会报告给组长，如果在这一级不能解决（3天内），就要升级给项目经理。如果5天内不能解决或不是项

40、目经理的权限可以解决，问题将被升级到公司管理层，集中资源进行解决。基于定义升级流程的目的，这里说的“解决”的意思是正在处理（问题可以解决），而不一定是完成。质量管理有限公司非常重视质量保证工作，在有限公司的各方面工作中，始终贯彻专业的质量管理标准。本项目的质量方针是“质量第一，用户至上，服务一流”。有限公司通过自身健全、有效的质量保证体系，保障此项目的设计、开发、检验、试验、安装、调试、交付和服务的全过程实施有效的质量控制，使项目质量得到保证。变更管理变更可能由各种事件引发。外部影响，如政府条例变化或自然灾害，会影响项目。为了节省费用、规避风险、缩短时间、或制造更好的交付物也会引起内部变更。被

41、采纳的客户变更可能导致功能的增加和减少。另外，为克服设计的上的难题，还可能会进行技术变更。对这个项目，变更管理主要管理以下内容：对项目进度的变更对需求分析说明书的变更对项目软件环境的变更对项目技术文档、说明书和手册的变更对维护和紧急响应服务时间的变更下面是变更流程的定义。变更开始如果项目以外的变化对项目执行、功能、成本、交付日期、交付物的其它技术限制因素造成影响，或者由于合同一方原因造成项目延期，或者合同一方不能履行项目计划中规定的责任，将会导致合同的变更。有限公司和科技发展有限公司的项目组成员都可以提出变更的建议。有限公司和科技发展有限公司的项目经理将讨论这个变更，如果他们同意，就会产生一个

42、变更申请。他们会指派专人进行分析，以决定接受还是拒绝变更。变更申请采用项目变更审批表。该审批表的内容将记录变更描述，识别变更的影响，决定管理该变更的最好的办法，获得受影响各方的批准。然后才能开始进行变更行动。变更评估如果评估一个变更的时间要超过1个工作日，并因此造成的项目进度滞后，会被书面记录下来，并导致项目进度的变更。当分析变更申请的影响时，将评估以下几方面：对解决方案质量，交付物和验收标准的影响对进度的影响对项目成本的影响对项目资源的影响（目前承诺的资源和/或额外的资源需求）对风险的影响变更的成本是基于风险，资源和进度影响的相互关联的所有成本。变更批准接着，变更申请需要获得双方的批准或终止

43、。有关变更申请的争议（如范围增加的大小）用升级流程来解决。当变更申请经过处理和批准，如果项目的范围保持不变，除非另外同意，有限公司和科技发展有限公司将继续按现有计划执行。如果有限公司和科技发展有限公司不能就变更申请达成一致，项目范围将维持本文档中的规定不变风险管理本次项目中一个十分重要的部分是对风险的控制， 有限公司将对本项目进行风险评估，以采取相应措施来降低可能出现的风险。在项目实施过程中，确保及时获得项目进程中所需的各种信息，及时预见、报警和防范项目实施中可能出现的各种风险，从而保证最小程度的差误损失。项目的风险包括项目外部风险和项目内部风险。下面列出项目可能遇到的风险及减轻风险的因素：风

44、险管理办法风险管理计划基于以前的风险评估、分析和减负产生的。风险管理是一个重复的过程，从项目开始时贯穿整个项目生命周期。以下五个部分构成风险管理过程。在项目开始时, 有限公司和科技发展有限公司必须对项目组中参与风险管理的人员和责任达到共识。我们将确定何时和如何重新评估风险及报告风险管理状态。通常风险评估是根据每月的项目组进展会议的议程来进行的，然而如果有必要也可以召开专门会议评估和管理风险。项目经理总结项目组的风险评估并向项目发起人报告发现。风险识别确定项目中潜在负面结果的不确定性。在项目生命周期中尽可能早的确定风险并在项目生命周期中持续进行风险管理。通过实施软件和技术基础结构的经验，有限公司

45、设计了一个风险评估表，由以下几类构成。 类1 - 与运行支持相关的风险。类2 - 与应用相关的风险。类3 - 与资源成本相关的风险。类4 - 基于实施时间线的风险。类5 - 基于使用技术的风险。在项目实施中，识别风险是一个反复进行的过程，项目团队应参与识别风险过程，以便创造并维护团队成员对风险及其应对措施的主人翁感和责任感。 风险分析风险分析是一个实时过程。在一个项目从始到终，任何新的或变更的风险应加到分析中。对每一个风险应完成以下的风险项目和评估表：影响区域 影响的一般区域是范围、进度、成本，产品质量。风险警告标志 风险警告标志是标志风险的事件、特征或状况，用来报告与计划相背的情况。例如，有

46、5%或更大的变化发生(计划、成本、人力、完成比例等) ，项目经理必须在报告和状况会议上描述解决问题的纠正行动。如果情况严重(大于10%),项目经理必须尽快将问题升级到管理委员会并同意采取必要的补救措施。风险概率 估计风险发生的概率。这个概率基于经验来确定。可能的风险成本 估计每个风险的可能的成本。估计某一事件的成本或估计风险成本在项目中的比例可以得到结果。风险分级 给风险分级以确定最严重的风险。决定哪些风险是对项目最为有害的。 首先用可能的风险成本乘以风险概率得到大概的风险成本，建立风险分级。最高的风险成本有最高的风险级别。此外还要考虑时间，最紧迫的风险的级别需要提高。 降低风险降低风险即采取

47、行动去除、减少、最小化项目风险的影响。为了合理地降低风险，我们需要制定一个风险降低计划，制定一个风险降低策略表，其中包括一系列为项目成功而采取的最小化风险影响的行动。对于低影响、低概率的风险，通常不准备风险降低计划，而是监控风险项目确保它们不发展成更高的风险。对于需要降低的风险，有两个降低策略需要考虑：预空策略 通过移走、减少或避免风险来最小化风险带来的威胁。如性能基准、尽早开始、提供培训、实行正式的更新管理过程、建立期望、在早期的计划阶段让客户参与。 意外策略 在情况发生时采用一个意外处理计划可以最小化风险的影响。如延长工作小时、增加员工、修改范围、延长进度。对每个风险，指定一个所有者来维护

48、风险降低计划。风险降低控制确定风险减低活动只是第一步，只有在正确的时间应用它们才是有效的。必须适当实行降低风险活动，并进行监控以决定其效力。随着项目进展，如有必要则修改降低策略。为了有效的管理风险，项目经理必须：实行风险降低计划 激活预空风险降低策略并实现风险降低计划。监控风险预警标志并快速反应来实现风险降低意外策略。因为问题很少自动解决，有效的降低必须是活动的。项目经理必须主动采取行动。评估降低效率 评估风险降低行动的效率可以客观地评估项目。重新评估 每月评估项目的当前风险状态可以了解项目的动态的状况。每月的项目进展会议可以有效的提升和报告项目风险、风险降低活动和结果。 必须注意风险的变化和

49、影响的变化，以及新确定的风险。新的风险需要经过风险评估过程。项目风险咨询服务风险风险名称风险处置措施本次项目的用户范围大、组织结构复杂、管理成熟度参差不齐获取科技发展有限公司管理层的支持在进行试点选择时从运维管理成熟度、业务代表性、规模等维度选择合适的试点在需求分析阶段细致区分管理需求和工作习惯需求，对于工作习惯类需求进行策略性处理整理各个业务系统的关键价值诉求，当个别问题无法最终形成一致时，关注主要矛盾，暂且搁置次要矛盾。系统架构设计时对科技发展有限公司已有工具的未来定位的风险本次系统的建设过程中肯定会与科技发展有限公司已有的管理工具发生关系，其中势必会涉及到对其中的部分系统的存废问题的讨论

50、，如何在保证统一运维管理体系搭建的同时不对各业务系统造成管理倒退，将通过以下措施来实现：重点调研已有管理系统的使用情况、使用场景及使用评价双方项目组在整体架构设计中的结果与已有管理工具的业务系统进行充分沟通，中间配合工具原型演示，落实整体设计思路对于与总体设计思路冲突，但无法达成共识的业务系统，采用暂时搁置、逐步验证推进的方式来深入。此次项目范围较大，涉及系统各异，且目前的运维体制与模式不尽相同，对配置数据的要求与理解均存在差异，如何能够设计一套可以满足所有系统要求的蓝图，而且能够在项目周期中做好控制，一旦蓝图设计不稳健，在项目过程中频繁对蓝图做调整（类、关系、属性），会引发一系列的关联影响，

51、容易让项目陷入被动的风险。只有充分理解各业务系统当前面临的问题，真正深入分析他们目前的配置数据情况，才可以设计一个尽可能接受大家需要的蓝图，同时此蓝图需要结合管理层的意志，即从科技发展有限公司的IT管理全局角度，未来的配置管理的数据发展考虑，如此才有可能形成一个基于事实需要的蓝图，有了蓝图设计出来后，需要设计一个严格的评审过程，且设计一个公告期，收集各个层面的人员的意见，让各方观点在项目初期完全碰撞而达成最后的一致，这样避免在后续项目无休止陷入调整模型的冲突与讨论，一旦形成统一的共识后，需要将蓝图的变更作为项目最高级别的控制权限，进行严格管理，并且提前定义变更策略，即在什么情况下才允许对蓝图做

52、变更，需要具体到什么人（项目角色）可以提出变更什么（分类、属性、关系、模型），由什么人（项目角色）审批才能进行蓝图调整与实施。实施及开发服务风险风险名称风险处置措施与大量周边系统集成的技术和协调风险本次项目的接口平台需要与大量的系统进行集成，由于对端系统的多样性，在技术和进度方面存在风险，建议通过以下措施处理：采用通用的接口技术，定义接口标准。针对需要集成的系统提供通用的技术方式和统一接口标准科技发展有限公司项目组协助协调相关系统的技术团队或厂商，配合进行必要的接口开发和联调工作项目管理外部风险控制风险名称风险处置措施业务需求改变（业务转型、市场变化和成长）制定并管理一个已被清楚定义的项目范围

53、在制定项目范围时，尽早获得科技发展有限公司高级管理人员的确认。制定项目的阶段性总结制度，并要求在下一阶段项目开始前，能得到管理层对上一阶段总结的批准和认可项目成员防止项目范围的变更，并坚持执行已定义且已获得批准的项目变更程序。当遇到不可避免的改变时，如业务转型时，需要确定项目范围改变的程度。对整个项目实施和成本的影响应尽可能快地得到管理层的批准。资源冲突或约束尽早指明项目资源需求（项目小组和关键成员）在项目小组内，指定任务和责任获得科技发展有限公司和有限公司管理层的承诺和支持 监控和管理项目组中关键成员的可用性厂商产品和服务交付延迟尽早指明产品商和系统集成商造成的延迟根据厂商、系统集成商和用户

54、的要求，建立补救措施和计划通报所有相关的合作伙伴因此可能造成的项目延迟得到有限公司和科技发展有限公司管理层对于项目的修改计划和费用的批准项目管理内部风险控制风险名称风险处置措施客户承诺作为项目开始的一个关键步骤，需建立一个指导小组，成员包括科技发展有限公司项目主管、最终用户项目主管、客户项目经理和一个核心用户小组。得到项目主管的所有承诺项目主管提名建立项目用户小组，确保小组成员全时间投入本项目并了解项目的重要性，提供全力的支持。客户的项目经理直接向项目主管负责。清楚制定项目的组织架构和责任建立和沟通对整个组织最有效的工作方式在项目开始时，与最终用户沟通项目的实施方法和里程碑及时批准工作项目和决

55、定坚持已制定并获得批准的决定，根据项目任务和责任改变管理的方针和程序增强关键用户的权利，使牵涉批准和事件解决过程的人员最为精简建立和管理清楚定义的交付项目范围改变从第一阶段开始，建立和管理清楚定义的项目范围所有项目成员了解和交流防止项目范围改变的策略项目成员防止项目范围的变更坚持执行已定义且已获得批准的项目变更程序沟通项目计划，管理双方的期望记下此项目范围之外的其他合作机会紧密而持续监控范围改变引起的结果和冲击厂商的管理尽早得到各厂商的承诺定义和明确各厂商在此项目中的任务和责任对进度和项目质量进行定期检查项目成员的期望、情绪和流动建立和明确项目成员的任务、责任以及上下级关系工作重点在于阶段性实

56、施的整体完成工作任务建立相关的奖励和奖金制度提前作出其他新合作机会的人员安排引导团队的建立鼓励培训和个人成长在项目实施期间对项目成员提供帮助，管理项目成员的变更项目成员的专业知识和能力项目合作伙伴确保为此项目提供适当的资源强调团队工作和知识共享监控项目成员的专业知识和能力及培训需求，并根据需要对人员的任务和责任作出调整项目验收计划验收测试计划系统应按双方共同确认的验收测试计划所规定的程序和步骤进行验收。验收测试程序应在证实系统满足功能需求规格说明书的基础上设定。验收测试计划定义了确定系统按测试程序被接受且满足功能需求规格说明书要求的流程和标准。测试计划应包括以下内容:介绍角色和责任测试环境测试

57、案例/脚本测试结果/报告在测试运行过程中，用户应记录所有未达到完成标准的提交件的问题记录并给每一项出现的问题划分严重性等级。有限公司将审查上述事项并在需要的情况下与用户讨论所分问题等级的划分。如发现有下面章节中“问题严重程度定义”中描述的“程度级1”问题出现，用户可以拒绝接受系统。有些失误可能是对工作说明书的误解造成的。这种误解需经评估以确定是归咎于有限公司责任或是用户的责任。如是有限公司责任， 有限公司将为用户作必要修改并重新测试；如是用户责任，将按“项目变更控制程序”规定执行。问题严重程度定义程度 1 -系统不能运行指一个系统不能使用或严重受损，对业务应用产生极大影响。问题不能规避。程度

58、2 -系统性能降低， 功能部件缺陷指一个系统或产品可以运行，但某些功能特性有缺陷，致使许多使用者受影响或系统性能明显降低。但存在替代方法或该问题可以被绕过。程度 3 限制受限指一个系统或产品功能符合要求，然而某些处理受到限制但不影响整体运行。程度 4- 微小缺陷指一个系统或产品功能完全符合要求，但所出现的缺陷仅需要做微小的改动或润色。验收不同种类的提交件将按下列不同方法验收:标准产品- 验收应采用检验以及分析相结合的方法；应用程序- 应用程序将通过由用户运行验收测试计划中规定的验收测试程序或用户已开始投产使用该应用程序的方法进行验收；文档- 文档将通过由用户对文档的检验而被验收。如果文档在5个

59、工作日内未被正式批准或拒绝 (有书面通知), 则视为该文件已被用户接受；培训- 当培训课程进行完毕，即视为培训已被验收。项目文档资料本次项目中有限公司项目组计划提交以下项目成果文档，最终的文档名称和内容在和招标方进行沟通，并得到招标方同意后，可能会有所调整。最终交付件数量和规定以工作说明书（SOW）中的约定为准。所有交付报告均提交纸介质和电子文档，按中文方式提交。项目成果文档清单本项目中有限公司建议的项目成果文档包括以下内容。序号文档名称文档内容说明科技发展有限公司运维平台系统_需求说明书详细记录科技发展有限公司关于运维平台系统需求说明，并形成最终的需求确认文档。科技发展有限公司运维平台系统_

60、功能设计文档详细描述运维平台系统的功能和界面,并详细接受功能实现的方式 科技发展有限公司运维平台系统_概要设计文档根据需求说明书与功能设计文档，对所需的架构和代码进行概要设计说明。科技发展有限公司运维平台系统_详细设计文档根据概要设计细化每个功能模块的设计。科技发展有限公司运维平台系统_系统架构设计文档描述生产系统的部署架构及相关建议科技发展有限公司运维平台系统_系统安装文档描述有限公司产品的安装步骤和注意事项科技发展有限公司运维平台系统_测试计划描述测试的具体安排（时间，人员及测试环境要求）科技发展有限公司运维平台系统_测试案例定义系统测试方法和测试案例科技发展有限公司运维平台系统_系统安装