1、1 信息系统软件运维第四章2 2 目 录123456信息系统软件运维体系信息系统软件运维管理流程信息系统软件运维的内容信息系统软件运维系统与专用工具云计算SaaS服务模式下的运维典型案例3 3.13.1管理体系4.1运维体系1 信息系统软件运维的概念 信息系统软件运维是指信息系统软件在开发完成投入使用后，对信息系统软件进行的改正性维护、适应性维护、完善性维护、预防性维护等软件工程活动。信息系统软件交付使用后，会有一部分隐藏的错误被带到运行阶段来，在某些特定的使用环境下才会暴露出来。为了识别和纠正这些错误、改正信息系统软件性能上的缺陷、排除实施中的误使用，所进行的诊断和改正错误的过程，就是改正性
2、维护。4 3.13.1管理体系4.1运维体系随着计算机和IT的飞速发展，新的硬、软件配置或数据环境可能发生变化，为了使信息系统软件适应这种变化，对信息系统软件所进行的修改过程，就是适应性维护。在信息系统软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性，对信息系统软件所进行的维护活动叫做完善性维护。5 3.13.1管理体系4.1运维体系在维护阶段的最初两年，改正性维护的工作量较大。随着错误发现率的大幅降低并趋于稳定，就进入了正常使用期。然而，由于改造的要求，适应性维护和完善性维护的工作
3、量逐步增加。在几种维护活动中，完善性维护所占的比重最大。除了以上三类维护外，还有一类维护活动，叫做预防性维护。这是为了提高信息系统软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。也就是采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。6 3.13.1管理体系4.1运维体系信息系统软件运维涉及的相关要素主要包括用户需求、环境、过程、软件产品、文档、人员和工具等，如表所示信息系统软件信息系统软件运维要素运维要素特特 点点用户需求 申请增加新的功能 申请错误的更正和可维护性的提高组织环境 政策的变化：政府级、行业和企业级 市场竞争引起的变化需求：工作内
4、容、流程与模式、新的软件功能运行环境 硬件平台的创新变化 软件平台的创新变化 通信技术的创新变化运维过程 变化需求的获取：系统使用后很多需求才清晰具体起来 认识编程实践的变化：认识到交付前后编程环境与技术的差异，并使这样的差异变化在后续运维中可理解、可维护 模式转换：低的开发模式、工具、平台向新的高一级的转变 错误检测与更正7 3.13.1管理体系4.1运维体系信息系统软件运维信息系统软件运维要素要素特特 点点信息系统软件产品 文档的质量：有无文档，文档的版本，更新是否同步，是否规范标准 程序的可延展性、复杂性、结构 软件产品的规模、年龄、结构运维人员 人员流动：使运维过程中问题理解阶段的投入
5、增大 领域专家：对运维的总体把握 工作实践流程：人的因素会增加运维的工作量和复杂性开发人员 从事计算机软件项目的概要设计、详细设计、编码和调试的技术人员，包括程序员、软件工程师、系统分析师、项目经理运维工具 辅助软件运维过程中的各种维护活动 主要的软件运维工具：配置管理支持工具、部署工具、版本控制工具及开发信息库工具、逆向工程工具、文档分析工具等开发工具 辅助软件为生命周期过程的基于计算机的工具 软件需求工具，包括需求建模工具和需求追踪工具 软件设计工具，用于创建和检查软件设计 软件构造工具，包括程序编辑器、编译器和代码生成器、解释器和调试器等 软件测试工具，包括测试生成器、测试执行框架、测试
6、评价工具、测试管理工具和性能分析工具8 3.13.1管理体系4.1运维体系2 信息系统软件运维的体系信息系统软件运维主要包括需求驱动、运维过程管理、运维内容管理、运维支撑要素等方面（1）需求驱动：信息系统软件运维是由用户需求驱动的，其目的是为了更好地满足用户的改正性、适应性、完善性、预防性需求。所以，信息系统软件运维是一项始于用户需求并服务于用户需求的活动。用户需求变化驱动软件运维，从而驱动信息系统软件的发展变化。9 3.13.1管理体系4.1运维体系（2）运维过程管理：信息系统软件运维过程并不是简单地读源程序、修改源程序的过程，而是一个软件再定义、开发、测试、修改、发布、验收评价的过程。首先
7、提出运维要求，然后对运维内容进行分析、分类，调查现有系统，确定修改范围，确定运维人员，修改现行信息系统，测试所做修改和整个系统，测试完成后再次投入正常运行。（3）运维内容：信息系统软件运维的内容主要包括日常运维、缺陷诊断与修复、变更管理、补丁程序管理、系统恢复管理、发布管理、版本管理等。10 3.13.1管理体系4.1运维体系（4）运维支撑要素：信息系统软件运维管理必须满足信息系统软件ITIL、ISO20000、ISO27001等规范要求。1）运维管理部门：具体管理信息系统软件运维，审批软件运维申请，确定运维报告，评价运维工作并制定运维规则。11 3.13.1管理体系4.1运维体系 2）运维管
8、理人员：主要包括软件运维工程师、系统管理员、技术服务经理等。软件运维工程师负责软件的运维，解决信息系统使用中软件问题的维修、更新、安装等，对系统应用过程中与业务相关的问题进行把关，从业务角度提出修改或优化意见，此类人员由系统使用部门的业务骨干或领导兼任，他们同时负责运维的组织和协调工作；系统管理员对运维申请组织评价，系统管理员应尽可能地相对稳定；技术服务经理组织如何进行修改，由熟悉计算机编程的软件技术人员担任。3）运维管理设施：包括信息系统软件运维所需要的基础环境、网络设备、硬件设备和基础软件等12 3.13.1管理体系4.1运维体系 4）运维管理原则：信息系统软件运维要遵从以下原则：遵守各项
9、规章制度，严格按照制度办事；与运维体系的其他部门协同工作，密切配合，共同开展运维工作；遵守保密原则，运维人员对运维单位的网络、主机、系统软件、应用软件等的密码、核心参数、业务数据等负有保密责任，不得随意复制和传播；在保证信息系统数据和系统安全的前提下开展工作；若在运维过程中出现暂时无法解决的问题或其他新的问题，应告知用户并及时上报，寻找其他解决途径；信息系统软件运维完成后，要详细记录运维的时间、地点、提出人和问题描述，并形成书面文档，必要时应向信息系统用户介绍问题出现的原因、预防方法和解决技巧。13 13 目 录123456信息系统软件运维体系信息系统软件运维管理流程信息系统软件运维的内容信息
10、系统软件运维系统与专用工具云计算SaaS服务模式下的运维典型案例14 14 管理流程4.2 信息系统软件运维的体系 运维策划 运维实施 运维检查 运维改进 文档管理15 3.13.1管理体系4.2管理流程 信息系统软件运维是不断地满足用户需求的过程。由于用户需求是不断变化的，因此，需要持续地对软件进行修改与维护，直到新的信息系统软件代替原有软件，这一过程从本质上来说是一个P、D、C、A（PPlan，计划；DDo，执行；CCheck，检查；AAction，处理）循环。信息系统软件运维的管理遵从P、D、C、A规则，在软件运维中首先应对运维的总体服务能力进行整体策划，分析所需资源，然后实施软件运维，
11、保证交付的信息系统软件满足运维要求；对信息系统软件的运维结果、运维过程及相关管理体系进行监督、测量、分析和评审，并持续改进。1 管理流程16 3.13.1管理体系4.2管理流程 软件运维策划是指对信息系统软件运维活动过程中的内容、组织、资源、标准进行全局策划，以确保信息系统软件运维活动顺利高效完成，具体内容如下：（1）内容：内容策划是根据信息系统软件所涉及的业务定位和管理范围，策划信息系统软件运维服务对象的业务内容与要求，并形成服务目录。信息系统软件运维的要求常常来自于系统的一个局部，而这种运维要求对整个信息系统来说是否合理，应该满足到何种程度，应从整个信息系统的全局进行权衡。对所能提供的运维
12、服务制定服务目录和说明性文件。服务目录内容宜详细描述服务种类、服务级别等信息，便于和用户交流所要进行的运维服务。2 运维策划17 3.13.1管理体系4.2管理流程（2）组织：软件运维和软件开发一样，技术性强，要有完善的组织管理作为保证。信息系统软件对稳定性和安全性要求高，数据保密，版本更新快，再加上运维人员流动性大，必须实施严格有效的管理。运维组织由业务管理部门人员和信息系统技术管理部门人员共同组成，以便从业务功能和技术实现两个角度控制运维内容的合理性和可行性。2 运维策划18 3.13.1管理体系4.2管理流程（3）资源：资源策划是指对信息系统软件运维所涉及的人力资源、环境资源、财务资源、
13、技术资源、时间资源等的分析。信息系统软件运维人力资源需求是主要的成本因素，同时也是最难精确估算的因素之一。运维人力资源策划涉及确定人力资源的方法。运维人员要协助信息系统用户策划运维软/硬件、网络等环境。为了提供有效的信息系统软件运维支持，维护人员需要策划财务预算，确定运维所需费用是否合理，并与不进行运维所造成的损失相比看是否合算。资源策划还要对运维活动所涉及的计算机语言开发技术、数据库技术等是否有特殊要求进行分析，并预估给定的运维周期是否能完成本次运维活动。2 运维策划19 3.13.1管理体系4.2管理流程（4）标准：信息系统软件运维工作涉及范围广，影响因素多，所以要用软件工程的方法，结合信
14、息系统软件运维的实际，制定出一套运维标准，包括运维流程、运维安全、运维各阶段所要完成的文档、考核评估体系等。2 运维策划20 3.13.1管理体系4.2管理流程按照信息系统软件运维内容的整体策划实施，在实施管理过程中要注意以下工作。（1）运维流程信息系统软件运维的工作流程如图所示3 运维实施21 3.13.1管理体系4.2管理流程首先以书面形式提出运维申请。运维人员根据提交的申请，组织相关人员对运维申请报告的内容进行核评。若情况属实，则依运维的性质、内容、预计工作量、缓急程度或优先级及修改所产生的变化结果等，编制运维报告，提交运维管理部门审批。22 3.13.1管理体系4.2管理流程 运维管理
15、部门从整个信息系统出发，从合理性和技术可行性两个方面对运维要求进行分析和审查，并对修改所产生的影响做出充分的估计。对于不妥的运维要求协商予以修改或撤销。根据具体情况对通过审批的运维报告制定运维计划。如果运维要求紧急，严重影响系统的运行，则应立即安排运维；如果问题不是很严重，可与其他运维项目结合起来统筹安排。按运维要求修改后的软件应经过严格的测试，以验证运维工作的质量。测试通过后，再由业务部门和信息系统管理部门对其进行审核确认，不能完全满足要求的应返工修改。只有经过确认的运维成果才能对系统的相应文档进行更新，最后交付使用。23 3.13.1管理体系4.2管理流程（2）运维申请所有运维活动必须按规
16、定的方式提出申请。运维申请可以由用户提出也可以由系统维护者提出，运维申请应该填写维护的原因、缓急程度。如果是系统出错，用户必须完整地说明出现错误的情况，包括输入数据、输出信息、错误清单及其他相关信息；如果是信息系统软件运行的环境和需求变化，用户要说明软件要适应的新环境、需求变化和性能要求；对于新增加的需求，要进行需求的分析、设计、编程和测试，相当于信息系统的一次新的开发工程。维护部门要对运维申请进行评价。运维申请应主要包括申请编号、问题说明、维护要求、优先级、预计维护结果、维护时间、申请人、申请评价结果、评价负责人、申请日期等内容。24 3.13.1管理体系4.2管理流程（3）运维计划若运维申
17、请通过了审批，维护主管要负责制定运维方案和运维计划。运维计划主要包括计划编号、计划日期、申请编号、维护部门、联系人、优先级、维护工作量、确认问题、运维范围、运维负责人等内容。运维人员将运维计划下达给相应的信息系统软件管理员，由软件管理员按计划进行具体的修改工作。25 3.13.1管理体系4.2管理流程（4）修改管理信息系统软件运维最终落实在修改源程序和文档上。在实施具体修改时，首先要确定修改的范围，包括确定哪些系统、哪些文件、哪些业务流程及哪些程序与本次修改有关。为了正确、有效地修改信息系统源程序，通常要分析和理解源程序，然后修改源程序，最后重新检查和验证源程序，而熟悉源程序的前提是熟悉所维护
18、的软件功能、用户的业务需求及软件架构体系。熟悉软件功能的主要方法是阅读软件的设计文档或用户手册；除了阅读文档外，与用户沟通也非常重要，了解用户怎么使用软件，为什么要这么使用，用户想要运维解决什么问题。熟悉软件架构体系有助于站在信息系统的最高点进行软件运维；26 3.13.1管理体系4.2管理流程（4）修改管理在面向对象分析与设计技术流行的今天，没有理解软件的架构体系，要去维护软件是很困难的。在理解信息系统软件架构、功能、源程序的前提下，按照一定的步骤对程序进行修改或扩充。另外，源程序修改后，相应的文档也应同步修改，保持源程序和文档的完整和一致。在修改源程序和文档时要做好相应的修改记录，以保证运
19、维过程的可追溯性、运维结果的可评估性。27 3.13.1管理体系4.2管理流程（5）运维记录运维记录记载信息系统软件的运维内容，将运维对象、规模、所用计算机语言、运行和错误发生的情况、运维所进行的修改情况及运维所付出的代价等以规范化文档的形式记录下来。运维人员必须按规定格式和内容填写运维过程和记录，软件运维记录主要包括记录编号、记录日期、计划编号、运维内容、运维措施、运维人员、程序改动的日期、运维涉及的表的标识、运维开始日期、运维完成日期、累计用于运维的人时数、与完成的运维相联系的纯效益等内容。运维记录有助于运维知识的积累，通过知识库沉淀日常运维中的工作经验，帮助软件运维人员提高技能，简化软件
20、运维任务，降低软件运维费用。28 3.13.1管理体系4.2管理流程（6）验证程序经修改后应重新测试以验证修改。由于在修改源程序的过程中可能会引入新的错误，影响信息系统软件原来的功能，所以，源程序修改后的重新测试不但要测试新修改部分的功能，还要测试未修改部分的功能。在进行测试时，应先对修改的部分进行测试，然后隔离修改部分，测试未修改部分，最后再对整个程序进行集成测试，验证修改完成并通过后通知用户修改已完成，并将修改以后的信息系统软件版本及相应的运维文档版本发布。验证修改的重新测试主要包括两个方面，如图所示29 3.13.1管理体系4.2管理流程（6）验证30 3.13.1管理体系4.2管理流程
21、（6）验证 首先是验证修改的有效性，即验证修改后软件的功能和性能是否如用户所合理期待的那样，确保用户最终接受所修改的信息系统软件的既定功能和任务。其次是软件配置复审，复审的目的在于保证修改后的软件配置齐全并分类有序，包括信息系统软件运维所必需的源程序清单、相关的文档。在信息系统软件运维的实际验收、测试、执行过程中，常常会发现文档审核是最难的工作，一方面，由于赶时间等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个信息系统软件运维活动都有一些特别的地方，而且也很难找到可用的参考资料。31 3.13.1管理体系4.2管理流程
22、 信息系统软件运维实施执行后要检查是否符合运维计划的要求和目标，对运维管理过程和实施结果进行监控、测量、分析和评审。分析运维工作的影响，包括对信息系统软件当前业务工作的影响、对系统其他部分的影响、对其他系统的影响等，要做好以下工作：（1）定期评审运维过程及相关管理体系，以确保运维能力的适宜和有效；（2）调查用户满意度，并对运维结果进行统计分析；（3）检查各项指标的达成情况。4 运维检查32 3.13.1管理体系4.2管理流程信息系统软件运维经过策划、实施、检查之后，要对信息系统软件运维管理情况进行重新评估，以改进运维管理过程中的不足，修改和优化运维管理计划和标准，如果有必要则需要修订相关的方针
23、、目标，为信息系统软件运维下一阶段的管理明确方向，提供持续改进建议和提升运维能力，这就是信息系统软件运维管理持续改进的思想。具体包括以下内容：（1）建立信息系统运维管理改进机制；（2）对不符合策划要求的运维行为进行总结分析；（3）对未达成的运维指标进行调查分析；（4）根据分析结果确定改进措施，评估结果中需要改进的项，确定改进目标，制定信息系统软件运维管理改进计划，按照计划对改进结果和改进过程执行监控管理、评审并记录，保留记录文档，以评估改进的有效性和持续性5 运维改进33 3.13.1管理体系4.2管理流程（1）信息系统文档 信息系统文档是描述系统从无到有整个发展与演变过程及各个状态的文字资料
24、。在信息系统整个生命周期中涉及多种软件文档，如果没有信息系统文档或没有规范的信息系统文档，则信息系统的开发、运行与维护会处于一种混沌状态。当系统开发人员发生变动时，问题尤为突出。因此系统文档被公认为信息系统的生命线，没有文档就没有信息系统。信息系统文档不是一次形成的，它是在系统开发、运行与维护过程中不断编写、修改、完善与积累而形成的。文档管理是信息系统开发与运行必须做好的重要工作。6 文档管理34 3.13.1管理体系4.2管理流程 信息系统文档在系统开发人员、项目管理人员、系统运维人员之间，以及其与用户之间起着重要的桥梁作用，如图所示。35 3.13.1管理体系4.2管理流程信息系统文档的作
25、用如下:1）用户与系统分析人员在系统规划和系统分析阶段通过文档进行沟通；2）系统开发人员与项目管理人员通过文档在项目期内进行沟通；3）前期开发人员与后期开发人员通过书面文档进行沟通；4）系统测试人员与系统开发人员通过文档进行沟通；5）系统开发人员与用户在系统运行期间通过文档进行沟通；6）系统开发人员与系统运维人员通过文档进行沟通；7）用户与运维人员在运行期间通过文档进行沟通。36 3.13.1管理体系4.2管理流程根据不同的性质，可将信息系统文档分为技术文档、管理文档及记录文档等若干类，如表所示文文 档档 类类 别别文文 档档 内内 容容产产 生生 阶阶 段段备备 注注技术文档系统总体规划报告
26、系统规划 系统分析报告系统分析 系统设计说明书系统设计 程序设计说明书系统设计 数据设计说明书系统设计 系统测试说明书系统设计 系统使用说明书系统实施 系统测试报告系统实施 系统维护手册系统实施运行中继续完善37 3.13.1管理体系4.2管理流程管理文档系统需求报告系统开发前 系统开发计划系统规划 系统开发合同书系统规划 委托或合作开发时系统总体规划评审意见系统规划 系统分析审批意见系统分析 系统实施计划系统设计 系统设计审核报告系统设计 系统试运行报告系统实施 系统运维计划 系统实施 系统运行报告系统运维 系统开发总结报告系统运维 系统评价报告 系统运维 系统维护报告系统运维 文文 档档
27、类类 别别文文 档档 内内 容容产产 生生 阶阶 段段备备 注注38 3.13.1管理体系4.2管理流程记录文档会议记录各阶段 调查记录各阶段 系统运行情况记录系统运维 系统日常运维记录系统运维 系统适应性运维记录系统运维 用户问题记录系统运维 维护反馈记录系统运维 运维过程记录系统运维 文文 档档 类类 别别文文 档档 内内 容容产产 生生 阶阶 段段备备 注注39 3.13.1管理体系4.2管理流程（2）信息系统软件运维文档管理信息系统软件运维文档主要包括系统运行报告、系统开发总结报告、系统评价报告、系统维护报告、系统运行情况记录、系统日常运维记录、系统适应性运维记录、用户问题记录、维护反
28、馈记录、运维过程记录等。文档能提高软件运维过程的能见度，把用户反映的问题、用户提交的报告、用户增加的需求、对用户反映问题的维护反馈记录、运维过程中发生的事件以某种可阅读的形式记录在文档中，管理人员可把这些记载下来的材料作为检查软件运维进度和运维质量的依据，正确统计运维的工作量，实现对信息系统软件运维的工程管理，提高运维效率。文档作为运维人员一定阶段的工作成果和结束标志，记录运维过程中的有关信息，便于管理人员、运维人员、操作人员、用户之间的协作和交流，使信息系统软件运维更科学、更有成效。6 文档管理40 3.13.1管理体系4.2管理流程信息系统软件运维文档管理应注意如下方面：1）文档管理制度化
29、。形成一整套完善的文档管理制度，根据这一套制度来协调、控制、评价信息系统软件运维中各类人员的工作。2）文档标准化、规范化。在信息系统软件运维前要选择或制定文档标准，在统一的标准约束下来规范地建立各类文档。3）落实文档管理人员。应设专人负责集中保管与信息系统软件运维相关的文档，他人可按一定的流程向文档管理员借阅文档。6 文档管理41 3.13.1管理体系4.2管理流程4）保持文档的一致性。信息系统软件在运维过程中如果修改了原来的需求和设计，但是文档却没有进行同步修改，造成交付的文档与实际信息系统软件不一致，使用户在使用信息系统软件参考文档对软件进行维护时出现许多误解，这将严重影响系统的质量和维护
30、的效率。所以，在信息系统软件运维过程中，如果修改部分涉及设计文档或用户手册的，一定要及时更改，这样才能达到事半功倍的效果。5）维护文档的可追踪性。由于信息系统软件运维的动态性，软件的某种修改最终是否有效要经过一定的时间检验，所以运维文档也应与相应的信息系统软件一样要分版本进行管理，这样软件和文档就具有可追踪性，便于持续地运维与改进。6 文档管理42 42 目 录123456信息系统软件运维体系信息系统软件运维管理流程信息系统软件运维的内容信息系统软件运维系统与专用工具云计算SaaS服务模式下的运维典型案例43 43 日常运维4.3 信息系统软件运维的内容 缺陷诊断与修复 变更管理 补丁程序管理
31、 系统恢复管理 部署管理 版本管理44 3.13.1管理体系4.3运维内容1 日常运维（1）日常运维的内容信息系统软件日常运维的主要内容包括：监控、预防性检查、常规操作。信息系统软件监控的主要内容有进程状态、服务或端口响应情况、资源消耗情况、日志、数据库连接情况、作业执行情况等。信息系统软件预防性检查的主要内容有典型操作响应时间、系统病毒定期查杀、口令安全情况、日志审计、分析、关键进程及资源消耗分析、队列等。信息系统软件常规操作的主要内容有日志清理，启动、停止服务或进程，增加或删除用户账号，更新系统或用户密码，建立或终止会话连接，作业提交，软件备份等。45 3.13.1管理体系4.3运维内容（
32、2）日常运维流程日常运维是指按照信息系统软件运维服务协议定时、定点、定内容重复进行的信息系统软件的常规维护活动。日常运维流程如图所示。46 3.13.1管理体系4.3运维内容 日常运维的常规操作包括查阅系统日常运行记录，处理运行过程中的随机事件，对不能解决的事件申请维护处理；对日常维护中发现的系统缺陷，申请转入缺陷诊断与修复流程；同时做好日常运行报告的编制工作，将日常运行报告与日常运行过程中产生的其他文档一并归档备查。47 3.13.1管理体系4.3运维内容（3）日常运维活动信息系统软件的日常运维活动主要包括例行测试维护和定期测试维护1）例行测试维护按照例行测试的测试结果进行信息系统软件常规维
33、护活动，例行测试流程如图所示48 3.13.1管理体系4.3运维内容例行测试流程的要点如下：开展例行测试前应先制定测试计划及准备测试用例；按计划依据用例执行测试；对测试结果进行分析，对需更新或修改的测试结果申请运维处理；对信息系统软件运维后若发现有缺陷不能解决，则申请进入缺陷诊断与修复；例行测试完成后应编制例行测试报告，并与例行测试过程中产生的文档一并归档。49 3.13.1管理体系4.3运维内容例行维护流程如图所示,其关键点如下：开展信息系统软件例行维护前应制定例行维护实施方案；对记录的维护情况进行分析，若在维护后发现系统有缺陷，则申请进入缺陷诊断与修复流程；例行维护完成后应编制例行维护报告
34、，并与例行运维过程中产生的文档一并归档。50 3.13.1管理体系4.3运维内容2）定期测试维护定期测试维护指按照信息系统软件开发或提供厂商规定的维护周期进行信息系统软件的测试与维护活动。定期测试维护的周期依据信息系统软件的使用手册和运行规范设定。其周期一般有周测试维护、月测试维护和季度测试维护三种基本类型。不同周期的测试内容详略程度可有所不同。51 3.13.1管理体系4.3运维内容定期测试维护基本流程如图所示。其要点如下：定期测试维护开始前应先查阅信息系统软件日常运行记录；对定期测试记录进行分析，对有需要维护的信息系统功能则申请进行维护处理；维护后发现系统存在缺陷，则申请转入缺陷诊断与修复
35、流程；定期测试维护完成后应编制定期测试维护报告，并与定期测试运维过程中产生的文档一并归档。52 3.13.1管理体系4.3运维内容2 缺陷诊断与修复（1）信息系统软件缺陷的概念信息系统软件缺陷是指信息系统软件中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。从信息系统软件产品内部看，缺陷是信息系统软件产品开发或运维过程中存在的错误；从信息系统软件产品外部看，缺陷是信息系统所需实现的某种功能的失效或违背。一旦发现信息系统软件缺陷，就要设法找到引起缺陷的原因，分析其对信息系统产品质量的影响，然后确定缺陷的严重性和处理这个缺陷的优先级。各种缺陷所造成的后果是不一样的，有的仅仅是不方便，有
36、的可能是灾难性的。一般问题越严重，其处理优先级就越高，缺陷的严重性通常分以下四种：53 3.13.1管理体系4.3运维内容1）微小的：对信息系统软件功能几乎没有影响的一些小问题，信息系统软件产品仍可使用；2）一般的：不太严重的错误，如信息系统软件次要功能模块丧失，提示信息不够准确，用户界面差和操作时间长等；3）严重的：严重错误，指信息系统软件模块功能或特性没有实现，主要功能部分丧失，次要功能全部丧失，或出现致命的错误声明；4）致命的：致命的错误造成信息系统崩溃、死机，或造成系统数据丢失，主要功能完全丧失等。54 3.13.1管理体系4.3运维内容除了缺陷的严重性之外，还需要判断缺陷所处的状态，
37、以便及时跟踪和管理。信息系统软件缺陷状态如图所示55 3.13.1管理体系4.3运维内容1）活动状态：问题没有解决，信息系统软件测试人员新报告的缺陷或者验证后缺陷仍旧存在；2）已解决状态：信息系统开发人员针对缺陷，进行信息系统软件修正，问题已解决或通过单元测试；3）关闭状态：信息系统软件测试人员经过验证后，确认缺陷不存在之后的状态。以上是三种基本的状态，还有一些需要用相应的状态描述，如“保留”、“不一致”状态等。56 3.13.1管理体系4.3运维内容（2）信息系统软件缺陷的分类从软件测试角度看，信息系统软件缺陷可分为五大类，如表所示构构 成成细细 分分解解 释释功能缺陷需求说明书缺陷需求说明
38、书可能不完全，有二义性或自相矛盾。修改信息系统功能后没有及时修改需求说明书功能不一致缺陷软件实现的功能与用户要求的不一致，包括错误的功能、多余的功能或遗漏的功能测试缺陷信息系统软件测试的设计与实施发生错误。软件测试自身也可能发生错误。另外，如果测试人员对系统或需求说明书缺乏了解，也会发生许多错误测试标准引起的缺陷对测试标准要选择适当，若太复杂，则导致测试过程出错的可能性就大57 3.13.1管理体系4.3运维内容系 统 缺陷模块接口缺陷信息系统软件内部子系统或模块之间的联系发生的缺陷，与程序内实现的细节有关，如输入/输出格式错，数据保护不可靠，子程序访问错等软件结构缺陷由于信息系统软件结构不合
39、理而产生的缺陷，通常与系统的负载有关，而且往往在系统满载时才出现，如错误地设置局部参数或全局参数等控制与顺序缺陷如忽视了时间因素而破坏了事件的顺序；等待一个不可能发生的条件；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等加工缺陷算法与操作缺陷在算术运算、函数求值和一般操作过程中发生的缺陷初始化缺陷错误地对循环控制变量赋初值；用不正确的格式、数据或类型进行初始化等静态逻辑缺陷如不正确地使用分支语句；在表达式中使用不正确的否定等58 3.13.1管理体系4.3运维内容数据缺陷动态数据缺陷动态数据是在程序执行过程中暂时存在的数据，在执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始
40、化，可能导致数据出错静态数据缺陷静态数据在内容和格式上都是固定的，它们直接或间接地出现在程序或数据库中，由编译程序或其他程序专门对它们进行预处理，要防止预处理出错内容、结构和属性缺陷数据内容缺陷是由于内容被破坏或被错误地解释而造成的缺陷；数据结构缺陷包括结构说明错误及数据结构误用错误；数据属性缺陷包括对数据属性不正确地解释代码缺陷 包括数据说明错、数据使用错、比较错、控制流错、界面错等59 3.13.1管理体系4.3运维内容（3）信息系统软件缺陷诊断与修复流程现信息系统软件缺陷后，要尽快修复。小范围内的错误不及时修复，可能会扩散成大错误，导致后期修改工作更多，成本也更高。信息系统软件缺陷发现或
41、解决得越迟，信息系统软件运维的成本就越高。按照信息系统软件开发提供的测试检查方法、测试检查工具或第三方测试工具，按测试规范对信息系统软件进行缺陷诊断与修复。对于诊断流程发现的缺陷按缺陷诊断和处理办法能够解决的缺陷问题在此流程范围内解决。缺陷诊断与修复流程如图所示。60 3.13.1管理体系4.3运维内容缺陷诊断与修复流程主要包括如下方面：接受问题申请后，应对问题进行初步诊断；经检查分析，对属于异常的缺陷进行修复，对属于常见问题的缺陷则进行技术支持；对不能修复的异常缺陷申请重大缺陷处理；缺陷诊断与修复完成后应编制缺陷诊断与修复报告，并同缺陷诊断与修复过程中产生的文档一并归档。61 3.13.1管
42、理体系4.3运维内容3 变更管理变更管理是信息系统软件变更过程的管理，信息系统软件变更是不可避免的，因为：（1）信息系统软件上线使用后，新的需求会不断出现；（2）信息系统软件已有的需求会随着业务环境的变化而变化；（3）信息系统软件运行中的错误要进行修改；（4）信息系统软件其他性能和非功能特性需要修改。62 3.13.1管理体系4.3运维内容信息系统软件最终的目的是要满足用户需求，而用户的需求总是在不断地变化，用户的一个需求变更作为一个新需求，等到一个新的迭代周期开始的时候将新变更需求引入，信息系统软件所有的规划、分析设计、实现、测试、部署都根据新的需求变更进行更新，形成一个周而复始的信息系统软
43、件迭代变更过程，如图所示:63 3.13.1管理体系4.3运维内容信息系统软件变更流程是信息系统运维的基本控制流程之一。信息系统软件应具有独立的变更管理功能，负责控制信息系统运行及运维过程中发生的变化，相应地指定级别足够高的相关人员负责变更管理，负责制定变更计划，监督变更实施等工作。信息系统软件变更管理应从工具和流程两个层面紧密地结合在一起，选用适当的软件来支持和管理变更管理流程64 3.13.1管理体系4.3运维内容信息系统软件变更流程如图4-13所示，主要包括如下方面：65 3.13.1管理体系4.3运维内容（1）软件变更申请提出后需要整理，并判断哪些需要重点讨论后再做决策，重点讨论时要解
44、决并消除变更需求及变更之间的冲突，从业务部门出发，从合法性的角度审核变更需求，确定变更需求，确定被批准的变更需求的优先级，决定变更实施的计划安排。运维部门管理协调信息系统变更需求提交、变更控制、跟踪，任务分派及与变更执行者的沟通等。任何变更需求应进行讨论并确定其实施计划。除特殊的紧急情况外，任何与解决软件问题相关的变更都应提交正式的变更需求。所有变更的需求在被讨论审核前被授予相应的优先级66 3.13.1管理体系4.3运维内容（2）对于不完善的软件变更申请需整理后重新提交申请。（3）经批准同意的软件变更实施后应进行变更信息发布，所有与软件运维相关的变更均应在授权下实施，除少数紧急特例外，任何变
45、更在使用前都要经过测试，为需要进行的测试提供所需的测试环境，评估并公布软件变更对业务部门的影响，应根据具体的需求定时向负责变更实施的员工及受变更影响的最终用户通报被批准实施的变更申请及计划实施的项目。（4）建立变更管理制度，规范变更管理过程，并形成文档。将变更过程中产生的文档归档，变更历史记录应与变更实施分析及分析后产生的变更管理报告紧密地结合在一起使用，并作为改进变更管理流程的重要工具。67 3.13.1管理体系4.3运维内容好的信息系统软件产品通常会有一定的用户群。用户新需求的不断积累最终会带来软件产品的变更问题。信息系统软件在原有版本可用的前提下，为了更好地满足用户需要而对原有信息系统软
46、件在功能、界面、性能、用户交互性等方面做出大范围的变更，可能涉及架构和界面的整体修改，会变更原有软件已形成的用户使用习惯。如何让变更后的信息系统软件产品向下兼容，如何在保持原有功能的基础上，使得变更后的信息系统软件产品在性能、功能、用户使用的便捷性等方面更加优越，针对这些特性，信息系统软件产品平滑变更的基本原则如下：68 3.13.1管理体系4.3运维内容（1）与原有信息系统软件的兼容：原有功能升迁到新的信息系统软件中，继续保留原有信息系统软件中适用的功能，并对原有的信息系统软件中不足的功能进行改进，使之更加实用。（2）用户透明性：信息系统软件的变更对用户来说，是一种功能增强、性能改善和业务处
47、理逻辑更加合理化的过程。所谓的用户透明性不是指用户感觉不到，而是指用户不需要从头学习新信息系统软件，就能根据原有软件产品的使用经验流畅地转入新系统的使用。（3）可扩展性：由于信息系统软件产品具有较长的生命周期，因此在兼顾原有信息系统软件的同时，还必须考虑新信息系统软件未来的可扩展性。69 3.13.1管理体系4.3运维内容4 补丁程序管理补丁程序管理指为修复原有信息系统软件在功能和易用性上的问题，对信息系统原有程序或存在的漏洞进行修改和补充形成的程序，通常可自由安装和卸载。如何有效安装信息系统软件补丁、管理好补丁是信息系统软件运维管理的重要内容。信息系统软件补丁管理涉及业务、流程、管理和技术，
48、是信息系统软件运维整体框架中不可缺少的组成部分之一，是提高信息系统软件整体可维护性和安全性必不可少的组成部分70 3.13.1管理体系4.3运维内容补丁程序管理主要是对制作完成的信息系统软件补丁进行检测、发布、跟踪，运维人员获取并安装信息系统软件补丁程序。补丁程序管理流程如图所示，其要点包括：现状分析、补丁跟踪、补丁分析、部署安装、疑难处理、补丁检查六个环节，同时由于补丁程序管理是一个长期、周而复始的工作，因此这些工作又形成一个环状的流程，其中既有事件驱动工作，又有例行工作71 3.13.1管理体系4.3运维内容下面着重分析其中的几个环节。（1）现状分析信息系统软件管理员查询日常运维记录，分析
49、目前的信息系统是否需要补丁升级，不需要则直接归档，若需要则申请由技术服务经理进行补丁跟踪。还需要分析信息资产、信息系统环境、信息资产重要等级，以便下一步有针对性地跟踪信息系统所需要的补丁和要采取的措施。系统管理员要分析和管理相应的信息系统软件补丁程序版本，还没有实施的补丁、原因及补救办法。72 3.13.1管理体系4.3运维内容（2）补丁跟踪虽然补丁程序在发布前已经进行了测试，但是测试永远是不充分的，从实际经验来看，每个信息系统软件都有本身的特殊应用环境，因此信息系统软件补丁程序往往不稳定，会造成很多迭代的未知问题，必须根据信息系统软件的实际安装环境进行补丁跟踪，以判断该补丁在该环境下的兼容状
50、况。信息系统软件补丁测试的关键要考虑测试的广泛性、针对性，即能针对信息系统的实际情况尽量充分地测试。测试环境最好能有信息系统的各种应用，特别是一些关键应用，以便判断该补丁对信息系统关键应用的影响。如果在测试中发现问题，就要进行详细的分析，以判断发生问题的原因，并及时解决。如果不能解决，则需要记录下发生该问题的环境，并进行重复验证。73 3.13.1管理体系4.3运维内容（3）补丁检查为了确认信息系统软件补丁安装情况，需要对安装的系统进行检查。74 3.13.1管理体系4.3运维内容5 系统恢复管理系统恢复管理是针对已不能正常运行的信息系统软件执行恢复安装的管理。它属于维修性质的服务管理，通常涉
