平台系统日常运维投标方案技术方案书

平台系统日常运维投标方案2

目录

第一章对政务共享应用平台系统业务架构、技术架构、功能架构的

撑握程度.................................................3

1.1.平台系统维护.....................................3

第二章提供基础数据维护架构和方案.......................7

2.1.平台系统运营.....................................8

第三章对政务共享应用平台系统数据库架构、数据库结构、表结构

的掌握程度.............................................10

3.1.系统安全维护的几个要点：.........................10

第四章对基础支撑平台业务架构、技术架构、功能架构、操作使用、

系统配置的撑握程度.......................................12

4.1.定岗定职准责...................................12

4.2.定级定时准责...................................12

第五章对协同办公系统业务架构、技术架构、功能架构、操作使用、

系统配置撑、流程配置的握程度.............................14

5.1.巡检服务.......................................14

5.2.维护双周报.....................................15

5.3.故障专项报告...................................15

第六章对移动办公系统业务架构、技术架构、功能架构、操作使用、

系统配置的撑握程度.......................................16

6.1.对于系统故障事件...............................18

6.2.对于自然灾害性事件.............................19

6.3.对于电力中断事件................................19

第七章对政务知识管理及决策支持系统业务架构、技术架构、功能

1

架构、操作使用、系统配置的撑握程度........................20

7.1.故障维护.........................................20

7.2.性能优化.........................................20

第八章对及时通讯系统业务架构、技术架构、功能架构、操作使用、

系统配置的撑握程度.......................................23

8.1.功能设计咨询服务.................................23

8.2.应用软件开发咨询服务.............................23

8.3.基础设施咨询服务.................................24

8.4.系统系统技术维护.................................24

第九章驻场维护人员团队中5年以上工作经验软件开发工程师参与

驻场......................................................26

9.1.UPS电源系统维护.................................26

9.2.UPS蓄电池的安装环境.............................27

9.3.使用UPS的注意事项...............................28

9.4.培训方案及计划...................................30

2

第一章对政务共享应用平台系统业务架构、技术架构、功能

架构的撑握程度

1.1.平台系统维护

政务共享应用平台系统测试完成并成功上线后，就进入了系统的

维护阶段，保证平台质量，确保其可以持续稳定的运行，防止出现平

台打开缓慢、页面显示错误、数据丢失等问题。一般来讲，大型系统

软件维护成本都比较高，甚至高出其开发成本的数倍。现阶段平台普

遍将一半以上的开发技术团队投入在其平台系统的维护上，伴随着平

台功能多样化、复杂化的发展趋势，这个比例还将持续增加。

1.1.1.现阶段平台维护的种类

1.改正性维护。

在平台开发过程中，系统在上线前的测试阶段不会完全把所有潜

在隐患都暴露出来，这些程序问题，会在用户使用期间逐步浮现出来，

并且被报告给平台的维护人员，维护人员根据相应问题进行系统的修

复。这一诊断和改正的过程成为改正性维护。

2.适应性维护

计算机硬件更新日新月异，当前市场的硬件设备换代周期为一年

左右，且经常增加或修改外部设备以及其他系统部件，适应性维护，

则是针对这一现象，配合变化了的环境而进行的对系统硬件的一种维

护措施。

3

3.完善性维护

当前市场功能需求变幻莫测，对出现新的需求的响应速度决定了

能否在惨烈的市场竞争中占领制高点。除了新功能的增添和修改，还

有可能出现一般性的系统改进意见，而对于系统软件进行完善性维护，

就是满足于此类需求的手段。

4.预防性维护

预防性维护主要是针对改进系统未来的可维护性，给未来改进奠

定基础的一类未雨绸缪的维护性活动。这种维护的大背景是系统基于

多年以前的老程序，体系结构和数据结构比较差，因而在现阶段平台

上使用较少。

1.1.2.平台维护过程内容

系统的维护过程包括建立一个维护性组织，确定报告和评价的过

程，同时需要为每个维护行为要求一个标准化的时间序列，此外，还

应建立一个适用于维护活动的记录复审过程。

1.维护组织

每个维护需求都应该通过维护团队的负责人转交给熟悉该项内

