软件定义运维范文

2022-06-05

第一篇：软件定义运维范文

运维管理定义

运维管理( IT Operations Management)帮助企业建立快速响应并适应企业业务环境及业务发展的IT运维模式，实现基于ITIL的流程框架、运维自动化。

核心思想随着国内企业业务信息化的深入, IT运维部门所负责的IT设备及软件的运行维护工作变得越来越复杂，技术难度也越来越高。传统的IT工具和流程集中在技术上，而不是业务目标上。业务服务管理(Business Service Management)使IT能轻松满足业务的需求，转变企业的环境，使业务部门和IT部门领导者能够拥有统一的语言，通过统一的界面面对挑战，理解新变化所带来的影响。

BSM主要强调从业务的视角来看待企业的IT运维，从而最大化发挥IT对企业业务的推动作用，这就IT运维的核心思想。

着眼点IT系统的业务服务管理主要着眼点

一、确立以业务价值为核心，业务驱动管理的管理思想面向业务要首先在IT管理的战略层面上建立“业务驱动”的IT治理和管理思想，使得业务部门的目标和IT运维的目标一致，都是为了企业整体战略目标的实现，把对业务的支撑能力和管理实效，作为评价IT系统效用和IT部门工作的首要指标。只有这样，才能在全企业范围内建立“技术服务于业务发展”的意识和文化，是真正实现IT与业务融合，共同为企业的战略目标服务。

二、建立关键业务服务模型今天的业务部门对应用程序的依赖性比过去更强了。应用程序软件可以实现关键业务流程的自动化 —自动化既包括付款、资金转账、下订单和订单履行。由于应用程序故障或性能问题可能导致严重的业务影响，因此业务部门迫切需要 IT 部门在发生问题时提供更高的应用程序服务级别和更快的问题解决方案。所以，必须结合企业战略和目前业务运营情况，辨识企业业务服务，特别是关键业务应用。为这些核心业务系统服务，建立和企业未来发展愿景、目前IT架构、管理模式等相适应的业务服务模型，能够清晰地描述业务与IT之间的关联关系和IT服务的关键目标。

三、管理信息共享目前，出于对IT资源专业化、精细化管理的要求，企业部署了诸多的监控管理工具，如网络监控、系统监控、数据库监控工具等。一般来说，这些监控工具往往来自于不同的厂商，彼此之间缺乏信息共享的手段。而一个具体的业务是由网络、主机、应用本身所组成，管理信息无法共享，这就造成了当一个故障出现时，无法通过系统直接自动分析并定位故障点，加大了IT故障的分析难度，降低了解决问题的效率。业务服务管理可以有效整合企业已经构建的众多IT监控系统，将分散的IT管理信息集中到一个单点的管理平台中，从而可以快速进行故障定位。

四、根源问题定位随着企业业务的快速发展，IT环境越来越复杂，IT组件越来越多，同时各组件之间的关联关系也更加纷乱和复杂。业务服务管理能够提供有效的根源问题定位能力，它着眼于企业的核心业务系统，通过集中与业务相关的IT信息，根据业务逻辑和IT组件之间的关联关系进行建模，企业可以在业务模型中的任何一点进行快速的根源问题分析和定位，大大提高了解决问题的速度和准确度。

五、故障影响范围评估当我们发现IT故障时，我们不仅应该关注故障本身，更应该考虑该故障对业务系统的影响。通过建立业务服务影响拓扑，可以快速的了解企业的关键性业务及业务故障时的影响范围，通过了解企业具体的业务环境，优先处理关键故障点。

第二篇：软件系统运维方案

软件开发维护服务外包

第I页

2010年7月

东软集团软件股份有限公司

1 项目概述.......................................................................................................................................... 1 1.1 1.2 2 项目背景 ................................................................................................................................. 1 项目范围 ................................................................................................................................. 1

运维服务需求内容 .......................................................................................................................... 4 2.1 2.2 2.3 2.4 2.5 软件维护需求 ......................................................................................................................... 4 软件开发需求 ......................................................................................................................... 4 集成服务需求 ......................................................................................................................... 5 现场服务需求 ......................................................................................................................... 6 用户培训需求 ......................................................................................................................... 7

3 东软服务理念 .................................................................................................................................. 8 3.1 3.2 3.3 服务理念 ................................................................................................................................. 8 服务宗旨 ................................................................................................................................. 8 服务理解 ................................................................................................................................. 8

4 东软运维服务保障体系 ................................................................................................................ 10 4.1 东软售后服务体系简介 ....................................................................................................... 10

售后服务体系理念 ....................................................................................................... 10 4.1.2 服务支持体系构架 ....................................................................................................... 10 4.1.3 技术支持服务形式 ....................................................................................................... 11 4.2 东软公司四级服务支持体系................................................................................................ 12 4.2.1 第1级服务：本地项目服务机构及项目经理 ........................................................... 13 4.2.2 第2级服务：东软公司南京分公司以及华东大区技术人员 .................................... 14 4.2.3 第3级服务：社保平台系统建设专家 ....................................................................... 14 4.2.4 第4级服务：东软总部技术支撑部门 ....................................................................... 15

5 运维服务总体方案 ........................................................................................................................ 16 5.1 5.2 无锡金保工程建设情况 ....................................................................................................... 16 金保工程总体架构 ............................................................................................................... 16 4.1.1

5.2.1 IT基础设施包括网络及硬件平台层和数据层 ............................................................... 17 5.2.2 基础服务应用平台 ....................................................................................................... 18 5.2.3 业务组件与表示层 ....................................................................................................... 18 5.2.4 东软通用企业应用平台—UniEAP .............................................................................. 19 5.2.4.1 通用企业应用平台的结构 ..................................................................................................... 19 5.2.4.2 通用企业应用平台的功能 ..................................................................................................... 25 5.2.4.3 通用企业应用平台的特点 ..................................................................................................... 26

5.2.5 基于通用企业平台的运维服务 ................................................................................... 27 5.2.6 应用逻辑实现策略 ....................................................................................................... 28 5.2.6.1 核心经办业务技术架构概述 ................................................................................................. 32 5.2.6.2 核心经办业务技术架构设计 ................................................................................................. 34 5.2.6.3 技术架构中各层对象在创建过程中的依赖关系 .................................................................. 36

第II页

5.3 5.4 维护服务计划 ....................................................................................................................... 38 软件维护方案 ....................................................................................................................... 38

远程支持服务流程 ....................................................................................................... 38

5.4.2 现场服务流程 ............................................................................................................... 40 5.4.3 服务内容 ....................................................................................................................... 42 5.4.4 客户服务质量文件 ....................................................................................................... 43 5.5 应急维护方案 ....................................................................................................................... 45 5.5.1 应急预案目标 ............................................................................................................... 45 5.5.2 应急预案具体措施 ....................................................................................................... 45 5.5.3 应急处理流程 ............................................................................................................... 46 5.6 软件开发方案 ....................................................................................................................... 47 5.6.1 项目启动过程 ............................................................................................................... 48 5.6.2 需求分析 ....................................................................................................................... 48 5.6.3 开发策划 ....................................................................................................................... 49 5.6.4 设计与编码实现 ........................................................................................................... 50 5.6.4.1 系统设计 ................................................................................................................................. 50 5.6.4.2 编码实现 ................................................................................................................................. 50 系统测试 ....................................................................................................................... 50 5.6.6 实施培训 ....................................................................................................................... 52 5.6.7 总结验收 ....................................................................................................................... 53 5.6.8 问题处理机制 ............................................................................................................... 54 5.6.9 系统维护流程 ............................................................................................................... 54 5.7 集成服务方案 ....................................................................................................................... 56 5.7.1 集成服务目标 ............................................................................................................... 57 5.7.2 岗位分工和职责 ........................................................................................................... 58 5.7.3 维护作业制度 ............................................................................................................... 59 5.7.4 系统安全制度 ............................................................................................................... 60 5.7.5 故障处理制度 ............................................................................................................... 60 5.7.6 技术档案和原始记录的管理制度 ............................................................................... 61 5.8 现场服务方案 ....................................................................................................................... 63 5.8.1 现场组织管理策略 ....................................................................................................... 63 5.8.2 项目管理组织体系 ....................................................................................................... 64 5.8.3 项目组织各角色的职责 ............................................................................................... 65 5.8.3.1 项目领导小组 ......................................................................................................................... 65 5.8.3.2 项目指导小组 ......................................................................................................................... 65 5.8.3.3 项目经理 ................................................................................................. 错误!未定义书签。 5.8.3.4 项目顾问委员会 ..................................................................................... 错误!未定义书签。 5.8.3.5 过程组 ..................................................................................................................................... 66 5.8.3.6 实施经理 ................................................................................................. 错误!未定义书签。 5.8.3.7 商务经理 ................................................................................................. 错误!未定义书签。 5.8.3.8 项目软件经理 ......................................................................................................................... 67

5.8.4 5.6.5 5.4.1

现场维护管理 ............................................................................................................... 70 5.8.5 项目管理监控 ............................................................................................................... 71 5.8.5.1 阶段评估 ................................................................................................................................. 71

第III页

5.8.5.2 5.8.5.3 5.8.5.4 迭代评估 ................................................................................................................................. 72 状态评估 ................................................................................................................................. 72 资源监控 ................................................................................................................................. 73

5.9 用户培训方案 ....................................................................................................................... 76

5.9.1 东软针对本项目的培训承诺 ....................................................................................... 76

5.9.2 东软针对本项目提供的技术培训 ............................................................................... 76 5.9.2.1 培训计划 ................................................................................................................................. 76 5.9.2.2 培训方式 ................................................................................................................................. 80 5.9.2.3 售后跟踪培训 ......................................................................................................................... 81

5.9.3

5.9.3.1 5.9.3.2 5.9.3.3 5.9.3.4 5.9.3.5 5.9.3.6 5.9.3.7 培训综合能力 ............................................................................................................... 81

东软公司培训中心简介 ......................................................................................................... 82 大连东软信息技术学院 ......................................................................................................... 82 南海东软信息技术学院 ......................................................................................................... 83 成都东软信息技术学院 ......................................................................................................... 83 东软在线大学 ......................................................................................................................... 84 公司培训优势 ......................................................................................................................... 86 咨询 ......................................................................................................................................... 86

6 项目管理及质量控制 .................................................................................................................... 88 6.1 6.2 6.3 东软项目管理概述 ............................................................................................................... 88 人员配备策略 ....................................................................................................................... 91 项目组人员列表 ................................................................................................................... 92

6.3.1 6.3.2 6.3.3

6.3.3.1 6.3.3.2 6.3.3.3 6.3.3.4 6.3.3.5 6.3.3.6 项目负责人员安排 ....................................................................................................... 92

现场人员安排 ............................................................................................................... 94 后台支持人员安排 ....................................................................................................... 96 设计人员 ................................................................................................................................. 96 开发人员 ................................................................................................................................. 97 软件测试人员 ....................................................................................................................... 100 项目管理人员 ....................................................................................................................... 103 咨询策划人员 ....................................................................................................................... 104 集成支持人员 ....................................................................................................................... 105 开发过程管理指导思想 ............................................................................................. 109 配置与变更管理 ......................................................................................................... 110 配置管理资源配备 ............................................................................................................... 111 项目配置策略 ....................................................................................................................... 111 创建项目配置环境 ............................................................................................................... 114 变更与交付工件 ................................................................................................................... 114 管理基线 ............................................................................................................................... 115 管理软件系统交付 ............................................................................................................... 116 变更请求管理 ....................................................................................................................... 116 监测与报告配置状态 ........................................................................................................... 121 项目质量方针 ............................................................................................................. 121 项目质量目标 ............................................................................................................. 121 6.4 项目组织管理 ..................................................................................................................... 109

6.4.1 6.4.2

6.4.2.1 6.4.2.2 6.4.2.3 6.4.2.4 6.4.2.5 6.4.2.6 6.4.2.7 6.4.2.8

6.5 质量保证方案 ..................................................................................................................... 121

6.5.1 6.5.2

第IV页

6.5.3 质量保证承诺 ............................................................................................................. 122

6.5.4 项目质量范围和标准 ................................................................................................. 122 6.5.4.1 质量范围 ............................................................................................................................... 122 6.5.4.2 质量标准 ............................................................................................................................... 123

6.5.5

6.5.5.1 6.5.5.2 6.5.5.3 6.5.5.4 6.5.5.5 质量管理 ..................................................................................................................... 123

质量保证的基本思想 ........................................................................................................... 123 软件生产过程中主要的工作活动........................................................................................ 125 质量过程管理 ....................................................................................................................... 126 质量保证专项活动SQA ...................................................................................................... 127 软件工作产品质量审计和相关文档 .................................................................................... 128 项目实施各方职责 ..................................................................................................... 131 需要用户和原承建商配合的建议 ............................................................................. 132 项目管理方面 ....................................................................................................................... 132 软件开发阶段 ....................................................................................................................... 132 培训组织工作 ....................................................................................................................... 133 项目验收阶段 ....................................................................................................................... 133 6.6 项目沟通管理 ..................................................................................................................... 130

6.6.1 6.6.2

6.6.2.1 6.6.2.2 6.6.2.3 6.6.2.4

客户交互的安排 ......................................................................................................... 133

6.7 项目风险管理 ..................................................................................................................... 134 6.7.1 风险管理过程 ............................................................................................................. 134 6.7.1.1 风险管理计划 ....................................................................................................................... 134 6.7.1.2 项目风险的跟踪 ................................................................................................................... 134 项目风险管理计划 ..................................................................................................... 135 6.7.3 本项目风险和对策 ..................................................................................................... 136 6.8 项目文档提交件管理 ......................................................................................................... 137 6.8.1 项目交付物 ................................................................................................................. 137 6.8.2 递交成果的签署 ......................................................................................................... 138 6.8.3 递交成果的拒绝 ......................................................................................................... 139 6.9 针对本项目的具体承诺 ..................................................................................................... 140

7 结束语.......................................................................................................................................... 142 7.1 7.2 7.3 东软与劳动保障信息化建设.............................................................................................. 142 东软与无锡金保信息化建设.............................................................................................. 143 预祝项目圆满成功 ............................................................................................................. 144 6.7.2 6.6.3

第V页

1 项目概述

无锡市金保工程自2007年上线以来，信息系统运行稳定，应用软件满足了劳动保障业务不断发展的需要，实现了劳动就业和社会保障业务办理的一体化，整个应用软件于2007年5月份完成验收。按合同约定，三年内由软件开发商负责免费维保。2010年5月是三年软件免费维保期期满之时。为了保证无锡金保工程应用软件系统能安全平稳运行，且能不断满足人力资源和社会保障业务的不断发展，采购单位拟将应用系统软件开发及维护服务实行统一外包。

1.1 项目背景

2007年，我市按照国家“金保工程”的建设要求，建成了全面覆盖劳动保障业务的信息系统，建设了集中式的劳动保障资源数据库，实现了劳动保障基础数据的“同人、同城、同库”，体现了数据向上集中、服务向下延伸。同时我市发行了用途广泛的社会保障卡，记录了持卡人个人身份、就业和社会保障等基础信息。应用软件主要由“无锡市社会保险管理信息系统”、“无锡市劳动就业管理信息系统”及相关应用系统组成，涵盖了劳动保障所有业务领域，包括劳动力资源、劳动关系、劳动监察、劳动仲裁、劳动事务代理、社会保险参保缴费、申领各项保险待遇、医疗就诊和费用报销、定点零售药店购药、公共服务、统计分析等，今后还要包括合并后的人力资源和社会保障局业务内容。

1.2 项目范围

根据招标文件要求，我市金保工程项目启动以来至2010年5月31日止，与软件开发商签订的所有软件项目合同所涵盖的内容，均在软件维保服务范围内，包含应用软件运行中的修改、完善、升级、优化、部署、监控等。目前尚未过免费维护期的仍然由原合同规定的维保单位进行免费维护。

本次运维服务所包含的我市金保工程应用软件主要包括以下内容：  无锡市社会保险信息管理系统  无锡市劳动就业信息管理系统

第1页

 无锡市企业退休人员社区管理系统  无锡市老年补贴管理系统  无锡市居民医疗管理系统

 无锡市社会保险单位管理信息系统(报盘软件)  无锡市征地报盘管理系统

 无锡市劳动保障单位网上申报管理系统  无锡市社保卡金融应用软件管理系统  无锡市社区扁平化管理单点登陆系统  无锡市异地就医系统  无锡市定点医疗机构托管系统  软件程序版本更新系统

 无锡市企业退休人员健康体检管理信息系统  无锡新农保系统和老农保系统  无锡市女职工单位报盘管理系统

 无锡市劳动保障行政权力内控及电子监察系统  劳动保障数据上传管理

 无锡市失业保险维护管理信息系统  无锡市零就业家庭管理系统

 无锡市创业促就业管理系统(内外网)  无锡市创业培训网上学校信息管理系统  劳动保障网百件实事网上办

 无锡市劳动保障综合统计系统和主要指标管理系统  无锡市劳动保障信访管理系统  触摸屏管理系统  各种接口软件

