4.1信息系统软件运维概述

信息系统软件运维的概念

信息系统软件运维是指信息系统软件在开发完成投入使用后，对信息系统软件进行的改正 性维护、适应性维护、完善性维护、预防性维护等软件工程活动。

信息系统软件的可维护性及维护类型

信息系统软件维护工作直接受到软件可维护性的影响。

软件可维护性是指软件产品被修改 的能力，修改包括纠正、改进或软件对环境、需求和功能规格说明变化的适应。

对软件可维护性的度量可以从以下几个方面进行：

(1)可理解性。可理解性描述了通过阅读源代码和相关文档来了解系统功能及其如何运行情况的难易程度。

(2)可靠性。可靠性表明一个软件系统在给定的一段时间内正确执行的概率。

(3)可测试性。可测试性表明能够用测试的方法来验证程序正确性的难易程度。

(4)可修改性。可修改性描述了程序能够被正确修改的难易程度。

(5)可移植性。可移植性表明程序从一个运行环境移植到另一个新的运行环境的可能性的 大小。

软件维护分类：

(1)纠错性维护 21%。由于系统测试不可能揭露系统存在的所有错误，因此在系统投入运行后 频繁的实际应用过程中，就有可能暴露出系统内隐藏的错误。诊断和修正系统中遗留的错误， 就是纠错性维护。

(2)适应性维护 25%。适应性维护是为了使系统适应环境的变化而进行的维护工作。

(3)完善性维护 50%。在系统的使用过程中，用户往往要求扩充原有系统的功能，增加一些在 软件需求规范书中没有规定的功能与性能特征，以及对处理效率和编写程序的改进。

(4)预防性维护 4%。系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护，即选择那些还有较长使用寿命，目前尚能正常运行，但可能将要发生变化或调 整的系统进行维护，目的是通过预防性维护为未来的修改与调整奠定更好的基础。

信息系统软件运维的体系

1.需求驱动

信息系统软件运维工作是由用户的需求驱动的，其目的是为了更好地满足用户的改正性、适应性、完善性、预防性需求。因此，用户需求是信息系统软件运维工作的起点，由用户的需求变化驱动信息系统软件运维，进一步驱动信息系统软件的发展变化。

2.运维流程

信息系统软件运维流程可以分为运维策划、运维实施、运维检查、运维改进四个阶段，这 四个阶段构成一个迭代的循环过程。

3.运维过程

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

4.运维支撑要素

信息系统软件运维管理应该遵从 ITIL 、ISO20000 、ISO27001等国内外先进的服务管理理 论的要求，管理制度、管理部门、管理人员、管理设施是开展运维工作的必要基础。

(1)运维管理制度。运维工作的各个流程能顺利执行的关键就是建立一套全面覆盖整个运 维工作的、有一定的约束和强制执行力的管理制度。应该将管理制度的各项指标细化、分解到 每个流程中，建立指标的采集、分析、评估和报告的整体流程，并与绩效考核制度联动起来， 以促进服务质量的提高。另外，运维管理制度也应该与运维流程一起持续的改进。

(2)运维管理部门。运维管理部门具体管理信息系统软件运维的各项工作，审批软件运维 申请，确定运维报告，评价运维工作并制定运维管理制度。

(3)运维管理人员。主要包括软件运维工程师、系统管理员、技术服务经理等。

软件运维工程师具体负责软件的运维，根据管理制度和手册，执行运维服务各过程完成信息系统使用中 软件问题的维护、更新、安装等工作，评估运维过程中和业务相关的内容，从业务角度提出修 改或优化意见；

系统管理员规划、检查运维服务的各个过程，对运维服务的策划、实施、检查、 改进的范围、过程和成果负责；

技术服务经理组织如何进行变更修改，由熟悉计算机编程的软件技术人员担任。

(4)运维管理设施。主要包括信息系统软件运维所需要的基础环境、网络设备、硬件设备 和基础软件等。

5.运维管理原则

信息系统软件运维要遵从以下原则。

(1)遵守各项规章制度，严格按照制度办事。

(2)与运维体系的其他部门协同工作，密切配合，共同开展运维工作。

(3)遵守保密原则，运维人员对运维单位的网络、主机、系统软件、应用软件等的密码、核心参数、业务数据等负有保密责任，不得随意复制和传播。

(4)在保证信息系统数据和系统安全的前提下开展工作。

(5)若在运维过程中出现暂时无法解决的问题或其他新的问题，应告知用户并及时上报， 寻找其他解决途径。

(6)信息系统软件运维完成后、要详细记录运维的时间、地点、提出人和问题描述，并形 成书面文档、必要时应向信息系统用户介绍问题出现的原因、预防方法和解决技巧。

信息系统软件运维的趋势——DevOps

DevOps的提出

产生这种鸿沟的原因如下:

(1)开发人员经常不考虑自己写的代码会对运维造成什么影响，他们在交付代码之前，并 不邀请运维人员参与架构决策或代码评审。

(2)开发人员对配置或环境进行修改之后，经常没有及时与运维人员沟通，导致新的代码 不能运行。

(3)开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤，想找到必要的 配置参数，通常需要尝试很多不同的参数。

(4)开发人员倾向于使用有利于快速开发的工具，这样的工具集与运营人员面对的目标运 行时环境非常不同(后者对稳定性和性能的要求远胜于灵活性)。

(5)开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统，生产环境 系统通常都运行在服务器操作系统上。

DevOps的原则

• 基础架构即代码。

  基础架构即代码(IaC) 是大部分通用DevOps 实践的前提要求，这 一概念涉及计算基础架构(虚拟机、网络、软件安装等)的管理和供应，以及通过机器可处理 的定义文件或脚本对其进行自动配置，交互式配置工具和手工命令的使用已经不合时宜了。通 过代码表示环境的相应状态，以免手动配置环境，同时确保一致性。

• 持续交付。

  持续交付是一种可以帮助团队以更短的周期交付软件的方法，该方法确保 了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、 测试和发布

• 协作。

  DevOps 文化的主要特征在于开发和运维角色之间日益增加的协作。这是一种 在团队内部以及组织层面上很重要的文化变迁，通过这样的变迁才能促进更好的协作。

DevOps的价值

• 产品高效交付：

  DevOps 理念指向“高度的自动化”,试图制定一条从开发到运维的 流水线，最大限度地摆脱人工的束缚。

• 改善公司组织文化、提高员工的参与感。

  员工们变得更高效，也更有满足和成就感。

DevOps的工具

DevOps 希望做到的是软件产品交付过程中IT 工具链的打通，使得各个团队减少时间损耗， 更加高效地协同工作。DevOps 需要的工具主要分3类。

• 版本控制软件库。

  它可以确保所有系统产品在整个版本发布生命周期中被很好地定义， 并且能够实现一致性共享，同时保持最新信息。开发和 QA机构能够从中取得相同平台版本， 生产机构部署已经被QA 机构验证过的相同版本。

• 深层模型系统。

  它的版本系统清晰地描述了软件系统相关的所有组件、策略和依赖性， 从而可以简单地根据需要复制一个系统或在无冲突的情况下引入变化。

• 人工任务的自动化。

  在依赖关系发现、系统构造、配置、更新和回滚等过程中减少人 工干涉。自动操作变为高速、无冲突和大规模系统管理的命令和控制基础。