4.3 信息系统软件运维的过程
文章目录
信息系统软件运维的过程主要包括：日常运维、缺陷诊断与修复、配置管理、变更管理、 系统恢复管理、发布管理等。
日常运维
日常运维的内容
信息系统软件日常运维的主要内容包括：监控、预防性检查、常规操作。
信息系统软件监控的主要内容有CPU、内存、磁盘、进程状态；服务或端口响应情况；日 志是否存在异常；资源消耗情况；数据库连接情况等。
信息系统软件预防性检查的主要内容有典型操作响应时间；病毒定期查杀；口令安全情况； 日志审计、分析；关键进程及资源消耗分析等。
信息系统软件常规操作的主要内容有日志清理；启动、停止服务或进程；增加或删除用户 账号；更新系统或用户密码；备份等。
日常运行
日常运行是信息系统软件运维服务的常规活动和常规流程，应当按规范定时间、定点启动。
日常运行流程的关键点主要包括如下方面。
-
日常运行开始前应先查阅系统日常运行记录。
-
在日常运行工作中，系统操作人员处理运行过程中的随机事件，对不能解决的事件移 交给维护工程师处理。
-
维护工程师对在维护后发现系统有缺陷，则向技术服务经理申请转入缺陷诊断与修复流程。
-
日常运行完成后应编制日常运行报告，并与日常运行过程中产生的文档一并归档。
例行测试维护
例行测试流程的关键点
-
开展例行测试前应先制定测试计划及测试用例。
-
测试人员按计划依据用例执行测试。
-
测试人员对测试结果进行分析，对有需维护的功能则移交给维护工程师处理。
-
维护工程师在软件维护后发现有缺陷不能解决，申请进入缺陷诊断与修复。
-
例行测试完成后应编制例行测试报告，并与例行测试过程中产生的文档一并归档。
例行维护流程的关键点
-
开展例行维护前应制定例行维护实施方案。
-
维护工程师对记录的维护情况进行分析，对在维护后发现系统有缺陷，则向技术服务经理申请进入缺陷诊断与修复流程。
-
例行维护完成后应编制例行维护报告，并与例行维护过程中产生的文档 一 并归档。
定期测试维护
定期测试维护基本流程其要点如下。
-
定期测试维护开始前应先查阅信息系统软件日常运行记录。
-
对定期测试记录进行分析，对有需要维护的信息系统功能则申请进行维护处理。
-
维护后发现系统存在缺陷，则申请转入缺陷诊断与修复流程。
-
定期测试维护完成后应编制定期测试维护报告，并与定期测试运维过程中产生的文档一并归档 。
缺陷诊断与修复
信息系统软件缺陷的概念
信息系统软件缺陷是信息系统软件中存在的某种破坏正常运行能力的问题、错误，或者隐 藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。从信息系统软 件内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从信息系统软件 外部看，缺陷是系统所需要实现的某种功能的失效。
软件缺陷在处理流程中的状态：
-
新建：新发现的缺陷。
-
延后处理：如果这个缺陷跟当前发布的这个版本没有直接关系，或者当前版本无法修 复，或者这个缺陷不是很严重，不需要立刻修复，那么项目经理可以把状态设为“延后处理”。
-
已指派：“指派给”这个值是由项目组长或者项目经理来填写，指定给具体的某个开 发人员。
-
已修复：当开发人员做了某些必要的代码改动，并且确认修改之后，那么他/她就可以 把状态改为“已修复”,然后就交给测试组进行回归测试。
-
无法重现：如果根据缺陷报告里面描述的步骤，无法重现这个缺陷的时候，那么开放 人员可以把这个缺陷标为“无法重现”。
-
需要更多信息：如果开发人员认为缺陷重现步骤不够清晰，因而无法重现缺陷的时候， 那么可以把状态标记为“需要更多信息”。
-
重新打开：如果在修复之后，依然出现同样的问题，那么可以把状态标记为“重新打开”。
-
关闭：如果已经验证过这个缺陷的修复结果，并且问题是已经得到了解决的，那么可 以把状态改为“关闭”。
-
驳回：如果缺陷的产生只是由于误解而引起的，那么可以把这些缺陷标记为“驳回”。
信息系统软件缺陷的分类
| 类型 | 细分 | 内容 |
|---|---|---|
| 功能缺陷 | 需求说明书缺陷 | 需求说明书可能不完全，有二义性或自身矛盾。另外，在设计过程中可 能修改功能，如果不能紧跟这种变化并及时修改需求说明书，则产生需 求说明书错误 |
| 功能缺陷 | 程序实现的功能与用户要求的不一致，包含错误的功能、多余的功能或 遗漏的功能 | |
| 测试缺陷 | 软件测试的设计与实施发生错误。特别是系统级的功能测试，要求复杂 的测试环境和数据库支持，还需要对测试进行脚本编写。因此软件测试 自身也可能发生错误。另外，如果测试人员对系统缺乏了解，或对需求 说明书做了错误的解释，也会发生许多错误 | |
| 测试标准引起 的缺陷 | 对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出 错的可能就大 | |
| 系统缺陷 | 接口缺陷 | 软件内部模块接口或与外部通信接口之间的缺陷 |
| 软件结构缺陷 | 由于软件结构不合理而产生的缺陷。这种缺陷通常与系统的负载有关， 而且往往在系统满载时才出现 | |
| 控制与顺序缺陷 | 如忽视了时间因素而破坏了事件的顺序；等待一个不可能发生的条件； 漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不 正确的处理步骤或多余的处理步骤等 | |
| 资源管理缺陷 | 由于不正确地使用资源而产生的缺陷。如使用未经获准的资源；使用后 未释放资源；资源死锁；把资源链接到错误的队列中等 | |
| 加工缺陷 | 算法与操作缺 陷 | 是指在算术运算、函数求值和一般操作过程中发生的缺陷。如数据类型 转换错；除法溢出；不正确地使用关系运算符；不正确地使用整数与浮 点数做比较等 |
| 初始化缺陷 | 如忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制 变量赋初值；用不正确的格式、数据或类类型进行初始化等 | |
| 控制和次序缺 陷 | 与系统级同名缺陷相比，它是局部缺陷。如遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等 | |
| 静态逻辑缺陷 | 如不正确地使用switch语句；混淆“或”与“异或”等 | |
| 数据缺陷 | 动态数据缺陷 | 动态数据是在程序执行过程中暂时存在的数据，它的生存期非常短。各 种不同类型的动态数据在执行期间将共享一个共同的存储区域，若程序 启动时对这个区域未初始化，就会导致数据出错 |
| 静态数据缺陷 | 静态数据在内容和格式上都是固定的。它们直接或间接出现在程序或数 据库中，有编译程序或其他专门对他们做预处理，但预处理也会出错 | |
| 数据内容、结 构和属性缺陷 | 数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数 据内容缺陷就是由于内容被破坏或被错误地解释而造成的缺陷。数据结 构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的 数据结构。数据结构缺陷包括结构说明错误及数据结构误用的错误。数 据属性是指数据内容的含义或语义。数据属性缺陷包括对数据属性不正 确地解释，如错把整数当实数，允许不同类型数据混合运算而导致的错 误等 | |
| 代码缺陷 | 包括数据说明错、数据使用错、计算错、比较错、控制流错、界面错、 输入输出错，及其他的错误 |
信息系统软件缺陷诊断与修复流程
信息系统软件诊断与修复是指按照标准的测试检查方法、测试检查工具或第三方测试工 具，按测试规范对软件进行缺陷诊断与修复的活动。对于诊断流程发现的缺陷按缺陷诊断和处 理办法能够解决的缺陷问题在此流程范围内解决。如果不能由客服人员和维护工程师解决的重 大缺陷，则申请重大缺陷处理程序。信息系统软件诊断与修复流程如图4-7所示。
缺陷诊断与修复流程的关键点
(1)接受问题申请后，应对问题进行初步诊断。
(2)经检查分析，对属于异常的缺陷则进行修复，对于属于常见问题则由相关人员进行技 术支持。
(3)对不能修复的异常缺陷申请重大缺陷处理。
(4)缺陷诊断与修复完成后应编制缺陷诊断与修复报告，并与缺陷诊断与修复过程中产生 的文档一并归档。
配置管理
信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。
配置管理计划
根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
-
该项目对配置管理的要求。
-
实施配置管理的责任人、组织及其职责。
-
需要开展的配置管理活动及其进度安排。
-
采用的方法和工具等。
配置与配置项
配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配 置项被作为一个单一的实体对待。
版本控制
版本是表示一个配置项具有一组定义的功能的一种标识。
变更控制
变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部 分，包含评估、协调、批准/拒绝、实施对配置项的变更。
配置审计
配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容 如下。
-
功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
-
物理审计：配置项的完整性、正确性、 一致性和可跟踪性。
状态报告
状态报告用来记录和报告有效管理配置所需要的必要信息。
变更管理
信息系统软件变更管理是指项目组织为适应项目运行过程中与项目相关的各 种因素的变化，保证项目目标的实现而对项目计划进行相应的部分变更或全部变更，并按变更 后的要求组织项目实施的过程。
变更管理要能体现出它的两个重要用途，
- 控制变更，保证项目可控；
- 变更度量分析，帮助组织提供自己的开发能力。
变更管理的主要目标如下。
-
使用标准化的方法和程序，用于有效处理所有变更。
-
在配置管理系统中记录配置项的变更。
-
降低变更的风险。
-
响应不断变化的客户需求，使价值最大化，减少破坏和重复工作。
-
确保通过受控的方法对变更进行记录、评估、授权、实施和评审等活动。
变更请求
变更请求可能有不同的来源(用户、客户、运维人员等), 但变更请求不是一个简单的记录，而应该记录变更的详细信 息(比如缺陷发生时的环境，要变更的功能等)。
评审变更
筛选不符合规定的变更请求，并将拒绝原因一起返回给变更请求提交者，同时记录在日志中。
评估变更
变更的评估中要充分考虑失败的变更对服务、服务资产和配置的影响。评估者应基于变更的影响度、紧急度(优先级)、风险、收益和成本来综合评估变更，并 要就是否支持该变更做出评估意见。
授权变更
由相应的人员授权变更的实施。
实施变更
变更实施应当采取规范、正式的方式进行，组织协调相关技术部门完成变更的实施。
评审和关闭变更
变更实施完成后，应该报告变更实施效果，便于对变更进行评估和管理，同时，还应该将 结果展示给利益相关者(比如客户)。所以需要进行评审后再关闭这个变更。
系统恢复管理
信息系统软件出现不能正常工作的情况时，需对系统实施恢复安装操作，使软件系统尽快 恢复正常、稳定运行。
信息系统软件恢复管理流程的关键点主要包括如下方面。
-
系统操作员提出系统恢复申请。
-
维护工程师分析系统故障原因。
-
维护工程师对恢复安装前检查、恢复系统后测试。
-
技术服务经理对恢复安装过程进行跟踪、确认。
-
系统恢复申请单、故障原因分析记录、恢复安装记录等过程文档的存档。
发布管理
信息系统软件发布是变更的后继过程，指的是将变更实施到生产环境中的过程。
发布管理是通过项目规划的方式来实施变更，确保只有经过测试的、正确无误的信息版本才能发布到运行环境中，保证运行环境的安全可靠。
发布管理的目的在于控制发布过程中存在的风险，避免 或减少发布失败对生产系统造成的影响。
标签：信息系统,4.3,软考,测试,软件,维护,缺陷,变更 From： https://blog.csdn.net/weixin_68522070/article/details/142822453