根据人力资源和社会保障业务发展的实际需要及时提出业务需求，中标单位及时根据用户要求，积极组织资源，配合制定进度，确保软件需求分析、软件开发、测试、培训、上线、运行跟踪监控、优化等工作在规定的时间进度内准确、及时、安全、稳定地上线运行。每个新项目按软件工程要求进行管理，验收完毕第2页

后纳入日常软件运维范围。

目前根据部相关文件要求今年需完成居民养老业务、社会保险经办能力提升、内控项目等的开发上线工作。

第3页

2 运维服务需求内容

根据招标文件要求，运维服务主要分为软件维护、软件开发、集成服务、现场服务和用户培训五个方面，每个部分的需求和具体要求如下：

2.1 软件维护需求

软件维护需求主要包括以下11项内容：

 协助检查数据库运行情况，及时处理数据库故障;  协助定期对数据库进行优化，提高数据库运行效率;

 协助检查应用软件中间件运行情况，及时优化并处理中间件故障;  接受全市各级劳动保障经办机构数据维护申请，在采购单位的授权下及时进行数据维护处理;

 接受全市各级劳动保障经办机构软件维护申请，对应用软件进行完善性修改，处理应用软件存在的问题;

 完成劳动就业系统及社会保险信息系统和月度初始化工作;  按照部、省要求从生产库向交换库转换数据，生成指标数据上报;  配合系统硬件的维护，及时处理涉及数据库和应用软件相关工作;  配合完成日常的统计分析报表，完成特殊的查询统计需求;

 在采购单位的统一安排下,按相关政策要求进行数据批量处理工作,如:养老调资、医疗帐户调整、失业金上下限标准调整等,整个过程需要建立有关数据安全、备份、测试、验证、应急恢复等机制;  医疗历史数据迁移，医院信息管理系统接口支持。

2.2 软件开发需求

软件开发维护方面对中标单位提出如下要求和需求，主要包括以下6项内容：  必须按软件项目开发的实际需要组织后台开发人力资源,现场技术人员与后端支持按照开发和维护服务要求配置资源，主要开发人员要培养后备力量，防止人员变动影响服务质量，确保软件开发和维护工作按计划第4页

顺利完成。

 对于采购单位提出的应用软件升级需求，由现场工程师与采购单位业务部门进行沟通，了解业务部门对应用软件的升级需求，形成需求文档，经采购单位相关部门确认后，按双方商定的开发进度进行开发和实施。  完成升级需求后，需经用户方相关领导确认。中心端应用版本升级、安排在中午休息时间;医院端软件升级一般在下午5点以后。软件部署上线时，主要开发人员必须到现场提供技术支持。

 软件升级完成，并运行稳定2周(以打版时间为准)后，向采购单位提供程序源代码，并及时组织对采购单位技术人员的培训工作。  软件开发和升级完善遇到不能按时完成等重大问题时，须提前提出，双方协商解决。

 本项目不接受联合投标及转包、分包行为，不得使用分包商履行本合同项下的任何义务。

2.3 集成服务需求

集成服务对中标单位提出如下要求和需求，主要包括以下6项内容：  中标单位应以保障无锡市劳动保障应用系统平稳运行为目标，对采购单位劳动保障信息系统提供总集成技术支持服务，包含对当前无锡市劳动保障应用系统涉及的各方面进行故障诊断、监控和巡检、应用级运维和调优、系统调整部署、升级规划和评估和相关单位服务调度，但不包含该系统所涉及系统硬件设备和系统软件产品本身的原厂维护和保修服务。

主要工作包括：根据应用软件系统运行要求提供应用级集成调优、数据库中间件与应用软件协同配置调整、网络设备配置优化和部署优化、主机操作系统、双机集群、中间件等系统软件的部署、配置、调优工作，备份容灾的应用级维护服务和定期演练等。

每年对采购单位的信息系统进行一次全面的评估，提交“无锡市人力资源和社会保障信息系统运行评估及升级调整建议书”，以使采购单位有充足的时间进行项目规划、申请、落实资金、采购等工作，满足不断发第5页

展的信息系统运行要求。

 需向采购单位提供集成技术支持服务方案，明确对系统运行监控和巡检、系统运行故障诊断、应用级运维和调优、应用系统按需部署调整、系统规划评估等方面的服务计划安排。

 须安排资深系统工程师负责采购单位金保工程系统的集成服务工作，响应级别为7*24，采购单位遇到问题第一时间向中标单位反映，中标单位必须在30分钟内响应，远程不能解决的需要在4小时内到现场，并协调各相关单位解决问题。

 须对采购单位金保工程系统提供两月一次的日常巡检服务。

 须每年对采购单位金保工程系统进行一次全面的评估，提交“无锡市人力资源和社会保障信息系统运行评估及升级调整建议书”，以使采购单位有充足的时间进行项目规划、申请、落实资金、采购等工作，满足不断发展的信息系统建设要求。

 采购单位如因业务要求有新的系统建设要求，中标单位应根据需求给出建设方案、预算规划和指导性意见，并协助采购单位进行前期方案论证、建设阶段的集成、数据迁移、数据库升级、应用迁移等工作，并协调相关厂商完成全部建设工作。

2.4 现场服务需求

现场服务对中标单位提出如下要求和需求，主要包括以下6项内容：  合同期内，中标单位需要派驻至少四名具有独立工作能力和经验的工程师长驻现场,其中至少2名熟悉社会保险信息管理系统，至少1名熟悉劳动就业信息管理系统，至少1人熟悉劳动社保一体化系统、劳动就业信息管理系统及相关业务系统接口部分;确定其中一人作为现场服务负责人,现场牵头协调与用户单位的相关事宜。

 指定一名熟悉劳动保障信息系统和现场经验的项目经理做为本项目的服务运维总负责人，根据系统运维服务需要进行远程支持和不定期的现场支持，确保整个系统高效、安全、稳定的运行，同时负责协调与用户单位的商务、技术、人员安排、项目管理及进度控制等事宜。

第6页

 每周召开一次“软件服务质量评估”例会，给采购单位相关负责人员以周报形式总结一周软件服务工作及下周工作安排。

 现场服务人员的变动，需经采购单位同意，采购单位有权要求对不合格人员的进行调整。

 中标单位现场人员必须遵守采购单位的管理要求，在关键时点，如假日或软件升级后第一天上班等，需要严格遵守作息时间,避免出现问题得不到及时解决。

 重大节假日必须提供值班人员名单及联系方式。

2.5 用户培训需求

用户培训对中标单位提出如下要求和需求，主要包括以下4项内容：  中标单位应按需对应用软件操作人员(包含报盘软件)集中进行免费培训，并提交掌握系统操作所需要的培训资料。

 系统升级后应对技术人员进行技术培训，帮助相关技术人员熟悉软件的各项功能及具体实现。

 中标单位负责每年对采购单位技术人员进行不少于两次的系统软硬件相关技术培训，使采购单位技术人员具备系统日常运行维护所需的技能(每次8人左右)。

 定期组织用户与软件开发人员之间的技术交流活动。

第7页

3 东软服务理念

3.1 服务理念

重视信用、值得信赖、留意形象、迅速反应、善解人意。

3.2 服务宗旨

东软服务宗旨是提供客户满意的服务，提供领先的客户关怀，并成为客户最佳的合作伙伴。客户满意是我们存在的目的，协助客户去赢得和保持竞争优势是我们服务的目标。

东软自成立以来，一直坚持应用软件创造客户价值的经营理念，使客户在激烈的竞争中获得巨大优势。我们通过以下几方面的实现从而使我们的服务宗旨和目标得以实现。

1、取得最高的客户满意度--通过东软专业化的优质的服务，协助客户去赢得和保持竞争优势，并取得最佳的经济效益;

2、在全国树立一致的服务形象--在全国各地，客户都将获得同样高水平的技术支持和专业的服务支持;

3、企业解决方案保持领先地位--为客户提供功能和质量均无可匹敌的企业解决方案;

4、采用当今最尖端的软件开发技术--东软采用的每一项技术都得到企业行业范围应用的检验;

5、拥有技术熟练、高度敬业的专业服务队伍--东软在应用软件业务、系统集成以及相匹配的服务均拥有最好的人力资源;

6、保持良好的业绩--东软每年以高速的业绩发展，并不断地投资于人才队伍建设，并将成为客户长久的合作伙伴。

3.3 服务理解

东软公司自创立以来，一直将“人”视为公司最重要的资产和力量，“以人第8页

为本”的激励体系和企业文化是对这一理解的完美体现。这些“人”包括我们的客户和我们的员工。他们对东软的忠诚与奉献，是我们取得成功的最主要因素。

客户对东软的支持，是建立在我们完整的企业解决方案及高效率的服务支持基础之上的。我们始终围绕客户价值创造东软的软件，通过技术创新来满足客户需求，为客户提供满意的服务支持。

客户满意是我们存在的目的，协助客户去赢得和保持竞争优势是我们服务的目标，服务固然是需要高成本和高技术，但服务的高价值使客户与我们共同发展进步。我们通过不断地服务客户，保证了客户对应用的理解，因为客户需要的并不是技术本身，而是能创造客户价值的一种方案，而方案不是通过我们与客户间的交易完成，而是通过我们与客户的伙伴关系共同完成，服务是我们与客户、产品技术与应用的融合。高质量的服务是东软的价值，服务是我们学习和成功的基础，服务使我们更加了解市场和客户，从而保证客户投资更加安全。

我们为客户提供了全国一致的服务，给全国客户提供了丰富的服务支持内容。东软的所有客户都可以通过签约购买东软的全面服务支持。东软在服务器、网络设备、布线系统、外部设备、平台软件、应用软件、备件支持等多方面为客户提供一年或多年的服务支持，而对于相关服务项目的响应速度，客户可以通过购买金牌服务、银牌服务、铜牌服务支持得以实现。

东软热线服务提供东软软件产品安装、实施以及使用等全面的全国化、一体化支持。东软沈阳设立服务策划管理部，并设立技术和产品服务支持热线，与全国各地分支机构联网，从而保证能快捷有效地向全国的客户提供一体化的全面的服务支持。对东软的软件产品维护，提供了及时的软件更新和升级服务。

东软具有多年的为客户提供本地化服务支持的经验，服务工作人员出色而敬业的表现得到了国内客户的一至认可。

第9页

4 东软运维服务保障体系

根据本项目的实际要求，东软公司组成了一支专业队伍负责担负着专业的客户服务工作，无论是在系统的开发、安装调试过程中还是在系统投入运行之后，无论发生任何问题用户都可以得到最快的响应。

4.1 东软售后服务体系简介 4.1.1 售后服务体系理念

为用户提供易用、可靠的产品和满意的售后服务。

4.1.2 服务支持体系构架

东软公司十分重视对客户的服务，在过去的十几年的时间里，东软公司逐渐建立起了集中管理与分布实施相结合的一套完整的技术支持与服务体系，主要有三层结构构成：

1、公司层面的集中管理机制

为了更好地快速响应客户的服务请求，同时严格执行ISO9000体系所要求的客户服务流程，公司在整个公司层面建立有客户服务中心(CSC)、项目管理办公室(PMO)和解决方案技术中心(STC)。

由CSC对应客户服务(包括需求、申请、投诉、反馈等)响应机制和客户满意度调查机制，从而达到对整个技术支持与服务机制的运营管理和检控职能。

由PMO负责公司全部在线实施项目的整体的项目管理与监控，包括开发流程、QA保证、统一配置管理、合同执行、现场项目状态、项目周报、项目资源协调等。

由STC负责对解决方案或者产品在出厂前的压力容量测试、业务功能验证、生产过程测试等。

2、基于分布式的区域支持与服务机制

东软公司面向国内市场在华东、华北、华南、东北、华中、西南、西北、山第10页

东设立八个大区，建立了虚拟总部，并相应的建立了强大的服务支持平台，实施总部职能，能够灵活快速的对客户服务需求做出及时响应，客户在任何地方都将获得同样高水平的技术支持和专业化服务。

八大区域分别是华东大区(区域总部在上海，南京设有分公司,下辖江苏、上海、浙江和安徽)、东北大区(区域总部在沈阳，下辖辽宁、吉林、内蒙古和黑龙江)、华北大区(区域总部在北京，下辖北京、天津、河北、河南和山西)、西北大区(区域总部在西安，下辖陕西、宁夏、青海和甘肃)、华中大区(区域总部在武汉，下辖湖北、江西和湖南)、西南大区(区域总部在成都，下辖重庆、四川、贵州、云南和西藏)、华南大区(区域总部在深圳，下辖广东、广西、福建和海南)、山东大区(区域总部在济南、下辖山东和新疆)。

3、基于事业部体系的业务咨询与应用系统支持与服务机制

东软公司是面向行业核心业务领域提供产品和业务解决方案的服务商，对此，面向行业客户的核心业务领域的咨询和支持或者软件应用技术的支持和服务机制是建立在东软公司行业事业部体制内的。

东软公司行业事业部能够为最终客户提供全方位的行业业务咨询、核心业务系统的技术支持以及应用系统的服务，包括现场服务(Onsite)或者离岸式服务(Offshore)。

4.1.3 技术支持服务形式

东软公司服务体系目前有300名专业技术服务人员，其中获得专业技术认证的人员占40%，大部分人员是具有丰富行业经验和项目实施经验的资深专业技术人员，他们主要是面向具有关键任务应用的客户提供专业技术服务。

东软公司已经建立了全国分布式的服务体系，能够为全国性、地区性大客户提供每周7天、每天24小时的全面的技术支持和专业服务。

东软公司非常重视客户满意度工作，公司的质量目标是客户满意度要达到95%，服务流程的全过程都有监控管理措施，客户服务代表会定期的与客户保持联系，进行客户满意度调查，及时协调处理客户遇到的各类支持请求，然后跟踪服务过程，最后形成客户满意度调查报告上报公司领导。

根据本项目的技术支持服务要求，东软公司为客户提供技术服务主要有两种第11页

方式：

1、远程方式

东软公司将提供服务热线电话，以便客户可以及时通过该热线提出服务请求，东软公司将对服务请求情况通过专门的管理系统进行记录和跟踪。同时作为热线电话的补充，还将提供专门的传真和电子邮箱以便服务请求信息的更准确交流。

对于客户的服务请求，东软公司将通过电话、传真和电子邮箱提供技术咨询和支持、问题分析和技术指导及相关技术文档和工具的支持。在客户的许可下，东软公司将通过远程拨号方式进入客户相关系统分析系统状况、协助客户分析和解决系统问题。

2、现场方式

对于客户的服务请求，东软公司能够保证其解决时效和质量的基础上以远程方式作为优先选择。但在下述条件下，东软公司会派出技术服务人员到现场提供技术支持和服务：

 远程方式不能满足服务时效要求、或服务任务必须到现场才可完成  客户系统出现非常严重的故障(如系统停机或其故障严重危及关键应用的运行)

 应客户要求且东软公司的项目经理同意的现场服务。

4.2 东软公司四级服务支持体系

我们遵循“技术领先、服务领先、意识领先”。而且我们领先满足客户的需求，想客户所想，急客户所急，领先给客户提供关怀。我们必须不断了解客户的需求，不断跟踪客户的发展，不断向客户学习，不断通过售后服务来完善软件的满意度，不断地通过技术创新快速地满足客户变化的需求，才能为客户提供满意的售后服务。

东软公司的销售、售后服务、软件开发队伍早已覆盖全国，本公司在全国各主要省会城市均设有分支机构，为全国各省市客户提供本地化的售后服务。2002年公司组织机构调整后，公司在南京设有分公司，拥有强大的技术力量和丰富的备件库，常驻本地服务，能够充分保证无锡金保信息系统建设项目售后服务的快速有效。

第12页

东软公司为无锡社会保险信息系统建设项目提供的技术服务工作将基于东软公司社保事业部的技术和支持力量，依托东软公司华东大区和东软公司沈阳总部的多层次技术支持，再加上本地项目组构成一个完善的四级服务体系，为本次项目相关业务应用软件开发、实施与服务项目提供最高效、方便、快捷的技术支持和售后服务。具体说明如下：

4.2.1 第1级服务：本地项目服务机构及项目经理

东软公司社保事业部将为本项目成立几个专门的工作小组，其中将负责完成主要的现场工作的人员有：

 负责本项目需求调研的需求调研小组;  负责本项目开发的项目开发组;

 负责系统的现场安装、调试、培训的系统工程师小组;

 负责平台系统正式移交后，在承诺的服务周期内提供售后服务支持的项目维护小组;

这些小组的东软公司工程师将提供最直接的现场服务工作，并且将和本项目实施小组的工作人员们一道完成现场开发和实施工作，提供第1级的技术服务支持。

东软公司将派出经过专业技术培训，有丰富的新农保信息系统建设经验，熟悉社保项目业务知识，能够对系统运行状况做出正确判断的优秀人才来参加本项目的现场实施和维护工作。

他们是设立在用户现场的系统服务队伍，能够迅速解决本项目的实际问题，提供本地化的第1级服务。

同时，由于此项目涉及双方部门都非常多，参与人员较多，协调难度大，工作量大，因此为了更好地完成本项目的实施工作，东软公司将任命有长期社保行业信息化建设经验的负责人作为本项目的项目经理，其职责如下：

1)作为东软公司与用户方工作组间的代表，与用户对口直接接触，第一时间获取用户信息、意见和需求，并协调东软公司内部各方面做出及时的相应;

