|
|
知识路径： > 信息系统运维概述 > 信息系统运维概述 > 信息系统运维的框架 >
|
被考次数：4次
被考频率：中频率
总体答错率：77%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：12个
|
|
|
|
|
管理信息系统在完成系统实施、投入正常运行之后，就进入了系统运行与维护阶段。一般信息系统的使用寿命短则4～5年，长则可达10年以上。在信息系统的整个使用寿命中，都将伴随着系统维护工作进行。系统维护的目的是要保证管理信息系统正常而可靠地运行，并能使系统不断得到改善和提高，以充分发挥作用。因此，系统维护的任务就是要有计划、有组织地对系统进行必要的改动，以保证系统中的各个要素随着环境的变化始终处于最新的正确的工作状态。
|
|
|
|
系统维护工作在整个系统生命周期中常常被忽视。人们往往热衷于系统开发，当开发工作完成以后，多数情况下开发队伍被解散或撤走，而在系统开始运行后并没有配置适当的系统维护人员。这样，一旦系统发生问题或环境发生变化，最终用户将无从下手，这就是为什么有些信息系统在运行环境中长期与旧系统并行运行不能转换，甚至最后被废弃的原因。随着信息系统应用的深入，以及使用寿命的延长，系统维护的工作量将越来越大。系统维护的费用往往占整个系统生命周期总费用的60%以上，因此有人曾以浮在海面的冰山来比喻系统开发与维护的关系，系统开发工作如同冰山露出水面的部分，容易被人看到而得到重视，而系统维护工作如同冰山浸在水下的部分，体积远比露出水面的部分大得多，但由于不易被人看到而常被忽视；从另一方面来看，相对于具有“开创性”的系统开发来讲，系统维护工作属于“继承性”工作，挑战性不强，成绩不显著，使很多技术人员不安心于系统维护工作，这也是造成人们重视开发而轻视维护的原因。但系统维护是信息系统可靠运行的重要技术保障，必须给予足够的重视。
|
|
|
|
信息系统运维是运维服务提供方按照需方的要求，基于一定的运维平台对相关信息技术资产进行服务活动，具体框架如下图所示。
|
|
|
|
|
|
|
|
|
|
信息系统运维的目标是建立一个高效、灵活的信息系统运维体系，确保信息系统安全、可靠、可用和可控，进而达到IT的充分利用。
|
|
|
|
（1）安全：安全是指信息系统使用人员在使用过程中，有一整套安全防范机制和安全保障机制，使他们不需要担心信息系统的实体安全、软件与信息内容的安全等。
|
|
|
|
（2）可靠：信息系统有足够的可靠性不会发生宕机、系统崩溃、运行处理错误等。
|
|
|
|
（3）可用：可用是指一个系统处在可工作状态的时间的比例，通常以几个9来量化表示。
|
|
|
|
（4）可控：可控是指信息系统IT资源的可管理、可优化，并应实现这些IT资产的价值提升。
|
|
|
|
|
|
从系统维护的特点可以看到，系统维护工作直接受到系统可维护性影响。可维护性是对系统进行维护的难易程度的度量，影响系统可维护性主要有以下3个因素。
|
|
|
|
（1）可理解性。可理解性表现为维护人员理解系统的结构、接口、功能和内部过程的难易程度。这种理解包括对功能、性能的分析与理解，对原设计的分析与理解以及对源程序的分析与理解。在系统中采用模块化方法、具有详细的设计文档、源程序内部文档的规范与完整、结构化设计及选择较好的高级程序设计语言等，都可以促进系统可理解性的提高。
|
|
|
|
（2）可测试性。可测试性表现为对系统进行测试和诊断的难易程度。系统中具有良好的系统文档、可用的测试工具和调试手段是十分重要的，特别是在开发阶段的测试方案尤为重要，是进行回归测试和证明修改正确性的基础。
|
|
|
|
（3）可修改性。可修改性表现为对系统各部分进行修改的难易程度。系统的模块化程度、模块之间的耦合、内聚、控制域与作用域的关系以及数据结构的设计等都直接影响系统的可修改性。而这些问题在系统分析、设计验收就应充分重视，否则系统将是很难修改的。
|
|
|
|
上述三个可维护性因素是密切相关的，只有正确的理解，才能进行恰当的修改，只有通过完善的测试才能保证修改的正确，防止引入新的问题。
|
|
|
|
对于系统的可维护性，通过上面三个因素可以看到很难量化，但是可以通过能够量化的维护活动的特征，来间接地定量估算系统的可维护性。例如1979年T. Gilb提出把维护过程中各项活动所消耗的时间记录下来，用以间接衡量系统的可维护性，其内容包括：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
显然这些数据是可以度量的，记录这些数据对于了解系统的可维护性是有益的。当然可维护性的定量分析还有其他方法，如新的学科——软件度量学就是专门研究这方面问题的。
|
|
|
|
通过对系统可维护性的分析可以看出，提高系统可维护性应当从系统分析与设计开始，直至系统实施的系统开发全过程，在系统维护阶段再来评价和注意可维护性为时已晚。所以必须特别强调提高系统可维护性的工作应该贯穿信息系统开发的全过程。
|
|
|
|
|
|
根据信息系统运维的目标，运维工作内容可分为例行操作、响应支持、优化改善和咨询评估四个方面，具体如下。
|
|
|
|
（1）例行操作：运维提供方提供预定的例行服务，以及时获得运维对象的状态，发现并处理潜在的故障隐患。
|
|
|
|
（2）响应支持：运维提供方接到需求方运维请求或故障报告后，在双方达成的服务品质协议（Service-Level Agreement，SLA）承诺内尽快降低和消除对需求方的业务影响。
|
|
|
|
（3）优化改善：运维提供方适应需方业务要求，通过提供调优、改进等服务，达到提高运维对象性能或管理能力的目的。
|
|
|
|
（4）咨询评估：运维提供方结合需方业务需求，通过对运维对象的调研和分析，提出咨询建议或评估方案。
|
|
|
|
|
|
信息系统运维的对象是运维服务的受体，主要包括基础环境、网络平台、硬件设备、基础软件、信息系统软件、数据等。
|
|
|
|
（1）基础环境是指为信息系统运行提供基础运行环境的相关设施，如安防系统、弱电智能系统等。
|
|
|
|
（2）网络平台是指为信息系统提供安全网络环境相关的网络设备、电信设施，如路由器、交换机、防火墙、入侵检测器、负载均衡器、电信线路等。
|
|
|
|
（3）硬件设备是指构成信息系统的计算机设备，如服务器、存储设备等。
|
|
|
|
（4）基础软件是指为应用运行提供运行环境的软件程序，如系统软件。
|
|
|
|
（5）信息系统软件是指由相关信息技术基础设施组成的，完成特定业务功能的系统，如ERP、CRM、SCM等。
|
|
|
|
（6）数据是指应用系统支持业务运行过程中产生的数据和信息，如账务数据、交易记录等。
|
|
|
|
|
|
将所有信息系统运维对象、内容及流程内嵌到一个统一的平台级软件中，究其规模，可以是综合的运维制度＋运维系统，也可以是局部的主要制度＋运维工具。
|
|
|
|
|
|
信息系统运维支撑要素有运维管理部门、运维管理人员、运维管理设施和运维管理制度四个方面，是支撑信息系统运维工作的软环境。
|
|
|
|
|
|
|
|
（1）是否采用结构化开发方法对系统维护工作有极大影响。如果系统开发没有采用结构化分析与设计方法，则相应进行的维护也只能是非结构化维护。因为这时系统软件配置的唯一成分是程序源代码，一旦有系统维护的需求时，维护工作只能从艰苦的评价程序代码开始。由于没有完整规范的设计开发文档，无程序内部文档，对于软件结构、数据结构、系统接口以及设计中的各种技巧很难弄清，如果编码风格再差一些，则系统维护工作十分艰难，因此，有许多软件人员宁可重新编码，也不愿维护这种系统。另一方面，由于无测试文档，不能进行回归测试，对于维护后的结果难以评价。
|
|
|
|
相反，如果系统开发采用了结构化方法，则系统交付时有完整的软件配置文档，维护的过程也就比较规范。维护从评价设计文档开始，从文档中确定软件结构、数据结构以及系统接口等特点，在考虑到修改可能带来影响的情况下，设计修正错误的途径。然后修改设计，在与设计相对应的源程序上进行相应的修改，使用测试说明书中包含的测试方案进行回归测试。可见经过结构化开发的系统，将大大减少维护的工作量，提高质量。
|
|
|
|
（2）系统维护要付出很高的代价。首先，有形的代价直接来自维护工作本身。维护工作可分为两部分，一部分为非生产性活动，主要是理解源程序代码的功能，解释数据结构、接口特点和性能限度等。这部分工作量和费用与系统的复杂程度（非结构化设计和缺少文档都会增加系统的复杂程度）、维护人员的经验水平以及对系统的熟悉程度密切相关；另一部分为生产性活动，主要是分析评价、修改设计和编写程序代码等。其工作量与系统开发的方式、方法、采用的开发环境有直接的关系。因此，如果系统开发途径不好，且原来的开发人员不能参加维护工作，则维护工作量和费用呈指数上升。例如，据1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，而维护成本大约是每条指令4000美元。统计表明，60%～70%的软件费用花在维护方面。
|
|
|
|
另外，许多无形的代价来自维护所产生的效果和影响上。由于系统开发人员和其他开发资源越来越多地被束缚在系统维护工作中，开发的系统越多，维护的负担越重，这将导致完全没有时间和精力从事新系统的开发，从而耽误甚至丧失了开发良机。此外，合理的维护要求不能及时满足，将引起用户的不满；维护过程中引入新的错误，使系统可靠性下降等问题将带来很高的维护代价。
|
|
|
|
（3）系统维护工作对维护人员要求较高。因为系统维护所要解决的问题可能来自系统整个开发周期的各个阶段，因此承担维护工作的人员应对开发阶段的整个过程、每个层次的工作都有所了解，从需求、分析、设计一直到编码、测试等，并且应具有较强的程序调试和排错能力，这些对维护人员的知识结构、素质和专业水平有较高的要求。
|
|
|
|
（4）系统维护工作的对象是整个系统的配置。由于问题可能来源于系统的各个组成部分，产生于系统开发的各个阶段，因此系统维护工作并不仅仅是针对源程序代码，而且包括系统开发过程中的全部开发文档。
|
|
|
|
（5）系统维护经常遇到的很多问题。系统维护中的绝大部分问题源于系统分析和设计阶段，而编码本身造成的错误比例并不高，仅占4%左右。理解别人编写的程序很难，难度随着软件配置文档的减少而增加。从实际情况来看，绝大多数系统在设计和开发时并没有很好地考虑将来可能的修改，如有些模块不够独立，牵一发而动全身。同时，系统维护工作相对开发工作来讲，不具挑战性，不吸引人，使系统维护人员队伍不稳定。
|
|
|