容的系统管理员去评价。系统管理员是指被指定去熟悉一部分程序内

容的技术人员。在系统管理员对维护任务作出评价之后，再转交被指

定技术人员进行维护行为。此项内容十分必要，可有效的减少维护过

程中出现的混乱。

4

2.维护报告

应该用所规定的格式表达所有系统的维护要求。系统组织内部应

该制定出一个修改报告，包含满足维护需求所需工作量、维护要求的

性质、要求的优先次序、与修改有关的事后数据等信息，保证时间节

点清晰可控，整个过程有序高效。

3.维护的事件流

对于改正性维护要求而言，整个流程从估量错误的严重程度开始。

如果是一个严重的错误，比如某个关键的系统不能正常运行，则在系

统管理员的指导下进行合理的人员分配，并且立即进行问题的分析过

程。对于不是很紧急的问题，则可以将其维护工作和其他的技术项目

一起统筹安排。

对于适应性维护和完善性维护，首先确定每个维护项目的优先次

序，并且安排要求的工作时间，整个过程跟系统开发的过程十分类似。

不论维护的类型如何，都需要同样的技术工作。这些工作包括修

改设计、复查、必要的代码修改、单元测试和集成测试、验收测试和

复审等。

收集有效的维护数据对衡量、评价整个维护活动以及以后的复查

至关重要。根据此结果，还可以做出关于开发技术、语言选择、工作

量拟定、人力资源分配等决策优化方案，提升了后续类似工作的效率。

维护过程中值得记录下来的包括：程序标识、源语句数、机器指

5

令条数、使用的程序设计语言、程序安装日期、安装以来的运行次数、

安装以来的失效次数、程序变动的层次和标识、因程序变动而增加的

源语句数、因程序变动而删除的源语句数、每个改动耗费的人数及时

间、程序改动日期、技术人员姓名、维护要求的标识、维护类型、维

护开始和完成的日期、累计用于维护的人数及时间、于此维护挂钩的

效益等。

6

第二章提供基础数据维护架构和方案

维护政务共享应用平台生命周期最后的阶段，也是最复杂、繁琐

的阶段，在平台运行的期间维护工作的开展伴随着很多难点。

1.政务共享应用平台系统的维护人员不一定是当初的开发人员，

或者系统开发是当初外包或者买来的，有些甚至没有源代码，这样就

给维护人员的素质设定了很高的门槛，对于一些对代码结构不是很熟

悉的技术人员而言，一些系统性的维护工作很难开展。

2.平台的维护工作工作量大，时间长，内容枯燥且成果不易体现，

从而造成维护人员工作热情低，积极性受挫。

3.开发记录文档内容丢失或不全。造成此类原因可能是开发阶段

文档本身由于开发人员的不专业造成的不健全，或者是由于时间长，

人员更迭交接不到位，开发文档部分丢失，还有可能是之前的维护工

作期间没有做好记录，及时修改文档。文档内容的不健全会对后期系

统维护及新功能的开发、测试工作带来极大阻碍。

4.维护工作成本高。系统的维护工作工作量高，时间跨度大，技

术人员要求严格，对于企业，尤其是初创企业而言是一个不小的负担。

5.政务共享应用平台在技术力量薄弱的情况下，普遍的做法是委

托系统开发商进行数据托管以及系统维护的工作，这样做的目的是有

效降低成本。但同时缺点也显而易见。由于数据库不由平台自己掌控，

会面临客户资料泄露、资金流动失误等业务风险，或者是系统维护不

7

及时，托管方响应速度慢等问题。

系统运营的每个阶段都与其维护性有着密切的联系。合理的设计，

完整准确易读的记录文档，以及严格的复审和测试流程，有助于发现

错误时的诊断与修正，当外部对系统提出新的要求是也能够较容易的

适应于优化，并且可以有效地节约后期工作的成本。因此，平台应在

系统运营的任何阶段都充分考虑其维护问题。

2.1.平台系统运营

2.1.1.系统内容

系统内容要及时更新，且要多加原创。现在对信息的要求更高：

有价值、可靠性及是否新颖及时等。只有及时研究和跟踪最新变化情

