|
一、资产和配置管理 资产管理是对购买价格超过一定限额的资产进行监控的一套会计核算过程，它记录了购买价格、折旧、所属业务单元和所处位置等信息。一套有效的资产管理系统，应该可以为建立配置管理系统提供基础。 资产管理流程的管理和控制目标，偏重于从公司财务视角，而非IT管理视角来对资产进行管理。固定资产管理程序包括对固定资产采购计划、采购申请、安装调试、成本计价、折旧计提、在建工程转固定资产、转固定资产验收、保管维修、维修费用资本化、拆拼和内部调拨、报废、闲置处理、对外出租出借及会计核算等各项工作的具体管理规程。 配置管理需要识别和确认系统的配置项记录和报告配置项状态和变更请求、检验配置项的正确性和完整性等活动构成的服务管理过程。 配置管理超越了资产管理，它保留了有关配置项的技术信息、配置项相互关系的详细信息，以及配置项的标准化和授权状况等方面的信息。 配置管理还监控对当前信息的反馈，如IT组件的状态、位置，以及对其实施了的变更。资产和配置管理的关键点包括： (1)配置管理的目标。好的配置管理不仅能体现单个个体的属性信息，而且能够体现IT组件之间的影响，并且为其他变更管理、事件管理和问题管理等流程提供足够的基础信息。1)提供IT基础架构的精确信息。 2)监控和维护下列信息，从而实现对基础架构的控制： ·交付服务所需要的所有资源； ·配置项（CI)的状态和历史； ·配置项的关系。 (2)固定资产管理相关流程。固定资产管理的一些需要考虑和定义的关键流程如下： ·资产采购； 资产变更； 资产盘点； 资产租入租出； 资产报废流程。
(3)资产管理相关文件。资产管理的常用文件定义如下： ·固定资产采购申请表； 固定资产采购合同； 固定资产设备签收单； 数据中心固定资产台账； 固定资产盘点清单； 闲置固定资产明细表； 固定资产出门记录； 固定资产盘点报告。
(4)配置管理数据库（CMDB)。配置管理数据库是指包括所有与配置项及其状态和相互关系有关的信息的数据库。配置管理数据库对所有组件、组件的不同版本和状态，以及组件之间的相互关系进行跟踪。在其最基本的形式下，一个CMDB可能是由一些纸质表格或一套清单组成。 (5)配置管理考虑的因素。对于配置管理广度和深度的确定，直接决定了配置管理未来的管理控制是否有效。如果广度太广，把关键资产和非关键资产全部纳入其中管理，可能会比较难于管理和控制。对于配置管理深度，如果定义太细，如一个设备配置项定义到网卡级别，则未来的管理成本也是极大的。配置管理工具的选择，如自动发现等工具，可以有效帮助配置管理工具的上线。同时，实施变更管理中，将配置项目的变化纳入其中，确保变更结束前，配置是被确认更新的，也将有效帮助配置管理的有效落地。下面是一些常见的配置管理考虑的因素： 配置管理的广度； 配置管理的深度； 配置项之间关联关系； 配置管理工具的选择； 配置管理与变更管理的绑定。
数据中心安全管理，是通过对数据中心安全管理组织、基础环境安全、信息技术安全的制定和实施，来确保数据中心的信息安全、技术安全和物理安全。 （1）数据中心安全管理框架。数据中心安全管理的框架，主要考虑下面的基本因素： 1)安全管理制度与策略。包括安全管理策略、安全管理制度、安全管理机构和人员安全管理。 2)数据中心物理与设备安全。包括建筑物结构安全、数据中心电力安全、空调系统及通信安全和数据中心安保系统。 3)数据中心信息技术安全。包括资产安全管理、通信安全管理、网络安全管理、系统安全管理、数据安全管理、软件开发安全和数据中心权限安全 （2）数据中心安全管理总则。数据中心安全管理总则包括下面的基本内容： 1)应制订明确的数据中心系统总体安全保障目标，建立数据中心信息安全管理工作的总体方针和策略，将数据中心信息安全保障及信息安全风险管理纳入公司全面风险管理体系。 2)应结合数据中心发展战略及业务特点，建立数据中心信息安全保障以及信息安全风险管理框架、策略及流程，制订针对数据中心运行与维护、备份与恢复、应急事件处置以及客户系统运维、信息保密等的安全策略。 3)应制订数据中心系统使用的网络设备、主机设备、安全设备的配置和使用的安全策略。 4)应建立数据中心信息安全风险管理策略，至少包括风险评价和定级、风险偏好、容忍度及参数制订、风险控制、成本及效益评价、控制措施有效性评价策略等，应根据数据中心发展及检查审计结果，定期修订策略。 5)应建立数据中心信息安全风险的持续监测机制，建立风险预警、报告、响应和处理机制，明确风险报告的内容、流程、主客体以及频率，建立符合数据中心实际状况的关键风险指标体系，实现信息安全风险监测的自动化，保证高级管理层和相关部门及时获取数据中心信息安全风险变化，验证现有控制措施的有效性。 6)对于衍生的数据中心信息安全风险以及未按计划达到的控制目标，应重新启动信息安全风险评估流程，制定和选择新的风险控制措施，对已接受的风险，定期进行再评估。 7)应按照国家及行业信息系统信息安全等级保护工作有关要求，开展数据中心系统信息安全测评及整改工作。 8)在选择外部评估时，应对其加强安全管理，签订保密协议或在相关服务协议中明确保密条款，避免泄露敏感信息。 9)应做好数据中心相关的新业务（IaaS云计算等）设计以及主要技术路线选择等关键规划的深入论证工作，关注产品及技术路线的合规性、相关业务及技术规则的一致性和延续性，以及系统间的关联性、依赖性，平衡客户体验和安全性，通过增加关键控制机制等措施防范潜在重要安全隐患，避免产生潜在的信息安全风险。 10)若人力、资源情况等条件许可，应规定所有与数据中心相关的信息资产的安全级别，并制订与其安全级别相对应的保护措施。 1)岗位设置。应设立信息安全管理工作的职能部门，设立安全主管、安全管理各个方面的负责人岗位，并定义各负责人的职责；应设立系统管理员、网络管理员和安全管理员等岗位，并定义各个工作岗位的职责；建立由董事会、高级管理层负责、相关各部门负责人及内部专家参与的数据中心信息安全领导协调机制；应制定文件明确安全管理机构各个部门和岗位的职责、分工和技能要求。 2)人员配备。应配备一定数量的系统管理员、网络管理员和安全管理员等；应配备专职安全管理员，实行A、B岗制度，不可兼任其他岗位；关键事务岗位应配备多人共同管理。 3)授权和审批。应根据各个部门和岗位的职责明确授权审批事项、审批部门和批准人等；应针对系统变更、重要操作、物理访问和系统接入等事项建立审批程序，按照审批程序执行审批过程，对重要活动建立逐级审批制度；应定期审查审批事项，及时更新需授权和审批的项目、审批部门和审批人等信息；应记录审批过程并保存审批文档；用户应被授予完成所承担任务所需的最小权限，重要岗位的员工之间应形成相互制约的关系。权限变更应执行相关审批流程，并有完整的变更记录；应建立系统用户及权限清单，定期对员工权限进行检查核对，发现越权用户要查明原因并及时调整，同时清理过期用户权限，做好记录归档。 4)沟通和合作。应加强各类管理人员之间、组织内部机构之间，以及信息安全职能部门内部的合作与沟通，定期或不定期召开协调会议，共同协作处理信息安全问题；应加强与兄弟公司、国家信息安全中心、公安机关、电信和网通等ISP公司的合作沟通以及应急协调机制，有效处置网络与信息安全事件；应加强与供应商、业界专家、专业的安全公司及安全组织的合作与沟通，增强日常安全防护、突发事件处置和故障处理等方面的能力；应建立外联公司联系列表，包括外联公司名称、合作内容、联系人和联系方式等信息；应关注和参加行业内信息安全研讨，学习更新安全知识和理念；应聘请信息安全专家作为常年的安全顾问，指导信息安全建设，参与安全规划和安全评审等。 5)审核与检查。安全管理员应负责定期进行安全检查，检查内容包括系统日常运行、系统漏洞和数据备份等情况；应由内部人员或审计公司定期进行全面安全检查，至少每年开展一次数据中心全面安全检查，检查内容包括现有安全技术措施的有效性、安全配置与安全策略的一致性、安全管理制度的执行情况等；内部审计部门应至少每两年对数据中心开展一次审计，审计内容至少包括相关管理制度的完备性及其执行的有效性，相关操作流程的合理性与合规性，信息安全保障体系的完备性和有效性，信息安全风险管理、规划实施、信息系统运行的安全性及重要客户信息和数据的安全性、应急管理、外包管理的有效性、SLA执行情况，以及其他重要信息安全保障的情况；评估和管理第三方公司或外包项目的安全。事件管理的目标就是在出现事件时尽可能快地恢复服务的正常运作，避免其造成业务中断，把对业务的负面影响降为最低，以确保服务质量和可用性满足服务等级协议（Service-Level Agreement，SLA）中定义的正常服务级别。为了实现这个目标，事件管理流程必须最佳地利用资源支持业务、开发和维护有效的事件记录，以及设计和应用统一的事件报告方法。
三、事件管理 所谓事件是指可能会导致服务中断或服务质量下降的，不属于标准服务的事件。事件不仅包括了与软件和硬件有关的错误，还包括服务请求。 事件管理不是找到引起系统异常的根本原因，而是尽快恢复系统业务功能，找到异常根本原因是问题管理流程的目的。
事件管理的主要任务是及时识别并跟踪发生的事件；对事件进行分类并提供初步支持；对事件进行调查分析，识别引发事件的潜在原因；解决事件并恢复服务；跟踪和监督所有事件的解决过程，并随时进行沟通。因此，研究事件管理对解决目前IT运维中存在的服务问题具有重要的意义，事件管理的时效性将直接影响整个企业的IT服务质量和整体运营状况。 事件管理的关键点包括： 1、事件记录 事件管理记录详细的事件信息，如事件发生的时间、受事件影响的服务等。这样做的目的是便于确认事件的影响，问题管理可以根据这些信息查找事件原因，密切跟踪事件进展。通过系统监测工具在事件数据库中自动生成基本事件记录是理想的解决方案。相关配置项的表征、基本诊断数据以及信息，在诊断以及记录阶段都应该包括在事件记录中。 在大多数情况下，事件会由服务台进行记录，所有的事件都应该被迅速记录下来。要避免对同一事件进行重复记录的情况出现。因此在记录某一事件时，需要进行一项检查来确定是否已有相似的记录。 2、事件分类 事件分类的目的是为了确定事件的来源以便采取相应行动，尽可能快地恢复用户的正常工作，尽量避免或者减少事件IT服务质量的影响。一般来说，许多事件是重复出现的，因此，当某个事件再次出现时，只需要根据已有的经验和措施采取行动即可。当新的事件出现时，就有一个与其问题和知名错误（知识库）相匹配的过程，如果匹配成功就可直接用已有的方案将其解决，而不需要进一步调查，否则就要继续进行下面提到的其他几个步骤。 ITIL中通常都将事件采取三级分类机制：分类、子分类及项目。可以根据所报告的事件的故障情况，对事件进行分类（为事件指派类型）。根据事件的类型、状态、影响度、紧急度、优先级、SLA等来对其进行编码，由此向用户提供建议来解决或处理问题，哪怕这些建议仅仅是临时性的。 3、事件状态定义 事件状态反映了其在整个生命周期中的当前状态，有时候指其在事件工作流中的位置。任何人都应该意识到每个事件的状态以及它所代表的含义。通常情况下，事件状态的例子有：新建；已接收；已计划；已分配/已指派给专业人员；激活状态；已暂停；已解决；已终止。 4、事件级别定义 在确定事件的类别后，需要确定事件的优先级，以确保支持小组对问题予以足够的关注。决定事件级别的要素主要有三个，分别是影响度（Impact）、紧急度（Urgency）和处理优先级（Priority）。影响度是指就所影响的用户或业务数量而言，事件偏离正常服务级别的程度；紧急度是在解决故障时，对用户或业务来说可接受的耽搁时间；优先级是根据影响度和紧急度决定了处理事件和问题的先后顺序，优先级通常用一个数字来表示，优先级=紧急度×影响度。 5、事件诊断处理 经过事件的查明和记录，对事件进行初步诊断后通过技术或管理手段快速恢复。事件管理的目标首先是快速解决问题，恢复业务的正常运作，而不是寻找问题的根本原因。对于未出现过的事件，一线人员无法解决，则尽快启动事件升级，目标依然是快速恢复系统和服务。过程中往往会采用变通的解决方案（Workaround）。对于事件发生的原因暂时无法找到，该事件需要升级为问题管理，通过问题管理的方式追踪问题发生的根本原因（Root Cause）直至问题被彻底解决，不再重复发生，这部分属于问题管理范畴。 6、事件升级机制 对于事件不能在规定的时间内由一线支持小组解决，那么更多的有经验的人员和有更高权限的人员将不得不参与进来，这就是升级。它可能发生在事件解决过程的任何时间和任何支持级别。升级分为职能升级和管理升级。 （1）职能升级：需要具有更多时间、专业技能或接入特权（技术机构）的人员来参与事件的解决。这种升级可能会超越部门界限而且可能会包括外部支持者。 （2）管理升级：当经授权的当前级别的机构不足以保证事件能及时、满意的得到解决时，需要更高级别的机构参与进来。 7、事件关闭 事件解决和恢复服务后，事件到达关闭阶段，这个阶段要跟用户确认事件解决是否成功。在事件解决后，要确保所有的事件信息都得到了更新并准确被记录；同时根据事件产生的根本原因对事件的分类进行调整；对于根本原因未找到的事件确认是否已经转入问题管理。在用户同意事件解决方案和方案执行的最终结果的基础上，该事件可以被关闭。 事件管理关键点的具体实例如下： 1、数据中心事件的分类 数据中心运维过程中发生的事件种类繁多，我们主要根据故障种类以及事件定级方法，对数据中心事件进行分类。从故障角度划分的事件包括：供配电系统事件、制冷系统事件、物理环境事件、物理安全事件、监控系统、网络故障、IT系统故障、自然灾害等；结合事件定级因素，将事件分为一级、二级、三级和四级等不同的等级。有的企业会划分为三级，有的企业会划分为五级。表1是事件分类的一个具体实例。读者可以参考下面的分类实例，根据自己的情况进行事件分类的定义和等级划分。在实际事件分类中，没有统一的强制标准，是由具体的业务和管理要求决定的。读者可以根据定级的标准，去枚举所属数据中心的具体分级事件的例子。 表1 数据中心事件定级分类实例 级别 | 状态描述 | 一级事件 | 关键服务中断，影响SLA的达成 | 二级事件 | 关键服务组件出现故障，导致不满足冗余条件或服务水平下降，有潜在影响SLA的可能性 | 三级事件 | 非关键服务组件故障，不影响SLA的达成 | 四级事件 | 非关键服务的质量下降，造成轻微影响或影响可以忽略 |
一级事件举例：用户可以根据自身数据中心的情况，定义具体的事件场景，便于判断。 （1）供电系统：整套供电系统瘫痪（双路市电供电中断、UPS供电中断及发电机无法正常启动），导致电力中断。 （2）制冷系统：多台精密空调服务中断，导致温度、湿度超出SLA承诺阈值。 （3）物理环境：大面积的渗水漏水，导致客户机房出现严重安全隐患。 （4）物理安全：出现恐怖袭击或者有针对性的破坏而导致客户服务中断。 （5）自然灾害：数据中心无法提供保障数据中心正常运营能力的物理指标、地震、洪水、台风、战争等。 2、数据中心事件的升级 数据中心事件可以根据处理的不同情况，在不同的运维团队间进行升级，表2是数据中心事件升级定义的一个实例，读者可以参考下面的升级实例，根据自己的情况进行升级的定义和划分，在实际事件升级中，没有统一的强制标准，是由具体的业务和管理要求决定的。 表2 数据中心事件升级定义实例 | 运维人员 | 三级事件 | 二级事件 | 一级事件 | 现场工程师 | 5min报告现场经理 | 5min报告现场经理 | 5min报告现场经理 | 机房经理/客服经理 |
| 10min报告事件管理经理、客服经理 | 10min报告事件管理经理、客服经理 | 事件经理 |
| 15min报告运维总监 | 15min报告运维总监 | 运维总监 |
| 30min报告运维总监 | 15min报告运维副总裁 | 运维副总裁 |
|
| 15min报告运维总监 |
目标值 | 一级事件 | 二级事件 | 三级事件 | 四级事件 | 响应时间/min | 5 | 5 | 15 | 15 | 派单时间/min | 10 | 15 | 15 | 15 | 接单时间/min | 15 | 60 | 工作时间 | 工作时间 | 管理升级时间 | 5 | 15 | N/A | N/A | 技术升级时间 | 15 | 30 | 12h | 24h | 解决时间 | N/A | N/A | N/A | N/A |
对于超越一级事件的重大影响事件，如对客户业务产生重大影响，严重影响合约的履行，有重大法律和商务风险的事件，建议高级管理层的参与，公关媒体的参与，与客户一起做危机处理。 3、数据中心事件的记录 数据中心事件的各种相关信息都要被及时记录下来，一般都应该记录在后台系统里面，并且以工单的形式在各处理环节中进行传递。数据中心事件记录包括很多相关信息，表3是数据中心事件记录的一个实例，读者可以参考下面的事件记录实例根据自己的情况进行事件记录信息的定义和划分，在实际事件记录中，没有统一的强制标准，是由具体的业务和管理要求决定的。 表3 数据中心事件记录定义实例 | 项目 | 描述 | 事件名称 | 事件的名字 | 严重级别 | 事件的严重级别 | 优先级 | 事件的优先级别 | 生成时间 | 事件产生的时间 | 重复次数 | 事件发生的重复次数 | 拥有人 | 事件处理拥有人 | 描述 | 事件的描述 | 开始时间 | 当前事件开始时间 | 结束时间 | 当前事件结束时间 | 第一次发生时间 | 事件第一次发生时间 | 最后一次发生时间 | 事件最后一次发生时间 | 状态 | 当前事件实际状态 | 事件ID号 | 事件ID号 | 事件显示数 | 事件计数 | 计数器名 | 计数器名 | 实例名 | 实例名 | 事件数据 | 事件数据内容 |
四、数据中心问题管理（Problem Management)
问题管理的目标是找出突发事件产生的根本原因，最小化由于IT基础架构错误引起的突发事件和问题的负面影响，防止与错误相关的突发事件的再次发生。通过实施主动问题管理，在事件发生之前发现问题并解决，从而减少事件发生的数量。 问题是导致一个或多个事件的根本原因，而这些根本原因还没有诊断出来。事件管理强调在给用户和公司的正常业务活动带来最小影响的情况下，尽快恢复到SLA中定义的正常服务级别。采取任何可能的方法，包括一个临时解决方案（应急措施）来快速地解决事件，尽可能确保最好的服务质量和可用性。与事件管理强调速度不同，问题管理则注重诊断事件的根源，确定问题的根本原因，从而制定恰当的解决方案，从根本上解决问题，防止类似事件的再次发生。事件管理为了尽可能快地恢复服务，往往会采用临时解决方案，问题管理比起事件管理则会花费更长的时间。 (1)问题的识别和记录。原则上，任何一个由未知原因引起的事件都与某个问题有关。问题的识别通常会发生在以下情况：在事件管理流程中没有问题或已知错误来匹配事件；通过分析发现该事件又再次发生了，或者发生了重大事件；事件不能与现有问题或已知错误相匹配；通过对IT基础设施的分析识别出导致事件的问题。 问题记录和事件记录一样都被记录在配置管理数据库（Configuration Management Database,CMDB)中，问题记录会跟所有有关联的事件记录关联在一起。事件的解决方案以及临时解决方案的细节都应该被记录在问题记录中而不是事件记录中，以便它们可以用于将来有关联的事件中。 (2)问题的诊断和处理。通过问题诊断成功获取问题的根本原因并找到解决途径后，该问题将转变为一个已知错误。问题调查除了与事件调查的目标不同外，其流程类似。事件调查的主要目的是为了恢复服务的正常运作，而问题管理则是为了确定问题的根源。 在事件调查期间所采用的任何应急措施，都应该在问题调查阶段考虑，如果有必要的话，在问题记录中还要更新与已知错误、解决方案和应急措施相关的信息。 一旦诊断出配置项中的故障，那么该问题状态被转变为已知错误，然后开始进行错误控制。当一个问题被诊断为一个程序错误而不是配置项故障时，记录应该被更新为正确的代码然后关闭该问题，通常这样的问题不会转化成已知错误。 (3)问题的关闭。在满足问题关闭规则指定的条件之后，关闭问题，同时可将关联的所有事件一同关闭。 (1)数据中心问题的定级。根据问题引发事件的程度，将问题定级为高风险问题和普通级问题；高风险问题是指问题不被解决，再度引发事件的可能性很大；普通级问题指问题不被解决，暂时不会引发事件。读者可以根据自己的情况进行问题定级的划分，在实际问题定级中，没有统一的强制标准，而是由具体的业务和管理要求决定。 (2)数据中心问题的分类。数据中心问题分类有多种方式，可以按照问题所处的区域和类别来进行分类。下面是一个可以参考的问题分类方式： 1)从业务角度分类。与事件分类相似，可参考数据中心事件分类。 2)从管理或治理角度分类。可以根据不同企业的管理目标来分，如流程问 题、工具问题人员问题、供应商的问题及技术架构问题。 3)管理角度还可以再细分。如人员问题中可以细分为人员执行力问题、人员技能问题、人员责任心问题及职责不清问题等。 问题的分类不是固定的，而是在问题的生命周期内可能发生变化的，问题管理的核心就是将问题多维度、多视角深度剖析，找出管理上、架构上的“短板”，从根本上去解决，这样才可以使得问题管理真正在IT管理或数据中心管理中发挥作用。在数据中心的管理中，问题管理通常因为没有事件管理、变更管理那么直接影响服务的可用性而被忽视，使得遗留下来的问题没有被及时解决，也会导致事件的重复发生，从而降低系统和服务的整体可用性。 为了更有效推进问题管理，建议：第一，形式很重要，可以将问题按照月度或者季度来跟踪和回顾，而不是作为每天的流程性工作；第二，问题经理人的选择非常重要，通常问题经理是具有丰富经验和行政级别的经理，才能调度资源和有迫切感来解决问题。如果是流程经理兼职问题经理，问题管理推行的难度和阻力将会很大。
五、数据中心变更管理(ChangeManagement) 数据中心的变更管理，是为在最短的中断时间内完成基础架构的任一方面的变更，而对其进行控制的服务管理过程。这里所指的变更，,是指在维护过程中对系统或服务所做的各种改变。包括增补、移除和其他修改。 变更管理的目的，是确保以受控的方式去评估、批准、实施和评审所有变更，确保标准方法和过程可以得到使用。阻止未授权的变更发生，使得变更风险可以降至最低，同时将变更相关突发事件的影响减到最小，并且确保所有变更都必须可跟踪和可追溯。 (1)变更请求(Request for Change, RFC)，变更发起的主要原因有解决事件、预防问题、升级部署、主动性改善以及业务需求。 变更请求是指对一个或多个特定设备或系统实施变更的正式请求，说明了变更的内容及与变更有关的配置项。变更请求只是为了请求对基础架构进行变更的机制，它必须包括变更所需要的必要信息以便评审、批准和创建。由于并不是每一个修改请求都像变更一样处理，也致使变更可以分为标准变更和非标准变更两种。⑧变更顾问委员会(Change Advisory Board, CAB)的建议；⑪恢复计划,(Back-out planning),一旦变更管理的执行计划没有效果，就需要恢复计划来稳定企业的运作，减少经营风险。(2)变更顾问委员会。变更委员会定期会合，对较大以上变更进行评估审核，并拟定相应计划，变更委员会应当从业务和技术两个角度充分评估变更的影响，变更委员会不能批准变更请求，只是给出相关意见。其成员是灵活的，这取决于变更请求，可以包括任何从商业和技术角度来看都能确保变更被充分评估的人员，可以包括:变更经理(主席和常任成员)、技术专家/顾问、客户经理和用户组代表、开发人员和供应商。(3)变更种类。变更通常按照两种方式进行分类:一种是基于变更类型进行分类，该分类的方式类似于事件分类，用于区分变更的类型；另一种是基于变更的影响程度，来定义变更的级别，用以确认变更的审核矩阵。如重大变更、较大变更、一般变更和标准变更。根据变更的紧急程度，又分为计划性变更和紧急变更。(4)变更审批。不同的变更有不同的审批流程和审核矩阵。对于重大的变更，需要CAB来审核。其中除了技术风险评估，还会涉及到财务和业务的评估。对于较大变更，可以是变更经理和变更相关部门负责人来审核确定。对于一般变更或者标准变更，则可以根据预先定义好的相关流程进行备案即可。变更的定级和授权对于变更是否可以在企业里被很好地执行非常相关。如果太多的变更需要走复杂的审批流程，管理成本大，流程效率低下，也会使得变更发起者不愿意走变更流程，导致变更风险无法被有效管控。1)财务审批。确保变更成本在预算范围内，或者满足变更管理所设定的成本/优势需求。2)技术审批。保证变更的可行性、合理性，变更的实现不会对IT服务产生过多的负面影响。3)业务审批。确保业务经理同意建议的变更，同时变更对业务产生的影响能令他们]满意。(1)数据中心变更的定级。根据变更风险,的高低，数据中心的典型变更级别分为重大变更、较大变更、一般变更及标准变更四个级别。变更定级方法见下表。用户可以根据自己的情况进行变更的定级划分，在实际变更定级中，没有统一的强制标准，而是由具体的业务和管理要求决定。 | | | | 变更风险高，可能影响一个或多个关键服务中断（自用数据中心）；影响一个或多个客户服务中断，从而违反SLA(第三方数据中心） | | 变更风险中等可控，可能影响一个或多个关键服务，可能导致服务质量下降或者非关键服务中断（自用数据中心）；变更风险中等可控，可能影响一个或者多个客户服务，可能导致服务质量下降，从而影响SLA的履行（第三方数据中心） | | 变更风险可控，不影响服务的正常提供；但仍然需要走批复流程 | | 紧急变更是指为迅速恢复服务或降低当前故障的影响范围而需要紧急实施的变更。一般情况下，仅限于因事件引发了服务中断、需尽可能得到快速处理的变更 | | 被制造商明确定义并由他们完成的常规管理任务，不需要由变更管理来控制，被称之为标准变更；通常有清晰的操作规程的变更 |
| | | 配电柜以上电路改造（如列头柜、UPS的新增、迁移及市电电路改造等） | | 机柜电路的带电改造（如需要在带电条件下实施的机柜接入电路、PDU等的调整） | | 机房已投产的安防系统改造（如消防系统、CCTV系统、门禁系统等的改造或重新部署，变更涉及该系统内大部分设备） | | 机柜电路改造（如新增PDU、单机柜或少数几个机柜的线缆接驳、机柜接地等） |
(2)数据中心变更的分类。根据所要变更的基础架构的特点，数据中心变更可以分为物理环境类变更、基础设施类变更、IT设备类变更、施工类变更、IT系统类变更、网络线路类变更以及资产类变更几类。为了在实施中把中断业务或服务的时间减少到最小，要对变更请求进行审批，确定变更的优先级，再进行变更操作。不同类别的变更参照变更定级标准进行定级。读者可以根据自己的情况进行变更分类的划分，在实际变更分类中，没有统一的强制标准，而是由具体的业务和管理要求决定。(3)数据中心变更审核要点。为了减少盲目的、随意的变更，数据中心的变更除了需要制定详尽的变更计划外，还要从多方面进行审核。数据中心变更的主要审核点包括：
|
