《系统分析师教程（第2版）》笔记——第 15 章 系统运行与维护

第 15 章 系统运行与维护【版权声明与学习说明】本文系笔者学习《系统分析师教程第2版》第15章后结合个人理解整理的原创学习笔记。文中所有表格、通俗化举例及箭头式总结均为本人消化后重新归纳表述不代表原书官方立场。整理初衷仅为交流学习、备考记录无意侵犯原作者版权。若您认为存在不当引用请通过CSDN私信联系我会第一时间处理。推荐备考的朋友购买正版教材尊重知识成果。系统交付使用后就进入了运行与维护阶段这一阶段占整个系统生命周期的 60%〜80%是保障系统长期稳定服务的核心环节。本章围绕系统运行的量化指标、日常管理、故障处理、软件维护、系统评价、遗留系统处置、新旧系统转换展开核心目标是通过科学的运维手段减少故障影响、满足新需求、延长系统生命周期确保系统持续为业务和管理提供支持。作为系统分析师需掌握运维的原理、方法和技术为系统稳定运行提供有力支撑。15.1 运维技术指标运维技术指标是量化系统运行状态和运维能力的核心依据通过这些指标可直观评估系统可靠性、故障恢复效率等关键维度。15.1.1 核心运维指标可量化、易计算平均故障修复时间MTTR定义系统从故障宕机到恢复正常运行的平均时间衡量运维团队的故障修复效率计算公式MTTR 给定时间段内故障修复总时间 / 维修次数示例某周期内系统出现 6 次故障总修复时间 120 分钟则 MTTR20 分钟 / 次意味着平均每次故障 20 分钟可修复目标MTTR 越小修复效率越高。平均故障间隔时间MTBF定义系统两次故障之间的平均运行时间衡量系统的可靠性计算公式MTBF 多次故障间系统总运行时间 / 故障总数示例某周期内系统累计运行 1000 小时发生 2 次故障则 MTBF500 小时 / 次即平均每 500 小时发生 1 次故障说明仅统计意外故障不包含计划内维护导致的停机MTBF 越大系统越可靠。平均无故障时间MTTF定义可更换 / 不可修理的系统 / 部件从正常运行到出现故障的平均持续时间常用于衡量硬件寿命计算公式MTTF 给定周期内系统正常运行总时间 / 故障次数示例系统持续运行 100 小时发生 5 次故障则 MTTF20 小时意味着平均每 20 小时需处理一次业务中断或更换部件。平均应答时间MTTA定义运维团队从收到故障告警到确认告警的平均时间衡量运维团队的响应速度计算公式MTTA 给定周期内告警触发到确认的总时间 / 告警次数示例5 次告警的确认时间分别为 6、7、9、5、8 分钟则 MTTA7 分钟 / 次目标是通过优化流程缩短 MTTA提升用户满意度。15.1.2 指标核心价值MTBF 反映系统 “抗故障能力”MTTR 反映运维 “修复能力”MTTF 反映硬件 / 不可修系统的 “使用寿命”MTTA 反映运维 “响应能力”四项指标共同构成运维能力的量化评估体系指导运维优化方向。15.2 系统运行管理系统运行管理的核心是对系统资源用户、网络、软件进行常态化管控记录运行状态确保系统高效、安全运行。15.2.1 系统用户管理用户管理聚焦身份认证和权限控制防范内部安全风险统一用户管理的好处用户使用方便同一用户名密码登录所有授权系统安全控制加强集中管控访问范围和权限可审计用户行为减轻管理负担集中管理用户信息减少人为失误。身份认证方法用户名 / 密码最简单常用但安全性低密码易被猜测或截取IC 卡认证硬件不可复制但读取的静态数据易被监听存在安全隐患动态密码通过专用硬件动态令牌生成一次性密码安全性高但需保持客户端与服务器同步USB Key 认证软硬件结合的双因子认证内置芯片存储密码 / 数字证书安全性与易用性平衡。用户安全审计审计内容用户访问资源的规律、不寻常时段登录记录、多次登录失败记录核心目的发现异常操作防范身份盗用导致的数据泄露或损坏。15.2.2 网络资源管理网络资源是 IT 基础设施核心管理目标是确保网络正常、高效运行核心功能网络管理五大功能性能管理监测网络活动优化资源使用确保低延迟、高可靠连接故障管理检测、定位、排除软硬件故障记录故障信息配置管理掌握网络设备状态和连接关系用逻辑图 物理布局映射呈现计费管理记录用户 / 应用对网络资源的使用情况计算运行成本安全管理控制网络资源访问验证用户权限检测未授权操作。网络资源管理系统核心功能基于地图查询 / 统计网络资源、管理物理路由图和逻辑拓扑图、关联设备展开图 / 端子图、配置光 / 电路路由、数据备份与恢复。15.2.3 软件资源管理软件资源包括运行的软件和相关文档管理核心是复用、分发和维护软件构件管理构件是可独立配置、可复用的单元通过构件库管理需依赖软件平台运行支撑环境、开发组装环境等支持。软件分发管理自动化完成软件部署全流程打包、安装、配置、回滚核心任务软件部署分发至目标计算机、安全补丁分发识别并推送系统 / 安全升级、远程管理和控制远程诊断、解决故障。文档管理软件文档是固定格式的记录数据贯穿软件生命周期需持续生成、修改和补充是维护和复用的重要依据。15.3 系统故障管理故障管理的目标是最快恢复系统运行减少故障对业务的影响核心流程包括故障监视、调查、排查恢复和收尾。15.3.1 故障监视故障监视是故障管理的基础核心是 “尽早发现异常”设置待监视项目重点监视影响范围大、紧迫性高的故障类别投入相应人力和工具监视对象包括故障接触人员操作员、开发工程师、用户等需制定其操作规范和报告流程。监视内容和方法核心监视对象人员行为跟踪、操作规范性非标准操作、系统硬件服务器、存储、路由器等用监控工具自动监测、系统软件应用性能、缺陷、变更需求自然灾害应对通过风险分析和容灾措施防范不纳入常规监视。15.3.2 故障调查故障调查的核心是 “明确故障信息、位置和原因”收集故障信息自动收集通过系统监控工具、日志等人工收集用户反馈、IT 部门巡检发现关键动作必要时故障隔离保留现场信息。确定故障位置硬件故障通过诊断测试、脱机 / 联机检测、专用命令定位软件 / 数据故障通过软件调试定位错误代码行相对复杂。调查故障原因故障记录每个故障分配唯一编号记录时间、症状、位置、影响服务等信息常见原因7 类计划内维护操作如扩充硬盘、系统升级应用性故障软件性能、缺陷、应用变更人为操作故障误操作、非标准操作系统软件故障操作系统崩溃、数据库故障系统硬件故障硬盘、网卡、路由器损坏相关设备故障如 UPS 失效灾难和灾害火灾、地震、洪水等。15.3.3 故障排查和恢复处理核心是 “快速恢复服务”按故障类型针对性处理硬件设备故障恢复主机故障启用备份主备、双活、资源池顶替线路 / 网络故障切换备用电路或通信路径其他设备故障分析原因联系供应商维修、调换。数据库故障恢复故障类型事务故障、系统故障、介质故障恢复方法利用数据库后备副本和日志文件恢复到故障前一致状态。应用软件故障恢复处理方式软件调试定位错误代码→修改→测试优化手段采用软件容错技术提高可靠性。15.3.4 故障收尾核心动作与用户确认故障已解决更新故障信息和记录形成闭环。15.4 软件系统维护软件维护是系统运行期的核心工作指交付后为改正错误、满足新需求而修改软件的活动难度高、占比大。15.4.1 软件维护概述软件维护性GB/T 25000.10-2016定义产品 / 系统被维护人员修改的有效性和效率包括纠正、改进、适应环境 / 需求变化6 个子特性模块化组件变更影响最小、可重用性多系统复用、易分析性评估变更影响、诊断缺陷、易修改性高效修改且不引入新缺陷、易测试性建立测试准则并验证、维护性的依从性遵循标准 / 法规。可维护性度量外部度量用 MTTR平均故障修复时间衡量需记录分析、设计、编码、测试等全流程时间内部度量通过软件复杂性间接衡量包括环路数McCabe 环路反映代码结构复杂度、软件规模构件越多越复杂、嵌套深度、用户数等。软件维护的分类改正性维护识别并纠正软件错误、性能缺陷确保正常使用适应性维护软件适应外部环境变化新软硬件配置、数据格式变更完善性维护满足用户新的功能 / 性能需求扩充功能、增强性能、提高可维护性预防性维护预先提高软件可维护性、可靠性为未来改进打基础用先进方法重构旧系统。15.4.2 软件维护的影响因素业务因素核心系统需 7×24h 运行维护需不影响业务理解的局限性50% 维护工作量花在理解待修改软件上用户理解不足也会引发问题维护优先级开发商可能倾向维持现有系统而非新增功能维护人员积极性维护工作易被视为 “次级工作”影响积极性测试的困难难以预测改动影响部分系统上线后不允许测试难以还原真实环境。15.4.3 提高软件可维护性的方法采用软件工程方法规范开发流程生成完整文档为维护提供依据注重可维护性的开发过程需求分析明确可修改、可移植的需求设计阶段遵循 “高内聚、低耦合”采用灵活可扩充方案加大可复用构件设计编码阶段遵守代码规范强化注释质量测试阶段减少维护工作量尤其是改正性维护完善测试文档支撑回归测试维护阶段严格配置管理更新系统 / 用户文档做好用户培训。15.4.4 软件维护管理软件维护组织核心模式大型企业设专业维护部门中小企业明确非正式责任临时组建维护小组关键角色维护管理员、系统管理员、维护配置员。维护流程核心步骤用户提交维护申请→维护要求评价→管理部门审批→制订维护计划→执行维护→测试→用户及管理部门审核→更新系统文档→交付使用特殊情况核心系统突发恶性故障如数据库崩溃按 “救火队” 模式快速响应事后补全流程。保存维护记录核心内容源代码行数、开发语言、安装日期、运行次数、失效次数、改动标识、改动耗时、维护类型、维护起止日期、效益等核心作用评估维护技术有效性、确定维护代价为后续评价提供依据。评价维护活动量化指标每次程序运行平均失效次数、各类维护的总人・时数、每种维护类型的程序变动数、改动源代码的平均耗时、旧维护引发的新需求比例等核心价值优化维护工作量规划针对性开展技术培训。15.5 系统评价系统评价是对运行一段时间后的系统进行技术性能、经济效益评估是审计工作的延伸核心是判断系统是否达预期目标。15.5.1 信息系统建设的核心问题核心矛盾建设方与承建方信息不对称承建方技术优势明显可能过度承诺或推销无用功能建设方需求模糊易引发纠纷解决方案引入第三方监理机制规范项目实施保障进度和质量。15.5.2 信息系统评价评价流程步骤确定评价对象→下达通知书→成立工作组 / 专家组→拟定方案→收集资料→实施评价→征求专家意见→撰写报告→复核→送达报告→公布结果→建立档案特殊环节企业自测自愿预备性质评价工作组需对比自测结论补充修改。评价指标核心维度系统性能评价可靠性、系统效率、可维护性、可扩充性、可移植性、实用性、适应性、安全保密性系统效益评价经济效益投资额、运行维护费、收益、投资回收期、社会效益间接效益系统建设评价贯穿生命周期各阶段的阶段评审指标设计方式效率驱动业务支撑效果、能力驱动运行保障能力、效果驱动整体运行效果、效益驱动用户满意度指标类型静态 / 动态、定量 / 定性、原生 / 衍生、相关性 / 因果性、先见性 / 后见性权重设计方法主观赋权法专家调查法、层次分析法、环比评分法体现主观意图客观赋权法主成分分析法、熵值法、变异系数法基于数据规律组合赋权法结合主观与客观。系统改进建议核心产出评价报告正文 附录正文含评价概述、指标对比、结论、依据、方法附录含基础文件和数据核心要求客观公正维护商业秘密反映系统实际状况和后续发展能力。15.6 遗留系统处置遗留系统是指难以修改和演化以满足新业务需求的系统处置核心是 “保护既有投资满足当前需求”。15.6.1 遗留系统的特点能完成重要业务但难以满足新需求少涉及经营决策技术过时如单机系统、旧开发语言未采用现代建设方法大型系统融入企业业务和决策机制替换困难。15.6.2 遗留系统的评价评价目的是全面理解系统为处置策略提供依据核心评价维度业务价值评价判断系统对企业的重要性概要评价 详细评价外部环境评价硬件供应商、失效率、使用年限、支撑软件操作系统、数据库等依赖性、企业 IT 基础设施应用软件评价系统级整体技术水平、部件级复杂性、数据、文档。评价结果分析四象限策略低水平 低价值淘汰技术落后且业务价值低直接淘汰借鉴其功能设计新系统低水平 高价值继承业务依赖度高但技术落后新系统需兼容其功能 / 数据模型新旧系统并行后切换高水平 高价值改造技术和业务价值均高仅需增强功能或改造数据模型高水平 低价值集成技术先进但业务价值低局部部门使用需集成多个此类系统打破信息孤岛。15.7 新旧系统转换新旧系统转换是由现有系统向新系统过渡的过程核心是 “平稳切换数据安全”。15.7.1 新旧系统的转换策略直接转换策略核心逻辑原有系统停止运行的同时新系统立即上线无过渡阶段优点人力和费用最省缺点风险高新系统需经严格测试适用场景新系统不复杂或现有系统完全不能使用。并行转换策略核心逻辑新旧系统并行运行一段时间2-3 个月至 1 年验证新系统可靠后旧系统退出优点风险低可对比性能、培训人员缺点人力和费用消耗大周期长需控制数据变化适用场景大型系统、处理复杂、数据重要的系统。分段转换策略逐步转换核心逻辑结合直接和并行转换分期分批切换按功能、部门、设备优点转换震动小用户易接受费用适中缺点周期长需开发新旧系统接口需求变化可能影响稳定性适用场景大型系统、转换风险高的系统如在线订票、银行中间业务系统。15.7.2 数据转换和迁移数据迁移是转换的核心目标是 “数据不丢失、格式适配、准确可靠”。数据迁移的方法工具迁移主流切换前用 ETL 工具抽取、转换、装载旧系统历史数据可一次或分次迁移手工录入适用于新旧系统数据结构差异大无法自动转换的期初数据新系统生成切换后通过新系统功能或配套程序基于迁移的原始数据生成结果数据。数据迁移前的准备工作核心步骤明确迁移范围和目标→建立新旧系统数据字典→分析数据质量和结构差异→建立表映射关系→开发 / 部署 ETL 工具→编写测试和校验程序→制定应急措施。数据转换与迁移过程核心环节抽取建立抽取函数优化 SQL通过调度程序抽取数据转换与清洗清洗垃圾数据二义性、重复、不完整转换代码数据适配新系统编码规则装载将处理后的数据加载到新系统数据库。数据迁移后的校验校验维度数据完整性、一致性、总分平衡、特殊样本数据校验方法数据质量检查工具→新旧系统查询结果对比→补充迁移期间的业务数据。15.7.3 系统扩展核心定义可扩展性是添加新功能的能力分为动态运行中添加不影响其他部分和静态需停止系统后添加扩展方法减少构件耦合架构预留扩展点引入第三方软件包二次开发如手写签批控件扩展与集成的区别扩展深度维护重点在设计阶段需细致回归测试避免影响原有系统集成广度维护重点在分析阶段需协调业务关联点重视接口和全流程测试。