况，才能使电子商务系统发挥最大的作用。其中系统服务等是必须及

时更新展示的。另外还需要注意以下几个方面：

1、新闻栏目：这是了解政务平台的门户，其应将政务的重大活

动、最新动态、发展趋势、服务措施及时，让新闻栏目成为系统的亮

点，以此吸引更多的客户前来浏览。

另外，系统技术人员要经常对网页链接进行测试，保证各链接正

确无误。在内容更新方面需要补充说明的是，要实现快捷更新、提高

效率，一定要考虑站点的维护计划，因为站点的整体运作具有开放性、

动态性和可扩展性，所以站点的维护是一个长期工作，其目的是提供

一个可靠、稳定的系统。使信息与内容更加完整、统一，并使内容更

加丰富、新颖，不断满足用户更高的要求。

8

其次，制定一整套信息收集、信息审查、信息发布的信息管理体

系，保证信息渠道的通畅和信息发布流程的合理性，既要考虑信息的

准确性和安全性，又要保证信息更新的及时性。第三，根据需要选择

合适的网页更新工具，如数据库技术和动态网页技术等。

9

第三章对政务共享应用平台系统数据库架构、数据库结构、

表结构的掌握程度

系统是对外开放的，这便于发布商务信息，但这同时也给系统的

安全带来了威胁，保证系统的安全运营是系统维护不可缺少的一部分。

为了维护系统的良好形象，保证系统业务系统的正常运行，保证商务

信息的秘密不外泄，系统的管理人员应该不断寻找网络中的簿弱环节

和安全漏洞，及时进行修复和改进。

3.1.系统安全维护的几个要点：

1.如果存储有系统的硬盘出现故障，那么在送修的过程中，一定

要选择信誉好的商家，以免系统等数据被全盘复制。仔细查看系统的

安装说明，切记修改默认数据库名称，并且把默认的数据库存储目录

进行更改。

2.尽量不采用无组件上传，使用其他组件上传方式，比如Fileup

或LyfUpload,部分无组件上传带有严重漏洞，一般可通过修改

upfile.asp文件选择上传方式。

3.经常访问相关软硬件官方系统，关注程序安全漏洞和更新版本，

及时给升级程序或打上补丁。

4.尽量不采用修改版和插件版的程序，因为修改后的程序可能

会使漏洞更多，而且补丁也不一定完全适用。

10

5.设置相对复杂的FTP密码和系统管理密码并经常修改，同时

考虑修改系统后台管理的文件名称。经常检查系统内文件，发现可疑

文件后及时处理，并分析可能的

6.对于SQL数据库，可以用企业管理器连接，然后把重要数据

表设置为只读权限，例如把系统的管理员表修改为只读以后，可以防

止任何方式添加管理员。

7.经常备份自己的系统数据，因为系统安全的第一要求就是备

份，防止被黑以后数据丢失。备份的方法有两种，一是只备份系统的

数据库，二是通过FTP的方式备份整个系统。

Il

第四章对基础支撑平台业务架构、技术架构、功能架构、操

作使用、系统配置的撑握程度

每一个系统平台在建立初期总是会经历一系列bug的调试阶段。

平台的管理人员需要针对系统各个方面的建议与提醒，从而保证系统

安全稳定的运行。为了让系统用户和平台团队能统一快速提交系统

BUG,平台的管理员需要做到以下几点：

4.1.定岗定职准责

平台对于系统BUG的收集、处理以及反馈需要进行定职，其技术

团队是最懂得系统平台的一群高级用户。同时，而系统BUG总是不断

存在并且不断地被发现，因此团队内部建立系统BUG的收集和处理以

及反馈体系就显得尤为重要。

在平台的建立初期就应当设立系统BUG信息收集的岗位，职位的

定岗这将成为解决系统BUG问题的前提；系统在建立后将团队分成若

干组，分别承担系统BUG信息处理，例如前端、程序与功能、内容错

误情况等，并制定各岗位针对系统BUG的处理进行框条式的规范，定

岗定组。

4.2.定级定时准责

随着系统用户基数的不断增加和高级用户群的不断积累，系统

BUG随时都有可能发生，并且需要在特定时间段内尽快解决。一般的