2)作为整个项目实施计划的执行负责人和监督者，负责协调、监督东软公司各部门按时、圆满地完成既定的实施工作任务，保证工程进度按时完成，保证第13页

工程质量达到项目要求;

3)作为整个项目的项目经理，在用户现场担任东软公司项目实施的总负责人，协调人员安排、问题协商与解决等工作。

4.2.2 第2级服务：东软公司南京分公司以及华东大区技术人员

负责本级任务的主要是华东大区和南京分公司的软件和系统集成工程师。  东软华东大区系统工程师(负责安全体系的技术支持和售后维护)  东软华东大区软件工程师(负责中间件、数据库系统的技术支持和售后维护)

 南京分公司软件工程师(负责应用软件、中间件、数据库系统的技术支持和售后维护)

他们为本项目设立的规模化系统服务队伍，能够迅速赶到现场解决系统的实际问题，提供本地化的第2级服务。

4.2.3 第3级服务：社保平台系统建设专家

对于无锡金保信息系统建设项目，东软公司将派遣最优秀的IT专家参与到该项目中，这其中包括：

 负责全面开发管理的高层专家

 负责全面质量管理的质量保证人员(包括负责QA质量管理和QC质量控制)

 负责系统测试的测试专家

 加入到项目组中的系统平台建设技术总负责人、总体和详细设计总负责人，加入到系统工程师小组中的硬件及网络技术专家等

这些专家为无锡社会保险信息系统建设项目提供系统级的技术基础平台建设于咨询，总体规划，详细设计、硬件及网络技术支持等服务，作为第3级服务，可与无锡市劳动保障业主方建设实施小组进行直接的技术交流。

第14页

4.2.4 第4级服务：东软总部技术支撑部门

东软公司总部沈阳东大软件园，下设有“研发部”，“网络软件事业部”，“培训中心”，“客户服务中心”，“网络技术支撑中心”等部门，都可为无锡金保系统建设项目的建设提供全方位基础核心系统软件及硬件和网络技术支持，还包括进行各种技术培训，解决各类技术疑难问题，计算机新技术的应用等，以上可作为第4级层次的技术服务。

第15页

5 运维服务总体方案

5.1 无锡金保工程建设情况

无锡金保工程涉及的业务面广，系统复杂度高，开始就提出了一体化紧耦合的设计思想，并且要实现金保工程中的业务经办、公众服务、基金监管、决策支持四大功能以及统一的社保卡系统建设。

无锡金保工程从2004年5月开始启动，经历了方案确定、需求调研、系统设计、开发、测试、试运行的过程，社保系统于2005年10月8日正式启动使用。包含的子系统有养老保险、失业保险、医疗保险、工伤保险、生育保险、儿童统筹、互助医疗、退休人员社会化管理等系统和劳动就业系统，目前各系统都在正常运行。

截止到2009年，系统共有参保单位两万多家，全年养老、医疗、失业、工伤、生育五大保险参保人数分别达到183.88万、 207.21万、128.22万、138.1万和123.55万，覆盖率均在98%以上。纳入“城保”、“地保”、“新农保”三个层次的农村养老保障人数达到169.44万，综合覆盖率达89.9%。联网的定点医疗机构有300多家，药店将近150家，同时东软还为参保单位提供了单位报盘系统，不仅方便了参保单位，也节省了经办机构二次录入的工作量，提高了工作效率。

5.2 金保工程总体架构

无锡是东软在社保信息化建设进程中遇到的包含软件功能最全、覆盖领域最广、开发周期最紧的城市之一。东软充分认识到此项目在全国的影响力，对此项目非常重视。我公司经过对无锡金保工程多年的建设对无锡市金保工程应用软件业务需求以及系统设计原则、设计思想和系统的技术路线都非常熟悉，结合信息技术的发展及东软在劳动保障行业信息化建设中的经验和产品，东软公司设计的系统逻辑结构模型，如下图所示：

第16页

图5-1金保工程逻辑结构图

如上图所示，无锡市劳动保障信息系统以电子政务标准体系和劳动及社会保障标准体系为指导，以投融资与运营模式和项目实施监理模式为依托，按照多层架构的模式将系统自上而下分为表现组件与业务组件、业务运作支撑平台、IT基础设施三个层次，监控及管理、信息安全是贯穿三个层次的两大体系。

5.2.1 IT基础设施包括网络及硬件平台层和数据层

网络及硬件平台包括网络设备、服务器主机、操作系统、存储设备等资源，是应用软件开发、运行的基础平台。网络平台层的构成具有个性化的特征，不同的应用环境具有不同的主机设备、不同的网络设备、不同的存储介质、不同的操作系统。因此这要求建立在网络平台层之上的应用支撑平台层必须具备跨平台的特性，只有这样才可延伸原有资源的生命周期，避免硬件设施的重复投资。东软的统一电子解决方案框架平台是基于J2EE技术建设的，因此系统具备跨操作系统的特性，从而可最大程度地保护用户投资。其中应用服务器中间件采用BEA Weblogic中间件，数据库采用Oracle。

第17页

5.2.2 基础服务应用平台

应用支撑平台层起到保证事务完整性、响应大规模并发处理、支持异构系统的互联，并对应用数据的安全性进行保障，是三层结构不可或缺的重要组成部分。本系统采用BEA Weblogic Platform、BEA TUXEDO为J2EE应用服务器和消息/交易中间件。

业务支撑平台层是多层架构业务系统的核心支撑部分。东软的业务支撑平台以J2EE应用服务器和消息(交易)中间件为核心依托，包括UniEAP、UniFlow、UniDXP、Neusoft IM UM四个东软自主版权的通用中间件产品。UniEAP是三层框架开发平台，为实现业务应用的快速开发提供动力和保障;UniFlow是工作流平台，用于管理业务系统易变的流程;UniDXP是数据交换平台，用于数据传输和数据转换以及应用系统集成;Neusoft IM UM是统一消息平台，主要用于公共服务系统中将手机、语音等多种渠道的消息统一成一种消息。业务支撑平台将各系统中的共性功能抽象、封装并统一解决，提供丰富的功能组件，使用开发人员可以将主要精力集成在业务逻辑，而不是复杂的技术实现。

业务支撑平台中UniEAP是东软的核心企业应用平台，在下面章节中将做详细介绍，在今后的运维服务系统开发中，我公司也将充分利用该开发平台的优势，利用平台中的一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。

5.2.3 业务组件与表示层

业务逻辑层实现了应用系统所有的业务组件，业务组件基于应用支撑层进行构建开发，并且业务组件设计开发遵循“高内聚、低偶合”的思想，使业务组件之间可以保持相对独立，并且通过表示层个性化定制业务组件。

用户通过系统表示层实现对业务系统的操作与交互，系统表示层设计遵循操作方式简便、灵活、友好;操作界面设计风格统一，符合业务办理流程规范，便于操作员学习掌握等标准进行设计，并可以根据每个用户使用特点和角色的不同，形成个性化的应用界面。表示层提供业务展现、内容管理、个性化定制、访问控制、搜索服务等功能。

第18页

5.2.4 东软通用企业应用平台—UniEAP 无锡市劳动保障信息系统系统的设计和开发将基于东软自主研发的通用企业应用平台UniEAP进行开发。下面对UniEAP的结构、功能和特点进行简要介绍。

UniEAP就是Universal Enterprise Application Platform(通用企业应用平台)。如果从更广义的角度来讲，又称为“组件框架”，即Component FrameWork。UniEAP是东软构建于多层架构的，以J2EE规范为核心技术实现模型的多层应用开发、运行的框架和平台。它不仅仅是一个框架，它还提供了一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。

UniEAP不是Application Server，它与BEA Weblogic Application Server、IBM WebSpere Application Server、Sun ONE Application Server、Tomcat、JBOSS均不属于同等性质产品。它是一个基于组件技术的快速开发和运行平台，它的部分组件最终同业务应用组件一起部署到Application Server上。

5.2.4.1 通用企业应用平台的结构

UniEAP在整体框架上采用典型的MVC模式，集中了大量功能强大、灵活易用的功能组件。UniEAP既支持C/S/S结构也支持B/S/S结构，其中两种体系结构共用同一套业务逻辑处理服务，只是表现和控制层不同。  UniEAP统一的业务逻辑层

第19页

商业逻辑层以EJB/Java Bean技术为实现手段，提供了对象持久化及打印、邮件等商业逻辑组件。设计要点如下：

1.用EJB和JavaBean做商业逻辑;

第20页

2.通过统一的服务组件基类调用安全、日志、工作流、规则等引擎式服务构件;

3.在管理管理信息系统中对象持久化是一个关键性服务，单一的数据库接口解决全部问题并不现实，因此采用由OP层统一包装，统一管理，但暴露多种操作接口的方式来解决。对象持久化接口提供面向对象和面向过程两大类，具体支持四种方式：

1) 得到connection 2) 简单的sql execute封装

3) 可持久化的数据总线DataSet,通过其xml接口可发送到页面) 4) DAO(单表抽成的可持久化的实体类对象)

平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。  C/S/S结构的视图层和控制层

第21页

C/S/S结构的框架设计基本上采用劳动部社保核心平台二版的结构，这是一套经过验证是健壮稳定的架构。与社保核心平台二版略有不同的是：由于业务逻辑层采用我公司统一的通用企业应用平台，所以在控制层最后一道任务分发环节Event调用业务逻辑服务组件时，是通用BSFactory利用“工厂”模式来获取服务组件对象的。这样做的好处是可以以透明的方式处理EJB和Java Bean的服务对象。

C/S/S结构中客户端的设计要点是：

第22页

1. GUI采用传统的Window界面，以Delphi为开发工具;

2. 客户端通过统一的动态库函数与服务端的门户MainServlet通讯，通讯的内容以XML为数据格式，整个通讯协议完全模拟SOAP协议;

3. 客户端的设计在分层基础上对类进行了适当的归类。做到类之间的调用关系明确。类的责任单一。类之间的依赖关系简单。编程实现较为方便。下面简略的介绍一下编程常用的调用关系。为了说明上的方便，图中把框架完成的调用关系去掉了。调用关系简图如下：

IVODAOServerDCMSieaf.dllServerClientDCM

C/S/S结构中控制层的设计要点是：

1. 整个控制层的设计思路参考B/S/S结构中的Struts框架。MainServlet可以映射到Struts的ActionServlet，而RequstProcesser + Event可映射到Struts的Action;

2. 但与Struts不同的是它与客户端之间传递的均是XML，没有表现语义，因此它要增加XML信息过滤器、转换器等功能;  B/S/S结构的视图层和控制层设计

第23页

界面层以JSP/XML/XSL/JS技术为主要实现手段，为系统开发提供了一系列功能强大的组件，主要有以下几大类：

1. 轻型控件：封装所有的HTML Form元素和按钮，提供显示、标准行为控第24页

制和校验功能;

2. 重型控件：包括DataWindow，目录树，Tab页等具有复杂功能属性的控件;

3. 局部刷新和对话框：采用微软提供的局部刷新控件，提供局部刷新功能，并封装通用的页面对话框;

4. Object：Applet和COM，用于复杂界面操作和客户端本地化操作。请求控制层以Servlet技术为实现手段，综合运用struts框架和WorkFlow引擎，以单点入口的方式统一控制请求。设计要点如下：

1. 采用Structs控制请求和业务流程，拓展Struts的ActionServlet和DispatchAction作为UniEAP的流程控制基类;

2. 组织机构和权限管理模块进行身份和权限认证，从视图、操作、数据三个层次控制权限行为;

3. 日志和异常处理负责系统信息的记录;

4. 封装UniWorkflow的接口，在流程多变的业务系统中用UniWorkflow定制和控制业务流程。

5. Action本身并不处理业务逻辑，而是通过统一的BSFactory从EJB Container获取Business Service Componets处理业务逻辑。

5.2.4.2 通用企业应用平台的功能

UniEAP作为我公司自主研发的各种管理信息系统(社保、电力、电信、证券、OA、CRM、ERP等)的一个整体的框架和平台，为应用系统的开发提供一个统一的模型，为应用系统的知识积累和模式提炼提供技术途径，为应用系统定制提供技术手段，解决具有共性的技术问题，提供具有通用性的系统组件，以达到简化应用系统的开发过程、提高应用系统开发效率、提高共享组件的重用率、提供应用系统开发的质量、加强应用系统之间的融合性、加强应用系统的重组能力、加强应用系统可定制的能力、加强对新技术的跟踪和适应能力的目的。

大型的平台才能支持超大型的多功能的软件，应用共性平台技术是社会保障行业IT建设规模化所必经的历程。要达到规模化系统建设就不得不搭建这样包含技术标准和行业标准的平台，UniEAP就是这样的一个平台。

第25页

标准化技术是构建共性平台的灵魂。从技术本身的发展来说，过去各个IT厂商注重突破性的技术，大家走到一起发展，标准化就变成了一个首要技术。只有标准化，使得客户获得的是所有软件提供商的精华浓缩，使世界上所有的软件精品找到公共的接口，所以标准化技术使得系统达到最优。在软件方面，在标准化技术方面体现为标准的组件框架和标准的软件部件。东软的每一个软件部件都是按照标准化软件部件的要求开发的，有着一个公开的标准化接口，可以很方便地嵌入到组件框架平台当中。标准化的软件部件是解决方案得以快速实施的一个重要的技术保证，一方面满足了客户可以根据自己的情况选择不同的部件的需求，另一方面也使软件开发更加规模化，软件产业更加工业化。

5.2.4.3 通用企业应用平台的特点

1)UniEAP采用了三层结构的技术框架，为应用系统提供了一个非常良好的结构，应用系统将来的升级、扩充、修改和定制都非常方便。当用户需要发生变化或需要对某个功能进行修改的时候，可能只需要对某一个层次的组件进行修改，而不会对整个系统的结构发生影响。

2)UniEAP支持WWW技术，允许用户通过WWW浏览器来操作。简化了系统安装和维护的难度，降低安装和维护的成本，由于界面操作风格一致、操作简单，也降低了对用户培训的要求。另外，由于支持WWW技术，为将来支持其他的客户端和移动用户也提供了技术上的可能。

3)UniEAP提供了最基本的系统组件，如用户管理、权限管理、组织机构管理、工作流管理、菜单管理、数据库管理等功能，简化了应用系统开发的过程，提高了工作效率。而且在将来应用系统开发的过程中，也可以提取和积累各种通用组件，增强系统功能。

4)UniEAP实现了界面层和数据层的统一管理，在应用系统的开发过程中，不需要对界面层和数据层进行编码，只需要通过系统工具对界面层和数据层对象进行定义即可。这样不仅简化了开发过程、提高了开发效率，而且在界面层和数据层需求发生变化和需要重新定制的时候，可以通过简单地修改界面层和数据层的进行来完成。

5)基于UniEAP应用框架，应用系统开发员可以集中精力开发业务层组件，第26页

不需要过多地考虑各种技术问题和其他方面的实现细节，也提高了业务层组件的独立性，减少与其他模块的关联，便于将来扩充、升级和修改。

6)UniEAP提供了一个统一的界面层，该界面层包括菜单管理、视图管理、界面权限管理、界面操作逻辑管理、界面元素自动生成等功能。应用系统开发员只需要定义好自己的界面层对象，不需要把精力花费在界面逻辑和界面操作的实现上，简化应用系统开发的过程，而且所有基于Uni EAP的应用系统界面风格一致、统一管理、操作方便，方便了用户学习和使用，也降低了培训和维护的费用。

7)UniEAP提供了一个通用的数据层，业务系统不需要重新开发，只需要定义自己的数据层对象，因次简化了应用系统的开发过程。

8)从界面层到数据层，UniEAP都充分体现了业务对象之间的各种关系(一对

一、一对多、多对多等)，并且提供了充分的实现手段，使得应用系统实现业务对象之间的复杂的逻辑关系成为可能，而且非常简单。方便了业务系统。

9)UniEAP在很多方面提供了通用的模式和技术规范，如组件设计、数据库设计、界面设计等，可以为应用系统的开发提供有效的指导和参考。

5.2.5 基于通用企业平台的运维服务

由于无锡市劳动保障信息系统系统的设计和开发基于东软自主研发的通用企业应用平台UniEAP进行开发，所有东软有信心做好无锡软件运维服务。

UniEAP提供了统一的模式和共享组件，降低了系统间的耦合度、减少了应用系统开发的模块，因而能够准确地控制应用系统开发的过程，有效地提高应用系统开发和维护的质量。

按招标文件要求对于采购单位提出的应用软件升级需求，由现场工程师与采购单位业务部门进行沟通，了解业务部门对应用软件的升级需求，按双方商定的开发进度进行开发和实施。UniEAP采用组件技术，系统具有非常好的可扩充性，对新技术的发展也具有很好的适应性。这是因为采用了组件技术后，可以开发出各种共享组件和通用组件，也可以集成第三方开发的组件，组件的升级也非常方便，而且随着组件技术的标准化，不同的组件标准之间也可以实现通讯，因而无论采用哪种组件标准都具有可扩充性和兼容性。

因此，应用升级中，对系统平台充分了解的情况下，能够较准确的规避升第27页

