信息系统软件运维监理方案来源：参考相关书籍资料 日期：[2020-07-31]
信息系统软件运维监理方案
a) 术 语
1、 建设单位（或称建设方）
信息系统工程项目法人以及为实施工程项目而设置的管理机构。
2、 监理单位（或称监理方）
在工商行政管理机关办理注册登记，取得企业法人营业执照，并取得信息行业行政管理部门颁发的监理单位资质证书，为建设单位提供信息工程监理服务的单位。
3、 （总）承包单位（或称承包方）
具有独立法人资格，与建设单位签订信息系统工程建设合同，具备信息系统集成有效资质，实施信息系统工程项目的企事业单位；承建方根据工程实际可实行工程分包。
4、 分包单位
具有独立法人资格，根据项目总承包合同约定或经建设单位和监理单位的认可，与承包单位就工程项目中的部分工程签订分包合同的单位。
5、 承建方
包括（总）承包单位和分包单位。
6、 项目监理部
受建设单位委托，监理单位在项目实施现场负责履行监理合同的组织机构。
7、 总监理工程师
经监理单位法定代表人书面授权，全面负责监理合同的履行，主持项目监理部工作的总负责人。
8、 监理工程师
在总监理工程师的领导下，根据项目监理岗位职责分工和总监理工程师的指令，负责项目实施某一专业或某一方面的监理工作，具有相应监理文件签发权的监理人员。
9、 质量控制
对承建方项目实施的全过程进行质量监控，严格审查关键性过程和阶段性成果，检查是否符合预定的质量要求。
10、 运行费用控制
对信息系统运维费预算的实际执行，信息系统运维费用控制是为了科学的使用、监督、评价运维费。
11、 变更控制
工程在实施过程中会根据实际实施的具体变化做相应的变更。包括：需求变更、设计方案变更、进度变更、投资变更、人员变更、合同变更等。监理方针对各种变更加以分析，并在实施过程中对各种变更采取对应的策略。
12、 合同管理
根据监理合同的要求，监理方在项目监理工作中对工程承包合同的签订、履行、变更和解除进行监督、检查，对合同双方争议进行调解和处理，以保证合同的依法签订和全面履行。
13、 信息管理
在实施监理的过程中，监理方对项目建设过程中的有用信息进行收集、整理、处理、储存、传递、应用等一系列工作。
14、 信息安全控制
通过管理措施和技术措施的手段，对信息系统环境安全、设备安全、媒体安全、通信安全和信息安全予以控制，保证信息系统的安全达到项目建设要求和国家相关标准；
15、 信息系统软件运维
信息系统软件在开发完成投入使用后，为改正软件中隐含的错误，或为提高信息系统软件的适应性、可靠性和完善信息系统功能，对信息系统软件进行的软件工程活动。
申请增加新的功能、申请错误的更正和可维护性的提高。
17、 运维过程
变化需求的获取、系统架构和开发方法的升级、错误检测与更正。
18、 运维工具
运维过程中的辅助软件，如版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、配置管理支持工具等。
b) 运维策划阶段
1.1 监理目标
监理机构通过监理工作，应实现如下目标：
a) 理解用户软件运维目标和运维模式，认定业主单位确定运维组织、运维能力等需求；
b) 促使招标文件与运维的需求、目标和范围相符合；
c) 协助业主单位选定合适的运维单位；
d) 促使运维合同在技术、经济上合理有效。
1.2 监理内容和要点
1.2.1 内容策划
需求认定阶段的监理内容和要点如下：
a) 监理机构应了解业主单位的信息系统软件所涉及的业务定位和管理范围，策划信息系统软件运维服务对象的业务内容与要求，并形成服务目录。
b) 监理机构应取得必要的工程资料，并理解和确认如下内容：
1) 运维要求对整个信息系统来说是否合理，应该满足到何种程度。
2) 服务目标与说明性文件；
3) 服务级别与服务种类；
1.2.2 组织策划
运维组织策划过程中监理内容和要点如下：
a) 监理机构应了解信息系统软件对稳定性和安全性的要求。
b) 监理机构业主单位对数据保密和版本更新的要求。
c) 监理机构宜业主单位业务管理部门和信息系统技术管理部门人员情况。
1) 业务功能的合理性；
2) 技术实现的可行性；
1.2.3 资源策划
资源策划是指对信息系统软件运维所涉及的人力资源、环境资源、财务资源、技术资源、时间资源等的分析 ，监理内容和要点如下：
a) 监理机构宜协助业主单位策划运维软/硬件、网络环境。
b) 监理机构宜协助业主单位确定运维所需费用是否合理。
1.2.4 标准策划
信息系统运维工作涉及范围广，影响因素多，要用软件工程的方法，结合信息系统运维实际需要，制定一套标准。监理应协助用户确定标准的内容：
a) 运维流程。
b) 运维安全。
c) 运维各阶段所需要的文档。
d ) 考核评估体系统。
c) 运维实施阶段
1.3 监理目标
监理机构通过监理工作，应实现如下目标：
a) 监督运维商是否严格按照流程推进工作 ；
b) 对计划的执行、记录的及时准确要做好记录；
c) 对运维商的相关文档的修改进行监督审查，对修改后的软件成果与用户共同验证。
d) 对失败的运维工作进行详细分析。
e) 对运维绩效进行考核。
1.4 监理内容和要点
1.4.1 运维流程
运维流程制定的监理内容和要点如下：：
a) 监理机构应配合用户单位共同对运维商提交的运维流程进行分析和审查：
1) 从合理性和技术可行性两方面进行审核运维需求。
2) 运维目标与业主需求的一致性；
3) 运维资源的合理性；
4）运维工具的有效性；
5）运维内定与业务需求的一致。
6）运维安全的量。
b) 监理机构应配合用户单位共同共同签认运维流程。
1.4.2 运维申请
监理内容和要点如下：
a) 所有运维活动必须按规定的方式提出申请。
b) 运维申请可以由用户提出也可以由系统运维商提出。
c) 运维申请必须填写维护的原因、缓急程度。
d) 如果是系统错误，需完整地说明错误的情况，包括输入数据、输出数据、错误清单及其它相关信息。
e) 运维申请运包括申请编号、问题说明、维护要求、优先级、预计维护结果、维护时间、申请人、申请评价结果、评价负责人、申请日期。
1.4.3 运维计划
运维申请通过了审批，运维主管要负责运维方案和运维计划 ，监理要重点审核：
a) 运维计划的内容是否完整？是否明确了运维优先级、运维工作量、运维实施人等内容。
b) 跟踪运维任务的流转。
1.4.4 修改管理
信息系统软件的运维最终要落实在修改源程序和文档上。
a) 确定修改范围，包括确定哪些系统、哪些文档、哪些业务流程及哪些程序与本次修改有关。
b) 源程序修改后，相应的文档要应同步修改，保持源程序和文档的完整一致。
c) 做好相关的修改记录，以保证运维的可追溯性。
d) 评估运维结果。
1.4.5 运维记录
运维记录记载信息系统软件的运维内容，将运维对角、规模、所用语言，发生的情况等以规范化记录下来。
a) 运维记录必须按规定的格式和内容填写。
b) 运维记录需纳入到运维管理知识库中。通过知识库沉淀日常运维中的工作经验。
1.4.6 验证结果
源程序经修改后应进行重新测试以验证修改。
a) 验证修改的有效性，验证修改后软件的功能和性能是否如用户所合理期待的结果。
b) 不但要测试新修改部分的功能，还要测试未修改部分的功能。
c) 软件配置复审，保证修改后的软件配置齐全并分类有序。
d) 运维检查阶段
运维实施执行完成后要检查是否符合运维计划的要求和目标，对运维过程和实施结果进行监控、测量、分析和评审。
a) 定期评审运维过程及相关管理体系，以确保运维能力的适宜和有效。
b) 调查用户满意度，并对运维结果进行统计分析。
c) 检查各项指标的达成情况。
e) 运维改进阶段
信息系统软件运维经过策划、实施、检查之后，要对信息系统软件运维管理情况进行重新评估，以改进运维管理过程中的不足。此阶段监理的重点工作是：
a) 督促运维实施单位建立信息系统运维管理改进机制。
b) 对不符合策划要求的运维行为进行总结分析；
c) 对未达成的运维指标进行调查分析。
d) 根据分析结果确定改进措施，确定改进目标和计划，并按计划进行督促检查，检查相关改进记录。
e) 评估改进的有效性和持续性。
f) 信息系统软件运维
1.5 日常运维
1.5.1 日常运维的内容
信息系统软件日常运维的主要内容包括：监控、预防性检查、常规操作。
a) 监控的主要内容有进程状态、服务或端口响应情况、资源消耗情况、日志、数据库连接情况、作业执行情况等。
b) 预防性检查的主要内容有典型操作响应时间、系统病毒定期查杀、口令安全情况、日志审计分析、关键进程及资源消耗分析 、队列等。
c) 常规操作的主要内容有日志清理，启动、停止服务或进程，增加或删除用户帐号，更新系统或用户密码，建立或终止会话连接，作业提交，软件备份等。
1.5.2 日常运维的操作流程
日常运维是指按照信息系统软件运维服务合同定时、定点、定内容重复进行的信息系统软件的常规维护活动。包括：
g) 查阅系统日常运行日志；
h) 处理运行过程中的随机事件；
i) 对不能解决的事件申请维护处理；
j) 对日常维护中发现的系统缺陷，申请转入缺陷诊断与修复流程；
k) 日常报告的编制工作；
l) 运维文档备案。
1.5.3 日常运维的操作活动
主要包括例行测试维护和定期测试维护。
a) 例行测试维护的监理要点：
1) 开展信息系统软件例行维护前应制定例行维护实施方案；
2) 对记录的维护情况进行分析，若在维护后发现系统有缺陷，则申请进入缺陷诊断与修复流程。
3) 例行维护完成后应编制例行维护报告，并与例行维护过程中产生的文档一并归档。
b) 定期测试维护的监理要点：
1) 定期测试维护开始前应先查阅信息系统软件日常运行记录；
2) 对定期测试记录进行分析，对有需要维护的信息系统功能则申请 进行维护处理；
3) 维护后发现系统存在缺陷，则申请转入缺陷诊断与修复流程。
4) 重点业务期准备测试要加强对软件的性能测试。
5) 定期维护完成后应编制定期维护报告，并与定期维护过程中产生的文档一并归档。
1.5.4 日常运维的监理重点
a) 软件运维各类文档提交的及时性与准确性；
b) 注意应用软件基线的管理，必要的信息是否进入配置管理流程；
c) 软件定义测试要注意对系统安全、性能测试的内容。
d) 应用软件的日常运维操作要注意监控对密码的管理与保护。
1.6 缺陷诊断与修复
1.6.1 信息系统软件缺陷
a) 缺陷的优先分级
1) 微小的：对信息系统软件功能几乎没有影响的一些小问题，软件产品仍可运行。
2) 一般的：不太严重的错误，如次要模块功能缺失，提示信息不够准确，用户界面差和操作时间长等。
3) 严重的：信息系统软件功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或出现致命的错误声明。
4) 致命的：造成系统崩溃、死机，或造成系统数据丢失，主要功能完全丧失等。
c) 缺陷的状态：
1) 活动状态：问题没有解决。
2) 已解决状态：问题已经解决或通过测试。
3) 关闭状态：经过验证，缺陷已不存在。
1.6.2 信息系统软件缺陷构成：
a) 功能缺陷：主要是指需求说明书缺陷；功能不一致缺陷；测试缺陷；测试标准引起的缺陷。
b) 系统缺陷：包括模块接口缺陷；软件结构缺陷；控制与顺序缺陷。
c) 加工缺陷：包括算法与操作缺陷；初始化缺陷；静态逻辑缺陷。
d) 数据缺陷：动态数据缺陷；静态数据缺陷；内容、结构和属性缺陷。
e) 代码缺陷
1.6.3 缺陷诊断与修复流程
发现信息系统软件缺陷后要尽快修复。缺陷诊断与修复流程有：
a) 接受问题申请后，应对问题进行初步诊断；
b) 经检查分析，对属于异常的缺陷进行修复，对属于常见问题的缺陷则进行技术支持。
c) 对不能修复的异常缺陷申请重大缺陷处理；
d) 缺陷诊断与修复完成后应编制缺陷诊断与修复报告，并同缺陷诊断与修复过程中产生的文档一并归档。
1.6.4 缺陷处理监理要点
a) 监理机构应配合用户、运维实施商一起对缺陷进行定位。
b) 发现重大缺陷时要定时跟踪处理流程。
1.7 变更管理
1.7.1 变更的流程
a) 软件变更申请提出后需要整理，并分析讨论变更的可行性，与其它相关方冲突等，决定变更实施的优先级，实施计划等。
b) 对于不完善的软件变更申请需整理后重新提交申请。
c) 经批准后的变更实施后应进行变更信息的发布，所有与软件运维相关的变更均应在授权下实施。
d) 建立变更管理制度，规范变更管理过程，并形成文档。
1.7.2 变更管理监理要点
a) 从变更需求的来源进行跟踪，对变更的潜在问题和风险进行分析，控制用户不合理的变更，监督查证运维商对变更的理解、判断和实施策划。
b) 严格按变更控制流程进行操作，把严用户审查，多方测试、内部安全审查及性测试。
c) 变更完成后审核对配置管理，修改基线文件。
d) 运维商变更分析 、计划阶段的及时性；
e) 变更流程过程执行的严谨性；
f) 变更测试工作的全面性；
g) 变更文档、配置文件修改的全面性与及时性；
h) 变更相关用户满意度调查。
1.8 系统恢复、发布及版本管理
1.8.1 信息系统软件恢复管理要点
a) 系统恢复申请被提出；
b) 分析信息系统软件故障原因；
c) 恢复安装前检查，恢复系统后测试；
d) 对恢复安装过程进行跟踪、确认；
e) 系统恢复申请单、故障原因分析记录、恢复安装记录等过程文档存档。
1.8.2 发布管理主要内容
信息系统软件发布管理主要包括以下内容：
a) 部署规划、设计
b) 设计验证
c) 硬件实施
d) 构建软件产品
e) 实施、运行及优化
1.8.3 版本管理
a) 版本管理是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本标识，并保证版本命名的唯一性。
b) 版本在生成过程中，自动依照设定的使用模型自动分支、演进。
c) 记录版本的辅助信息。
1.8.4 监理要点
系统恢复、发布及版本管理更多属于软件运维的日常操作，监理人员将重点关注：
a) 跟踪实施过程，对每一个步骤产出的过程记录文件进行准确性复查。
b) 在系统恢复中，要注意对用户授权行为的监控
c) 在发布过程中，要对发布内容 的配套文件进行审查，比如安全测试结果、功能测试结果、性能测试结果等。
d) 版本发布要考核其对基线文件的修订。