处理方法如下：

12

系统BUG在定岗定职后须进行等级划分，例如，产生在的问题会

员中心划分为A级、系统前端划分为B级、内容错误划分为C级，并

对于不同级的BUG进行定时处理机制。A级错误一旦发现必须马上进

行修正，因为会员中心的内容涉及系统用户最为核心的操作。

定完系统BUG级别后，还应将技术团队分为一线和二线。一线人

员负责的内容为系统体验和用户体验，并定好时间周期进行BUG提交，

并在划定好的时间内将修正信息传达给二线。二线人员将其提交至

BUG信息数据库中，以备运营者及时了解系统BUG情况。

系统初期的建设伴随着的就是不高的体验度和非一般的用户数

据，面对层层不良的情况，平台管理员应该做好准备进行逐一解决。

系统BUG是系统发展中最为致命和升华的内容，处理好系统BUG是每

一个平台必须做好的事。

13

第五章对协同办公系统业务架构、技术架构、功能架构、操

作使用、系统配置撑、流程配置的握程度

协同办公系统验收完毕后，定期对用户系统进行巡回检修服务。

对用户系统的工作环境、设备运行状态、性能、安全性等方面进行检

查。进行必要的预防性维护，及时解决用户系统中存在的问题，以确

保整个系统的安全、高效运行。并在每个季度末向业主方提交《系统

巡检报告》,详细报告系统的运行状态、发现的问题，解决情况，是

否有遗留问题，遗留问题状态等方面的情况。

5.1.巡检服务

实施方根据信用平台运行情况，每周对信用平台健康性进行检查

并提供巡检报告，巡检内容包括：

信用平台运行检查；

错误日志分析；

检查信用平台相关数据库结构、初始化参数、主要配置文

件；

检查信用平台相关数据库运行状况；

检查信用平台相关数据库空间的使用情况及规划管理；

检查信用平台相关数据库备份的及时性；

检查信用平台相关硬件设备运行状态检查。

14

并将结果以巡检报告的形式及时反馈给业主信息化管理部门，乙

方将定期向甲方提供平台运行情况统计分析、数据质量分析、系统升

级、故障处理、系统优化建议等相关报告。主要有：

5.2.维护双周报

乙方根据甲方要求提交双周报，内容包括系统平台总体运行情况，

软硬件检查，故障处理分析，系统升级情况，数据质量检查，系统使

用次数统计，系统优化建议，重大问题进展等。

5.3.故障专项报告

每次故障处理后五个工作日内提交故障报告单，内容包括故障时

间，故障现象描述，故障处理过程，故障处理结果，预防保障措施。

服务内容

开始时间结束时间

巡检服务计划表：

巡检维护报告

巡检时间巡检设备内容

子系统

网络子系统1周/次交换机、防火墙

在线系统1天/次相关软、硬件设备

15

第六章对移动办公系统业务架构、技术架构、功能架构、操

作使用、系统配置的撑握程度

具有远程接入服务、现场支持服务、系统恢复和故障解决服务。

故障排除过程中如遇到紧急情况需要处理，为规范和加强网络重

大信息安全事件的信息报告管理工作，及时掌握和评估重大信息安全

事件有关情况，协调组织力量进行事件的应急响应处理，降低信息安

全事件的损失和影响，根据中共中央办公厅、国务院办公厅转发《国

家信息化领导小组关于加强信息安全保障工作意见》的通知(中办

[2003]27号)和有关法律、法规的规定，结合公司实际，制定本规范，

则全体网络管理员组成网络安全应急团队：

(一)完善各项应急预案的制定和各项措施的落实。

(二)认真搞好各项物资保障，严格按照预案要求积极配备网络

安全设施设备，落实网络线路、交换设备、网络安全设备等物资，强

化管理，使之保持良好工作状态。

(三)采取一切必要手段，组织各方面力量全面进行网络安全事

故处理工作。

(四)调动一切积极因素，全面保证和促进网络安全稳定地运行。

紧急故障应急措施应以快速恢复客户使用为目标，第一时间将客

户使用状态恢复到正常，避免或尽量减少因故障而导致的损失。