级过程中的技术难点，提出多种适合无锡劳动保障系统的升级方案，能够较准确的根据企业平台的特点估计工作量，对升级时间进度准确把握，让客户方对升级的进度和时间安排做到心中有数。

另外，由于由于UniEAP采用了组件技术，提供了很强的可定制能力，因而应用系统能够在此基础上能够建立面向具体行业的业务模型，在每一次为具体用户定制业务系统的时候，都可以积累经验，提高业务模型的通用性，以便适应更加广泛的用户需求。

5.2.6 应用逻辑实现策略

图5-2架构技术实现策略

无锡金保应用软件系统将涉及社保、劳动、局机关等多个政府机构及与其他政府机构和内部系统的接口，软硬件基础设施复杂，因此在系统的实现上必须采用标准的技术，以求跨操作系统平台、跨数据库平台、跨中间件平台。基于此本公司在整体技术实现路线上采用基于J2EE 和web service组件的技术构建应用逻辑。

应用逻辑层和公用服务层的每个功能模块均是一个相对独立的组件，这些组第28页

件的开发和部署保持相对的独立性，而且在未来很可能是由不同的团队开发和部署的，也是可以相对独立的进化的。每个组件通过定义良好的接口，向外部提供服务。这些服务的获取者可能来自客户端、可能来自其他组件。这种基于组件的设计可以达到比较好的重用性。在J2EE 的架构下，各组件通过J2EE 标准定义的RMI 协议，向各客户组件提供服务。

业务操作员及公众信息查询人员通过标准的HTTP 协议或安全的HTTPS协议访问社保管理信息系统及公共服务系统。

公用服务层同样以组件的方式实现，可以与业务逻辑的组件的部署在同一应用服务器上，也可以部署在不同的服务器上。如果业务逻辑层的组件和公用服务层的组件驻留在同一进程空间中，则通过对象间的消息机制通讯，如果驻留在不同的进程空间中，则通过标准的RMI-IIOP 的协议通讯。

在管理信息系统中，最重要，难度最大的是数据操作的实现策略，因为在任何一个管理信息系统中“信息”都是系统的核心，几乎每一个业务逻辑都与数据操作相关，因此本方案将对数据操作的实现策略进行详细阐述：

在J2EE 的架构中，对数据库的操作有两种方式，一种是组件管理的持久性(Bean managed persistence)，也即组件自行管理数据库操作的完整性和一致性;另一种EJB 容器管理的持久性(Container Managed Persistence)，也即通过J2EE的应用服务器提供的对数据库操作的服务。考虑到性能和负载方面的因素，我们建议采用结合事务处理服务器和组件管理的持久性的方式，管理对数据源的操作。

介于业务逻辑层和数据服务器之间的是事务处理服务器，交易处理服务器负责处理实际的对数据源的操作，保证多个数据读写请求对多数据源的操作的原子性、一致性、隔离性和持久性。同时通过交易处理服务器，进一步降低业务逻辑层和数据源之间的耦合度。逻辑架构中的交易服务和查询处理服务均驻留在事务处理服务器上，操作数据库，保证交易的完整性和查询的性能。

J2EE 组件与事务处理服务器通讯的机制，与事务处理服务器的平台和应用服务器的平台有关。事务处理服务器一般需要在数据库服务器上安装相应的组件，通过紧密集成的数据库访问机制，访问数据库。

介于交易处理服务器和业务逻辑层之间的是公用的数据存取服务，这一层封第29页

装业务逻辑和公用服务层其他组件对各种数据源的读写操作，直接管理与数据库、目录服务器、应用集成服务器之间的数据交换请求，进一步降低业务逻辑与交易服务器、目录服务器等数据源之间的耦合度。

在基于J2EE 应用架构下，将数据存取服务独立出来的原因如下：  采用诸如bean 管理的实体bean、会话bean 等组件，需要从持久存储和诸如遗留系统、B2B、LDAP 等等其他数据源中检索数据，以及进行数据存储等操作。

 根据产品供应商不同，持久存储API 差别很大。一些数据源拥有非标准化或私有的API。这些API 和其能力同样根据存储的类型不同也有差别.这些存储类型包括RDBMS、面向对象数据库管理系统 (OODBMS)、XML 文档、纯文本文件等。这样存在如下缺点，即访问这些系统的API 很不统一。

 组件通常使用私有的API 来访问外部或遗产系统，以便于检索和存储数据。当组件中包含特殊的访问机制和API 时，组件的可移植性直接就受到影响。组件需要透明于实际的持久性存储或者数据源实现，以便于提供到不同供应商产品、不同存储类型和不同数据源类型的更容易的移植性。

解决以上的问题，需要采用数据访问对象(Data Access Object，DAO)来抽象和封装对数据源的访问。DAO 管理着与数据源的连接以便于检索和访问数。

下图说明采用数据访问对象提供数据存取服务的实现。

第30页

图5-3实现示意图

其中业务对象代表数据客户端，该对象需要访问数据源以获取和存储数据。数据存储对象是数据存取服务的主要对象，数据存储对象封装业务对象对数据源的访问，以保证对数据源的透明访问，业务对象也把数据加载和存储操作委托给数据存取对象。事务处理服务负责完成对数据对象的实际存储和加载的工作，应用集成服务实际完成将数据发布到外部系统以及从外部系统读取数据的职能。值对象代表用作数据携带的值对象。数据存取对象可能使用值对象来把数据返回给客户端。数据存取对象也可能使用值对象接受来自于客户端的数据，并更新数据源中的数据。

下面的时序图表示使用数据存取对象读取数据库数据、更新数据库数据的过程：

第31页

图 5-4过程示意图

业务对象负责完成应用逻辑的处理，通过数据存取对象向事务处理服务器发出读取数据的请求，事务处理服务器将数据库中的数据读取出来，数据存取对象创建值对象，将值对象返回给业务对象。

5.2.6.1 核心经办业务技术架构概述

为了开发一套可以适应于无锡市两区本地业务特点的业务系统，东软公司在本项目应用软件系统中综合利用劳动部核心平台的架构特点，基于劳动核心平台进行开发，设计实现基础服务应用平台，在此平台基础上构建可拆可合、可配置的业务组件。下面对其结构、功能和特点进行简要介绍。

基础服务应用平台，如果从更广义的角度来讲，又称为“组件框架”，是构建于多层架构的，以J2EE规范为核心技术实现模型的多层应用开发、运行的框架和平台。它不仅仅是一个框架，它还提供了一系列的组件和工具以及相应的开发方法，进而达到快速建设应用系统的根本目的。

基础服务应用平台不是Application Server，它与BEA Weblogic Application Server、IBM WebSpere Application Server、Sun ONE Application Server、Tomcat、JBOSS均不属于同等性质产品。它是一个基于组件技术的快速开发和运行平台，它的部分组件最终同业务应用组件一起部署到Application Server上。

第32页

图5-5示意图

基础服务应用平台的结构简图如上图所示，各组成部分的功能及职责如下：  GUI：用户界面层

 呈现用户交互界面  提供表现控件  界面控件布局

控制界面的表现，包括具体的设备和与设备相应的UI的控制。功能限于界面的具体在设备上的展现(如：Browser对html的解析)、界面表现的控制、界面组件的布局。

 Interaction Control：交互控制层

 定义业务逻辑的逻辑表单  开启和关闭事务

 响应用户界面层的业务请求  Transaction Management：事务管理提供事务管理机制

将基础服务纳入统一的事务管理范畴  Application Logic：应用逻辑组件

 处理事务规则及功能  提供原子业务功能

 Application Service：基础服务组件

第33页

 统一资源访问服务  身份认证服务  权限管理服务  报表服务  日志服务  审计服务  其它服务

5.2.6.2 核心经办业务技术架构设计

基础服务应用平台的技术架构如下图所示，它是对上节中架构简图的细化。

图5-6架构简图

 Web Container设计

GUI层由Client和UIM两层组成。基础服务应用平台同时支持浏览器、传统客户端、PDA等多种用户界面模式。UIM是用户界面控制层。

Client层以JSP/XML/XSL/JS/PB技术为主要实现手段，为系统开发提供了一系列功能强大的组件，主要有以下几大类：

轻型控件：封装所有的HTML Form元素和按钮，提供显示、标准行为控制第34页

和校验功能;

重型控件：包括DataWindow，目录树，Tab页等具有复杂功能属性的控件; 局部刷新和对话框：采用微软提供的局部刷新控件，提供局部刷新功能，并封装通用的页面对话框;

Object：Applet和COM，用于复杂界面操作和客户端本地化操作。

UIM层以Servlet技术为实现手段，以struts框架为依托，采用单点入口的方式统一控制请求。设计要点如下：

采用Structs控制请求和业务流程，拓展Struts的ActionServlet和DispatchAction作为基础服务应用平台的流程控制基类;

Action本身并不处理业务逻辑，而是通过统一的Ineraction Object Factory从EJB Container获取Ineraction Object处理业务逻辑。

 EJB Container设计

商业逻辑层以EJB/Java Bean技术为实现手段，提供了对象持久化及打印、邮件等商业逻辑组件。设计要点如下：

用EJB和JavaBean做商业逻辑;

通过统一的服务组件基类调用安全、日志、工作流、规则等引擎式服务构件; 在管理管理信息系统中对象持久化是一个关键性服务，单一的数据库接口解决全部问题并不现实，因此采用由OP层统一包装，统一管理，但暴露多种操作接口的方式来解决。对象持久化接口提供面向对象和面向过程两大类，具体支持四种方式：

1) 得到connection 2) 简单的sql execute封装

3) 可持久化的数据总线DataSet,通过其xml接口可发送到页面) 4) DAO(单表抽成的可持久化的实体类对象)

平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。

 Web Container与EJB Container请求模型

第35页

图5-7Web Container与EJB Container请求模型

基础服务应用平台在逻辑服务组件上借鉴Spring的实现机制，采用类似Web Service的UDDI所定义的、由基本的三个角色构造的“Service Requestor — Service Registry — Service Provider”三角型访问模式，所有发布的Interaction Object都在Interaction Object Factory中注册，且可以同时存在多个Provider(如在J2EE体系中就存在Java Bean、EBJ、Web Service三种典型的Provide)。Action相当于Service Requestor，它调用Interactional Object时先通过Interactinal Object Factory根据注册信息找到Interactional Object的Provider，然后得到由Provider提供一个Interactional Object的stub，最后再调用Interactional Object的service method对请求进行处理。这所以这样做的一个根本目的是：将逻辑组件开发和部署分开，由工具插件统一负责组件部署，业务开发人员只需要用最简单的语言完成业务逻辑即可。

基础服务应用平台专门为Interactional Object的访问定义了一个“Interactional Object Factory”层，这一层主要考虑的是屏蔽在Action中对Interactional Object的不同调用方式，使得在不同的环境下的移植变得很方便(不管是何种组件的调用方式，返回给Action的服务接口都是相同的，从而保证Action中代码的可复用性)。

5.2.6.3 技术架构中各层对象在创建过程中的依赖关系

架构中的几层在“创作”过程的依赖关系是什么，即凭什么知道要创建几个AppLogic、几个Interaction、几个Action、几个PB/JSP界面?

下图阐述了几层对象在创作过程中的依赖关系，它们之间的连线是本节说明第36页

的重点，所以颜色调成了红色，对这些线的说明调成了蓝色，以显突出。注释文字可能有点不清楚，拷在下面：

 用户界面需求会决定最终的界面窗口是什么样子的。我们提倡在需求调研时就把大部分界面都确定下来。

 界面会决定有什么样的Interaction，以及Interaction都完成什么样的功能。但并非一个窗口就完全对应一个Interaction，一个窗口可能会用到多个Interaction，而一个Interaction也可能被多个窗口调用。但界面中的一次请求肯定对应一个Interaction对象中的一个方法，要不然怎么管Interaction叫“交互对象呢”?一次交互就是一个完整的事务。  一般说来，一个Interaction对应一个Action，Action是替Interaction收发HTTP请求的“门童”。  界面间接决定了Action的命运。

 逻辑需求和行业经验会决定设计出多少AppLogic，落实到具体的模型就是有什么实体类，有什么控制类。其中实体类会在编码阶段被拆分为DataSet、DAO、行为类。

 Interaction是GUI层和BL层的“和事佬”，它主要是要满足GUI的请求，但也要照顾AppLogic的脸色，必要时要对GUI和BL做个折中处理。

图5-8示意图

前后台交互文档中对说明哪个Action的哪个方法来响应界面请求，入参、出参是什么，看了交互文档后就一目了然了。这只是表面现象，本质上是界面在第37页

向后台说明，你的哪个Interaction和哪个方法响应我的请求。

5.3 维护服务计划

按招标文件要求，软件服务日期从合同签署日起到2015年5月31日止。软件外包服务计算到次年的5月31日，如第一年为合同签署日到2011年5月31日，第二年从2011年6月1日到2012年5月31日，第三年从2012年6月1日到2013年5月31日，第四年从2013年6月1日到2014年5月31日，第五年从2014年6月1日到2015年5月31日。

我公司如果有幸中标，将严格按照合同签订服务日期进行软件维护服务，并在服务期间对每个软件服务项目(包括新业务开发项目和日常事务)都需要给出项目开发完成进度、工作量(人月)、人员安排及项目管理措施，得到采购单位的同意后按计划组织实施。

5.4 软件维护方案 5.4.1 远程支持服务流程

我公司为用户提供400免费技术服务热线(400-655-6789)，在接到用户请求后，根据请求情况协调公司资源，第一时间给用户反馈并解决问题。

第38页

用户接线员登记和查询应用软件系统工程师平台系统工程师项目组汇总解决售前技术支持工程师高级培训教师系统专家疑难问题图表5-1技术支持服务热线工作流程图

1、诊断故障并提交故障诊断报告

根据系统运行过程中出现的系统故障或其它异常情况，及时进行故障诊断，并提出故障诊断报告。故障诊断报告的主要内容包括：故障现场情况记录、故障的级别和紧急处理过程记录等。

2、制定系统维护和故障恢复的实施计划

根据提交的故障诊断报告，制定系统维护和故障恢复的实施计划。按照制定的计划实施系统维护工作。

3、管理、监督维护计划的实施

组成系统维护工程管理和监督工作组，全面负责管理和监督系统维护工作实施过程(应包含用户方与项目承包商双方)。并根据系统维护实施的各个阶段提交维护工作报告。

4、确认维护工作完成并提交维护报告

在系统维护工作完成后，由系统维护人员提交系统维护工作报告，由用户方项目组的技术人员对系统维护情况进行测试并予以确认。

5、提交成果

每次系统维护工作完成后，都应提交如下的报告、记录等文档等资料：

第39页

 故障诊断报告

 系统维护和故障恢复的实施计划  维护工作阶段报告  系统维护工作报告

说明：紧急情况下，以排除故障，满足用户需要为首要任务，可以进行紧急处理，但事后要补充相应文档与记录。

5.4.2 现场服务流程

众所周知，最优的售后服务是一个项目的承建商必须做出的承诺。但是，如何根据用户的实际情况(人员素质、计算机应用水平、系统的要求等)，做出切合实际的项目售后服务计划书，才是用户关注的问题。优质的售后服务也一直是我们东软公司在经营活动中最基本的原则。东软公司的技术支撑部门担负着专业的服务工作，无论是在系统的安装调试过程中还是在系统投入运行之后，无论发生任何问题用户都可以得到最快的响应，售后服务流程如下图所示：

第40页

图表5-2售后服务流程

社会保险的组织结构、计算机应用水平、系统对人员素质要求等情况的分析，我们认为：社会保险信息系统稳定运行是保证本项目建设成功的一项关键因素。

东软公司提供的服务内容包括：

 应用软件运行维护：应用软件自身缺陷的调整，为客户及时解决日常运行中出现的问题。

 根据政策和经办规程调整，及时响应需求变更(含与金保工程其他子系统和外部机构的接口)，并在业主要求的时限内完成对应用系统的修改或调整。

 应用软件技术改造与升级服务：主动或应客户要求，将最新的技术成果和先进的管理模式升级到原有系统，使应用系统的永远保持先进性。

 数据库支持服务：东软公司提供通过Oracle OCP认证的专职工程师第41页

为客户提供长期的数据库优化及技术支持服务，以及异常数据修正、批量数据处理等数据维护工作。

 定期系统巡检：在系统维护期过后，按照签订的维护合同，定期等到现场对应用系统运行情况，主机运行情况，数据库系统情况进行检查和维护。

 客户新技术培训服务：为使客户技术人员能及时掌握最新技术，东软公司每年组织客户在沈阳、大连信息学院进行技术学习。  现场诊断与客户回访：东软公司启动心贴心客户服务计划，每年选一批客户，由东软公司领导组团对客户进行回访和现场系统诊断，对诊断发现的问题跟踪解决。

 网络与硬件服务：虽然本次只是软件招标，但离不开网络及硬件系统的支持，东软公司愿凭自身的技术实力，为本项目提供硬件调试与网络技术支持服务。  客户端服务

(1)收集最终用户对系统的使用意见和建议; (2)对最终用户进行操作指导; (3)客户端故障判断和排除指导;

(4)单机版数据转入系统的操作指导和技术支持; (5)服务方式以提供远程服务为主。

5.4.3 服务内容

(1)协助检查数据库运行情况，及时处理数据库故障; (2)协助定期对数据库进行优化，提高数据库运行效率;

