以下是重构后的内容:

资产管理和配置管理是两个不同的概念。资产管理是对购买价格超过一定限额的资产进行监控的一套会计核算过程,它记录了购买价格、折旧、所属业务单元和所处位置等信息。而配置管理则需要识别和确认系统的配置项记录和报告配置项状态和变更请求、检验配置项的正确性和完整性等活动构成的服务管理过程。

配置管理超越了资产管理,它保留了有关配置项的技术信息、配置项相互关系的详细信息,以及配置项的标准化和授权状况等方面的信息。配置管理还监控对当前信息的反馈,如IT组件的状态、位置,以及对其实施了的变更。资产和配置管理的关键点包括:

- 配置管理的目标。好的配置管理不仅能体现单个个体的属性信息,而且能够体现IT组件之间的影响,并且为其他变更管理、事件管理和问题管理等流程提供足够的基础信息。

- 固定资产管理相关流程。固定资产管理的一些需要考虑和定义的关键流程如下:资产采购;资产变更;资产盘点;资产租入租出;资产报废流程。

- 资产管理相关文件。资产管理的常用文件定义如下:固定资产采购申请表;固定资产采购合同;固定资产设备签收单;数据中心固定资产台账;固定资产盘点清单;闲置固定资产明细表;固定资产出门记录;固定资产盘点报告。

- 配置管理数据库(CMDB)。配置管理数据库是指包括所有与配置项及其状态和相互关系有关的信息的数据库。配置管理数据库对所有组件、组件的不同版本和状态,以及组件之间的相互关系进行跟踪。在其最基本的形式下,一个CMDB可能是由一些纸质表格或一套清单组成。

配置管理广度和深度的确定,直接决定了配置管理未来的管理控制是否有效。如果广度太广,把关键资产和非关键资产全部纳入其中管理,可能会比较难于管理和控制。对于配置管理深度,如果定义太细,如一个设备配置项定义到网卡级别,则未来的管理成本也是极大的。

常见的配置管理考虑因素包括:配置管理的广度;配置管理的深度;配置项之间关联关系;配置管理工具的选择;配置管理与变更管理的绑定等。

数据中心安全管理是通过对数据中心安全管理组织、基础环境安全、信息技术安全的制定和实施,来确保数据中心的信息安全、技术安全和物理安全。数据中心安全管理的关键点包括:安全管理制度与策略;数据中心物理与设备安全;数据中心信息技术安全;数据中心安全管理总则等。

以下是重构后的内容:

5、建立持续监测机制,确保信息安全风险的及时识别和处理。应建立风险预警、报告、响应和处理机制,明确风险报告的内容、流程、主客体以及频率。同时,建立符合数据中心实际状况的关键风险指标体系,实现信息安全风险监测的自动化。这样可以保证高级管理层和相关部门及时获取数据中心信息安全风险变化,验证现有控制措施的有效性。

6、对于衍生的数据中心信息安全风险以及未按计划达到的控制目标,应重新启动信息安全风险评估流程,制定和选择新的风险控制措施,对已接受的风险定期进行再评估。

7、应按照国家及行业信息系统信息安全等级保护工作有关要求,开展数据中心系统信息安全测评及整改工作。

8、在选择外部评估时,应对其加强安全管理,签订保密协议或在相关服务协议中明确保密条款,避免泄露敏感信息。

9、应做好数据中心相关的新业务(如IaaS云计算等)设计以及主要技术路线选择等关键规划的深入论证工作。关注产品及技术路线的合规性、相关业务及技术规则的一致性和延续性,以及系统间的关联性、依赖性。平衡客户体验和安全性,通过增加关键控制机制等措施防范潜在重要安全隐患,避免产生潜在的信息安全风险。

10、若人力、资源情况等条件许可,则应规定所有与数据中心相关的信息资产的安全级别,并制订与其安全级别相对应的保护措施。

(3)安全组织架构:

1)岗位设置:应设立信息安全管理工作的职能部门,设立安全主管、安全管理各个方面的负责人岗位,并定义各负责人的职责;应设立系统管理员、网络管理员和安全管理员等岗位,并定义各个工作岗位的职责;建立由董事会、高级管理层负责、相关各部门负责人及内部专家参与的数据中心信息安全领导协调机制;应制定文件明确安全管理机构各个部门和岗位的职责、分工和技能要求。