16

根据实际情况和需要制定基本的安全管理制度，对重要设备、软

件和业务数据的安全性进行规范、可靠的管理，提高本部门信息系统

的安全防护能力。包括配合技术部制定机房管理制度、设备管理制度、

病毒防治管理制度、数据备份与恢复制度、系统管理制度、安全审计

制度和应急响应制度等。

在【问题管理】流程中，当服务主管收到服务台人员或助理提交

的《运维工作单》,并判断该问题属于重大事故时，则启动应急处理

流程。重大事故包括以下几种情况：

大范围系统中断、区域性系统崩溃、关键业务中断、大范围病毒

爆发系统严重破坏、数据严重破坏。

根据重大事故的紧急程度和状态不同，服务主管可采取以下方式

启动应急流程：

当紧急事件发生时，我公司的运行人员首先要进行故障分析，确

定故障的范围和程度，确认为紧急故障的，在查找原因和解决问题的

同时，要同步将故障解决情况通报给部门领导、及向客服中说明事件

发生的状况。如需其他部门协助的，需要请求相关部门共同尽快解决

故障。

对于系统故障事件，我公司的运维人员首先要启用备份系统，再

判断故障类型：硬件损坏、操作系统故障、软件故障。硬件损坏的情

况，首先向服务器供应商报障；操作系统故障多数情况都和硬件故障

同时出现，处理方式相同；软件故障如果是由购买的软件造成的，立

17

即向软件厂商寻求技术支持；如果是应用系统软件，立即向相关人员

联系并排除故障。

对于自然灾害性事件，运维管理人员要尽可能将设备转移到安全

地带，将损失降低到最少。

在故障排除之后，运行管理人员要填写故障记录，如果故障是由

于项目实施中存在的隐患造成的问题，具体操作请参见上层文件《网

络系统维护管理指引》。故障记录汇总到“系统运行故障记录表”,重

大事故由故障处理人填写故障报告。

当紧急事件发生时，我公司的运行人员首先要进行故障分析，确

定故障的范围和程度，确认为紧急故障的，在查找原因和解决问题的

同时，要同步将故障解决情况通报给部门领导、及向客服中说明事件

发生的状况。如需其他部门协助的，需要请求相关部门共同尽快解决

故障。

6.1.对于系统故障事件

我公司的运维人员首先要启用备份系统，再判断故障类型：硬件

损坏、操作系统故障、软件故障。硬件损坏的情况，首先向服务器供

应商报障；操作系统故障多数情况都和硬件故障同时出现，处理方式

相同；软件故障如果是由购买的软件造成的，立即向软件厂商寻求技

术支持；如果是应用系统软件，立即向相关人员联系并排除故障。

18

6.2.对于自然灾害性事件

运维管理人员要尽可能将设备转移到安全地带，将损失降低到最

少。

6.3.对于电力中断事件

由于机房多采用UPS防止断电带来的系统停机现象，在UPS还能

供应电力期间恢复供电，对系统使用不会有影响；但遇到特殊情况导

致供电部门在短期内不能恢复供电时，如有备用发电设备要启用备用

发电设备供电，否则要关闭所有设备，确保突然断电造成设备损坏。

19

第七章对政务知识管理及决策支持系统业务架构、技术架构、

功能架构、操作使用、系统配置的撑握程度

为了平台各种级别的故障时得到相应级别的关注和资源支持，在

故障处理过程中，乙方维护工程师和甲方工程师可根据故障处理进

度，参照下表逐级升级。

升级时限一级故障二级故障三级故障四级故障

1小时运维经理.///

4小时项目经理运维经理//

24小时副总经理项目经理运维经理/

48小时总经理副总经理项目经理运维经理

7.1.故障维护

质保期内用户正常使用时出现的软件故障和缺陷，由我方负责任

修复。因用户使用不当或者不可抗拒因素所造成的问题，我方全力配

合解决，派驻至少1名技术人员现场服务，对软件系统提供免费维护，

同时，对接口变更、需求优化等基本模块调整的开发，提供无偿服务。

7.2.性能优化

结合系统实际运行情况和客户方需要，对信用平台进行性能优化