(3)协助检查应用软件中间件运行情况，及时优化并处理中间件故障; (4)接受全市各级劳动保障经办机构数据维护申请，在采购单位的授权下及时进行数据维护处理;

第42页

中标单位接到采购单位通过电话，信函，传真，电子邮件等方式提出关于软件的服务请求后，一个工作日内给予响应并提供服务，不得推诿。应及时响应系统的技术支持，如系统出现问题，须提供7*24小时技术支持服务;

中标单位应按采购单位要求负责全市新定点医疗机构的许可证制作发放工作;

(5)接受全市各级劳动保障经办机构软件维护申请，对应用软件进行完善性修改，处理应用软件存在的问题;

(6)完成劳动就业系统及社会保险信息系统和月度初始化工作; (7)按照部、省要求从生产库向交换库转换数据，生成指标数据上报; (8)配合系统硬件的维护，及时处理涉及数据库和应用软件相关工作; (9)配合完成日常的统计分析报表，完成特殊的查询统计需求; (10)在采购单位的统一安排下,按相关政策要求进行数据批量处理工作,如:养老调资、医疗帐户调整、失业金上下限标准调整等,整个过程需要建立有关数据安全、备份、测试、验证、应急恢复等机制;

(11)医疗历史数据迁移，医院信息管理系统接口支持。

5.4.4 客户服务质量文件

在客户服务中，东软公司通过以下文件来保证服务的规范和质量：  客户服务管理：

 《客户服务管理》，售后技术维护，客户问题管理  客户问题办理：

 《客户问题受理规范》，问题记录，问题分发、办理监督，问题回复，问题月报

 《故障诊断报告》，故障现场情况记录、故障的级别和紧急处理过程记录等

 《系统维护和故障恢复的实施计划》

第43页

 《维护工作阶段报告》、《维护工作总结报告》  《系统维护验收测试计划》  《维护工作验收报告》  客户满意度测量：

 《客户满意度测量》，收集满意度，统计分析(月、季、半年、全年)，提出改进措施

 客户培训的相关表格：(为把客户培训工作做得更好的辅助性表格)

 《客户培训申请表》  《客户培训费用确认表》  《客户培训邀请函》  《客户培训邀请函回执》  《客户培训计划》  《客户培训记录》  《客户培训调查表》  《客户培训评估表》  《客户培训总结》

根据以上的质量保证体系规定，东软公司为无锡社会保险信息系统建设项目设计的执行一次较完整的系统维护过程的基本步骤如下：

1) 根据无锡社会保险信息系统建设项目运行过程中软硬件出现的系统故障或其它异常情况，双方合作及时进行故障诊断，并提出《故障诊断报告》;

2) 根据提交的《故障诊断报告》，制定《系统维护和故障恢复的实施计划》，东软公司按照制定的计划实施维护工作;

3) 双方共同组成系统维护工程管理和监督工作组，全面负责管理和监督系统维护工作实施过程;

4)东软公司根据系统维护实施的各个阶段具体情况提交《维护工作阶段报告》，在系统维护工作完成后，由系统维护人员提交《维护工作总结报告》;

5)最后根据《故障诊断报告》、《系统维护和故障恢复的实施计划》、《维护工作阶段报告》和《维护工作总结报告》，东软公司技术人员和用户方项目组的技术人员一起，讨论确定《系统维护验收测试计划》;并依此对系统进行测试验第44页

收，测试合格提交《维护工作验收报告》维护工作完成，否则继续整改。

几年来的实践证明，基于ISO9000：2000和CMM的质量保证体系的规范化质量管理为东软公司的发展创新、为客户提供更高质量的软件产品发挥着至关重要的作用。东软公司仍将充分利用规范化的客户服务体系，依靠多年来的成功经验，在项目的全过程中为无锡社会保险信息系统建设项目的建设提供最优良的服务。

5.5 应急维护方案

系统在运行过程中一旦出现紧急重大问题，导致新系统不能正常运行的情况下，就需要启动售后服务紧急预案，以保证业务经办的正常进行。

5.5.1 应急预案目标

在一旦出现紧急情况下，需要启动应急预案的情况下，应急预案必须以保证业务经办正常运行为目标。

5.5.2 应急预案具体措施

应急预案需要从业务系统、数据库、网络平台三个方面来考虑应急处理措施，在出现紧急重大问题的情况下，我公司会在最短时间内作出故障响应，第一时间由驻现场维护人员启动备份系统，同时将指派具有解决故障能力的软件工程师、数据库工程师以及硬件网络工程师组成的紧急服务小组解决问题。

第45页

第三篇：软件运维服务方案V1.2

软件开发维护服务外包

东软集团软件股份有限公司

2010年7月

第I页软件开发维护服务外包

目

录

第II页软件开发维护服务外包

远程支持服务流程 ....................................................................................................... 38

5.8.4 5.6.5 5.4.1

第III页软件开发维护服务外包

5.9 用户培训方案 ....................................................................................................................... 76

5.9.1 东软针对本项目的培训承诺 ....................................................................................... 76

5.9.3

5.9.3.1 5.9.3.2 5.9.3.3 5.9.3.4 5.9.3.5 5.9.3.6 5.9.3.7 培训综合能力 ............................................................................................................... 81

6.3.1 6.3.2 6.3.3

6.3.3.1 6.3.3.2 6.3.3.3 6.3.3.4 6.3.3.5 6.3.3.6 项目负责人员安排 ....................................................................................................... 92

6.4.1 6.4.2

6.4.2.1 6.4.2.2 6.4.2.3 6.4.2.4 6.4.2.5 6.4.2.6 6.4.2.7 6.4.2.8

6.5 质量保证方案 ..................................................................................................................... 121

6.5.1 6.5.2

第IV页软件开发维护服务外包

6.5.3 质量保证承诺 ............................................................................................................. 122

6.5.5

6.5.5.1 6.5.5.2 6.5.5.3 6.5.5.4 6.5.5.5 质量管理 ..................................................................................................................... 123

6.6.1 6.6.2

6.6.2.1 6.6.2.2 6.6.2.3 6.6.2.4

客户交互的安排 ......................................................................................................... 133

第V页软件开发维护服务外包

1 项目概述

1.1 项目背景

1.2 项目范围

本次运维服务所包含的我市金保工程应用软件主要包括以下内容：  无锡市社会保险信息管理系统  无锡市劳动就业信息管理系统

第1页软件开发维护服务外包

 无锡市企业退休人员社区管理系统  无锡市老年补贴管理系统  无锡市居民医疗管理系统

 无锡市社会保险单位管理信息系统(报盘软件)  无锡市征地报盘管理系统

 无锡市劳动保障单位网上申报管理系统  无锡市社保卡金融应用软件管理系统  无锡市社区扁平化管理单点登陆系统  无锡市异地就医系统

 无锡市定点医疗机构托管系统  软件程序版本更新系统

 无锡市企业退休人员健康体检管理信息系统  无锡新农保系统和老农保系统  无锡市女职工单位报盘管理系统

 无锡市劳动保障行政权力内控及电子监察系统  劳动保障数据上传管理

 无锡市失业保险维护管理信息系统  无锡市零就业家庭管理系统

 无锡市创业促就业管理系统(内外网)  无锡市创业培训网上学校信息管理系统  劳动保障网百件实事网上办

 无锡市劳动保障综合统计系统和主要指标管理系统  无锡市劳动保障信访管理系统  触摸屏管理系统  各种接口软件

根据人力资源和社会保障业务发展的实际需要及时提出业务需求，中标单位及时根据用户要求，积极组织资源，配合制定进度，确保软件需求分析、软件开发、测试、培训、上线、运行跟踪监控、优化等工作在规定的时间进度内准确、及时、安全、稳定地上线运行。每个新项目按软件工程要求进行管理，验收完毕

第2页软件开发维护服务外包

后纳入日常软件运维范围。

目前根据部相关文件要求今年需完成居民养老业务、社会保险经办能力提升、内控项目等的开发上线工作。

第3页软件开发维护服务外包

2 运维服务需求内容

根据招标文件要求，运维服务主要分为软件维护、软件开发、集成服务、现场服务和用户培训五个方面，每个部分的需求和具体要求如下：

2.1 软件维护需求

软件维护需求主要包括以下11项内容：

 协助检查数据库运行情况，及时处理数据库故障;  协助定期对数据库进行优化，提高数据库运行效率;

 接受全市各级劳动保障经办机构软件维护申请，对应用软件进行完善性修改，处理应用软件存在的问题;

 完成劳动就业系统及社会保险信息系统年度和月度初始化工作;  按照部、省要求从生产库向交换库转换数据，生成指标数据上报;  配合系统硬件的维护，及时处理涉及数据库和应用软件相关工作;  配合完成日常的统计分析报表，完成特殊的查询统计需求;

 在采购单位的统一安排下,按相关政策要求进行数据批量处理工作,如:养老调资、医疗年度帐户调整、失业金上下限标准调整等,整个过程需要建立有关数据安全、备份、测试、验证、应急恢复等机制;  医疗历史数据迁移，医院信息管理系统接口支持。

2.2 软件开发需求

软件开发维护方面对中标单位提出如下要求和需求，主要包括以下6项内容：

 必须按软件项目开发的实际需要组织后台开发人力资源,现场技术人员

第4页软件开发维护服务外包

与后端支持按照开发和维护服务要求配置资源，主要开发人员要培养后备力量，防止人员变动影响服务质量，确保软件开发和维护工作按计划顺利完成。

 本项目不接受联合投标及转包、分包行为，不得使用分包商履行本合同项下的任何义务。

2.3 集成服务需求

每年对采购单位的信息系统进行一次全面的评估，提交“无锡市人力资

第5页软件开发维护服务外包

源和社会保障信息系统运行评估及升级调整建议书”，以使采购单位有充足的时间进行项目规划、申请、落实资金、采购等工作，满足不断发展的信息系统运行要求。

 须对采购单位金保工程系统提供两月一次的日常巡检服务。

2.4 现场服务需求

 指定一名熟悉劳动保障信息系统和现场经验的项目经理做为本项目的服务运维总负责人，根据系统运维服务需要进行远程支持和不定期的现

第6页软件开发维护服务外包

场支持，确保整个系统高效、安全、稳定的运行，同时负责协调与用户单位的商务、技术、人员安排、项目管理及进度控制等事宜。  每周召开一次“软件服务质量评估”例会，给采购单位相关负责人员以周报形式总结一周软件服务工作及下周工作安排。

 现场服务人员的变动，需经采购单位同意，采购单位有权要求对不合格人员的进行调整。

 重大节假日必须提供值班人员名单及联系方式。

2.5 用户培训需求

 系统升级后应对技术人员进行技术培训，帮助相关技术人员熟悉软件的各项功能及具体实现。

 定期组织用户与软件开发人员之间的技术交流活动。

第7页软件开发维护服务外包

3 东软服务理念

3.1 服务理念

重视信用、值得信赖、留意形象、迅速反应、善解人意。

3.2 服务宗旨

1、取得最高的客户满意度--通过东软专业化的优质的服务，协助客户去赢得和保持竞争优势，并取得最佳的经济效益;

2、在全国树立一致的服务形象--在全国各地，客户都将获得同样高水平的技术支持和专业的服务支持;

3、企业解决方案保持领先地位--为客户提供功能和质量均无可匹敌的企业解决方案;

4、采用当今最尖端的软件开发技术--东软采用的每一项技术都得到企业行业范围应用的检验;

5、拥有技术熟练、高度敬业的专业服务队伍--东软在应用软件业务、系统集成以及相匹配的服务均拥有最好的人力资源;

6、保持良好的业绩--东软每年以高速的业绩发展，并不断地投资于人才队伍建设，并将成为客户长久的合作伙伴。

第8页软件开发维护服务外包

3.3 服务理解

东软公司自创立以来，一直将“人”视为公司最重要的资产和力量，“以人为本”的激励体系和企业文化是对这一理解的完美体现。这些“人”包括我们的客户和我们的员工。他们对东软的忠诚与奉献，是我们取得成功的最主要因素。

东软具有多年的为客户提供本地化服务支持的经验，服务工作人员出色而敬业的表现得到了国内客户的一至认可。

第9页软件开发维护服务外包

4 东软运维服务保障体系

4.1 东软售后服务体系简介 4.1.1 售后服务体系理念

为用户提供易用、可靠的产品和满意的售后服务。

4.1.2 服务支持体系构架

1、公司层面的集中管理机制

由CSC对应客户服务(包括需求、申请、投诉、反馈等)响应机制和客户满意度调查机制，从而达到对整个技术支持与服务机制的运营管理和检控职能。

由STC负责对解决方案或者产品在出厂前的压力容量测试、业务功能验证、生产过程测试等。

2、基于分布式的区域支持与服务机制

第10页软件开发维护服务外包

东软公司面向国内市场在华东、华北、华南、东北、华中、西南、西北、山东设立八个大区，建立了虚拟总部，并相应的建立了强大的服务支持平台，实施总部职能，能够灵活快速的对客户服务需求做出及时响应，客户在任何地方都将获得同样高水平的技术支持和专业化服务。

3、基于事业部体系的业务咨询与应用系统支持与服务机制

4.1.3 技术支持服务形式

东软公司已经建立了全国分布式的服务体系，能够为全国性、地区性大客户提供每周7天、每天24小时的全面的技术支持和专业服务。

第11页软件开发维护服务外包

根据本项目的技术支持服务要求，东软公司为客户提供技术服务主要有两种方式：

1、远程方式

2、现场方式

 远程方式不能满足服务时效要求、或服务任务必须到现场才可完成  客户系统出现非常严重的故障(如系统停机或其故障严重危及关键应用的运行)

 应客户要求且东软公司的项目经理同意的现场服务。

4.2 东软公司四级服务支持体系

东软公司的销售、售后服务、软件开发队伍早已覆盖全国，本公司在全国各主要省会城市均设有分支机构，为全国各省市客户提供本地化的售后服务。2002年公司组织机构调整后，公司在南京设有分公司，拥有强大的技术力量和丰富的

第12页软件开发维护服务外包

备件库，常驻本地服务，能够充分保证无锡金保信息系统建设项目售后服务的快速有效。

4.2.1 第1级服务：本地项目服务机构及项目经理

东软公司社保事业部将为本项目成立几个专门的工作小组，其中将负责完成主要的现场工作的人员有：

 负责本项目需求调研的需求调研小组;  负责本项目开发的项目开发组;

 负责系统的现场安装、调试、培训的系统工程师小组;

 负责平台系统正式移交后，在承诺的服务周期内提供售后服务支持的项目维护小组;

他们是设立在用户现场的系统服务队伍，能够迅速解决本项目的实际问题，提供本地化的第1级服务。

1)作为东软公司与用户方工作组间的代表，与用户对口直接接触，第一时间获取用户信息、意见和需求，并协调东软公司内部各方面做出及时的相应;

第13页软件开发维护服务外包

2)作为整个项目实施计划的执行负责人和监督者，负责协调、监督东软公司各部门按时、圆满地完成既定的实施工作任务，保证工程进度按时完成，保证工程质量达到项目要求;

3)作为整个项目的项目经理，在用户现场担任东软公司项目实施的总负责人，协调人员安排、问题协商与解决等工作。

4.2.2 第2级服务：东软公司南京分公司以及华东大区技术人员

 南京分公司软件工程师(负责应用软件、中间件、数据库系统的技术支持和售后维护)

他们为本项目设立的规模化系统服务队伍，能够迅速赶到现场解决系统的实际问题，提供本地化的第2级服务。

4.2.3 第3级服务：社保平台系统建设专家

对于无锡金保信息系统建设项目，东软公司将派遣最优秀的IT专家参与到该项目中，这其中包括：

 负责全面开发管理的高层专家

 负责全面质量管理的质量保证人员(包括负责QA质量管理和QC质量控制)

 负责系统测试的测试专家

 加入到项目组中的系统平台建设技术总负责人、总体和详细设计总负责人，加入到系统工程师小组中的硬件及网络技术专家等

这些专家为无锡社会保险信息系统建设项目提供系统级的技术基础平台建设于咨询，总体规划，详细设计、硬件及网络技术支持等服务，作为第3级服务，

第14页软件开发维护服务外包

可与无锡市劳动保障业主方建设实施小组进行直接的技术交流。

4.2.4 第4级服务：东软总部技术支撑部门

第15页软件开发维护服务外包

5 运维服务总体方案

5.1 无锡金保工程建设情况

5.2 金保工程总体架构

第16页软件开发维护服务外包

图 5-1金保工程逻辑结构图

5.2.1 IT基础设施包括网络及硬件平台层和数据层

第17页软件开发维护服务外包

5.2.2 基础服务应用平台

5.2.3 业务组件与表示层

第18页软件开发维护服务外包

5.2.4.1 通用企业应用平台的结构

第19页软件开发维护服务外包

商业逻辑层以EJB/Java Bean技术为实现手段，提供了对象持久化及打印、邮件等商业逻辑组件。设计要点如下：

1.用EJB和JavaBean做商业逻辑;

第20页软件开发维护服务外包

2.通过统一的服务组件基类调用安全、日志、工作流、规则等引擎式服务构件;

1) 得到connection 2) 简单的sql execute封装

