(精编)项目运维服务工作量评估V1.02
运维服务绩效考核指标
运维服务
3.2 发现问题
说明：待完善
1、考核内容按不同职位不同项目，分为五个等级：好、较好、一般、较差、差，总分100分。
2、每名运维人员总分不得低于70分，否则按不合格计。
3、考核指标排在最末的和不达标的，需要以书面形式写出原因及改进方案，并绩效奖金扣？%。
4、当月考核指标达到90分以上，绩效奖金给予奖励？
5、连续6个月考核指标达到90分以上，月薪资提升？%
维服务绩效考核指标（v1.1）
、较差、差，总分100分。
进方案，并绩效奖金扣？%。
10
运用技术问题发现率发现问题次数/运用技术总数
好10 、较好8、一般6、较差4、差2。
运维工作中的KPI指标有哪些
运维工作中的KPI指标有哪些在当今数字化的时代，运维工作对于企业的稳定运营和业务发展起着至关重要的作用。
为了有效地评估和管理运维工作的绩效，确定合适的关键绩效指标（KPI）至关重要。
KPI 能够帮助企业衡量运维团队的工作效果，发现问题并及时改进，从而提高系统的稳定性、可靠性和性能。
那么，运维工作中究竟有哪些重要的 KPI 指标呢？首先，系统可用性是一个关键的 KPI 指标。
它反映了系统在特定时间段内正常运行的时间比例。
例如，如果一个系统在一个月内计划运行时间为 720 小时，但实际上出现故障导致停机的时间为 20 小时，那么系统可用性就是（720 20）／ 720 × 100% ＝ 9722%。
通常，对于大多数关键业务系统，目标可用性应在 999%以上。
系统可用性直接影响到用户体验和业务的连续性，如果系统频繁出现故障或停机，将给企业带来巨大的损失。
其次，故障平均修复时间（MTTR）也是一个重要的指标。
MTTR 是指从故障发生到故障完全修复所花费的平均时间。
例如，一个月内发生了 10 次故障，修复这些故障所花费的总时间为 50 小时，那么MTTR 就是 50 ／ 10 ＝ 5 小时。
MTTR 越短，说明运维团队处理故障的能力越强，能够更快地恢复系统的正常运行，减少故障对业务的影响。
再者，服务响应时间也是需要关注的 KPI 之一。
这包括用户提出服务请求到运维团队做出响应的时间。
比如，规定在收到用户请求后的30 分钟内必须做出响应，如果能够在更短的时间内响应，就说明服务响应效率高。
及时的响应能够提高用户满意度，增强用户对运维服务的信任。
另外，性能指标如系统的吞吐量、响应时间和资源利用率等也是运维工作中的重要 KPI。
系统的吞吐量表示单位时间内系统处理的事务数量或数据量。
例如，一个网站在一小时内处理了10000 个页面请求，那么其吞吐量就是 10000 个页面请求/小时。
响应时间则是指用户发起操作到系统给出响应的时间间隔，对于在线交易系统，响应时间通常要求在几秒钟以内。
工作量评估方法完整版.完整版.docx
关于工作量评估方法为能清楚阐明论点。
先举两个例子。
大家一定都听说过“龟兔赛跑”的故事，故事里乌龟是正面人物，而兔子作为反面人物受人讥讽，其中的寓意教育人们做事要像乌龟一样有坚忍不拔的精神。
如果换个角度分析这个故事。
则会有不同的结论。
兔子在整个赛跑过程中做了两件事，那就是赛跑和睡觉；乌龟则仅做了一件事，就是不停地赛跑。
如果我们试把时间延长（即看看它们在赛后又做了什么），可以想象乌龟由于比赛的疲劳，而跑回家呼呼大睡了；兔子呢？由于比赛中同时也保养了精神，赛后可以做其它更多自己想做的事。
由此，不难得出整个过程兔子的效率更高。
另外，乌龟并不擅长跑步，却安排它去参加这场比赛，其效率必然极低，把这种现象映射到企业管理中去，也颇发人深思。
试看一个说明工作效率与工作饱和相矛盾的例子：某工厂的一位计算机技术人员，现场发生了微机故障，从他的办公室到达故障点的方式有两种选择，其一是步行，需要10分钟；其二是骑自行车，只需2分钟。
我们设步行到现场的为甲，骑车到现场的为乙，最后统计：两人去处理同样的一个工作，甲用了30分钟，而乙只用了15分钟，（这里是假设两人故障的修复时间相同，但事实上甲这类人在故障修复中要花更多的时间）。
乙在剩下的15分钟又可以做其它更多的事情，单从这点出发，甲与乙在工作成效上就不仅是1：2的差距了，而是1：N（即甲做一件事的时间，乙做了N件事）的差距。
但在现实中，甲往往成了“工作量饱满、劳动模范”的象征；而乙却常常恰好相反，这是管理人员认识上的一大误区，长此下去必然带来管理上的一系列问题。
工作效率由员工的自身因素决定，但如何激励员工提高工作效率，目前仍是管理上的问题。
首先是工作分配的合理化，它直接影响工作的效率，让乌龟去赛跑，显然是不合理，所以对工作的合理分配是提高效率的首要条件，这与管理人员的工作密不可分，要求管理人员不仅清楚了解管辖范围内的工作内容，而且要对被管理人的基本情况有清楚的认识。
工作分配合理后，那如何主动去提高每个员工的工作效率呢？竞争是个好方法，奖惩也是个好方法，另一种就是让员工自身有好的素质，拥有正确的人生观及世界观，提高效率便成为很自然的事。
项目涉及运维评估
生成环境工作主要包括3个阶段，分别为日常发布的需求收集及确认，预发布确认，正式发布。
在日常发布需求的收集及确认阶段，由于需求收集确认完成后运维后端准备服务器，存储，网络等资源需要一定的时间，因此对于开发提交需求的时间有一定的要求，具体要求如下：
1、如果涉及涉及网络的专线、网络策略、前置机等，需在项目开始时就找asa评估。
2、如果涉及存储、主机等内容，随日常发布的，在发布前一周的周四中午12点之前
提交asa评估。
3、如果搞活动推广、或者业务量切割等等涉及系统的容量有关（扩容等）的需求，请
至少提前5个工作日联系asa评估。
4、如果不知道是否有相关需求的，项目一开始就可以联系asa评估和讨论。
5、原则：运维评估宜早不宜迟！。
运维工作绩效评价指标
高级10分，中级5分 1分/邮件，总分不超过3分
2分/次，总分不超过5分 表扬通报2分/次 每次扣10分 根据情节严重给予一次10-20分的扣分
核者沟通
总
考核 被考核人签字：
认：
上级确认：
依据数据/来源 自评得分 主管评分 扣分说明/备注
总分
考核人签字：
被考核人签字：
日期：
日期：
加、减分项
加、减分项
3 知识分享
4 表扬通报 5 用户投诉 6 工作失误，通报批评
主动为大家提供培训及专业
知识指导 明确得到公司、客户的表扬 客户或内部投诉 工作中的重大失误
上月绩效改进结果：
考核面谈
本月绩效改进目标：
对于上述考核结果及意见本人表示：□愿意接受 □不愿意接受，本人要求与考核者沟通
9年_____________部运维岗位_____月绩效考核表
：
月初目标员工确认：
评价标准
目标值
按照实际达标率赋分，即每项达 100%
标率*权重
100%
权重 月中自查完成比例 完成情况 10%
100%
按照实际达标率赋分，即每项达 标率*权重
Байду номын сангаас
100%
30%
100%
100%
按照实际达标率赋分，即每项达 标率*权重
100% 100% 100%
20%
100%
100%
100%
计划完成进度*100% 达标率=实际完成升级次数/
当月升级总次数*100% 达标率=实际进度/当月计划
应达到进度*100% 达标率=实际进度/当月计划
应达到进度*100% 达标率=实际进度/当月计划
运维服务评价考核
满分ห้องสมุดไป่ตู้0分
工程师服务态度（4分）
协作性、责任心、积极性等
满分4分
工程师解决事件后向用户陈述说明（6分）
书面/口头陈述
出现用户投诉未陈述说明（每次扣2分）
标准分值
考核人
得分
四、能力与可持续性考核情况
5
一级指标
二级指标
三级指标
指标说明
评分说明
考核得分
能力与可持续性
（5分）
符合合同要求人员比例（1分）
本月运维人员对安排事件的处理效率及解决程度合格/不合格，经考核得x分；（扣分分值为负）
例行型服务质量（15分）
巡检巡查完成情况（4分）
出现以下任何一种情况一次扣2分：完成得4分。
1、没有按时按要求对软硬件设备、网络、应用系统进行日常巡检巡查；
2、工作报告没有如实反映存在的问题。
本月日常巡检巡查是/否按要求进行，并报送/未报送相关巡检记录等，得x分；（扣分分值为负）
主动完成软硬件、应用系统的更新与升级，数据备份等操作。（不包含对安全层面），更新与升级得3分，数据备份得2分，没有的不得分
本月完成/未完成了xx的更新与升级，完成/未完成数据备份，得x分；
用户培训（2分）
组织进行信息化相关培训，得2分
当月组织信息化相关培训，得2分
本月组织/未组织人员培训，得x分；
知识（问题库管理）（3分）
符合要求实际驻场人数/合同要求人数
符合人员要求得1分，不符合扣1分
本月驻场人员符合/不符合，得x分；
运维人员流失/人员变更（2分）
人员流失（变更）人/次数
未出现人员流失和变更情况得2分，人员流失（变更）1人/次(扣2分)
工单规范标准化-2016.7.25-V1.0（2）
提交工单流程规范标准化文档修改历史中软国际科技服务有限公司1.文档介绍编写此文档的目的是梳理和规范在提走工单流程中各个主要节点输出的文档及工作要求和目的。
具体的工单流程应在具备可实施性的同时进行规范要求，灵活运用。
当前编写的是一份讨论稿，以供相互学习交流。
2.具体规范内容完整的工单实施流程工单流图：（1）准备阶段不管是开发还是修改缺陷，首先找对应模块负责人，开发负责人，或者运维负责人提前进行沟通商量，然后找相关责任人进行提单事宜软件开发人员通过熟悉工单标准规范文档，对缺陷进行修复或者对任务进行开发，记录并以文档形式提出来，由该项目的组长负责归纳整理。
在准备提交版本计划和评估工作量评审之前进行确认，由开发组长与相关责任人进行解答。
（2）组内评估工作量接到项目需求，依据需求进行评估工作量表，完成工作量的评估。
《评审工作量表》评审修改后，重新下发，流程重复进行直至相应文档确认定稿。
（此处为相对定稿，具体开发过程中仍会出现需求变更或增加的情形，需要有具体人员负责整理归纳这些变更细节，以供产品提交单之前最终整理定版之用，同时定期将此在SVN 上进行更新，以供具成开发、运维人员对工单信息了解不一致造成的偏差，以供开发人员进行查阅。
避免出现因具体变更信息传达不畅，造成影响。
(3) 工作量评审A：工作量>50，走邮件评审，开发按照模板填写完工作量，发组内评估，确定无误之后，发给移动运维人评审（至少发送3个人（与项目有关的运维人员，不固定），其他人用抄送）B：工作量>100，先走邮件评估（用纸质模板填写），再打印出来，葛经理签完字之后，拿给3位移动运维人员签字，再拿给移动领导人签字，最后打印成电子版交给张双露保管（电子版的纸质评估表需传到对应的PM或者KR附件下）（4）版本计划评审开发完成后，准备好版本计划，版本计划预计提交前一天发出评审，按照版本计划要求编写，先发组内评审，评审通过后，按要求发给对应的负责人，抄送给组内（邮件标题，内容，附件都有模板），待对应的负责人回复之后，再完善好版本计划，（5）创建KR、工作量评估成功后，版本计划评审成功，之后可以联系对应移动运维人员创建KR单，（6）提交KR1.最终版本计划、RN文档、部署文档、自检清单等文档发出评审，通过之后就可以提交KR具体提交详情请参照开发规范统一支付项目组开发规范 2016-5-13.d2.KR提交后，将最终的版本计划，用邮件的方式发送给相关人员，通知各方人员KR已提交，相关人员回复的时间也一并截图贴上去，确保无误。
常用的工作量评估方法
常用的工作量评估方法常用的工作量评估方法在测试项目管理中或编写测试计划时，经常需要对某个测试工作进行工作量的预算，很多时候都是凭个人的工作经验进行估算的，如能结合一些常规的估算方法，有助于估算的精确度。
以下是网上找到的一些常规的估算测试工作量的方法：1、Ad-hoc方法这种方法下的测试工作量不基于任何确定的期限。
工作一直继续直到达到一些由管理或市场人员预先定下的时间表。
或者，一直到用完了预算的经费。
这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。
2、开发时间的百分比法Percentage of development time。
这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。
首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。
这种方法变化比较大而且通常基于以前的经验。
通常预留项目的总花费时间的35%给测试。
？5-7%给组件和集成测试？18-20%给系统测试？10%给接收测试（或回归测试等）3、类比法（经验值法或历史数据法）根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。
类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
需要收集以下相关的历史数据：？在设计和实现阶段花费的时间？测试工作的规模，例如用户需求的数量，页面数，功能点？数据样式，例如实体，字段的数量？屏幕或字段数量？测试对象的规模，例如KLOC4、WBS（work breakdown structure）估算法将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。
5、Delphi法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。
信息化项目运维服务内容参照表
主机托管
1
设备主机委托管理
型号及性能要求
2
机架空间及环境租赁
空间大小、性能要求
3
存储空间租赁
空间大小、性能要求
指网站空间或系统介质容量租赁
五、机房环境
布线、不间断电源、空调、消防、防雷、监控等
1
设备及环境保养
定期巡检（周期:周、旬、月、季、年）
机房清洁保养、给配电等环境保养
2
机房日常维护
1
数据录入、更新
录入信息的数据量、格式（文字、图表、图像等）、工作方式、时间以及录入质量等要求
明确数据所处业务环节,对于涉密数据应按相关涉密要求执行。根据具体录入工作量评估预算
2
数据处理、备份
数据整合、分离、统计、备份等数据处理方式,处理依据和处理后预期目标等要求。
明确数据所处业务环节,对于涉密数据应按相关涉密要求执行。根据具体录入工作量评估预算
操作系统、中间件、数据库、安全管理软件等
1
操作系统维护
用户数扩容、版本升级,补丁更新,故障修复
2
中间件等工具软件维护
用户数（或CPU数）扩容、版本升级,补丁更新、故障修复
用户数（或CPU数）扩容、版本升级,补丁更新按使用数量估算；故障修复按工作量估算
3
数据库系统维护
补丁升级、版本升级、用户数（或CPU数）扩容、日常维护（定期巡检周期:周、旬、月、季、年）、故障修复
5
设备主机租赁
租赁周期、设备性能档次或型号说明
6
设备主机维修及备件提供
维修部件及备件性能要求,维修和备件支持周期
7
主机固件软件版本升级更新
8
安全策略制定和更新
运维服务评价考核列表.doc
文章标题：深度评述运维服务评价考核列表近年来，随着信息化技术的快速发展，IT运维服务在企业中扮演着越来越重要的角色。
为了确保企业运维服务的质量和效率，运维服务评价考核列表成为了企业评估和改进运维服务的重要工具。
在本文中，我们将从深度和广度的角度，全面评估运维服务评价考核列表，并探讨其在实践中的应用和意义。
一、运维服务评价考核列表的概念和意义1.1 什么是运维服务评价考核列表？运维服务评价考核列表，简称运维评价列表，是用于对企业运维服务进行全面评估和考核的一份重要清单。
它包含了运维服务质量、效率、安全、稳定性等多个方面的评价指标，旨在帮助企业全面了解和评估运维服务的情况。
1.2 运维服务评价考核列表的意义运维服务评价考核列表的制定和应用，有助于企业全面了解和评估自身的运维服务质量和水平。
通过运维评价列表，企业可以找到运维服务中存在的问题和不足，并及时进行改进和优化，以提升运维服务的质量和效率，保障企业信息系统的稳定运行。
二、运维服务评价考核列表的设计和实践2.1 运维服务评价考核列表的设计原则在设计运维服务评价考核列表时，应该遵循一些基本的原则，包括全面性、客观性、实用性和可操作性。
评价指标要能够全面覆盖运维服务的各个方面，评价结果要客观反映实际情况，评价指标要具有实际意义，评价过程要简单易行。
2.2 运维服务评价考核列表的实践应用运维服务评价考核列表一般通过定期的考核评估来应用，包括定期问卷调查、定期服务评估等方式。
在实践中，运维服务评价考核列表还可以结合实际情况进行灵活调整，以确保评价结果的真实性和准确性。
三、运维服务评价考核列表的优势和局限3.1 运维服务评价考核列表的优势运维服务评价考核列表的制定和应用，可以帮助企业全面了解和评估运维服务的情况，发现并解决存在的问题，提升运维服务质量，保障信息系统的安全稳定运行。
3.2 运维服务评价考核列表的局限运维服务评价考核列表过于简单或者过于复杂都会影响其实际应用效果。
常用的工作量评估方法
常用的工作量评估方法常用的工作量评估方法在测试项目管理中或编写测试计划时，经常需要对某个测试工作进行工作量的预算，很多时候都是凭个人的工作经验进行估算的，如能结合一些常规的估算方法，有助于估算的精确度。
以下是网上找到的一些常规的估算测试工作量的方法：1、Ad-hoc方法这种方法下的测试工作量不基于任何确定的期限。
工作一直继续直到达到一些由管理或市场人员预先定下的时间表。
或者，一直到用完了预算的经费。
这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。
2、开发时间的百分比法Percentage of development time。
这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。
首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。
这种方法变化比较大而且通常基于以前的经验。
通常预留项目的总花费时间的35%给测试。
？5-7%给组件和集成测试？18-20%给系统测试？10%给接收测试（或回归测试等）3、类比法（经验值法或历史数据法）根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。
类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
需要收集以下相关的历史数据：？在设计和实现阶段花费的时间？测试工作的规模，例如用户需求的数量，页面数，功能点？数据样式，例如实体，字段的数量？屏幕或字段数量？测试对象的规模，例如KLOC4、WBS（work breakdown structure）估算法将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。
5、Delphi法Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。
应用运维-EIP~工作量评估
应用运维工作职责与范围EIP-工作量评估1、系统监控与运维管理：1）操作系统运行情况巡检，包括磁盘空间、IO读写、内存使用、CPU使用情况检查；日均耗时20分钟2）Domino服务运行情况巡检，包括邮件死信情况、邮件群集复制情况、邮件路由情况、应用报错情况、Domino应用Http处理响应检查以及运行数据采集；日均耗时60分钟3）定期例行停机维护工作；平均45天一次，耗时3小时，日均4分钟/天4）DB2数据库备份；4次/月，耗时20分钟/次，日均耗时4分钟5）系统日志检查与清理，包括domino与tivoli；日均耗时20分钟；6）EOS定期附件同步情况检查；2次/周，日均耗时10分钟2、系统运营管理类：1）由于个人电脑设置、未使用标准的操作系统、未使用标准的office软件、不具备管理员权限的账号操作电脑等原因导致EIP 系统无法正常使用的情况处理；30次/月，1.5次/天，耗时10分钟/次，日均耗时15分钟(客户端维护,应由一线处理)2）系统BUG或故障分析处理；5次/月，0.25次/天，耗时420分钟/次，日均耗时100分钟(二三线共同处理)3）用户不规范操作等原因，导致文件无法正常流转或需要调整文件内容处理；50次/月，2.5次/天，耗时10分钟/次，日均耗时25分钟4）人力操作不规范，导致用户无法正常使用系统的原因分析及问题定位处理；10次/月，0.5次/天，耗时20分钟/次，日均耗时10分钟5）业务需要，已有模块的需求变更；50次/月，2.5次/天，耗时10分钟/次，日均耗时25分钟6）新增发布；10次/月，1次/3天，耗时30分钟/次，日均耗时10分钟7）数据提取工作；2次/月，0.1次/天，耗时210分钟/次，日均耗时20分钟8）集体邮箱业务受理；2次/月，0.1次/天，耗时30分钟/次，日均耗时3分钟9）业务咨询；200次/月，10次/天，耗时3分钟/次，日均耗时30分钟3、信息安全管理：按安全技术室要求，处理信息安全相关工作；2次/月，耗时420分钟/次，日均耗时40分钟4、知识管理：收集、整理、总结并沉淀关于应用维护的各相关知识；5次/月，耗时40分钟/次，日均耗时10分钟6、制度建立与规范管理：1次/月，耗时3天/次，日均60分钟小计：维护类工作日均467分钟，约1人/天；。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
日常会议、沟通、互动 日常工作进度汇报、日常沟通
16
会议讨论、需求讨论
预计平均每周一次
6
常情况。
预计平均每月一次 预计平均每月一次
三、业务系统维护
系统性能日常维护 7
定期巡检，补丁升级，日志检查分析，错误分析 预计平均每月一次 及统计
受理系统保障服务 8
公布系统的的报障电话，按要求在工作的时间段 按需(预计平均每周 内接受报障，并组织技术人员按要求解决故障。 一次）
系统故障检测及排除 9
存使用情况
二、服务器网络与网络安全情况维护
定期检查服务器的网络情 包含每台服务器网络连接情况。如果是连接外网
5况
的，测试网络带宽是否正常，服务器之间的网络 是否正常。如果不正常的需要跟进并直到解决为
定期检查安全设备或者安 止 如。 果有安全设备，或者安全软件，定期查看日
全软件，检查安全情况 志，并测试是否生效，并查看是否有被攻击等异
计划定期手动备份数据或者检查系统自动定期备 份的数据。
数据库情况监控 14
五、其他内容与服务
培训 15
监控数据库的运行情况、负载情况以及进行相应 的优化； 包括巨量数据迁移、数据库空间碎片整理，数据 库性能监控分析
预计平均每月一次
后台管理培训、Android端培训、IOS端培训等， 预计平均每月一次 操作方式培训、系统功能培训。主要在 业务知识 、平台功能专业培训
2015年运维服务工作量评估
序号
服务项目
维护内容概要
服务频度
一、服务器远程服务
服务器硬件远程定期监 1 控，以及对出现的硬件问
题解决跟进
定期检查后台支撑集群服务器硬件的健康情况， 并及时跟进催促处理所出现的各种硬件问题。
预计平均每月一次
跟进催促新买或新加服务 新购买添加的服务器，验证测试是否健康，服务 预计平均每月一次
按照业务保障需求，检测各功能，如果检测到故 预计平均每月三次 障后，第一时间排除
系统运行状态监控以及预 系统日志大小，无用资源的清除，图片等资源文 预计平均每月一次
10 警
件占用磁盘大小等日常管理。
系统的重新安装，调试和 按照业务保障需求，重新安装业务系统，备份系 预计平均每月一次
11 备份
统，恢复系统等工作
2 器上线，服务器升级等事 器升级等事务跟进与协调。 务
服务器操作系统维护监控 监控操作系统是否需要补丁更新，是否需要版本 预计平均二月一次
3
升级，用户数扩容，故障修复
服务器操作系统性能日常 定期巡检 操作系统日志，并查看日志。检查日志 预计平均每月一次
4 维护
文件是否过大、检查硬盘空间是否已满，检查内
四、数据库信息维护
数据处理
处理工作包括：1）生成系统未开发的不常用报 预计平均每月一次
表，并且导出
12
2）导出业务工作需要的数据库数据。
3）异常数据查找修正，并且反馈给开发工程师。
4）系统初始化数据的规范化录入。 数据库的安装与备份 按业务要求，执行数据库的安装工作。按照维护 预计平均每月一次
13