和调试，提升信用平台各方面的综合性能，具体优化事宜双方友好协

商。

20

平台占用资源优化；

平台运行效率优化；

平台软件配置优化；

操作友好性优化；

平台现有功能优化。

用户与你系统服务器的接近程度会影响响应时间的长短。把你的

系统内容分散到多个、处于不同地域位置的服务器上可以加快下载速

度。

性能与应用系统的代码、应用服务器都有着密切的关系，应用的

代码写的再好，如果应用服务器的配置不当，性能也不会好；同样，

应用服务器调整的再好，也难以掩盖应用代码中存在的缺陷，因此，

首先要保证应用有个稳固可靠的体系结构，有最优质的代码，在此基

础上再来集中精力调整应用服务器，这样才能达到应用系统性能优化

的理想效果。

按地域布置系统内容让他们在分发服务器上正常运行。根据应用

的需求来改变系统结构，这可能会包括一些比较复杂的任务，如在服

务器间同步Session状态和合并数据库更新等。要想缩短用户和内容

服务器的距离，这些架构步骤可能是不可避免的。

在终端用户的响应时间中有80%到90%的响应时间用于下载图像、

样式表、脚本、Flash等页面内容。这就是系统性能黄金守则。首先

21

来分布静态内容会更好一点。这不仅会缩短响应时间，而且对于内容

分发网络来说它更容易实现。

内容分发网络是由一系列分散到各个不同地理位置上的Web服务

器组成的，它提高了系统内容的传输速度。用于向用户传输内容的服

务器主要是根据和用户在网络上的靠近程度来指定的。例如，拥有最

少网络跳数和响应速度最快的服务器会被选定。

再者，可以检查系统的空载负荷，空载负荷指仅安装操作系统的

情况下，通过一些工具查看系统的负荷。这样做的目的是通过检查系

统的运行情况，减少和屏蔽不必要的服务，最大限度的为应用系统提

供更多的资源，建议是通过编写脚本记录系统运行时的性能情况，比

如按占用CPU对进程排序，如果是非核心进程，则可以根据情况停止

这些进程的启动。

22

第八章对及时通讯系统业务架构、技术架构、功能架构、操作使用、

系统配置的撑握程度

对及时通讯系统提供数据接入和应用开发的技术支持和咨询服

务。

平台推广的方式有很多，例如平台互推、广告、新媒体方式宣传

等，对于我们这个行业，有政府和国家的支持，社会发展的依托，凡

是需要查询征信、出征信报告的人或者企业均需登录平台。

数据接入，需要通过数据接口来完成，数据接口方式(WebService、

数据库、FTP等),接口需具备数据配置、数据加解密、数据压缩/解

压缩、数据完整性校验、数据版本管理、数据入库、跨网数据交换监

控和日志管理等功能。

8.1.功能设计咨询服务

●甲方提出关于新功能的具体要求、期望、目标，乙方项目经理

及时响应并组织研讨，提出相应的软件系统规划建议，提交甲

方。

8.2.应用软件开发咨询服务

●行业征信系统开发咨询；

●企业信用应用产品开发咨询；

●信用评价相关系统开发咨询；

23

●知识管理系统开发咨询。

8.3.基础设施咨询服务

网络系统咨询；

安全系统咨询；

技术平台咨询；

应用系统咨询；

技术标准与规范咨询；

网络资源管理咨询；

系统发展策略咨询。

8.4.系统系统技术维护

根据采购人与数据源单位协调进度，及时提供技术支持，配合完

成各数据源单位数据接入，主要包含数据采集、数据清洗入库等。

数据采集方面主要需要将市政府部门、省信用平台、第三方征信

系统、信用主体自主申报及互联网收集等来源的数据进行数据清洗、

转换、关联、装载、非结构化处理后才做分析使用依据。这则需要通

过接入数据接口、前置机、互联网抓取等技术方式来实现。

在网络等条件允许的情况下，可通过桥接交互的方式，由数据交

换平台与各单位业务系统对接，实现数据的自动交换，完成数据采集。

数据接口采集，提供统一标准数据接口规范，可满足不同应用系统的

24

对接，同时支持不同类型的数据接口定制开发。

