|
|
知识路径： > 信息系统运维的组织与管理 > 信息系统运维的管理 > 信息系统运维管理主要流程 >
|
被考次数：7次
被考频率：中频率
总体答错率：66%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：7个
|
|
|
|
|
作为信息系统服务的一种管理方式，当前大部分信息系统运维管理是基于流程框架展开的。这里的流程是指信息系统运维管理的各种业务过程，运维管理流程将达到以下目标。
|
|
|
|
|
|
（2）流程化：将大部分运维工作流程化，确保工作可重复，并且这些工作都能有质量地完成，提升运维工作效率。
|
|
|
|
（3）自动化：基于流程框架将事件与运维管理流程相关联，一旦被监控的系统发生性能超标或宕机，会触发相关事件及事先定义好的流程，可自动启动故障响应和恢复机制；此外，还可以通过自动化手段（工具）有效完成日常工作，如逻辑网络拓扑图、监控、硬件备份等。
|
|
|
|
信息系统运维管理流程主要包括事件管理、事故管理、问题管理、配置管理、变更管理、发布管理和知识管理等，如下图所示。
|
|
|
|
|
|
|
|
|
|
事件管理负责记录、快速处理信息系统运维管理中的突发事件，并对事件进行分类分级，详细记录事件处理的全过程，便于跟踪了解事件的整个处理过程，并对事件处理结果统计分析。事件是指引起或有可能引起服务中断或服务质量下降的不符合标准操作的活动，不仅包括软硬件故障，而且包括服务请求，如状态查询、重置口令、数据库导出等，因此又叫事故／服务请求管理。
|
|
|
|
事件管理流程的主要目标是尽快恢复信息系统正常服务并减少对信息系统的不利影响，尽可能保证最好的质量和可用性，同时记录事件并为其他流程提供支持。事件管理流程通常涉及事件的侦测记录、事件的分类和支持、事件的调查和诊断、事件恢复及事件的关闭。事件管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）事件发生和通告。事件发生后，配置项以轮询和通知两种方式产生通告信息，其中轮询是通过管理工具的询问，配置项被动地提供相关信息；而通知是为特定状态满足后，配置项主动产生通告。
|
|
|
|
（2）事件检测和录入。事件发生后，管理工具通过两种方法对其进行检测，第一种是通过运行在同一系统之上的代理，检测和解析通告信息，并将其发送给管理工具；第二种是管理工具直接读取和解析通告信息的含义。
|
|
|
|
（3）事件过滤。当检测到事件后，应当对其进行过滤。过滤的目的是确定哪些事件应被通过，哪些事件可以被忽略。例如，连续产生的一系列相同事件通告，只通过第一个到达的通告，其余则可忽略。对于过滤掉的事件应当及时记录到日志文件中。
|
|
|
|
（4）事件分类。根据事件的重要性，将事件分为信息类、告警类和异常类。信息类事件通常存入日志文件中；告警类事件需要提交给事件关联做进一步分析，以决定如何处理；异常类事件需判定是否需要提交给事故、问题或变更管理中的一个或多个管理流程来处理。
|
|
|
|
（5）事件关联。事件关联是指通过特定的管理工具将告警类事件与一组事先规定的标准和规则进行比较，从而识别事件的意义并确定相应的事件处理行动。这些标准和规则通常被称为业务准则，说明了事件对业务的影响度、优先级、类别等信息。
|
|
|
|
（6）响应选择。根据事件关联的结果，可以选择自动响应，报警和人为干预，事故、问题或变更判定等方式处理告警类事件。如果告警类事件及其处理方法已被充分识别和认识，则可以为其定义合适的自动响应方式。如果告警类事件处理需要人为干预，则应该发出报警信息通知相关人员或团队。如果告警类事件处理需要通过事故、问题或变更管理的一个或多个流程完成，则需要启动相应的流程。当初始事件被判定为异常，或是在事件关联中管理工具将一类或一组告警类事件的发生定义为事故时，则应当启动事故管理；在故障尚未发生时，通过对事件进行完备成熟的评估和分析得出问题存在，则直接启动问题管理；当事件被判定为异常时，组织可能依据自身的事故管理和变更管理的策略确定启动哪个流程。
|
|
|
|
（7）事件关闭。不同类型的事件有不同的关闭形式。信息类事件通常不存在关闭状态，它们会被录入到日志中并作为其他流程的输入，直到日志记录被删除；自动响应的告警类事件通常会被设备或应用程序所自动触发的另一事件关闭；人为干预的告警类事件通常在合适的人员或团队处理完毕评估后关闭；异常类事件通常在成功启动事故、问题或变更管理流程后评估关闭。
|
|
|
|
（8）事件评估。因为事件发生频率非常高，不可能对每件事件都进行正式的评估活动。如果事件触发了事故、问题或变更管理，评估重点应当关注事件是否被正确移交，并且是否得到了所期待的处理；对于其他事件，则进行抽样评估。
|
|
|
|
|
|
事故管理包括对引起服务中断或可能导致服务中断、质量下降的事件的管理，这包括了用户提交或由监控工具提交的事故。事故管理不包括与中断无关的正常运营指标或服务请求信息。事故管理的主要目标是尽快恢复正常的服务运营，并将对业务的影响降到最低，从而尽可能保证服务质量和可用性要求。
|
|
|
|
事故管理的流程包括事故识别和记录、事故分类和优先级处理、初步支持、事故升级、调查和诊断、解决和恢复、事故关闭等。事故管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）事故识别和记录。通过对所有组件的监控，及时准确地检测出故障或潜在故障，尽可能在未对客户造成影响之前启动事故管理流程。事故记录包含事故基本描述、事故状态、事故类型、事故影响度、事故优先级等信息。
|
|
|
|
（2）事故分类和优先级处理。事故的分类通常采用多层次结构，一个类别包括多个子类。分类时将事故归入某一类别或某一子类中。分类时可以按事故发生的可能原因分类，也可按相关支持小组进行分类。当同时处理若干事故时，必须设定优先级。优先级通常用数字来表示，通常根据紧急度和影响度确定。其中，紧急度指在解决故障时，对用户或业务来说可接受的耽搁时间；影响度是指其所影响的用户或业务数量和大小而言，事件偏离正常服务级别的程度。
|
|
|
|
（3）初步支持。初步支持是指服务台在与用户协商并达成解决时限后，依据自己职责和能力优先尝试解决事故。如果用户满意解决结果，则服务台关闭事故；如果无法解决事故或用户不满意，则应执行事故升级，转交给二线或三线支持处理。在初步支持过程中，可借助知识库提供帮助。
|
|
|
|
（4）事故升级。事故升级是指当前支持人员在规定的时间内不能解决或没有解决某个事故时，便转交给更有经验或更权威的其他人员处理，包括职能性升级和结构性升级两类。职能性升级又称水平升级，是指当前技术人员无法在规定时间内解决事故时，需要具有更多时间、专业技能或访问权限的技术人员参与解决事故；结构性升级又称垂直升级，是指当机构的级别不足以保证事故能及时、满意地得到解决时，需要更多的高级别机构参与进来。
|
|
|
|
（5）调查和诊断。事故在提交给指定的支持小组后，支持人员应该对事故进行调查和诊断工作。具体活动包括确定事故发生的位置及用户需要的帮助；确认事故导致的所有影响，包括影响到的用户数量和规模；识别出由此事故触发的其他事件；通过搜索当前事故／问题记录、已知错误数据库、厂商／供应商错误日志或知识库等，整合相关知识。
|
|
|
|
（6）解决和恢复。通过对事故的调查和诊断，支持人员制定相关解决方案，并在对该方案进行必要的测试之后提交实施。根据事故性质的不同，实施的行为也有所不同，通常包括指导用户在他们的桌面或远程设备上实施解决方案；服务台实施解决方案，或是远程使用软件控制用户桌面实施解决方案；专业的支持小组实施恢复方案；供应商或厂商解决方案。
|
|
|
|
|
|
问题管理包括诊断事故根本原因和确定问题解决方案所需要的活动，通过相应控制过程，确保解决方案的实施。问题管理还将维护有关问题、应急方案和解决方案的信息，以减少事故的数量和降低影响。问题管理流程的目标是通过消除引起事故的深层次根源以预防问题和事故的再次发生，并将未能解决的事故影响降到最低。
|
|
|
|
问题管理的流程包括问题检测和记录、问题分类和优先级处理、问题调查和诊断、创建已知错误记录、解决问题、关闭问题、重大问题评估等。问题管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）问题检测和记录。问题检测的方法包括：服务台和事故管理等提交的事故需要进一步查明潜在原因；技术支持小组在日常维护工作中发现有尚未对业务产生影响的潜在问题存在；自动化的事件／告警检测工具检测出IT基础设施或应用存在问题；供应商或承包商通告其产品或服务存在的问题；主动问题管理通过趋势分析提交潜在的问题。问题记录包含问题描述、问题状态、问题类型、服务信息和设备信息等。
|
|
|
|
（2）问题分类和优先级处理。问题的分类原则与事故管理中事故的分类相同。问题优先级处理与事故管理中事故的优先级处理方法相同。
|
|
|
|
（3）问题调查和诊断。问题调查的技术包括借助于配置管理数据库定义问题的影响级别并调查故障点；问题匹配技术和故障重现技术。问题分析和诊断的常用方法包括时序分析法、KT决策法、头脑风暴法、石川图法、帕累托分析法等。
|
|
|
|
（4）创建已知错误记录。针对调查和诊断的结果及解决方案创建已知错误记录，并将其存放在已知错误库中，以方便下次发生同样问题时能够快速匹配出已知错误。
|
|
|
|
（5）解决问题。根据制定出的解决方案，问题管理者组织问题处理人员实施方案。如果解决方案需要对基础设施进行变更，则必须首先提交变更请求，启动变更管理流程。
|
|
|
|
（6）关闭问题。当变更完成并且解决方案成功实施使得问题解决之后，可正式关闭问题记录，更新已知错误库，将问题状态置成“已解决”。
|
|
|
|
（7）重大问题评估。重大问题解决之后应当召开重大问题评估会议，需探讨的问题包括工作中的经验和教训、改进方案、预防措施、第三方责任等。
|
|
|
|
|
|
配置管理包括负责识别、维护服务、系统或产品中的所有组件，以及各组件之间关系的信息，并对其发布和变更进行控制，建立关于服务、资产及基础设施的配置模型。配置管理的目标是对业务和客户的控制目标及需求提供支持：提供正确的配置信息，帮助相关人员在正确的时间做出决策，从而维持高效的服务管理流程；减少由不合适的服务或资产配置导致的质量和适应性问题；实现服务资产、IT配置、IT能力和IT资源的最优化。
|
|
|
|
配置管理的流程包括管理规划、配置识别、配置控制、状态记录和报告、确认和审核等。配置管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）管理规划。确定配置管理流程的政策、标准和战略，分析现有的信息，确定所需要的工具和资源，制定并记录一份总体计划，其内容包括配置管理的目标和范围，识别相关需求，现行适用的政策和标准，组建配置管理小组，设计配置管理数据库（Configuration Management Database，CMDB）、数据存放地点、与其他服务管理系统的接口和界面，以及其他支持工具等，实施配置管理活动的进度和程序，接口控制与关系管理，与第三方的接口控制和关系管理等。
|
|
|
|
（2）配置识别。配置识别活动是配置管理流程的基础，它确定了配置结构，定义了配置项的选择标准、命名规范、标签、属性、基线、类别及配置项之间关系等方面的内容。
|
|
|
|
（3）配置控制。配置控制活动负责对新的或变更的配置项记录进行维护，确保配置管理数据库只记录已授权和可识别的配置项，并且其配置记录与现实匹配。配置控制的政策和相关程序包括许可证控制、变更控制、版本控制、访问控制、构建控制、电子数据及信息的移植和升级、配置项在发布前制定基线、部署控制、安装控制等。
|
|
|
|
（4）状态记录和报告。配置项在其生命周期内有一个或多个离散状态，每一个状态详细信息和数据都应该被记录。记录的细节包括服务配置信息、配置项实施变更的进展及质量保证检测结果等。配置状态报告是指定期报告所有受控的配置项的当前状态及其历史变更信息。
|
|
|
|
（5）确认和审核。配置确认和审核是指通过一系列评价和审核确认有且只有授权的、注册的、正确的配置项存在于配置管理数据库中的活动，对于监测出的未授权或未注册的配置项应及时通过变更管理登记注册或将其移除。
|
|
|
|
|
|
变更管理负责管理服务生命周期过程中对配置项的变更。具体对象包括管理环境中与执行、支持及维护相关的硬件、通信设备、软件、运营系统、处理程序、角色、职责及文档记录等。变更管理流程的目标包括对客户业务需求的变化做出快速响应，同时确保价值的最大化，尽可能减少突发事件、中断或返工；对业务和IT的变更请求做出响应，使服务与业务需求相吻合。
|
|
|
|
变更管理的流程包括创建变更请求、记录和过滤变更请求、评审变更、授权变更、变更规划、协调变更实施、回顾和关闭变更等。变更管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）创建变更请求。变更请求（RFC）由变更发起人负责创建并提交给变更管理者。变更请求可能涉及所有的IT部门，任何相关的人都可以提交一项变更请求。变更发起人虽然可能初步为变更分类和设定优先级，但最终的优先级必须在变更管理中确定。
|
|
|
|
（2）记录和过滤变更请求。变更管理者负责将接收到的变更请求按一套规范的形式记录成RFC文档。具体信息包括RFC标识号、相关联的问题／错误码、变更影响的配置项、变更原因、不实施变更的后果、变更的配置项当前的和新的版本、提交该RFC的人员／部门的信息、提交RFC的时间。
|
|
|
|
（3）评审变更。在接收到变更请求后，变更管理者、变更咨询委员会成员及IT执行委员会应从财务、技术及业务三方面对其进行审核，以确立变更的风险、影响度、紧急度、成本及利益等。
|
|
|
|
（4）授权变更。不同类别的变更有不同方式的授权。标准变更通常有预定的执行流程，不需要得到变更咨询委员会（Change Advisory Board，CAB）和变更管理者的授权，而直接转交“请求实现”处理；次要变更无须提交CAB而直接由变更管理者批准实施；针对实质性变更，变更管理者根据变更风险、紧急度和影响度来决定是否事先征求CAB成员的意见或召开CAB会议；重大变更必须事先得到IT执行委员会的评审，再交由CAB讨论具体实施方案。
|
|
|
|
（5）变更规划。得到变更授权后，变更咨询委员会成员应当对变更进行规划，同时制定变更进度计划表。变更规划和进度计划表的制定及发布是一个动态和持续的过程。此外，根据组织的变更策略，如果需要以发布包的形式将变更部署到生产环境中去，则应启动发布管理流程实施变更。
|
|
|
|
（6）协调变更实施。在得到变更授权并完成规划后进入变更实施阶段，具体包括变更构建、测试及实施。变更管理者在整个过程中起监控和协调作用。
|
|
|
|
（7）回顾和关闭变更。变更成功实施之后，变更管理者应当组织变更管理小组和CAB的成员召开实施后的评估会议。会议上要提交变更结果及在变更过程中发生的任何事故。
|
|
|
|
|
|
发布管理负责规划、设计、构建、配置和测试硬件及软件，从而为运行环境创建发布组件的集合。发布管理的目标是交付、分发并追溯发布中的一个或多个变更。
|
|
|
|
发布管理的流程包括发布规划，发布设计、构建和配置，发布验收，试营运规划，沟通、准备和培训，发布分发和安装等。发布管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
|
|
发布规划包括协调发布内容，就发布日程安排、地点和相关部门进行协商，制定发布日程安排、沟通计划，现场考察以确定正在使用的硬件和软件，就角色和职责进行协商，获取详细的报价单，并与供应商就新硬件、软件和安装服务进行谈判协商，制定撤销计划，发布制定质量计划，由管理部门和用户共同对发布验收进行规划。
|
|
|
|
|
|
（1）设计。根据发布策略和规划，为发布进行相应的设计活动。这些活动具体包括明确发布类型，定义发布频率和定义发布方式。
|
|
|
|
（2）构建。一个发布单元可能会由多个发布组件构成，这些组件中有些可能是自主研发的，有些可能是外购的，发布团队应当整合所有发布组件，并对相关的程序进行规划和文档记录，并尽可能重复使用标准化流程。同时发布团队也需要获取发布所需的所有配置项和组件的详细信息，并对其进行必要的测试，确保构建的发布包中不包含具有潜在风险的项目。
|
|
|
|
（3）配置。需要发布的所有软件、参数、测试数据、运行中的软件和其他软件，都应处在配置管理的控制之下。在软件被构建应用之前，需要对其执行质量控制审核。有关构建结果的完整记录也要求记录到配置管理数据库（Configuration Management Database，CMDB）中，以确保在必要时按照该配置记录重复构建。
|
|
|
|
|
|
用户代表应对发布进行功能测试并由IT管理人员进行操作测试。在测试过程中，IT管理人员需要考虑技术操作、功能、运营、绩效，以及与基础设施其他部分集成等方面的问题。测试还应该涉及安装手册、撤销计划。在试运营开始之前，变更管理应安排由用户进行的正式验收及由开发人员签发的开发结束标记。发布应当在一个受控测试环境中验收，并确保该项发布可以被恢复至一个可知的配置状态。这种针对该项发布的基线状态应该在发布规划时明确，并应记录在配置管理数据库中。
|
|
|
|
|
|
试运营规划包括制定日常安排，以及有关任务和所需人力资源的清单，制定有关安装配置项、停止配置项，以及退出使用的具体方式的清单，综合考虑可行的发布时间及所在时区，为每个实施地点制定活动计划，邮寄发布备忘录及与有关方面进行沟通，制定硬件和软件的采购计划，购买、安全存储、识别和记录所有配置管理数据库中即将发布的新配置项。
|
|
|
|
|
|
通过联合培训、合作和联合参与发布验收等方式，确保负责与客户沟通的人员、运营人员和客户组织的代表都清楚发布计划的内容及该计划的影响。如果发布是分阶段进行的，则应该向用户告知计划的详细内容。
|
|
|
|
|
|
发布管理监控软件和硬件的采购、存储、运输、交付和移交的整个物流流程。硬件和软件存储设施应该确保安全，并且只有经过授权的人员才可以进入。为减少分发所需的时间，提高发布质量，推荐使用自动工具来进行软件分发和安装。在安装后，配置管理数据库中的相关信息应立即进行更新。
|
|
|
|
|
|
知识管理贯穿于整个服务管理生命周期。广义的知识管理涉及知识管理策略，知识的获取、存储、共享和创新等多个环节。本书仅规定与运维知识识别、分类、提交、过滤、审核、发布、维护等相关的流程细节。知识管理的目标是确保在整个服务管理生命周期中都能获得安全可靠的信息和数据，从而提高组织运维管理决策水平。
|
|
|
|
知识管理的流程包括知识识别和分类、初始化知识库、知识提交和入库、知识过滤和审核、知识发布和分享、知识维护和评估等。知识管理基本流程模型如下图所示。
|
|
|
|
|
|
|
|
（1）知识识别和分类。对于组织而言，知识的数量非常多且来源范围非常广。为准确地获取到对自身有价值的知识，组织必须事先对知识进行定义，以便清楚地识别哪些及哪类知识才是自己最需要的，同时也为知识分类做好准备。组织应当对知识来源进行归类，知识的来源包括内部来源和外部来源。知识所覆盖的范围非常广泛，为有效地管理知识，提高知识的使用效率，组织还应当对知识进行必要的分级和分类，以此建立知识目录。分级和分类的依据有很多，例如，按IT基础设施类别可将一级目录分为应用系统、业务操作、系统软件、网络通信、硬件设备、信息安全及其他，然后再进一步划分二、三级目录；按知识用途将一级目录分为故障解决类、经验总结类、日常操作类等；按知识的使用权限将一级目录分为公共类、私有类、涉密类等。组织应根据自身情况合理选择和建立知识目录。
|
|
|
|
（2）初始化知识库。组织应当建立知识库来存储已获取的知识，并制定相应的管理策略，对其进行维护。知识库是指用于知识管理领域的特殊数据库，它能够为知识管理提供电子化收集、存储和检索知识等功能，从而保证知识安全、可靠、长期地得到存储，同时也为组织成员分享知识提供帮助。
|
|
|
|
（3）知识提交和入库。知识提交人员可以来自组织中的任何部门。组织应当采取积极的政策和措施鼓励、帮助员工贡献出自己的知识，例如，提供Web录入、E-mail、电话通信、座谈会议及手工文档等方式。此外，组织还应制定统一的知识提交模板，以方便提交人员准确提交知识。知识库通常分为临时知识库和正式知识库。知识提交人员在提交知识时应对所提交的知识按照组织的知识目录结构进行初步的归类。所有提交的知识都应存入临时知识库，待知识审核人员进行审批。
|
|
|
|
（4）知识过滤和审核。知识管理者对临时知识库中的知识记录进行初步筛选和过滤，去除明显错误和完全无实用性的知识，之前已重复提交、已接受的或已拒绝的，以及仍处于评审状态的知识、不完善的知识。对于过滤的知识记录，知识管理者应当反馈相应的意见和理由给知识提交人员。之后知识管理者负责将临时知识库中的知识分配给相应的知识审核人员进行审批。知识审核人员应当综合考虑知识的正确性、准确性及实用性等因素，对知识进行严格的评审。对于通过审核的知识需进行进一步分类和权限设置等，最后待管理者发布；对于未通过审核的知识，应当给出相应意见和理由，而后由知识管理者负责将其反馈给知识提交人员。
|
|
|
|
（5）知识发布和分享。知识管理者将通过审核的知识转移至正式知识库并将其发布。发布后的知识可供组织内相应的人员分享。组织成员分享知识的方式有很多，通常可以借助科技手段（如网络检索、视频或语音通信、数字期刊和文档及多媒体会议等）来提高知识分享的效率。
|
|
|
|
（6）知识维护和评估。知识管理者负责对知识库进行日常维护，并定期对每条知识记录进行详细评定，具体方法包括收集来自用户对知识记录使用的反馈意见，调查和统计知识记录的利用率和解决问题的成功率，定期召开知识评估会议，召集组织内的知识审核人员及聘请各领域知识专家对知识库中的知识记录进行评估。组织应为知识制定合理而有效的评估标准（如优、良、合格、不合格等），以此对知识记录进行考核，并对不同考核结果的知识记录进行相应的处理，例如，对判定为优的知识的提供者进行奖励；对需要改进的知识进行修订；对未达到标准的知识进行删除等。
|
|
|
