软考《信息系统运行管理员》- 4.3 信息系统软件运维的过程

极客编程坊

已于 2024-10-10 15:26:32 修改

阅读量1.7k

点赞数 41

分类专栏：信息系统运行管理员文章标签：运维数据库网络

于 2024-10-10 15:14:13 首次发布

本文链接：https://blog.csdn.net/weixin_68522070/article/details/142822453

版权

信息系统运行管理员专栏收录该内容

22 篇文章 40 订阅

订阅专栏

4.3 信息系统软件运维的过程

信息系统软件运维的过程主要包括：日常运维、缺陷诊断与修复、配置管理、变更管理、系统恢复管理、发布管理等。

日常运维

日常运维的内容

信息系统软件日常运维的主要内容包括：监控、预防性检查、常规操作。

信息系统软件监控的主要内容有CPU、内存、磁盘、进程状态；服务或端口响应情况；日志是否存在异常；资源消耗情况；数据库连接情况等。

信息系统软件预防性检查的主要内容有典型操作响应时间；病毒定期查杀；口令安全情况；日志审计、分析；关键进程及资源消耗分析等。

信息系统软件常规操作的主要内容有日志清理；启动、停止服务或进程；增加或删除用户账号；更新系统或用户密码；备份等。

日常运行

日常运行是信息系统软件运维服务的常规活动和常规流程，应当按规范定时间、定点启动。

在这里插入图片描述

日常运行流程的关键点主要包括如下方面。

日常运行开始前应先查阅系统日常运行记录。
在日常运行工作中，系统操作人员处理运行过程中的随机事件，对不能解决的事件移交给维护工程师处理。
维护工程师对在维护后发现系统有缺陷，则向技术服务经理申请转入缺陷诊断与修复流程。
日常运行完成后应编制日常运行报告，并与日常运行过程中产生的文档一并归档。

例行测试维护

在这里插入图片描述

例行测试流程的关键点

开展例行测试前应先制定测试计划及测试用例。
测试人员按计划依据用例执行测试。
测试人员对测试结果进行分析，对有需维护的功能则移交给维护工程师处理。
维护工程师在软件维护后发现有缺陷不能解决，申请进入缺陷诊断与修复。
例行测试完成后应编制例行测试报告，并与例行测试过程中产生的文档一并归档。

例行维护流程的关键点

开展例行维护前应制定例行维护实施方案。
维护工程师对记录的维护情况进行分析，对在维护后发现系统有缺陷，则向技术服务经理申请进入缺陷诊断与修复流程。
例行维护完成后应编制例行维护报告，并与例行维护过程中产生的文档一并归档。

定期测试维护

在这里插入图片描述

定期测试维护基本流程其要点如下。

定期测试维护开始前应先查阅信息系统软件日常运行记录。
对定期测试记录进行分析，对有需要维护的信息系统功能则申请进行维护处理。
维护后发现系统存在缺陷，则申请转入缺陷诊断与修复流程。
定期测试维护完成后应编制定期测试维护报告，并与定期测试运维过程中产生的文档一并归档。

缺陷诊断与修复

信息系统软件缺陷的概念

信息系统软件缺陷是信息系统软件中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。从信息系统软件内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从信息系统软件外部看，缺陷是系统所需要实现的某种功能的失效。

在这里插入图片描述

软件缺陷在处理流程中的状态：

新建：新发现的缺陷。
延后处理：如果这个缺陷跟当前发布的这个版本没有直接关系，或者当前版本无法修复，或者这个缺陷不是很严重，不需要立刻修复，那么项目经理可以把状态设为“延后处理”。
已指派：“指派给”这个值是由项目组长或者项目经理来填写，指定给具体的某个开发人员。
已修复：当开发人员做了某些必要的代码改动，并且确认修改之后，那么他/她就可以把状态改为“已修复”,然后就交给测试组进行回归测试。
无法重现：如果根据缺陷报告里面描述的步骤，无法重现这个缺陷的时候，那么开放人员可以把这个缺陷标为“无法重现”。
需要更多信息：如果开发人员认为缺陷重现步骤不够清晰，因而无法重现缺陷的时候，那么可以把状态标记为“需要更多信息”。
重新打开：如果在修复之后，依然出现同样的问题，那么可以把状态标记为“重新打开”。
关闭：如果已经验证过这个缺陷的修复结果，并且问题是已经得到了解决的，那么可以把状态改为“关闭”。
驳回：如果缺陷的产生只是由于误解而引起的，那么可以把这些缺陷标记为“驳回”。

信息系统软件缺陷的分类

类型	细分	内容
功能缺陷	需求说明书缺陷	需求说明书可能不完全，有二义性或自身矛盾。另外，在设计过程中可能修改功能，如果不能紧跟这种变化并及时修改需求说明书，则产生需求说明书错误
	功能缺陷	程序实现的功能与用户要求的不一致，包含错误的功能、多余的功能或遗漏的功能
	测试缺陷	软件测试的设计与实施发生错误。特别是系统级的功能测试，要求复杂的测试环境和数据库支持，还需要对测试进行脚本编写。因此软件测试自身也可能发生错误。另外，如果测试人员对系统缺乏了解，或对需求说明书做了错误的解释，也会发生许多错误
	测试标准引起的缺陷	对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大

系统缺陷	接口缺陷	软件内部模块接口或与外部通信接口之间的缺陷
	软件结构缺陷	由于软件结构不合理而产生的缺陷。这种缺陷通常与系统的负载有关，而且往往在系统满载时才出现
	控制与顺序缺陷	如忽视了时间因素而破坏了事件的顺序；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等
	资源管理缺陷	由于不正确地使用资源而产生的缺陷。如使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接到错误的队列中等

加工缺陷	算法与操作缺陷	是指在算术运算、函数求值和一般操作过程中发生的缺陷。如数据类型转换错；除法溢出；不正确地使用关系运算符；不正确地使用整数与浮点数做比较等
	初始化缺陷	如忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式、数据或类类型进行初始化等
	控制和次序缺陷	与系统级同名缺陷相比，它是局部缺陷。如遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等
	静态逻辑缺陷	如不正确地使用switch语句；混淆“或”与“异或”等

数据缺陷	动态数据缺陷	动态数据是在程序执行过程中暂时存在的数据，它的生存期非常短。各种不同类型的动态数据在执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，就会导致数据出错
	静态数据缺陷	静态数据在内容和格式上都是固定的。它们直接或间接出现在程序或数据库中，有编译程序或其他专门对他们做预处理，但预处理也会出错
	数据内容、结构和属性缺陷	数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容缺陷就是由于内容被破坏或被错误地解释而造成的缺陷。数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构缺陷包括结构说明错误及数据结构误用的错误。数据属性是指数据内容的含义或语义。数据属性缺陷包括对数据属性不正确地解释，如错把整数当实数，允许不同类型数据混合运算而导致的错误等

代码缺陷		包括数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入输出错，及其他的错误

信息系统软件缺陷诊断与修复流程

在这里插入图片描述

信息系统软件诊断与修复是指按照标准的测试检查方法、测试检查工具或第三方测试工具，按测试规范对软件进行缺陷诊断与修复的活动。对于诊断流程发现的缺陷按缺陷诊断和处理办法能够解决的缺陷问题在此流程范围内解决。如果不能由客服人员和维护工程师解决的重大缺陷，则申请重大缺陷处理程序。信息系统软件诊断与修复流程如图4-7所示。