[toc]
系统分析师笔记15_系统运行与维护
该笔记内容来自《系统分析师教程》第2版。
运维技术指标
系统在完成开发并交付使用后系统就处于运行和维护阶段，在系统运行和维护过程中，难免会因为系统本身的异常，抑或外部环境等因素导致系统出现这样或那样的问题，从而引发系统业务的间断不可用或失效等。
针对这些问题，需要制定必要的应对策略或措施以降低异常情况发生的概率，提升用户的服务体验。比如，可通过一些可量化的指标来对系统的运行和维护能力进行衡量，以便提升系统的运行和维护管理水平。
在系统运行和维护中，可使用平均故障修复时间(MTTR)、平均故障间隔时间(MTBF)、平均无故障时间(MTTF)和平均应答时间(Mean Time to Acknowledge，MTTA)等指标来帮助运维部门开展管理工作。
平均故障修复时间(MTTR)
MTTR是指系统可修复故障的平均维修时间，即在给定时间(时间段)内所发生的一次或多次系统故障的累计维修时间相对于故障次数的平均值。
这里的系统故障维修时间是指从系统故障发生时刻起到系统被维修并恢复至正常状态所花费的时间，其中包括故障通知、故障排查诊断、故障系统修复所需测试时间等。
平均故障间隔时间(MTBF)
MTBF是指系统两次故障之间的平均运行时间，即在给定周期内，系统发生一次或以上的故障之间累计运行时间相对故障次数的平均值。
这里，每段系统运行时间从系统开始正常运行或故障恢复后开始计算，到下次故障发生为止。MTBF用于衡量系统的可靠性。因此MTBF值越大，系统越可靠。
平均无故障时间(MTTF)
MTTF是指可更换或不可修理系统或部件提供正常功能的平均持续时间，即指多个同类系统或部件从开始正常运行起到出现故障为止所持续时间相对同种系统或部件数量的平均值。MTTF用于衡量不可修复系统或部件的可靠性，表示系统在失效之前可以运行的时间。
MTTF常用于衡量可更换或不可修理硬件寿命的。硬件MTTF的历史数据可作为运维人员掌握硬件预期使用寿命，有计划进行系统检查、维护工作的参考。
平均应答时间(MTTA)
MTTA是运维团队响应业务部门的投诉、业务中断或异常事件所花费的平均时间。MTTA体现了告警管理系统的效率，以及运维团队的响应能力。运维团队通过优化流程，尽可能将MTTA减至最短，可提升客户满意度，同时也降低运维成本。
系统运行管理
系统用户管理
系统用户管理是指管理用户的身份和权限，使用户在授权范围内对系统进行操作，防止非授权访问。用户管理的功能包括用户账号管理、权限管理、企业外部用户管理和用户安全审计。
统一用户管理
在信息系统中，通常对用户进行统一的管理。
例如，对于一个内部用户而言，身份识别管理的时间跨度从员工加入企业开始直到离开为止。进入企业后，新员工的资料就被添加到人力资源管理系统，系统会自动生成各种密码和授权，开始记录这名员工在企业里所做的任何访问活动。当员工离开时，网管只需将其从人力资源管理系统中删除，身份识别管理系统就会自动地将与该员工相关的授权全部删除。
因此，进行统一的用户管理可以带来如下好处:
- (1)用户使用更加方便。采用统一认证系统后，用户只需要使用同一个用户名和密码就可以登录所有允许他登录的系统，就能对各个应用系统进行访问。
- (2)安全控制力度得到加强。管理人员可以集中控制用户的访问范围和权限，并对用户的行为进行审计。
- (3)减轻管理人员的负担，提高工作效率。管理人员可以通过一个统一的管理界面集中管理用户信息，提高工作效率，减少人为失误的可能性。
身份认证
目前，信息系统中的用户身份认证方式主要有以下4种:
- (1)用户名/密码方式。这种方式是最简单也是最常用的身份认证方法。但是，其安全性不太好，密码容易被猜测，或者被驻留在计算机内存中的木马程序或网络中的监听设备截获。
- (2)集成电路(Integrated Circuit，IC)卡认证。IC卡是一种内置集成电路的芯片，芯片中存有与用户身份相关的数据。IC卡由专门的厂商通过专门的设备生产，理论上是不可复制的硬件，通过IC卡硬件不可复制性来保证用户身份不会被仿冒。
- (3)动态密码。动态密码技术是一种让用户密码按照时间或使用次数不断变化、每个密码只能使用一次的技术。它采用一种叫做动态令牌的专用硬件，内置电源、密码生成芯片和显示屏，密码生成芯片运行专门的密码算法，根据当前时间或使用次数生成当前密码并显示在显示屏上。认证服务器也采用相同的算法计算当前的有效密码。二者进行对比验证，从而实现用户身份认证。
- (4)USBKey认证。它采用软硬件相结合、“一次一密码”的强双因子认证模式，很好地解决了安全性与易用性之间的矛盾。
用户安全审计
用户安全审计的主要功能是收集、保护和分析用户安全审计数据，形成用户安全审计报告。
网络资源管理
网络资源是企业重要的IT基础设施，包括局站、机房、管道、光缆、电缆、传输设备、光/电路、交换、数据、动力、接入、时钟同步、基站等。
随着信息化建设的深入，企业网络资源的规模不断扩大，网络资源的管理和维护任务也越来越困难，管理和维护工作的要求也越来越高。
软件资源管理
软件资源就是指企业整个环境中运行的软件和文档。软件资源管理是指优化管理信息的收集，对企业所拥有的软件授权数量和安装地点进行管理。
软件资源管理还包括软件分发管理，即通过网络把新软件分发到各个站点，并完成安装和配置工作。
系统故障管理
故障管理的主要目标是尽可能快地恢复系统运行，尽量减少故障对业务运营的不利影响，以确保最好的服务质量和可用性。
故障管理包括故障监视、故障调查、故障排查、恢复处理和故障收尾5项基本活动。
为了实现对故障流程的完善管理，需要对故障管理的整个流程进行跟踪，并做相应的处理记录。
故障监视
在信息系统运行过程中，不可避免会出现一些由于系统自身问题，或者是任何不符合标准的操作规程，已经发生或者可能发生的系统运行中止和服务质量下降的事件，这就是故障。
故障监视是故障管理流程的第一项基础活动，大多数故障都是在故障监视活动中发现的。
故障调查
故障调查就是收集故障信息、确定故障位置和调查故障原因的过程。
根据实践经验的总结和有关统计数据，导致信息系统故障的原因大致可以分为以下7类:
- (1)按计划进行硬件、操作系统维护操作时引起的故障，例如，扩充硬盘和进行操作系统升级等。
- (2)应用性故障，例如，应用软件的性能问题、缺陷和系统应用变更等。
- (3)人为操作故障，例如，人员的误操作和不按规定的非标准操作引起的故障等。
- (4)系统软件故障，例如，操作系统崩溃和数据库的各类故障等。
- (5)系统硬件故障，例如，硬盘、网卡、路由器等设备的损坏。
- (6)相关设备故障，例如，停电时UPS失效导致服务中断等。
- (7)灾难和灾害，例如，火灾、地震、洪水和战争等。
故障排查和恢复处理
硬件设备故障的恢复
主机故障需要启用系统备份进行恢复，对于比较重要的系统，一般采用冗余的结构，如主备或双活，抑或以资源池方式提供保护。当系统出现故障时，就用一个备用的模块或另外处于同等功能的主机，或资源池里的其他主机来顶替它并重新运行。
数据库故障的恢复
数据库故障主要分为事务故障、系统故障和介质故障，不同故障的恢复方法也不同。当系统运行过程中发生故障，利用数据库后备副本和日志文件就可以将数据库恢复到故障前的某一致性状态。
应用软件故障的恢复
信息系统中的应用软件由于设计不当，或者程序代码有误，都会造成系统故障。对于软件类故障的处理方法，通常是通过软件调试，找出错误的代码，然后进行修改和测试。为了提高系统的可靠性，也可以采取软件容错技术。
故障收尾
解决故障和恢复服务后，就到了故障收尾阶段。该阶段主要是基于上一阶段更新后的故障记录和已解决的故障，与用户一起确认故障是否被成功解决，并更新故障信息和故障记录。
软件系统维护
软件维护概述
在系统交付使用后，改变系统的任何工作都可以被称为维护。与硬件不同，软件系统在构建时就包含了变化，软件并不会老化或需要周期性的维护。
软件维护是指在软件交付使用之后，直至软件被淘汰的整个时期内，为了改正错误或满足新的需求而修改软件的活动。
软件维护的影响因素
软件维护阶段占整个软件生命周期60%以上的时间，因此，分析影响软件维护的因素，提高软件可维护性就显得十分重要。
软件维护的影响因素很多，主要有以下几个方面:
- (1)业务因素。因为系统在线运行，某些系统要保证7X24h运行，维护人员必须寻找一种途径，在不影响用户业务的情况下实现改动。
- (2)理解的局限性。统计数据显示，50%左右的软件维护工作量花在理解要修改的软件上。有时用户的理解也会出现问题，约有超过半数的维护问题源自用户技能或理解的缺乏。同时，维护人员也要具备一些人际技巧，努力理解不同用户的思维方式，以说服的方式处理掉一些问题。
- (3)对待维护的优先级问题。有时开发商会倾向于维持现有系统的运行，而客户更迫切地需要新功能，甚至一个新系统。
- (4)维护人员的积极性。通常，维护人员被认为是第二阶层，程序员大都认为设计和开发比维护工作更具技巧性和挑战性。
- (5)测试的困难。测试人员很难预测设计或代码改动带来的影响，使得测试很难做到充分。另外，有些系统只能在测试环境或备份系统中进行测试，上线后则不允许测试，由于无法精确地再现真实环境，也使得测试有一定的局限性。
软件维护管理
软件维护工作流程
如图所示。 
系统评价
信息系统建设
按照信息系统工程监理相关规定，对信息系统工程进行监理时，需要依法设立且具备相应资质的信息系统工程监理单位，其受业主单位委托，并依据国家有关法律法规、技术标准和信息系统工程监理合同，对信息系统工程项目实施监督管理。
信息系统评价
系统评价是对系统运行一段时间后的技术性能和经济效益等方面的评价，是对信息系统审计工作的延伸。
评价的目的是检查系统是否达到了预期的目标，技术性能是否达到了设计的要求，系统的各种资源是否得到充分利用，经济效益是否理想，并指出系统的长处与不足，为以后系统的改进和扩展提供依据。
遗留系统处置
遗留系统(Legacy System)是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统，它通常具有以下特点:
- (1)遗留系统虽然完成企业中许多重要的业务管理工作，但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。
- (2)遗留系统在性能上已经落后，采用的技术已经过时。例如，多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。
- (3)通常是大型的软件系统，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难。
- (4)没有使用现代信息系统建设方法进行管理和开发，现在基本上已经没有文档，很难理解。
在企业信息系统升级改造过程中，如何处理和利用遗留系统，成为新系统建设的重要组成部分。处理恰当与否，直接关系到新系统的成败和开发效率。
新旧系统转换
当新系统开发完毕投入运行，要取代现有系统时，就要进行系统转换。
系统转换是指运用某种方式，由现有系统的工作方式向新系统工作方式的转换过程，也是系统设备、数据、人员等的转换过程。在系统转换时，必须协调新旧系统之间的关系，否则将造成紊乱与中断，从而导致一定的经济损失。
在系统转换过程中，需要考虑多个方面的问题，包括成本、风险、应急措施和人员的培训等。
在系统转换与交接之前，需要做好一些准备工作，包括数据准备、系统文档准备、人员培训和设备安装，以及系统试运行。
系统试运行是指在系统没有正式转换之前所进行的试验运行，它是系统调试工作的延续。系统试运行时要输入各种真实数据，记录系统运行状况和产生的数据，比较现有系统与新系统输出的结果，同时对新系统的操作方式进行考查，测试系统运行、响应速度等性能指标。
新旧系统的转换策略
在实施新旧系统转换时，转换的策略通常有三种。如图所示
直接转换策略
直接转换就是在原有系统停止运行的某一时刻，新系统立即投入运行，中间没有过渡阶段。
采用这种方式时，人力和费用最省，适用于新系统不太复杂或现有系统完全不能使用的场合，但是，新系统在转换之前必须经过详细而严格的测试，转换时应做好准备，万一新系统不能达到预期目的时，必须采取相应措施。直接转换的新系统是完全重构的系统，可能采用了全新的技术平台和软件来构建，或者用户业务和使用方式发生了剧烈变化，对原有系统只能进行淘汰处理。
采用这种策略的优点是新系统能够非常灵活地适应业务需要，功能齐全、结构合理、系统稳定、扩展性强，整个信息系统的利用率比较高。
采用这种策略也存在着一些问题，列举如下:
- (1)新旧系统之间的转换代价比较大。
- (2)由于需要一套比较完整的业务需求，开发新系统的周期比较长，一次性投资巨大，未经广泛使用并证明是成熟可靠的新技术平台通常具有一定的技术风险。
- (3)旧系统通常积累下了大量的业务数据，必须将业务数据的录入、转换、检查以及在新系统中的重建作为重要的工作进行考虑，尽量减小在新旧系统转换的时候对用户现有业务的冲击。
- (4)需要考虑诸如维持新系统运行的日常开销，由于使用习惯改变带来的学习时间、培训人员的成本等因素。
并行转换策略
并行转换就是新系统和现有系统并行工作一段时间，经过这段时间的试运行后，再用新系统正式替换现有系统。在并行工作期间，手工处理和计算机处理系统并存，一旦新系统有问题就可以暂时停止而不会影响现有系统的正常工作。
在并行转换的实施过程中，首先以现有系统的作业为正式作业，新系统的处理结果作为校核之用，经过一段时间的运行，在验证新系统处理准确可靠后，现有系统退出运行。根据系统的复杂程度和规模大小不同，并行运行的时间一般可在两三个月到一年之间。
采用并行转换的风险较小，在转换期间还可同时比较新旧两个系统的性能，并让系统操作员和其他有关人员得到全面培训。
因此，对于一些较大的信息系统，或处理过程复杂、数据重要的系统，并行转换是一种最常用的转换方式。但是，由于在并行运行期间，要两套班子或两种处理方式同时并存，人力和费用消耗较大，转换的周期长，并且难以控制新旧系统中的数据变化。这就要求做好转换计划并加强管理，在新旧系统验证吻合后要及时停止现有系统的运行。
分段转换策略
分段转换策略也称为逐步转换策略，这种转换方式是直接转换方式和并行转换方式的结合，采取分期分批逐步转换。
一般比较大的系统采用这种转换方式较为适宜，它能保证平稳运行，费用也不太高;或者现有系统比较稳定，能够适应自身业务发展需要，或新旧系统转换风险很大(例如，在线订票系统、银行的中间业务系统等)，也可以采用分段转换策略。
采用分段转换时，各子系统的转换次序及转换的具体步骤，均应根据具体情况灵活考虑。通常可采用如下策略:
- (1)按功能分阶段逐步转换。首先确定新系统中的一个主要的业务功能率先投入使用，在该功能运行正常后再逐步增加其他功能。
- (2)按部门分阶段逐步转换。先选择系统中的一个合适的部门，在该部门运行新系统，获得成功后再逐步扩大到其他部门。这个首先运行新系统的部门可以是业务量较少的，这样比较安全可靠;也可以是业务最繁忙的，这样见效大，但风险也大。
- (3)按机器设备分阶段逐步转换。先从简单的设备开始转换，再推广到整个系统。
分段转换策略的优点是，新旧系统的转换震动比较小，用户容易接受。但由于是采用渐进方式，导致新旧系统的转换周期过长，同时由于需求的变化，给新系统的稳定造成比较大的影响。而且，分段转换策略对系统的设计和实现都有一定的要求，在转换过程中，需要开发新旧系统之间的接口，还需要制订阶段性的转换目标和计划。
数据转换和迁移
数据转换和迁移是新旧系统转换交接的主要工作之一。为使数据能平滑迁移到新系统中，在新系统设计阶段就要尽量保留现有系统中合理的数据结构，这样才能尽可能降低数据迁移的工作量和转换难度。
但是，由于新系统的引入，数据迁移工作是个必然的过程，现有系统中的数据可以通过定制开发的转换工具软件翻译为新系统可以接受的数据格式。
数据转换和迁移工作的原则是数据不丢失。许多无法自动转换的数据，必要时通过手工方式补录进入新系统。数据迁移对系统切换乃至新系统的运行有着十分重要的意义。数据迁移的质量是新系统成功上线的重要前提，同时也是新系统今后稳定运行的有力保障。
如果数据迁移失败，新系统将不能正常启用;如果数据迁移的质量较差，没能屏蔽全部的垃圾数据，对新系统将会造成很大的隐患，新系统一旦访问这些垃圾数据，可能会由这些垃圾数据产生新的错误数据，严重时还会导致系统异常。相反，成功的数据迁移可以有效地保障新系统的顺利运行，而且能够继承珍贵的历史数据。
数据迁移的方法
数据迁移的主要方法大致有三种，分别是系统切换前通过工具迁移、系统切换前采用手工录入和系统切换后通过新系统生成。
系统切换前通过工具迁移
系统切换前通过工具迁移。在系统切换前，利用ETL工具把现有系统中的历史数据抽取、转换，并装载到新系统中去。这种方法是数据迁移最主要，也是最快捷的方法。其实施的前提是，历史数据可用并且能够映射到新系统中。
这种迁移方式既可一次实现，也可以分次实现。一次迁移的优点是迁移实施的过程短，相对分次迁移，迁移时涉及的问题少，风险相对比较低。其缺点是工作强度比较大，由于实施迁移的人员需要一直监控迁移的过程，如果迁移所需的时间比较长，工作人员会很疲劳。一次迁移的前提是新旧系统数据库差异不大，在允许的宕机时间内可以完成所有数据量的迁移;分次迁移可以将任务分开，有效地解决了数据量大和宕机时间短之间的矛盾。但是分次切换导致数据多次合并，增加了出错的概率，同时为了保持整体数据的一致性，分次迁移时需要对先切换的数据进行同步，增加了迁移的复杂度。
系统切换前采用手工录入
系统切换前采用手工录入。在系统切换前，组织相关人员把需要的数据手工录入到新系统中。这种方法消耗的人力、物力比较大，同时出错率也比较高。这种方法主要针对新旧系统数据结构存在特定差异的情况，即对于新系统启用时必需的期初数据，无法从现有的历史数据中得到。对于这部分期初数据，就可以在系统切换前通过手工录入。
系统切换后通过新系统生成
系统切换后通过新系统生成。在系统切换后，通过新系统的相关功能，或为此专门开发的配套程序生成所需要的数据。通常根据已经迁移到新系统中的原始数据来生成所需要的结果数据。这种方法可以减少迁移的数据量。
数据迁移前的准备工作
数据迁移的实施可以分为三个阶段，分别是数据迁移前的准备、数据转换与迁移和数据迁移后的校验。由于数据迁移的特点，大量的工作都需要在准备阶段完成，充分而周到的准备工作是完成数据迁移的主要基础。
具体而言，要做好以下7个方面的工作:
- (1)待迁移数据源的详细说明，包括数据的存放方式、数据量和数据的时间跨度。
- (2)建立新旧系统数据库的数据字典，对现有系统的历史数据进行质量分析，以及新旧系统数据结构的差异分析。
- (3)新旧系统代码数据的差异分析。
- (4)建立新旧系统数据库表的映射关系，以及对无法映射字段的处理方法。
- (5)开发或购买、部署ETL工具。
- (6)编写数据转换的测试计划和校验程序。
- (7)制定数据转换的应急措施。
数据转换与迁移
数据转换与迁移程序大致可以分为抽取、转换与装载三个过程。
- 数据抽取、转换是根据新旧系统数据库的映射关系进行的，转换步骤一般还要包含数据清洗的过程。
- 数据清洗主要是针对源数据库中，对出现二义性、重复、不完整、违反业务或逻辑规则等问题的数据进行相应的清洗操作。在清洗之前需要进行数据质量分析，以找出存在问题的数据。
- 数据装载是通过装载工具或自行编写的SQL程序将抽取、转换后的结果数据加载到目标数据库中。
数据迁移后的校验
在数据迁移完成后，需要对迁移后的数据进行校验。数据迁移后的校验是对迁移质量的检查，同时数据校验的结果也是判断新系统能否正式启用的重要依据。
可以通过以下两种方式对迁移后的数据进行校验:
- (1)对迁移后的数据进行质量分析:可以通过数据质量检查工具，或编写有针对性的检查程序进行。
- (2)新旧系统查询数据对比检查:通过新旧系统各自的查询工具，对相同指标的数据进行查询，并比较最终的查询结果。先将新系统的数据恢复到现有系统迁移前一天的状态，然后将最后一天发生在现有系统上的业务全部补充到新系统，检查有无异常，并和现有系统比较最终产生的结果。
现有系统演进
系统扩展
系统的可扩展性是指将新的功能添加到系统中的能力。可扩展性可以分为动态可扩展性和静态可扩展性。
- 动态可扩展性是指在系统运行的过程中，能够添加新的功能，而不会影响系统的其他部分;
- 静态可扩展性是指在添加新的功能时，系统必须停止运行，当新功能添加之后，系统再重新启动。
一般地，当客户提出需求变更或增加新的功能时，通常采用的方法首先就是对现有系统进行扩展，以满足这种变化。
扩展与集成的比较
系统扩展和集成分别属于深度维护和广度维护活动，和开发过程类似，通常也需要经过需求分析、设计、编码、测试和实施的各环节来共同保证系统扩展和集成活动的最终成效。因此，需要分析人员、设计人员、编码人员、测试人员和实施人员参与其中，同时，也需要过程管理人员进行项目管理。