3) 可持久化的数据总线DataSet,通过其xml接口可发送到页面) 4) DAO(单表抽成的可持久化的实体类对象)

平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。  C/S/S结构的视图层和控制层

第21页软件开发维护服务外包

C/S/S结构中客户端的设计要点是：

第22页软件开发维护服务外包

1. GUI采用传统的Window界面，以Delphi为开发工具;

2. 客户端通过统一的动态库函数与服务端的门户MainServlet通讯，通讯的内容以XML为数据格式，整个通讯协议完全模拟SOAP协议;

IVODAOServerDCMSieaf.dllServerClientDCM

C/S/S结构中控制层的设计要点是：

1. 整个控制层的设计思路参考B/S/S结构中的Struts框架。MainServlet可以映射到Struts的ActionServlet，而RequstProcesser + Event可映射到Struts的Action;

2. 但与Struts不同的是它与客户端之间传递的均是XML，没有表现语义，因此它要增加XML信息过滤器、转换器等功能;  B/S/S结构的视图层和控制层设计

第23页软件开发维护服务外包

界面层以JSP/XML/XSL/JS技术为主要实现手段，为系统开发提供了一系列功能强大的组件，主要有以下几大类：

1. 轻型控件：封装所有的HTML Form元素和按钮，提供显示、标准行为控

第24页软件开发维护服务外包

制和校验功能;

2. 重型控件：包括DataWindow，目录树，Tab页等具有复杂功能属性的控件;

3. 局部刷新和对话框：采用微软提供的局部刷新控件，提供局部刷新功能，并封装通用的页面对话框;

1. 采用Structs控制请求和业务流程，拓展Struts的ActionServlet和DispatchAction作为UniEAP的流程控制基类;

2. 组织机构和权限管理模块进行身份和权限认证，从视图、操作、数据三个层次控制权限行为;

3. 日志和异常处理负责系统信息的记录;

4. 封装UniWorkflow的接口，在流程多变的业务系统中用UniWorkflow定制和控制业务流程。

5. Action本身并不处理业务逻辑，而是通过统一的BSFactory从EJB Container获取Business Service Componets处理业务逻辑。

5.2.4.2 通用企业应用平台的功能

第25页软件开发维护服务外包

5.2.4.3 通用企业应用平台的特点

5)基于UniEAP应用框架，应用系统开发员可以集中精力开发业务层组件，

第26页软件开发维护服务外包

不需要过多地考虑各种技术问题和其他方面的实现细节，也提高了业务层组件的独立性，减少与其他模块的关联，便于将来扩充、升级和修改。

7)UniEAP提供了一个通用的数据层，业务系统不需要重新开发，只需要定义自己的数据层对象，因次简化了应用系统的开发过程。

8)从界面层到数据层，UniEAP都充分体现了业务对象之间的各种关系(一对

一、一对多、多对多等)，并且提供了充分的实现手段，使得应用系统实现业务对象之间的复杂的逻辑关系成为可能，而且非常简单。方便了业务系统。

9)UniEAP在很多方面提供了通用的模式和技术规范，如组件设计、数据库设计、界面设计等，可以为应用系统的开发提供有效的指导和参考。

5.2.5 基于通用企业平台的运维服务

由于无锡市劳动保障信息系统系统的设计和开发基于东软自主研发的通用企业应用平台UniEAP进行开发，所有东软有信心做好无锡软件运维服务。

因此，应用升级中，对系统平台充分了解的情况下，能够较准确的规避升

第27页软件开发维护服务外包

5.2.6 应用逻辑实现策略

图 5-2架构技术实现策略

应用逻辑层和公用服务层的每个功能模块均是一个相对独立的组件，这些组

第28页软件开发维护服务外包

业务操作员及公众信息查询人员通过标准的HTTP 协议或安全的HTTPS协议访问社保管理信息系统及公共服务系统。

介于交易处理服务器和业务逻辑层之间的是公用的数据存取服务，这一层封

第29页软件开发维护服务外包

解决以上的问题，需要采用数据访问对象(Data Access Object，DAO)来抽象和封装对数据源的访问。DAO 管理着与数据源的连接以便于检索和访问数。

下图说明采用数据访问对象提供数据存取服务的实现。

第30页软件开发维护服务外包

图 5-3实现示意图

下面的时序图表示使用数据存取对象读取数据库数据、更新数据库数据的过程：

第31页软件开发维护服务外包

图 5-4过程示意图

5.2.6.1 核心经办业务技术架构概述

第32页软件开发维护服务外包

图 5-5示意图

基础服务应用平台的结构简图如上图所示，各组成部分的功能及职责如下：  GUI：用户界面层

 呈现用户交互界面  提供表现控件  界面控件布局

 Interaction Control：交互控制层

 定义业务逻辑的逻辑表单  开启和关闭事务

 响应用户界面层的业务请求  Transaction Management：事务管理提供事务管理机制

将基础服务纳入统一的事务管理范畴  Application Logic：应用逻辑组件

 处理事务规则及功能  提供原子业务功能

 Application Service：基础服务组件

第33页软件开发维护服务外包

 统一资源访问服务  身份认证服务  权限管理服务  报表服务  日志服务  审计服务  其它服务

5.2.6.2 核心经办业务技术架构设计

基础服务应用平台的技术架构如下图所示，它是对上节中架构简图的细化。

图 5-6架构简图

 Web Container设计

GUI层由Client和UIM两层组成。基础服务应用平台同时支持浏览器、传统客户端、PDA等多种用户界面模式。UIM是用户界面控制层。

Client层以JSP/XML/XSL/JS/PB技术为主要实现手段，为系统开发提供了一系列功能强大的组件，主要有以下几大类：

轻型控件：封装所有的HTML Form元素和按钮，提供显示、标准行为控制

第34页软件开发维护服务外包

和校验功能;

Object：Applet和COM，用于复杂界面操作和客户端本地化操作。

UIM层以Servlet技术为实现手段，以struts框架为依托，采用单点入口的方式统一控制请求。设计要点如下：

采用Structs控制请求和业务流程，拓展Struts的ActionServlet和DispatchAction作为基础服务应用平台的流程控制基类;

Action本身并不处理业务逻辑，而是通过统一的Ineraction Object Factory从EJB Container获取Ineraction Object处理业务逻辑。

 EJB Container设计

商业逻辑层以EJB/Java Bean技术为实现手段，提供了对象持久化及打印、邮件等商业逻辑组件。设计要点如下：

用EJB和JavaBean做商业逻辑;

1) 得到connection 2) 简单的sql execute封装

3) 可持久化的数据总线DataSet,通过其xml接口可发送到页面) 4) DAO(单表抽成的可持久化的实体类对象)

平台在商业逻辑层还提供了许多通用业务组件，如打印、报表组件。

 Web Container与EJB Container请求模型

第35页软件开发维护服务外包

图 5-7Web Container与EJB Container请求模型

5.2.6.3 技术架构中各层对象在创建过程中的依赖关系

架构中的几层在“创作”过程的依赖关系是什么，即凭什么知道要创建几个AppLogic、几个Interaction、几个Action、几个PB/JSP界面?

下图阐述了几层对象在创作过程中的依赖关系，它们之间的连线是本节说明

第36页软件开发维护服务外包

的重点，所以颜色调成了红色，对这些线的说明调成了蓝色，以显突出。注释文字可能有点不清楚，拷在下面：

 用户界面需求会决定最终的界面窗口是什么样子的。我们提倡在需求调研时就把大部分界面都确定下来。

 Interaction是GUI层和BL层的“和事佬”，它主要是要满足GUI的请求，但也要照顾AppLogic的脸色，必要时要对GUI和BL做个折中处理。

图 5-8示意图

前后台交互文档中对说明哪个Action的哪个方法来响应界面请求，入参、出参是什么，看了交互文档后就一目了然了。这只是表面现象，本质上是界面在

第37页软件开发维护服务外包

向后台说明，你的哪个Interaction和哪个方法响应我的请求。

5.3 维护服务计划

按招标文件要求，软件服务日期从合同签署日起到2015年5月31日止。软件外包服务年度计算到次年的5月31日，如第一年为合同签署日到2011年5月31日，第二年从2011年6月1日到2012年5月31日，第三年从2012年6月1日到2013年5月31日，第四年从2013年6月1日到2014年5月31日，第五年从2014年6月1日到2015年5月31日。

5.4 软件维护方案 5.4.1 远程支持服务流程

我公司为用户提供400免费技术服务热线(400-655-6789)，在接到用户请求后，根据请求情况协调公司资源，第一时间给用户反馈并解决问题。

第38页软件开发维护服务外包

1、诊断故障并提交故障诊断报告

2、制定系统维护和故障恢复的实施计划

根据提交的故障诊断报告，制定系统维护和故障恢复的实施计划。按照制定的计划实施系统维护工作。

3、管理、监督维护计划的实施

4、确认维护工作完成并提交维护报告

在系统维护工作完成后，由系统维护人员提交系统维护工作报告，由用户方项目组的技术人员对系统维护情况进行测试并予以确认。

5、提交成果

每次系统维护工作完成后，都应提交如下的报告、记录等文档等资料：

第39页软件开发维护服务外包

 故障诊断报告

 系统维护和故障恢复的实施计划  维护工作阶段报告  系统维护工作报告

说明：紧急情况下，以排除故障，满足用户需要为首要任务，可以进行紧急处理，但事后要补充相应文档与记录。

5.4.2 现场服务流程

第40页软件开发维护服务外包

图表 5-2售后服务流程

东软公司提供的服务内容包括：

 应用软件运行维护：应用软件自身缺陷的调整，为客户及时解决日常运行中出现的问题。

 根据政策和经办规程调整，及时响应需求变更(含与金保工程其他子系统和外部机构的接口)，并在业主要求的时限内完成对应用系统的修改或调整。

 应用软件技术改造与升级服务：主动或应客户要求，将最新的技术成果和先进的管理模式升级到原有系统，使应用系统的永远保持先进性。

 数据库支持服务：东软公司提供通过Oracle OCP认证的专职工程师

第41页软件开发维护服务外包

为客户提供长期的数据库优化及技术支持服务，以及异常数据修正、批量数据处理等数据维护工作。

 定期系统巡检：在系统维护期过后，按照签订的维护合同，定期等到现场对应用系统运行情况，主机运行情况，数据库系统情况进行检查和维护。

(1)收集最终用户对系统的使用意见和建议; (2)对最终用户进行操作指导; (3)客户端故障判断和排除指导;

(4)单机版数据转入系统的操作指导和技术支持; (5)服务方式以提供远程服务为主。

5.4.3 服务内容

(1)协助检查数据库运行情况，及时处理数据库故障; (2)协助定期对数据库进行优化，提高数据库运行效率;

第42页软件开发维护服务外包

中标单位应按采购单位要求负责全市新定点医疗机构的许可证制作发放工作;

(5)接受全市各级劳动保障经办机构软件维护申请，对应用软件进行完善性修改，处理应用软件存在的问题;

(6)完成劳动就业系统及社会保险信息系统年度和月度初始化工作; (7)按照部、省要求从生产库向交换库转换数据，生成指标数据上报; (8)配合系统硬件的维护，及时处理涉及数据库和应用软件相关工作; (9)配合完成日常的统计分析报表，完成特殊的查询统计需求; (10)在采购单位的统一安排下,按相关政策要求进行数据批量处理工作,如:养老调资、医疗年度帐户调整、失业金上下限标准调整等,整个过程需要建立有关数据安全、备份、测试、验证、应急恢复等机制;

(11)医疗历史数据迁移，医院信息管理系统接口支持。

5.4.4 客户服务质量文件

在客户服务中，东软公司通过以下文件来保证服务的规范和质量：  客户服务管理：

 《客户服务管理》，售后技术维护，客户问题管理  客户问题办理：

 《客户问题受理规范》，问题记录，问题分发、办理监督，问题回复，问题月报

 《故障诊断报告》，故障现场情况记录、故障的级别和紧急处理过程记录等

 《系统维护和故障恢复的实施计划》

第43页软件开发维护服务外包

 《维护工作阶段报告》、《维护工作总结报告》  《系统维护验收测试计划》  《维护工作验收报告》  客户满意度测量：

 《客户满意度测量》，收集满意度，统计分析(月、季、半年、全年)，提出改进措施

 客户培训的相关表格：(为把客户培训工作做得更好的辅助性表格)

根据以上的质量保证体系规定，东软公司为无锡社会保险信息系统建设项目设计的执行一次较完整的系统维护过程的基本步骤如下：

1) 根据无锡社会保险信息系统建设项目运行过程中软硬件出现的系统故障或其它异常情况，双方合作及时进行故障诊断，并提出《故障诊断报告》;

2) 根据提交的《故障诊断报告》，制定《系统维护和故障恢复的实施计划》，东软公司按照制定的计划实施维护工作;

3) 双方共同组成系统维护工程管理和监督工作组，全面负责管理和监督系统维护工作实施过程;

4)东软公司根据系统维护实施的各个阶段具体情况提交《维护工作阶段报告》，在系统维护工作完成后，由系统维护人员提交《维护工作总结报告》;

5)最后根据《故障诊断报告》、《系统维护和故障恢复的实施计划》、《维护工作阶段报告》和《维护工作总结报告》，东软公司技术人员和用户方项目组的技术人员一起，讨论确定《系统维护验收测试计划》;并依此对系统进行测试验

第44页软件开发维护服务外包

收，测试合格提交《维护工作验收报告》维护工作完成，否则继续整改。

5.5 应急维护方案

系统在运行过程中一旦出现紧急重大问题，导致新系统不能正常运行的情况下，就需要启动售后服务紧急预案，以保证业务经办的正常进行。

5.5.1 应急预案目标

在一旦出现紧急情况下，需要启动应急预案的情况下，应急预案必须以保证业务经办正常运行为目标。

5.5.2 应急预案具体措施

第45页

第四篇：中小型企业管理软件、中小型企业管理软件适合就好、中小型企业管理软件定义、中小型企业管理软件意义

中小企业ERP软件适合就好

来自：杭州集控

如今，ERP软件种类繁多，许多企业不知如何选择，笔者写此文的目的就是为了帮助企业选择适合自己的ERP。此文中没有对目前的ERP产品做任何优劣比较，因为笔者始终认为适合自己的就是最好的,因此就有了这篇文章。翻开各个ERP公司的产品介绍或者成功案例，我们经常可以看到这样的数据，成功实施某某ERP之后，可以为企业带来如下经济效益：如库存下降xx%;制造成本降低xx%;采购提前期缩短xx%等等，为企业描绘一副美丽图画。可是又有谁去验证这些数据是否属实呢，答案是无法验证。

一方面国家在这方面没有相应的法律法规，也就是说无法可依。比方说消费者买了一台空调，如果认为空调不制冷(相当于使用了ERP之后库存没有下降xx%)，可以送到技术监督检验部门，只需要花很少一点儿钱就可以得到较为权威的检测报告，这个报告一般都具有相当效力，而且，甚至当你对这个报告还不够信服满意的话，可以送到国家级技术检验部门检验，这样将得到最权威的检验报告，在这份报告中将明确标明，产品是否合格，以及各项技术指标实际是多少。说完了这个例子，大家就明白了，无论是省还是国家级技术监督和检验部门都是依据国家的空调质量标准而进行的相应检验，进而得到权威结论。同样道理，对于ERP来说恰恰缺少了这样的标准，让用户无从知晓到底库存下降多少，成本下降多少才算达到合格的标准，也正是因为这样没有标准约束和规范产品，也就有了各种各样的百分比统计数据，因为这些数据来自不同的ERP厂商以及他们彼此不同的软件产品。总之，没有国家标准是问题的根本原因。

另一方面，ERP厂商众多，很难全面考察，给盲目选择埋下伏笔。笔者将ERP厂商划分为3个阵营，第1阵营是在中国市场的国外ERP厂商，特点是市场范围是全球，中国市场只是一部分，代表厂商有SAP，ORACLE;第2阵营是中国国内的厂商，他们的特点是市场范围仅在国内，中国市场就是他们的全部市场，国内的某个省成为他们的重点市场，代表厂商有用友，神州数码;第3阵营是各省市本地的ERP公司，他们的特点是市场范围就在本地区或本省，全国范围内这样的公司有数百之多。面对如此众多的选择，企业一时没有了招法也

就不奇怪了。

那么如何选择一个适合企业的ERP呢?再举个简单例子说明这个问题，人们在买汽车的时候，只要一接触汽车一般都会知道，奔驰汽车绝对是好车，可是最后市场上并不是只剩下奔驰一种，还有比奔驰差好多的车也都在销售，原因很明显就是不仅要看到奔驰的售价和性能，还要计算购车以后的费和税，更重要的是以后的运营费用，要知道奔驰的好性能还需要与其匹配的司机，零部件等等，这些费用也是非常可观的，以及他的车库，保安等等，全都是应当考虑的事项，权衡以上内容之后想必您已经清楚了自己是否需要这个牌子的汽车。少有人盲目买车，即只考虑解决眼前问题，就买了车，结果买完以后又有了新的问题。这就是对买车做了全面考察的结果。