系统具备多种数据接口方式(WebService、数据库、FTP等),接

口需具备数据配置、数据加解密、数据压缩/解压缩、数据完整性校

验、数据版本管理、数据入库、跨网数据交换监控和日志管理等功能。

系统除支持本约定的设计规范外，还提供标准化的WEBSERVICE外部

接口，遵循SOA功能架构规范，遵循XML技术标准、TCP/IP协议标

准、LDAP协议标准、SSL安全协议标准。

需根据网页的交换链接设置不同的抓取深度，抓取相关系统上的

页面数据；可自定义格式化数据表，根据关键字进行采集，设置不同

的解析规则，实现格式化数据的抓取；可在不同的主机资源上设置无

限个调度任务，无限设置添加采集节点，实现对互联网数据的深度抓

取。

25

第九章驻场维护人员团队中5年以上工作经验软件开发工程师参与

驻场

我公司承诺

1、派遣2名工程师驻场负责政务共享应用平台的日常运维工作；

2、为期2年；

3、驻场维护人员团队中5年以上工作经验软件开发工程师参与

驻场。

其他；

9.1.UPS电源系统维护

UPS电源系统由整流、储能、变换和开关控制4个部分组成，原

理如图1。

在电网电压工作正常时，给负载供电，同时给储能电池充电；当

突发停电时，UPS电源开始工作，由储能电池供给负载所需电源，维

持正常的工作；当由于需要，负载严重过载时，由电网电压经整流直

接给负载供电。

当我们没有使用UPS的时候，采集器、PC机及打印机等终端设

备是直接使用市电的，用了UPS,就将终端设备接到UPS上(相对于

UPS而言，我们将这些终端设备称为负载),而UPS再接入市电。当

26

市电输入正常时，UPS将市电稳压后供应给负载使用，此时的UPS就

是一台交流市电稳压器，同时它还向自己的内置电池充电；当市电中

断(例如停电)时，UPS立即将内置电池的电能，通过逆变转换的方法

向负载继续供应220V交流电，使负载维持正常工作并保护负载的软、

硬件系统不受损坏。

9.2.UPS蓄电池的安装环境

目前UPS所用的蓄电池一般都是免维护的密封铅酸电池，设计寿

命普遍是5年。UPS电源安装环境直接影响到UPS系统的运行情况及

使用寿命。因此，合理选择安装位置尤为重要。

1)UPS设备应安装在清洁、阴凉、通风、干燥的地方，否则灰

尘加上潮湿会对其内部器件造成腐蚀或短路，引起主机工作紊乱从而

影响UPS的正常工作，严重的可能会损坏UPS。同时要避免受到阳光、

加热器或其他辐射热源的影响；

2)UPS的电源主机对使用环境的温度要求不是很高，一般情况

下+5℃~40℃都可以正常运行。然而它的储能蓄电池对温度的则较高，

标准使用温度为25℃,在平时不能超过+15℃~+30℃;

3)将UPS接到专用的带有过电流保护装置的插座上时，所用电

源插座应接保护地端，一般接地电阻小于5Ω较为理想；另外无论输

入电源线是否插入市电插座，UPS输出都可能带电；

4)UPS不间断电源不宜侧放，每个电池之间的连接要牢固，应

保持进风孔与出风孔通畅。

27

9.3.使用UPS的注意事项

3.1正确使用UPS

1)使用前要认真阅读操作说明书，熟练掌握各种开关，按钮的

作用，明白每个警示信息，警示代码及指示灯的含义，及产生问题的

原因和解决办法；

2)掌握正确的开、关机步骤。开机时，应该先开启UPS的市电

开关，再按照负载的冲击电流从大到小的顺序逐个打开负载开关。切

忌将所有负载同时开启，更不能带载开机。关机时，则先逐个关闭负

载，再关闭UPS开关，最后关闭UPS市电开关。当然同样也不能进行

带载关机的操作；

3)加强日常检查和维护，确保小问题能够早发现早处理。检查

内容包括设备指示是否正常，有无告警提示或异常声响，各种接头有

无松动或发热等。

3.2UPS电池的保养

UPS电源在正常使用情况下，主机