2)人员配备:应配备一定数量的系统管理员、网络管理员和安全管理员等;应配备专职安全管理员,实行A、B岗制度,不可兼任其他岗位;关键事务岗位应配备多人共同管理。

以下是根据提供的内容完成的重构后的段落结构:

3)授权和审批。应根据各个部门和岗位的职责明确授权审批事项、审批部门和批准人等;应针对系统变更、重要操作、物理访问和系统接入等事项建立审批程序,按照审批程序执行审批过程,对重要活动建立逐级审批制度;应定期审查审批事项,及时更新需授权和审批的项目、审批部门和审批人等信息;应记录审批过程并保存审批文档;用户应被授予完成所承担任务所需的最小权限,重要岗位的员工之间应形成相互制约的关系。权限变更应执行相关审批流程,并有完整的变更记录;应建立系统用户及权限清单,定期对员工权限进行检查核对,发现越权用户要查明原因并及时调整,同时清理过期用户权限,做好记录归档。

4)沟通和合作。应加强各类管理人员之间、组织内部机构之间,以及信息安全职能部门内部的合作与沟通,定期或不定期召开协调会议,共同协作处理信息安全问题;应加强与兄弟公司、国家信息安全中心、公安机关、电信和网通等ISP公司的合作沟通以及应急协调机制,有效处置网络与信息安全事件;应加强与供应商、业界专家、专业的安全公司及安全组织的合作与沟通,增强日常安全防护、突发事件处置和故障处理等方面的能力;应建立外联公司联系列表,包括外联公司名称、合作内容、联系人和联系方式等信息;应关注和参加行业内信息安全研讨,学习更新安全知识和理念;应聘请信息安全专家作为常年的安全顾问,指导信息安全建设,参与安全规划和安全评审等。

5)审核与检查。安全管理员应负责定期进行安全检查,检查内容包括系统日常运行、系统漏洞和数据备份等情况;应由内部人员或审计公司定期进行全面安全检查,至少每年开展一次数据中心全面安全检查,检查内容包括现有安全技术措施的有效性、安全配置与安全策略的一致性、安全管理制度的执行情况等;内部审计部门应至少每两年对数据中心开展一次审计,审计内容至少包括相关管理制度的完备性及其执行的有效性,相关操作流程的合理性与合规性,信息安全保障体系的完备性和有效性,信息安全风险管理、规划实施、信息系统运行的安全性及重要客户信息和数据的安全性、应急管理、外包管理的有效性、SLA执行情况,以及其他重要信息安全保障的情况;评估和管理第三方公司或外包项目的安全。

事件管理的目标是在出现事件时尽可能快地恢复服务的正常运作,避免其造成业务中断,把对业务的负面影响降为最低,以确保服务质量和可用性满足服务等级协议(Service-Level Agreement,SLA)中定义的正常服务级别。为了实现这个目标,事件管理流程必须最佳地利用资源支持业务、开发和维护有效的事件记录,以及设计和应用统一的事件报告方法。

三、事件管理

所谓事件是指可能会导致服务中断或服务质量下降的,不属于标准服务的事件。事件不仅包括了与软件和硬件有关的错误,还包括服务请求。事件管理不是找到引起系统异常的根本原因,而是尽快恢复系统业务功能,找到异常根本原因是问题管理流程的目的。

事件管理的主要任务是及时识别并跟踪发生的事件;对事件进行分类并提供初步支持;对事件进行调查分析,识别引发事件的潜在原因;解决事件并恢复服务;跟踪和监督所有事件的解决过程,并随时进行沟通。因此,研究事件管理对解决目前IT运维中存在的服务问题具有重要的意义,事件管理的时效性将直接影响整个企业的IT服务质量和整体运营状况。

事件管理的关键点包括:

1. 事件记录

事件管理记录详细的事件信息,如事件发生的时间、受事件影响的服务等。这样做的目的是便于确认事件的影响,问题管理可以根据这些信息查找事件原因,密切跟踪事件进展。通过系统监测工具在事件数据库中自动生成基本事件记录是理想的解决方案。相关配置项的表征、基本诊断数据以及信息,在诊断以及记录阶段都应该包括在事件记录中。在大多数情况下,事件会由服务台进行记录,所有的事件都应该被迅速记录下来。要避免对同一事件进行重复记录的情况出现。因此在记录某一事件时,需要进行一项检查来确定是否已有相似的记录。