买车时不易犯的错误在选择ERP时却常常发生，此错误就是忽视了产品后面的众多因素而导致的。企业总是盯着选中的ERP产品，然后竭尽所能(准备好购车款)，将其迎娶回家，而大大忽视了这购车款后面将要花费的人力和物力。大家都知道好车一定需要好司机，当然车仅有司机是不够的，只是这里用司机比喻而已。那ERP的好司机是什么呢?对于一个高效运行的ERP系统，下面这3类人是不可缺少的，很像司机的作用：

网络工程师。ERP是基于计算机和网络的管理平台。网络工程师的作用在于保障操作系统以及系统硬件正常运行，维护和管理WAN/LAN，为ERP以及其他所有基于计算机和网络的信息系统提供最基本的硬件保障。

数据库管理员。任何ERP都必需数据库，经过认证并且有工作经验的DBA(数据库管理员)，对于系统的运行有着不可替代的作用。其作用在于提供数据安全和运行保障。

ERP管理员，这类人员即要精通本企业的业务有要熟悉ERP软件，其作用在于维护ERP系统正常运行。

笔者认为这3类人员对ERP系统来说好比汽车需要司机一样重要，其他人可多可少，而这3类人一类都不能少。他们的作用在于维持和保证日常运营，就像在好的汽车厂商也只能负责把汽车交到顾客手上之前的质量，交付之后就全靠顾客自己维护和保养了。ERP也是一样，厂商只能负责软件交付之前的质量，交付以后基本上要靠顾客自己了，而且ERP的培训和上线的时间比较长，换言之，

驾照也不是1个月就能拿到的，ERP上线和学驾照有相似之处。企业往往缺少上述一类或者多类人员，没有他们ERP很难发挥应有的作用，即使再好的ERP产品也是白费。随着ERP系统的应用规模增加，上述的这3类人员的数量也应该相应增加，反之则减。对于采用了ERP以后的企业来说(采用SAP等国际产品的企业这个问题更明显)，还不可忽视地产生了另一个新问题，就是除了要保持ERP运行是件困难的事以外，还要想办法保持这3类人员的稳定，要知道，他们都是目前炙手可热的人才啊，他们要是离开企业，将给企业带来无可挽回的损失。发生这些问题的根本原因就是没有全面考虑产品后面的众多因素，犯了一个盲目买车的简单错误。

其实关键在于选择适合企业的ERP，笔者总结了如下几条规则，帮助企业也做出正确的决策：

明确需求，不盲目。

不要盲目追求，随大溜，明确自己的ERP需求，无法明确，就问自己是否需要ERP。要知道如果你的产品销路不畅，产品功能和服务还急需改进，技术人才持续流失等等，ERP不能为你解决这些根本的问题，即使上了ERP，产品还是销路不畅，产品功能和服务还是没有改进。而技术人才流失，更会让你陷入数据混乱无序的沼泽。这时候首先考虑的是，是否需要ERP的问题，而不是选择那种ERP的问题。真正需要ERP的企业应该是经过一个时期的发展，已经进入缓慢增长的企业，这时候需要一种的新理念推动企业再次进入一个新的高速增长时期，那么ERP就是这种新的理念。

ERP的标准自己定，只买适合自己的ERP。

作为企业自身，最清楚自己下一步发展的目标是什么，把这个目标量化，即把文章前面提到的各个xx%都具体化，宏伟的公司和市场目标，都是由成本下降等诸多因素构成的，完成了各个分解的指标，公司的总体目标就实现了。把这些量化的指标作为选择ERP的考核标准，能够满足这些要求的ERP就是符合你的标准的ERP，也就是最适合企业的ERP，也可以说完成了企业信息化。这样一来，企业实施ERP时就可以目标明确，实施ERP后，企业整体上了一个台阶，ERP成为企业发展的里程碑。来源网址：

第五篇：漫谈运维—运维工程师

《谈网站或其他服务器运维》，这里只谈运维工程师所要做的细节工作，让人们知道运维工程师到底都在做些什么，至于上级所要做的，只是提一下，不做参考。

以下是个人观点，我说的只是我自己的想法，也是我发展的目标。你可以有异议，我们是来交流的。你对的我肯定会向你学习。因为我也在摸索。运维工程师至少要能做以下的工作：

1，网络工程师的工作

你至少要能配置CISCO 6509以下的设备，熟悉各种网络协议，否则网络出问题的时候你会傻掉。

2，系统工程师的工作

你至少要理解各种系统服务，在出问题的情况下要迅速解决问题，而不是等系统工程师来解决。

3，安全工程师的工作

我不要求你一定要会各种网络编程，但是在服务器收攻击的情况下，没有防火墙的情况下，做一些简单的处理工作。

4，存储工程师的工作

至少要熟悉各个厂商的设备，各种备份和还原的办法

5，测试工程师的工作

在新版本上线之前，你至少要协同测试工程师做测试工作，因为你是运维人员，不了解程序架构导致无法解决故障，你也有一份责任。

6，研发人员的工作

运维工具都需要自已开发，熟悉开发语言，需要有过实际开发经验，否则工作会非常痛苦，我深有体会。

7，英语

不想说了，我的最大痛苦就在这里

8，好的沟通者不出问题时候你可以打游戏睡觉，出问题的时候要能和项目人员沟通，快速解决问题，而不是推;我知道有很多人能推责任，你可以做替死鬼，但是离开这个工作你还能找到更好的;把责任推到别人身上的人，下次出问题的时候，绝对没人帮你。你要能和各个兄弟部门关系非常的密切，出了问题有兄弟帮你担责任;也要能非常扯皮，没事在会议上把别人都搞定。

9，库房管理员

数万台服务器让你来管理，任何丢失或者损坏都是不负责任和失职的表现。

10，运动员

不要回家就睡觉，有空还是运动下吧;在服务器down机的时候，机房恰巧就你一个人，机柜没有空间，你需要更换一台HP 585 4U的服务器，满配约80公斤的服务器，你怎么做?

11，责任心

这个我不想说什么，这是你的职业精神。

12，组织者

给你2个啥都不会的民工，再给你2000台服务器，要求你2天把服务器装完，你咋办?

13，1-7条中，你必须有一条非常精通，是这个行业的专家。否则过了32岁，没有公司要你。

大家看了肯定觉得这个人是神仙，但是这必须是你慢慢能做到的，至少是我6年来运维经验的一点总结。

因为现在的公司都在用招聘民工的钱招聘神仙，其次我也是想让各位看看，运维工程师要担负多少责任。

我去面试过的一些公司都说，你什么都会，什么都不精。我说对，正是需要我们这些什么都会的人领导什么都精的人。

我这句话没有贬低大牛的任何意思，只是当时一个临场的发挥。虽然说完就知道这个面试白来了，但是我还是想为广大的运维工程师出口气。

不怕千招会，就怕一招精。这仍旧是我给大家的建议。

最后给大家最后最大最重要的建议，做什么工作都可以，千万别做SA。我把SA的定义成：speediness answer而不是system admin。为什么?你可以想象一下哪些工作需要快速响应。网络工程师需要，机房网络骨干交换机故障，整个机房所有服务器无法连接，需要快速响应不?系统工程师需要，系统出问题了，要快速响应不?安全工程师需要，服务器被攻击了，要快速响应不?存储工程师需要，公司核心存储有问题了，要快速响应不?

你可以做研发，出了问题可以测试，可以想办法慢慢解决;你可以做DBA，出了问题可以推到网络工程师或者系统工程师身上，说不是DB连接问题;你可以做测试工程师，你说有问题这个东西就可以不上线„„在出问题的时候，倒霉的就是SA，所以不要再争论SA包含哪些工作，SA就是一个倒霉的快速响应者，你想，哪个SA 24小时不开手机?哪个SA 晚上可以舒服的睡觉或者安心的出去度假?走在路上一听到和自己手机短信铃声一样的，利马下意识的抓出自己的手机看看是不是服务器报警;晚上和老婆 XXOO00，一个电话过来，立马停下，抓出手机看流量图;包里放着笔记本，但是因为还要开机，太慢，拿着手机上putty ping或者telnet机器„„

这就是大家羡慕的SA ，你也不要抱怨自己做了SA，生活就是这样。所以不要再争论哪些xxx员应该归属于SA，系统管理员或是运维工程师，如果想做这行，就安生的当一个“快速响应者”，这是你的职业，也是你需要做到的。作为一个SA，你肯定经历过通宵好几天加班做事，你肯定经历过饭买来已经忘记了吃，你肯定经历过几天加班没睡觉，着个沙发坐下就失去知觉睡倒„„没有经历过不能说你不好，只能说你管理的机器太少。

我公司是每月发21天工资，某两月我一月发了44天工资一月发了47天工资，创全公司建司7年来加班记录„„项目做完自然也就落了个部门通告表扬，然后的结果就是健康情况急剧下滑，然后就是某天晚上在机房内加班一通宵，穿着短裤进机房，然后一个通宵被机柜下面的冷风吹了个关节炎„„这就是做SA的代价。

以下是一些实际经验，发给大家做参考，有任何问题可以mail我，answer3ai@gmail.com

有的东西是企业机密，我不能透露也不能给你相关文档。

一，架构设计

现在你要做的，就是设计你的服务器架构和网络架构。这要先看你的网站是做什么的，每日有多少的人数访问，例如，我打算站点初期每日有20000左右的访问量，和1000人左右的并发量。我可以用我的人数并发量1000×站点中每个页面的平均大小200k×每个访问用户可能要打开4个网页=800 000k=800M的网络流量(当然这个数字肯定是非常的过分，至于为啥，自己可以想下)

然后可以用测试环境用软件检测在你的真实环境下的服务器压力，比如在2000人在线的情况下，服务器的cpu占用多少，内存占用多少。

那么你可以得到你大致配置，其实市面上的标准服务器配置都足够你用了，比如现在的DELL 1950,HP DL360G5,IBM X???(忘记了)

等服务器，足够我跑一个这样简单的网站。其实说白了，双奔3都够，真的。当然你网站的流量比我要大的多，那你可以买的更好一点的服务器。或者负载均衡器。

网络架构

站点现在是一台独立服务器，未来采用的是分布式架构，比如bbs.hilinux.com是一台服务器，man.hilinux.com是一台服务器„„

mysql是一台服务器。这样你要算服务器要多少台，交换机要多少口，防火墙要买什么级别的。

哪些服务器可以放在一个防火墙下，哪些服务器不用防火墙保护，哪些服务器是内网服务器，

需要什么样的网络连接，最好是画出大致拓扑，方便你预算设备花费。

服务器交换机等设备选型和购买

说的简单点就是买什么机器，你可以和google一样开始，买几台pc作为你的网站服务器，也可以自己组装一台服务器

或者也可以和我一样，去挑选品牌服务器当然，现在你要看你服务器做什么的，

你可以亲自去电脑城看组装服务器，也可以打电话到IBM,HP,DELL的各地销售商让他们送服务器来测试，

当然你不要告诉他们你只买一台，那你就别指望测试了。我告诉供货商hilinux.com需要200台服务器，一个F5，10台CISCO 2960交换机，3个NETSREEN206防火墙，一个EMC CX500+满硬盘那么不到3天，hilinux.com所需要的4台测试服务器，就送来了„„当然，不要牛了这么多最后只买1台，那么你晚上走夜路会被人打的。

最后就是价钱问题了，这个你自己看着办吧。让你公司的财务或者采购出马砍价付钱就是了。当然，除了服务器的服务，你最好还是想想有利于自己的服务，比如人家公司可以帮你拆箱子了什么的。我做的最弱智的一件事情就是，来了400台服务器，50个交换机，8台EMC，我一个人花了一星期把箱子才全部拆完„„

机器选型的时候你也要为自己考虑，比如HP的ILO功能，可以让你远程BIOS级操作服务器，比如浪潮的自动资产管理等等，为自己管理服务器提供便利，否则机器10来台还好，100台还一般，我这里3万来台，我不死几百遍了。丢失一台服务器，几个月工钱就没了„„

二，IDC选择

首先要看你服务的地区是哪里，然后再去找当地的电信机房。毕竟，虽说全国已经互联了，但是各地的网速还是有差异的。

或者说有的IDC机房利用率高，虽然出口带宽大，但是利用率高的结果是导致你网速慢的原因之一。

我的做法是在全国各个机房的服务器用pingplus这个软件进行一周的的流量测试。可以看到平均丢包，最大延时等等。

当然，你也可以到你目标服务的地方，找个可以上网的地方进行网络测试，比如说网吧包个机器„„

好了，网络测试完了。那么你已经决定去哪个IDC了吧。

然后你就可以电话或者自己提着礼品登门拜访一下IDC服务商的老大了

当然，你也可以找代理服务商，因为他们拿到的价钱有时候比电信或者网通给你的价钱低，但是，关键还是一个服务，因为你毕竟服务器放在那，晚上关键着急没人给你重启，机器出了问题其实按个F1就可以解决的问题，服务商的值班人员不懂。你就只能打晚上的打飞机去机房维护吧。

提着东西拜访一下服务商老大是礼节性的东西，东西不在多而在精，这样你未来谈事情人家也给你绿色通道，做事情要好做很多。当然，我也不反对你空手去，你一次租个100个机柜+10G带宽，人家还是很优惠的。哈哈。大家都是混口饭吃，也不至于难为你什么。

最后你要知道现在的中国还是卖方市场，你给人家牛，那你买的产品只能是„„蒙牛然后是开始去参观机房

细心的检查一下空调数量，空调出厂和最后维护日期，网络布线类型和架构，是否可扩展，主备从电力等。

基本都是非常关键的东西，出问题了，人家可以给你更换一个新的，服务很好，但是你服务器挂一天的损失是多少，你可以自己掂量。

还有机柜电力，现在的机柜放置16台1U的服务器是正好，多了过于热，少了资源浪费;但是你发现人家只让你用10安培电力，过了要交钱买电;

或者不限制你用电，但是插线板只有10个，你还真买个托线板去转接?你要想想你一个托线板挂了，你服务器要挂几个?

最后，我的一个机房包间里140个机柜，2个空调，结果某天挂了一个空调，虽然6小时人家IDC商就给更换了一个空调机(这速度已经非常快了)，

结果我机器至少被热死了100台以上，机器是HP的，机器过热，HP会自动关机，而且会不让你启动。你崩溃不?注：不是给hp做广告哈。

三，服务器上架

好了，要是你买的服务器到了，你会发现你接到电话后，楼下一个N大的“擎天柱”集装箱车给你送服务器来„„(某次我收2000台服务器就是这样的阵势);在这里有个重大的提示，你们财务给厂商下单的时候，收货地址一定要写对。比如 XX路XX号XX大厦XX楼XX室，你写到xx号，送快递的会给你堆到院子里，你写到xx楼，送快递的会给你送到电梯口，你写到xx室，他们才会给你搬到室内。因为送货的都是服务器厂商找的，你因为这个事情去联系厂商修改送货地址，至少要多等N小时。而且他们视你的单子的数量和楼层，判断来多少搬运人员。而且，一定要把服务器搬到你指定的地方再签字收货，否则„„嘿嘿„„

我最霉气的是：来了20台机器(还好不多)，下着大雨人家给我往院子里一丢，让我自己搬上19楼，我没推车没啥的„„

你可以说，找电信的帮忙撒，废话，这个我还不知道。那我告诉你，我在某电信大楼工作时，从CCIE到机房主管到机房工作人员，全部是美女„„

虽然我在这个地方只干了5天活，我的同事们口水都有3尺长„„你还叫人家给你搬机器不? 你可以说，雇民工撒，我又不是没雇过，钱得你自己支付，公司不给你报销的话，爽不?

下面是拆箱子，面对着堆积如山的2000台服务器，我是连抬手的力气都拿不出来„„当时机房只有我们公司3个人+电信值班2个人„„

这时候，我的办法是„„我打电话找来了2队收废品的：

这么多箱子，除了机器和电源线留下，里头的导轨光盘等等你全部拿走，谁拆的多谁拿的多„„

最后按照我的要求帮忙搬到机柜上„„于是我们5个人是监工„„看人家拆箱子搬机器。

于是人家2队人找来了30多号人，一早上把2000台机器全部拆箱子完毕放到机柜上。

要是我们几个人拆，估计„„„„

最后再说个行价，服务器箱子一个价值5块钱甚至更多。你服务器到了，卖卖箱子请大家吃饭吧。别让扫地的阿姨拿走，几个无所谓，10来个箱子，够大伙儿吃顿烤肉了„„还有EMC的木箱子„„拿去养个小鸡小鸭的„„

42U机柜1U的服务器最好是16台。你就看着上吧。呵呵

四，安装系统和布线

好了，面对几千台服务器开始装系统，我不知道你会怎么想„„

全部是1U服务器有什么办法安装系统?(我们公司穷，买不起刀片;而且电信不配合，要是上刀片，电路你们自己拉线，价钱还是原来的价钱;最重要的„„我们公司以人为本，宁愿多养个人也不愿意买个好服务器让人失业)，而且不允许GHOST，因为你这是服务器，不是网吧„„GHOST出来的系统，我不知道谁用过，爽不。我自己是郁闷郁闷到了，莫名问题的时候，你就知道GHOST还是靠不住的。