2. 事件分类

事件分类的目的是为了确定事件的来源以便采取相应行动,尽可能快地恢复用户的正常工作,尽量避免或者减少事件IT服务质量的影响。一般来说,许多事件是重复出现的,因此,当某个事件再次出现时,只需要根据已有的经验和措施采取行动即可。当新的事件出现时,就有一个与其问题和知名错误(知识库)相匹配的过程,如果匹配成功就可直接用已有的方案将其解决,而不需要进一步调查,否则就要继续进行下面提到的其他几个步骤。

TIL中的事件管理是一种针对IT服务运营中的故障事件、警告事件和正常操作事件的处理方法。它旨在快速恢复服务的正常运行,减少服务不可用或降级的时间,确保用户和客户的满意度 。在ITIL中,事件通常采取三级分类机制:分类、子分类及项目。可以根据所报告的事件的故障情况,对事件进行分类(为事件指派类型)。根据事件的类型、状态、影响度、紧急度、优先级、SLA等来对其进行编码,由此向用户提供建议来解决或处理问题,哪怕这些建议仅仅是临时性的。

事件解决和恢复服务后,事件到达关闭阶段,这个阶段要跟用户确认事件解决是否成功。在事件解决后,要确保所有的事件信息都得到了更新并准确被记录;同时根据事件产生的根本原因对事件的分类进行调整;对于根本原因未找到的事件确认是否已经转入问题管理。在用户同意事件解决方案和方案执行的最终结果的基础上,该事件可以被关闭。

以下是重构后的内容:

数据中心事件升级定义实例:

| 运维人员 | 三级事件 | 二级事件 | 一级事件 |

| --- | --- | --- | --- |

| 现场工程师 | 5分钟报告现场经理 | 5分钟报告现场经理 | 5分钟报告现场经理 |

| 机房经理/客服经理 | 10分钟报告事件管理经理、客服经理 | 10分钟报告事件管理经理、客服经理 | 10分钟报告事件管理经理、客服经理 |

| 事件经理 | 15分钟报告运维总监 | 15分钟报告运维总监 | 15分钟报告运维总监 |

| 运维总监 | 30分钟报告运维总监 | 15分钟报告运维副总裁 | 15分钟报告运维总监 |

| 运维副总裁 | 15分钟报告运维总监 | N/A | N/A |

| 目标值 | 四级事件(N/A)| N/A| N/A|

| 响应时间/min | 5,15,30,45,60 (根据实际情况而定)| 5,15,30,45,60 (根据实际情况而定)| 5,15,30,45,60 (根据实际情况而定)|

| 派单时间/min | 10,20,30,40 (根据实际情况而定)| 15,20,30,40 (根据实际情况而定)| 15,20,30,40 (根据实际情况而定)|

| 接单时间/min | N/A,10-15 min (根据实际情况而定)| N/A,20-30 min (根据实际情况而定)| N/A,20-30 min (根据实际情况而定)|

| 工作时间(天) | 根据具体情况而定 | 根据具体情况而定 | 根据具体情况而定 |

| 管理升级时间(小时) …………………………………………(根据实际情况而定) | 根据具体情况而定 | 根据具体情况而定 | 根据具体情况而定 |

| **技术升级时间**(小时) ………&{"func_name":"simplify","args":["3*7"]}

问题管理和事件管理都是IT服务管理的一部分,但它们有不同的目标和流程。事件管理的目标是在事件发生后尽快恢复客户的服务,采取的应急解决方案而不是永久解决方案。事件管理强调解决速度。而问题管理则旨在查明事件发生的潜在原因,并找到解决此事件的方法或防止其再次发生的措施。问题管理强调解决质量 。

在ITIL 4中,问题管理可分为主动管理和被动管理。主动管理包括对历史事件记录的回顾以及趋势分析,主动识别潜在的问题,查找出导致问题的根源,设计针对性的方案或预防措施,从根本上解决问题。被动管理则是通过对当前事件的分析,查找引起该事件的根源,找出针对该根源的解决方案。