其次，我们公司安全部要求：必须得一台一台安装，先安装光板的系统(比如没有SP的WIn2000)，然后手工打SP4补丁，不能网络打补丁。于是我们就光盘堆成山。最扯淡的，为了快，我做了一个补丁共享的服务器，所有的补丁CP的本地来打。结果忘记拔网线，导致人家说我们是插了网线打补丁，有中毒的危险，需要重装。我直接崩溃„„ 办法1，你可以1台1台慢慢装，反正这么多机器，你可以管公司要更多的时间。但是我们公司一般是机器到了，最多2-3天就要要，一向是那种计划不如变化快的没有计划没有进度管理的“小”公司，项目组拿着鸡毛当令箭，牛x哄哄的公司。郁闷!

这个时候前期的准备就比较重要了(我公司多用windows2003)，因为首先我要装一个光系统，再打驱动，再打补丁，再安装远程控制软件。一台机器装完大约要1小时多点。那么机器多了怎么办?光盘不够怎么办?等等问题就来了。

我的办法是，我一看TMD全部是DVD，IBM的机器直接佩combo，公司给我们发的全部是CD，娘的，典型的没有最慢只有更慢，出了问题闲你慢的领导班子。于是只好自己出钱买了DVD，用软件把RAID,网卡，显卡其他驱动做到光盘里，需要安装的软件也直接做成自动安装的方式，补丁也刻录到光盘里(我们要求补丁必须单打，不能安装集成补丁的ISO，shit)，这样弄，你只用把光盘往光驱里一丢，分区一分，就可以下一台机器了。然后等你在去关注这个机器的时候，已经可以设置IP插网线了。灵感来自番茄花园。吼吼。

当然这时候你最好是买个KVM,16口的KVM，一次准备16张光盘就可以用一套键盘鼠标操作16台机器。当然啦，KVM是可以级联的，我最牛一次一次一套键盘安装166台机器。郁闷的是，塞光盘塞死，插KVM线插死，配置IP配死，有时候还会弄错„„

办法2，你可以用NETKVM去远程安装，但是你插那些NETKVM的线路，2000个插下来，爽不?然后你继续扎KVM和网线的时候，看着和瀑布一样的网线和KVM线交错在一起。估计直接崩溃。远程KVM有的牛x的是可以分发ISO的，就是传说中的远程分发安装。可以自己买一个研究研究了，我们公司以人为本，从来不买这类高科技。

办法3，我犯贱时候发明的：我们的机器全部是RAID1，于是我安装一台raid1的机器，系统全部安装好，然后拔掉一个硬盘，插上一个新硬盘自动恢复镜像，基本10来分钟恢复好一个硬盘，插到机器上去。这样，还是比装系统来的快。当然啦，型号是一模一样的„„

办法4，HP的ILO2功能，实现远程分发。前提你得一台一台配置好BIOS里的ILO2。也是蛮痛苦的。IBM和DELL现在也都有这个功能，但是你在分发以前，还是得一台一台机器插上网线，配置好BIOS的IP，痛苦。然后把操作系统和机器的驱动程序和后续的软件全部做到一张DVD里，让他自动运行。然后所有的服务器远程运营这一个ISO,最好多弄几台，否则一台机器弄的慢死。

办法5，绝对最简单的办法!!!就是买机器前，让厂家给你在硬盘里灌好系统，和你买笔记本一样，打开是个安装完成需要你输入序列号的系统。但是弱点是后续的软件需要自己装。因为服务器厂商是不会帮你安装别的软件的。还有更多的办法，只是暂时没想到，大家也可以谈论自己的办法。互相交流嘛。(51CTO编辑注：其实现在已经有很多无人值守安装系统的管理软件，比如KickStart和现在流行的Cobbler，都是不错的批量安装工具，而且都是开源的。现在都追求自动化，希望越来越多的运维们将不必面对一台一台装机的困扰)

所以我喜欢linux，可以用N种办法安装系统。

windows就是个让IT人当装机男，挨踢人当民工。

好了系统装好了，电源线和网线连接完，和瀑布一样的。这时候还是尽量把他扎一下吧。

否则机器通风不畅，会导致热死。

简单办法就是电源线扎一边，网线扎一边。有钱的公司可以买个网线序号标，没钱就自己拿胶布标。

你可以随便扎，或者和给你老婆梳头一样，好好扎。哈哈

插交换机的时候，从上往下，从1-24往后，这样网络异常，数一下就知道了。

想来想去这里也没啥值得关注的地方。所以就几行带过。

五，资产统计

假如你的机器只有2000台反而好容易管理了，但是现在我要管理的全国IDC有31个，平均每个机房有不同品牌服务器1500台。

一共大约有45000台的样子(我的资产管理系统里的数字，不包含交换机，防火墙等)

这时候怎么办?

每季度和财务小MM一起出去旅游盘点IDC资产，幸福啊„„(我们财务小mm很PL的哦) 到了机房就是我一个人干活点资产，小mm带着大口罩，披着双层的放辐射服„„

可怜我们这些干活的，短裤背心，IDC里一呆就是好几个月(IDC办公室就在机房边上„„)，不知道精子被辐射杀死多少„„

1，必须有资产管理系统，虽然这个其实是个很简单的数据库，但是你可以把每一台机器的品牌，硬件信息，操作系统信息，购买年限，质保年限等，你非常关注的东西做一个详细记录，并配发同一的资产编号。比如我们的资产号，FWQ-123456 服务器-123456，这是一个总的资产号，这个服务器哪怕搬到美国，也是这1个资产，直到丢失，或者抛弃，都是这一个资产，永远不会变。

比如我现在的板凳就是一个资产号是：服务器-000010的一个4U服务器，配置是P2 300*2 256M内存 16G硬盘×4 购买时间是1999年10月，从中维修过1次，升级过1次，在哈尔滨机房-广州机房-河南机房-北京网通机房-上海公司内部测试机房-上海库房服役过。

有历史吧„„. 2，送到机房

看过我这个服务器去过的地方，羡慕不?见证我们公司的发展史。9年过去了，终于成了我的板凳„„

服务器在购买合同确定以后，就应该按照配置记录资产，并且在财务备案，资产编号一定和财务记录相同。这样这个服务器走到哪里，都有备案和记录。现在要把这个服务器送到某个机房去，搬着走吧„„汗

送到机房，我们要给服务器按照财务给的表格粘贴资产编号，选个顺眼的地方，不会磨损的地方。

一般是机器正面某个地方，然后是机器屁股后面某个地方，然后机器侧面把手的地方，粘贴3个，以防掉了就烦了。

然后在粘贴这个机器的应用资产号和IP标签：

应用资产号举例：FWQ-SH-XX-B31-WEBSERVER 意思是：服务器-上海-xx机房-B列31号机柜-web服务器

IP标签举例：外123.234.123.234内10.0.0.1。这2个标签你可以分开也可以在一张标签上写清楚。

并且在安装服务器的时候。把FWQ-SH-XX-B31-WEBSERVER-123-234 把这个作为你的HOSTS信息，windows里叫做计算机名

这样远程上来都非常清晰自己在哪个服务器上，出问题时候也非常容易找到这个机器，不要闲麻烦，一切的麻烦都是为了以后快速的解决down机问题而做的。当然啦，甚至在密码管理上你也可以用这个规则来设置密码，但是最好规则别让别人知道了„„

3，把这些信息全部录入你的资产管理系统

系统无非服务器名，IP信息，用途，机架位置，或者是否在使用一类的，我就不多讲了

4，资产系统软件交互，也可以说是监控系统。

企业可以开发一个软件，在装机的时候安装到服务器上。然后资产管理系统定时去取服务器上的信息，比如网络流量，CPU内存硬盘负载一类的东西，这样你的资产管理系统又变成了一个监控系统;

当然啦，你也可以在资产系统里集成一个远程桌面管理系统，自动载入用户名和密码，还有随机码，就可以登录系统。省的还得管理服务器密码。

然后用户的访问权限不同，看到的节面权限就不同。

比如说，监控人员没有登录权限，或者IDC人员没有登录权限一类。权限分配你自己研究好了。

5，还是IDC的工作。

话题继续回到我和财务小mm去盘点(你公司比较大的话，你可以多派几个人分开去各个地方„„)

小mm一看我们机房服务器黑压压的一片，铺天盖地的，直接无语。为啥，因为要拿着资产表一个一个核对，面对几千个机器，直接晕倒。

虽然按照资产管理系统里导出的信息，机柜号，IP号，机器从上到下的顺序都非常精确，但是你一个一个核对，还是慢。

怎么办?

库房管理的工作用上了，哈哈。你买服务器或者买笔记本电脑的时候有没有注意到箱子上的条码?

那个条码非常清楚的记录了这个机器的详细信息。所以黑莓手机或者NOKIA手机(别的我没用过)都有扫描条码的功能„„好像与主题无关„„

那么剩下的就简单了。

去买个这种条码标签的打印机，编辑成自己需要的条码，一个一个贴好，上面有你所有需要盘点的信息„„ 比如我们是从资产到机柜号到服务器名字到内外网IP都要盘点„„小崩溃

打印出来贴上去。然后买个扫描枪，和超市那种一样，不过你要买有存储功能的，否则你要端着笔记本去扫描，SB了。

然后我和财务mm本来需要一个人念号码一个人核对(你要直到在机房里大喊资产号，喊一天的结果是啥，自己想)，现在一个人拿一个扫描枪，按照规则一个一个扫描。完成后把数据导出后重新整理分析。直接和数据库核对(当然这个也需要你自己开发)，核对完成生成一张表。

表上写的非常清楚你哪个机架没有哪个机器，哪个机器不在特定的位置上，哪个机器缺少„„等等

这样比如说，机器位置不对扣5块钱工资，机器IP不对扣2块钱工资，或者„„反正扣到最后„„这月不给发工资了，还得倒贴点„„哈哈哈

六，监控架构

监控架构其实每个地方都有自己的做法，我也知道我的办法不是很先进，但是仍然拿出来和大家一起讨论

首先谈谈监控软件，一说起这个常用的东西MRTG,cacti一类的就都可以用了。只要稍微归类一下，流量展示看的还是很清楚的。

要是要监控服务一类的，那就只好启用大名鼎鼎的nagios,和一些牛x人基于这个做的一些别的商业软件。

或者就是自己做个脚本去定时探一下，不通了给你发邮件了啥的，你vim一下nagios的chack_xxx ，学习一下里头人家探测的办法，自己也能搞出来个啥东西，都还是很不错的了。

作为IDC工程师，我们所要关注的东西就是个流量了，我们要很清楚某台65下的某台35上每个口的应用，当遭受攻击或者流量异常的时候，一眼就能知道是怎么回事。我不相信你天天看着10M的流量，某天突然一下给你来个80M，你说这是正常事件吧。哪怕正常，你也找相关的人确认一下吧，一个100m口跑 80M,估计电信的人都来找你了。

每天看着这些流量图是很枯燥的事情，那么我们没事只能想办法让他自动报警给我们了，于是EMAIL报警，然后把他发送到一个有手机提示新邮件的邮箱，你手机就有了。MSN报警，还是不错的吧，手机报警一类的办法都是不错的。这样你你可以和我一样放心的去打网游了。这里只谈经验，不谈详细的技术，因为我一说我的系统架构地球人都知道我是哪个公司的了，虽然已经离职，但是咱也有个职业道德，谢谢。

当然了，有些公司是有网络监控部门的。但是我就一直在想这个问题，所有的数值都可以用短信报警，你随时都可以收到信息。用这个部门干啥，让一群可怜的家伙 8小时一动不动盯着屏幕，公司又在他们电脑上安装了抓屏软件，上班事件聊天上网就扣钱„„我估计他们每天最期望的事情也莫过于服务器挂了，可以给我们打个电话重启个服务器或者连到服务器上检查一下啥问题，重启个服务了啥的。当然了，这些兄弟最后的职业方向也只能是进入运维部门了，至少公司服务器宕机维护的流程性东西掌握的非常熟练了。但是这是用好几年时间换来的经验，太„„所以我是奉劝兄弟们有发现监控部门招聘人，就别去了吧。面前8台显示器，猛一看还以为是黑客帝国呐，结果仔细一看全tmd是流量图。常年对着8个显示器，那个辐射„„

我就不清楚设置个节点，出现问题告诉人，人去操作会死啊，非要让人和机器一样一动不动的盯着显示器，TMD，官僚。虽然我没经历过，但是想也能想到。做SA，最大的要点是懒，把一些需要人做的事情都自动化„„但是话说回来，我公司以人为本，人海战术嘛，可以理解。

上面的帖子位子已经满了，下来的帖子在这里写。

企业实际面对的一些问题

我大概通读了veyron 大侠的文章，认为系统架构方面的我绝对不如他。我就不在这里卖艺了，那么我卖企业都会实际面对的一些问题。

1，自动化，流程化你的信息管理

为什么要自动化，这年头流行办公自动化，你丫没事还拿着工单四处签字，老土了吧。

为什么要流程化，这念头流行流程管理，假如你公司没有一个固定的流程管理，出了事情，大家都不知道怎么做，各个部门的电话乱打，大家都一锅粥没有效率。所以，未雨绸缪，在没有出问题的时候，模拟出问题，多多准备，建立规范的流程，公司的每个人都要遵守，这样，流程化的管理+办公自动化，大家只用在电脑上翘翘键盘，点击确定，流程就发出去，一路审批，OK,流程发送到做事的人地方，也许这个做事的人在美国，也一样方便。

上面说的是一个原理和意思，用这样的理念去管理你的服务器应该如何去做?当然了，你假如只有10来台服务器，就不用考虑这个了„„. 首先服务器采购录入资产管理系统(详细见上面有写)，服务器的去向和调度都在管理系统里有提现。

这里说的是：如何去上架，维修，下架等流程控制

先说上架下架：服务器到机房以后，别人要用服务器怎么办?先可以到你的资产管理系统里，看你机房还有什么配置的机器多少台，然后让他们选择自己项目服务器的配置，数量。在流程管理系统中，把这些机器选中，生成一个表单，表单名字为xx项目上架需求，写清楚谁用，做什么，数量，哪个机房等。然后提交给他们部门领导，他们部门领导同意后，转给需要审批的领导，一层层下来，流转到我们部门领导，我们部门领导流转给部门机房员工，员工收到流程，检查上架下架服务器;如要上架，安装完系统后填写IP，机器名，机架等相关信息。如要下架，删除相关信息，提交给流程控制的人员，流程控制人员确认后，这个流程完成。届时，所有的人审批过的数据，经手人，数据库里都有，出现什么问题找相关责任人，一下就找到了，省的和某些XX部门JJYY。

维修也一样了，机器坏了，或者需要重装系统，按照上面的流程，一步步走一遍，就可以了。年底统计机房一天要干多少活，省的某些领导认为机房人TMD都在闲着。机房的人呢?没有流程不干活，否则白干。

在流程系统里重启服务器，重启服务器要是要流程，就太慢了，那么你可以做一个绿色通道，写清楚原因，重启哪个机器，直接提交给相关机房人员，在你的流程系统里绑定一个短信网关，机房人员可以收到需要重启服务器的短信。准确无误。

这样代替了无纸化办公，既有自己做的事情的每一个记录，又有相关人员管理，可以量化自己的工作，免得年终奖的时候xx人有说你干的少，发的少。你把记录拉出来对比对比就知道谁多谁少了。

2，如何升级你的服务器

服务器老了，或者需要加内存加硬盘，怎么升级。

虽然说是很简单换个CPU，加个内存，加个硬盘很简单。

但是，如何控制你的配件不丢失，确定的安装到机器上利用了呢?

简单，在服务器上做一个探测服务器配置的客户端，每天探测一次硬件配置发送到资产管理服务器上。

与资产管理系统的硬件配置做对比，出了问题就报错发一封邮件到机房工作人员，抄送流程控制人员一封就可以了。

至于的加内存的时候注意型号啥的问题就不说了，大家应该都没问题了要说的是，假如你一个机柜上放的机器比较多，比如4个6个机器一摞，恰巧坏了，恰巧一个人在机房，非得解决，怎么办?

简单，一个办法，但是还是需要你有力气，虽然有力学原理

比如有4台服务器，最下面的坏了，

你可以拽住最下面的把4台一起往出拉，拉出来一点，把上面3台往后推，这样一点一点的拉出来，

下面最关键：

拉到最后，前面要留出来一点，轻轻的把上面3台的尾巴着地，然后一只手抬住上面3台机器，一只手拉出下面一台机器。

上面3台一定要留出来一点，否则放下的时候，机器和机柜托板会压住你的手，你一松手，机器震一下，硬盘就挂了„„

所以在推进去的最后仍旧要留一点在外面，最后放下来了再推进去这最后一点。

然后就可以换或者加内存了。相对比较省劲，不危险，不会压倒自己，不会砸坏服务器的办法就是这样了。

本文来自 99学术网(www.99xueshu.com)，转载请保留网址和出处

>> 查看更多相关文档

上一篇：肉鸡养殖标准范文下一篇：入党详细流程范文

软件定义运维范文

第一篇：软件定义运维范文

第二篇：软件系统运维方案

第三篇：软件运维服务方案V1.2

第四篇：中小型企业管理软件、中小型企业管理软件适合就好、中小型企业管理软件定义、中小型企业管理软件意义

第五篇：漫谈运维—运维工程师

热门文章

精品范文

全站热搜