数据中心问题分类有多种方式,可以按照问题所处的区域和类别来进行分类。以下是一个可以参考的问题分类方式:

1)从业务角度分类。与事件分类相似,可参考数据中心事件分类。

2)从管理或治理角度分类。可以根据不同企业的管理目标来分,如流程问题、工具问题人员问题、供应商的问题及技术架构问题。

3)管理角度还可以再细分。如人员问题中可以细分为人员执行力问题、人员技能问题、人员责任心问题及职责不清问题等。

变更请求(Request for Change, RFC)是为了解决事件、预防问题、升级部署、主动性改善以及业务需求而发起的一种正式请求。它说明了对一个或多个特定设备或系统实施变更的内容及与变更有关的配置项。变更请求只是为了请求对基础架构进行变更的机制,必须包括变更所需的必要信息以便评审、批准和创建。因此,并非每一个修改请求都像变更一样处理,也致使变更可以分为标准变更和非标准变更两种。

变更请求应包含以下内容:

1. 变更请求标识码和日期;

2. 变更请求的状态;

3. 变更项的描述,包括版本号;

4. 变更原因;

5. 提出变更请求的人员信息;

6. 变更优先级、影响以及成本评估;

7. 风险评估和管理细节;

8. 变更顾问委员会(Change Advisory Board, CAB)的建议;

9. 变更授权人的签名、日期和时间;

10. 实施计划,用于详细说明如何变更;

11. 恢复计划(Back-out planning),一旦变更管理的执行计划没有效果,就需要恢复计划来稳定企业的运作,减少经营风险。

变更顾问委员会(CAB)是负责对较大以上变更进行评估审核并拟定相应计划的专门机构。其成员应当从业务和技术两个角度充分评估变更的影响。需要注意的是,变更委员会不能直接批准变更请求,而只能给出相关意见。其成员可以根据实际需要灵活调整,包括任何从商业和技术角度来看都能确保变更被充分评估的人员,例如:变更经理(主席和常任成员)、技术专家/顾问、客户经理和用户组代表、开发人员和供应商等。

根据不同的分类方式,变更可以分为多种类型。一种常见的分类方式是基于变更类型进行分类,类似于事件分类,用于区分不同类型的变更。另一种分类方式是基于变更的影响程度,将变更划分为不同级别以确认审核矩阵。这些级别可能包括重大变更、较大变更、一般变更和标准变更等。此外,根据紧急程度的不同,还可以将变更分为计划性变更和紧急变更两类。

以下是重构后的内容:

变更审批是企业中非常重要的一个环节,不同的变更有不同的审批流程和审核矩阵。对于重大的变更,需要CAB来审核。其中除了技术风险评估,还会涉及到财务和业务的评估。对于较大变更,可以是变更经理和变更相关部门负责人来审核确定。对于一般变更或者标准变更,则可以根据预先定义好的相关流程进行备案即可。

变更的定级和授权对于变更是否可以在企业里被很好地执行非常相关。如果太多的变更需要走复杂的审批流程,管理成本大,流程效率低下,也会使得变更发起者不愿意走变更流程,导致变更风险无法被有效管控。

上述重大变更,可能需要经历三个部门的审批流程:1)财务审批;2)技术审批;3)业务审批。确保财务、技术和业务经理同意建议的变更,并且变更对各自领域产生的影响能够令他们满意。

具体实例如下:

- 数据中心变更的定级:根据变更风险高低,数据中心的典型变更级别分为重大变更、较大变更、一般变更及标准变更四个级别。用户可以根据自己的情况进行变更的定级划分,在实际变更定级中没有统一的强制标准,而是由具体的业务和管理要求决定。

- 具体事例:例如重大变更包括配电柜以上电路改造(如列头柜、UPS的新增、迁移及市电电路改造等)、机柜电路的带电改造(如需要在带电条件下实施的机柜接入电路、PDU等的调整)。

根据我所了解的,数据中心变更审核要点包括:变更计划、变更风险、变更回退预案、变更窗口、变更前导时间、变更通知策略、变更影响、变更成功的标准、变更成本和变更投入产出 。为了减少盲目的、随意的变更,数据中心的变更除了需要制定详尽的变更计划外,还要从多方面进行审核。