大家好,欢迎来到IT知识分享网。
业务连续性管理大家并不陌生,听的很多,但真正落地的时候发现很多规范、标准中都涉及业务连续性,无论是ITIL4、ISO22301-2019、GBT30146-2013、ISO27001等标准中都是专门或者有独立的模块讲解业务连续性的。因此,只有真正理解了业务连续性的核心目标或期望解决的问题后才能够拨开迷雾,真正理解或落地业务连续性。这篇文章期望能够将业务连续性的概念、定义和不同标准/规范中的区别做一个整理,以帮助业务连续性能够更好的落地。
一、业务连续性的本质
业务连续性管理(BCM)是一个框架,它包括风险识别和控制的过程,以确保一个组织在面对潜在的威胁时能够持续运作。这些威胁可以是自然灾害、技术故障、恐怖主义行为、电力故障等。BCM的目标是减少这些威胁对业务运营的影响,并确保关键业务功能在危机发生后能够迅速恢复。
从这个定义我们可以看出,业务连续性不仅针对IT业务,其实企业多有业务都可能面临不连续的情况。因此,业务连续性其实分为针对IT业务的和针对企业运营的。本文我们仅介绍针对IT业务的业务连续性管理。
二、与业务连续性相关标准与规范
服务连续性管理(ITIL4)
服务连续性管理(ITIL4):服务连续性管理实践的目的是确保在出现灾难时保持服务可用性并维持足够性能。该实践提供了一个 建立组织弹性的框架和产生有效反应的能力,可保障关键利益相关者的利益,以及组织的声誉、品牌和价值创造活动。
概念:服务连续性(ITIL4)
是指在灾难事态或破坏性事件发生后,服务提供者以可接受的预定义级别继续服务运营的能力。
服务连续性管理通过确保 IT 和服务可以在灾难或危机后所需的商定业务时间范围内恢复,从而支持整体业务连续性管理 (BCM) 和规划能力。当服务中断或组织风险发生的规模大于组织通过正常响应和恢复实践(如事件和重大事件管理)处理它们的能力时,就会触发该实践。这种大规模的组织事态通常称为灾难。
每个组织都需要了解在自身的环境中什么是灾难。在触发事件之前,必须使用业务影响分析,在组织层面和 每个服务级别上考虑和定义灾难的含义。
业务连续性(BCM:ISO22301-2019)
业务连续性管理ISO标准的描述相对比较晦涩,但是在2011年发布过一个《商业银行业务连续性监管指引》中对业务连续性的要求基本符合ISO的要求,但理解和落地性比较好,本文我们引用了其中的内容:
业务连续性管理:是指商业银行为有效应对重要业务运营中断事件,建设应急响应、恢复机制和管理能力框架,保障重要业务持续运营的一整套管理过程,包括策略、组织架构、方法、标准和程序。
重要业务:是指面向客户、涉及账务处理、时效性要求较高的银行业务,其运营服务中断会对商业银行产生较大经济损失或声誉影响,或对公民、法人和其他组织的权益、社会秩序和公共利益、国家安全造成严重影响的业务。
重要业务运营中断事件(以下简称运营中断事件)是指因下述原因导致信息系统服务异常、重要业务停止运营的事件。主要包括:
(一)信息技术故障:信息系统技术故障、配套设施故障;
(二)外部服务中断:第三方无法合作或提供服务等;
(三)人为破坏:黑客攻击、恐怖袭击等;
(四)自然灾害:火灾、雷击、海啸、地震、重大疫情等。
业务连续性管理需要做的事情:
- 确定重要业务及其恢复目标,
- 制定业务连续性计划,
- 配置必要的资源,
- 有效处置运营中断事件,
- 积极开展演练
- 业务连续性管理的评估改进。
三、业务连续性的核心概念定义
灾难
ISO将灾难定义为“一种具有高度不确定性的情况,这种情况会破坏核心业务和/或组织的信誉,并需要紧急行动。可以通俗理解为一种突发的计划外事态,可给组织造成巨大损害或重大损失。灾难会导致组织在某些预定最短时间段内无法履行重要的业务功能. 如:供应链故障、恐怖主义、天气、网络攻击、卫生紧急情况、政治或经济事件、技术故障、公共危机。
RTO (Recovery Time Objective)
定义:RTO 是指从业务流程中断到恢复到可接受的服务水平所需的最大时间。
示例:假设一个在线零售商店的网站发生了故障。如果他们确定RTO为4小时,这意味着他们需要在4小时内恢复网站的正常运行,以避免更大的业务损失。如何定义:RTO的定义通常基于以下因素:
- 业务对停机时间的容忍度。
- 潜在的经济损失。
- 客户和合同方面的义务。
- 法规和合规要求。
RPO (Recovery Point Objective)
定义:RPO 是指在发生中断事件后,可以接受数据丢失的最大时间段。
示例:继续上面的在线零售商店的例子,如果他们确定RPO为30分钟,这意味着他们可以接受最近30分钟内的数据丢失(例如,最近30分钟的订单)。因此,他们的备份策略可能需要每30分钟备份一次数据。如何定义:RPO的定义通常基于以下因素:
- 业务对数据丢失的容忍度。
- 数据的价值和重要性。
- 法规和合规要求。
在确定RTO和RPO时,关键是进行全面的业务影响分析(BIA),了解各个业务流程和系统的重要性,并与相关的利益相关者进行沟通。这样可以确保这两个指标与业务的实际需求和风险承受能力相匹配。
最大容忍中断时间/最大可接受中断(MAO:Maximum Acceptable Outage)
ISO22301-2012定义如下(2019版已经删除):
- MAO指在中断威胁到组织实现其业务目标和/或生存能力之前必须进行有效恢复的时间。
- RTO事件之后的时间段,在此期间生产或业务活动必须重新开始,或者资源必须恢复
- 按照此逻辑, RTO应当比MAO在数量上少一些,这足以说明组织的风险偏好.MAO应该在业务影响分析中确定。
RTO 应该在服务连续性计划的开发中定义。
业务影响分析 (BIA)
服务连续性管理实践中的一个关键活动,用于识别重要的业务功能 (VBF) 及它们的依赖关系。这些依赖关系可能包括供应商、人员、其他业务流程和 IT 服务。BIA 定义 IT 服务的恢复需求。这些需求包括每个 IT 服务的 RTO、RPO 和最小目标服务级别。
灾难恢复计划
一系列定义清晰的计划,涉及组织如何从灾难中复原并恢复到灾难前状态,这些计划应考虑服务管理的四个维度。通常包括的内容:
- 响应计划: 明确了服务提供者最初如何对破坏性的事态做出反应,以防止损坏,例如火灾或网络攻击。
- 恢复计划:明确了服务提供者如何恢复服务以实现 RTO 和 RPO。
- 返回正常运营的计划:
定义了服务提供商在恢复后如何恢复正常运营。
例如,如果已经使用了备用数据中心,那么这个阶段将使主数据中心重新投入运营,并恢复再次调用IT服务连续性计划的能力。
应急预案
- 应急预案是组织应对运营中断事件的总体方案,包括总体组织架构、各层级预案的定位和衔接关系及对运营中断事件的预警、报告、分析、决策、处理、恢复等处置程序。
总体预案通常用于处置导致大范围业务运营中断的事件。 - 应当制定重要业务专项应急预案,专项应急预案应当注重灾难场景的设计,明确在不同场景下的应急流程和措施。
业务条线的专项应急预案,应当注重调动内部资源、采取业务应急手段尽快恢复业务,并和信息科技部门、保障部门的应急预案有效衔接。
专项应急预案的主要内容应当包括:
(一)应急组织架构及各部门、人员在预案中的角色、权限、职责分工;
(二)信息传递路径和方式;
(三)运营中断事件处置程序,包括预警、报告、决策、指挥、响应、回退等;
(四)运营中断事件处置过程中的风险控制措施;
(五)运营中断事件的危机处理机制;
(六)运营中断事件的内部沟通机制和联系方式;
(七)运营中断事件的外部沟通机制和联系方式;
(八)应急完成后的还原机制。
四、业务连续性在各规范/标准中的区别
可用性管理与服务连续性管理的区别
服务的连续性和可用性管理的实践之间的界限是不明显的。两种做法都涉及风险的概念,并致力于识别和准备应对可能威胁并导致服务不能运转的事件。对于这两种实践,都需要了解VBF和风险评估或服务故障的BIA。最终,两种做法都确保了组织的抗故障能力。但两个实践在设计上是有不同的考虑,具体表现在:
纬度 | 可用性管理 | 服务连续性管理 |
---|---|---|
关注点 | 高概率风险 | 高影响风险(紧急情况、灾难) |
方法 | 更加主动 | 更加被动 |
目的 | 减少不期望事件的可能性 | 减少不期望事件的影响 |
解决方案的重点 | 技术解决方案 | 组织措施 |
策略 | 优化 | 创建冗余 |
是否为公司功能的一部分 | 不是 | 通常是 |
情境 | 业务照常 | 特殊情况 |
相关指标 | MTRS、MTBF、MTBSI | RTO、RPO |
在实际落地和执行可用性管理和服务连续性管理时,我们需要关注以下几个不同点:
- 服务连续性管理实践不包含那些不会严重影响组织的轻度或短期故障。
它关注与重大损害相关的风险,无论它们发生的可能性或不可能性有多大。
通常,这些是紧急情况:火灾,洪水,断电,数据中心故障等。
虽然可用性管理实践并未忽略故障对服务提供者和消费者造成的负面影响但是单个组件的轻度中断也在流程中有所考虑。 - 二者目标不同。
可用性管理实践处理统计数据并分析趋势;
连续性管理关心如何应对破坏性事件。 - 可用性规划致力于满足当前和将来的商定要求,并避免出现偏差。
可用性管理实践发现并消除单点失效;
所采取的对策通常是积极主动的,以减少意外事态发生的可能性。 - 服务连续性管理实践专注于规划,以管理破坏性事件的严重后果。
备份站点,服务提供的替代方案的过渡,还有恢复程序,都可以减少损坏,但是通常不影响事件发生的可能性。
业务连续性在各个标准规范中的对比
特点/标准 | ISO 22301-2019 (业务连续性管理) | ISO 27001 (安全管理) | 应急管理 | 可用性管理 |
---|---|---|---|---|
主要焦点 | 业务连续性和恢复 | 信息安全 | 灾难和紧急响应 | 系统和服务的持续可用性 |
目的 | 确保关键业务功能在中断后能迅速恢复 | 保护信息资产的完整性、机密性和可用性 | 减少紧急事件的影响,保护生命和财产 | 优化和确保关键服务和应用的高可用性 |
方法 | 风险评估、业务影响分析、恢复策略 | 风险评估、选择和实施控制措施 | 预防、准备、响应、恢复 | 监控、维护和恢复服务 |
业务连续性的角色 | 核心组成部分 | 一个控制目标,确保信息安全在业务连续性事件中得到维护 | 在灾难后迅速恢复正常运营 | 通过技术手段确保服务不间断 |
与其他标准/概念的关系 | 可与 ISO 27001 整合 | 可与 ISO 22301 整合 | 与业务连续性和安全管理有交集 | 与业务连续性有交集,但更偏重技术层面 |
适用场景 | 任何可能面临业务中断风险的组织 | 任何需要保护其信息资产的组织 | 面临自然灾害、技术事故或人为事件的组织 | 依赖关键IT系统和服务的组织 |
五、业务连续性与灾难恢复(DR)
业务连续性管理(BCM)是一个全面的管理过程,预先定义了各种对组织运作能力有干扰的潜在影响,使组织能够容忍部分或全部业务能力的丧失所带来的影响。
灾难恢复DR
灾难恢复(DR)是在发生自然或人为灾害后,重新启用信息系统的数据、硬件及软件设备,恢复正常商业运作的过程。灾难恢复是的业务连续性管理的一部分,其核心是对企业的灾难性风险做出评估、防范,特别是对关键性业务数据、流程予以及时记录、备份和保护。
业务连续性管理(BCM)与灾难恢复(DR)是两个密切相关的做法,是指企业为了保持业务持续运行,为防范不可预见的风险所做的准备。
业务连续性管理更加宽泛,关注企业的战略,以保障业务运营为目标,解决全生命周期的问题,而灾难恢复更加注重具体操作,以系统为目标,着重解决事中的问题,同步处理事后的问题。
灾难恢复(DR)与业务连续性管理(BCM)的区别和联系
特点/标准 | 业务连续性管理 (BCM) | 灾难恢复 (DR) |
---|---|---|
主要焦点 | 整体业务流程和功能 | IT系统和数据 |
目的 | 确保关键业务功能在中断后能迅速恢复 | 在IT系统出现故障后迅速恢复数据和应用 |
方法 | 风险评估、业务影响分析、恢复策略 | 数据备份、系统恢复、备用站点 |
涵盖范围 | 整个组织的所有关键业务流程 | 主要是IT系统和数据 |
实施时间 | 在中断事件发生前、中、后 | 在中断事件发生后 |
与其他标准/概念的关系 | BCM通常包括DR作为其组成部分 | DR是BCM的一个子集 |
适用场景 | 任何可能面临业务中断风险的组织 | 依赖关键IT系统和数据的组织 |
联系:
- 互补性:业务连续性管理和灾难恢复是互补的。
BCM关注整个组织的连续性,而DR专注于IT系统和数据的恢复。 - 层次:DR通常被视为BCM的一个关键组成部分。
当组织制定BCM策略和计划时,它们通常会包括一个专门的DR计划来处理IT相关的中断。 - 目标:两者的最终目标都是确保组织能够在中断事件后迅速恢复正常运营。
六、灾备、容灾和业务连续性
常说的容灾系统就属于灾难恢复管理的技术范畴,这是一个完整的业务连续性大框架内的一个极为重要的部分。一般而言,建设灾备系统,需要根据业务的要求和投入规模,确定业务连续性管理的范围和程度,然后,针对IT容灾和恢复提出切实可行的方案。缺少任何一个环节,整个灾备体系的建设都是不完整的。没有IT容灾和恢复的技术实现,整个灾备体系的规划和计划就是无源之水和空中楼阁,根本没有根基。而没有一个完善的业务连续性体系,则使得整个业务的灾难后的连续运行无法有效进行,整个组织无法形成联动机制,做到危机响应和危机应急。
业务连续性计划是基于企业战略的、处理长期的、面向中断后维持业务连续性的规划,核心是业务连续;灾难恢复计划是面向重大的、灾难性的系统故障,在异地恢复业务暂时性正常运转的计划。
当业务连续性管理和灾难恢复结合到一个单一的项目中时,不能孤立地制订业务连续性计划或灾难恢复计划,要求企业管理人员和技术人员密切协作,制定切实可行的业务连续性和灾难恢复的计划和策略,保证业务连续性管理和灾难恢复有效联动。
根据监管要求,每年需对企业的业务连续性管理做持续更新,包括风险分析、业务影响分析、业务连续性管理策略或灾难恢复策略等。其次,随着企业业务需求不断增加,IT系统也需要经常更新升级。
灾备和备份的区别
容灾(Disaster Tolerance):就是在上述的灾难发生时,在保证生产系统的数据尽量少丢失的情况下,保持生存系统的业务不间断地运行。
容错(Fault Tolerance):指在计算机系统的软件、硬件发生故障时,保证计算机系统中仍能工作的能力。
区别:容错可以通过硬件冗余、错误检查和热交换 再加上特殊的软件来实现,而容灾必须通过系统冗余、灾难检测和系统迁移等技术来实现。当设备故障不能通过容错机制解决而导致系统宕机时,这种故障的解决就属于容灾的范畴。
什么是灾难恢复(Disaster Recovery):指的是在灾难发生后,将系统恢复到正常运作的能力。
区别:容灾强调的是在灾难发生时,保证系统业务持续不间断地运行的能力,而灾难恢复强调的灾难之后,系统的恢复能力。现在的容灾系统都包含着灾难恢复的功能,所以本文的讨论除了包括容灾方面的内容,还包括了 灾难恢复的部分内容。
容灾系统在企业中给与数据安全系数相当高的保障,但是容灾系统倒是是什么,他们是什么意思?恐怕连正在使用容灾备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释容灾备份到底是什么。
容灾和备份的目的不同
容灾系统的目的在于保证系统数据和服务的“在线性”,即当系统发生故障时,仍然能够正常地向网络系统提供数据和服务,以使系统不致停顿。
而容灾备份技术的目的与此并不相同,备份是“将在线数据转移成离线数据的过程”,其目的在于应付系统数据中的逻辑错误和历史数据保存。
所以,在各种容错技术非常丰富的今天,备份系统仍然是不可替代的。
备份是基石
备份是指为防止系统出现操作失误或系统故障导致数据丢失,而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。
备份是数据高可用的最后一道防线,其目的是为了系统数据崩溃时能够恢复数据。
容灾不可少
那么建设了备份系统,是否就不需要容灾备份系统?这还要看业务部门对RTO(恢复所需的时间指标)/RPO(能够恢复到的最新状态)指标的 期望值,如果允许1TB的数据库RTO=8小时,RPO=1天,那备份系统就能满足要求。同时,备份的目的在于应付系统数据中的逻辑错误和历史数据保存。只能够满足数据丢失、数据破坏时的数据恢复目的,而不能提供实时的业务接管功能。
因此,容灾系统对于某些关键业务而言也是必不可少的。人们谈及容灾备份往往是针对当生产系统,不能正常工作时,其业务可由容灾系统接替这些业务,继续进行正常的工作。
能够提供很好的RTO和RPO指标。同时远程容灾系统具备应付各种灾难,特别是区域性与毁灭性灾难的能力,具备较为完善的数据保护与灾难恢复功能,保证灾难降临时数据的完整性及业务的连续性,并在最短时间内恢复业务系统的正常运行,将损失降到最小。
容灾不能替换备份
容灾系统会完整地把生产系统的任何变化复制到容灾端去,包括不想让它复制的工作,比如不小心把计费系统内的用户信息表删除了,同时容灾端的 用户信息表也会被完整地删除。如果是同步容灾,那容灾端同时就删除了;如果是异步容灾,那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份,来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。
七、业务连续性与高可用
高可用(High availability,即 HA)的主要目的是为了保障「业务的连续性」,即在用户眼里,业务永远是正常(或者说基本正常)对外提供服务的。通常,高可用主要是针对架构而言,但其实高可用系统设计有一套比较科学的工程管理套路,要从产品、开发、运维、基建等全方位去考量和设计,高可用系统的设计思想包括但不限于:
- 做好研发规范,系统都是研发人员设计和编码写出来的,因此首先要对研发层面有一个规范和标准
- 做好容量规划和评估,主要是让开发人员对系统要抗住的量级有一个基本认知,方便进行合理的架构设计和演进。
- 做好服务层面的高可用,主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。
- 做好存储层面的高可用,主要是冗余备份(热备、冷备)、失效转移(确认,转移,恢复)等。
- 做好运维层面的高可用,主要是发布测试、监控告警、容灾、故障演练等。
- 做好产品层面的高可用,主要是兜底策略。
- 做好应急预案,主要是在出现问题后怎么快速恢复,不至于让我们的异常事态扩大。
可以使用一张图来表示高可用的设计思路。
BCM、容灾、灾备、高可用在数据中心的应用,BCM主要用于解决数据中心业务连续性两个方面的问题:
(1) 高可用性
是指提供在数据中心部分故障的情况下,仍能提供继续访问应用的能力。不论这个故障是业务流程、物理设施、IT软/硬件的故障。
(2) 灾难恢复
是指当灾难破坏数据中心时在不同地点、不同硬件设备上恢复数据的能力。上述两个方面不是相互孤立的,而是相互关联、有交叉的。为保证数据中心的业务连续性,高可用性和灾难恢复要映射到数据中心的各个层面,从用户终端到服务器、 存储器、甚至包括机房环境。国际标准ISO20000和ISO27001建立了规范的IT服务和信息安全的管理体系,在ISO20000的框架内,就包含了可持续性管理流程的内容。
八、总结:业务连续性、灾备、容灾、高可用
业务连续性是一套完整的管理体系核心目的是保障业务永远正常。在这样的目标之下需要一系列的管理方法、流程、制度、人员、技术去配套实现。因此,为企业重要应用和流程提供业务连续性应该包括以下三个方面:
- 业务连续性管理(BCM):
建立一套保障业务永远正常的保障管理体系; - 灾难恢复(Disaster Recovery):
指当灾难破坏生产中心时,在不同的地点恢复数据的能力。 - 高可用性(High availability) :指提供在本地故障情况下,能继续访问应用的能力。
无论这个故障是业务流程、物理设施,还是IT软硬件故障。
同时,上述三个部分不是相互孤立的,是相互关联,而且有交叉的,可以总结如下图:
实施业务连续性的关键动作
业务连续性行业生态,有哪些细分市场领域\
与业务连续性相关的厂商可以称之为一个细分的行业市场,这个市场中可以大致的分为以下几种:
咨询
主要是以ISO、GBT、DR、应急管理等相关标准、规范和行业指引为依据,进行与业务连续性管理落地、建设方案设计相关领域建设咨询、认证,DR建设、优化、维护以及容灾体系建设规划设计服务的相关咨询。代表厂商:
H3C https://www.h3c.com/cn/Service_New/Technical_Solution/Solution/Architecture_Consulting/Service/Tolerance/
北京同创永益
https://www.hatech.com.cn/h-col-134.html
中金数据
服务比较全,从体系建设咨询、业务影响分析咨询、演练咨询都有独立的内容,核心面向金融行业
https://www.centrin.com.cn/index.php/product/index/mid/18.html
业务连续性管理系统
这类业务主要是开发能够辅助业务连续性落地的管理系统,通常是以业务连续性理论为基础设计包含有业务连续性相关管理文档体系功能、IT应急管理与演练、容量管理、业务影响分析、混沌工程等功能的软件系统。神州信息
神州信息业务连续性和应急管理系统BCM,基于业务连续性全生命周期管理的设计理念,采用一体化的技术管理平台,将风险分析、业务影响度分析、预案开发和管理、应急演练、应急响应、应急恢复等业务连续性相关工作全面覆盖,形成完整的IT业务连续性管理闭环。
容灾与备份解决方案
这通常是很多与业务连续性市场分析报告中主要的内容,是一个非常大的市场,其不仅包括了企业级的容灾备份方案、企业级灾备方案、企业级灾备数据中心建设,还包括了针对个人备份与恢复的厂商和解决方案。尤其是云计算的发展,云备份容灾也是一个非常重要的领域。代表厂商中,这份市场报告BCM中写的比较详细。
https://www.shangyexinzhi.com/article/10174117.html
高可用方案
这个领域的厂商主要是被服务器、云计算、存储、网络等基础设施厂商为主导,也包含很多软件的高可用方案,通常是分为业务系统层、应用层和基础设施。代表厂商:所有服务器、云计算、存储等解决方案都有相关的高可用的方案。
九、写在最后
以下是对业务连续性管理(BCM)、应急管理、容灾恢复(DR)、容灾备份和高可用的总结,以及它们之间的联系和区别:
- 业务连续性管理 (BCM):
- 焦点:整个组织的所有关键业务流程。
- 目的:在任何形式的中断发生时,确保组织能够继续运营或尽快恢复正常运营。
- 应急管理:
- 焦点:对紧急情况或灾难的即时响应。
- 目的:减少紧急事件或灾难的影响,保护人民的生命和财产。
- 容灾恢复 (DR):
- 焦点:IT系统和数据的恢复。
- 目的:确保在IT系统中断后,可以迅速恢复正常运营。
- 容灾备份:
- 焦点:数据和信息的备份。
- 目的:确保在数据丢失或损坏时,可以迅速恢复数据。
- 高可用:
- 焦点:减少系统停机时间,确保关键服务的连续性。
- 目的:通过冗余、负载均衡和故障转移等技术手段,确保关键IT系统和应用的高度可用性。
联系和区别:
- BCM 是一个宏观的概念,它涵盖了组织在面对各种中断时的整体策略和计划。
而应急管理、容灾恢复、容灾备份和高可用都是实现BCM目标的具体手段或策略。 - 应急管理 更多地关注即时的响应和紧急情况的处理,而不仅仅是业务的连续性。
- 容灾恢复 和 容灾备份 通常被视为BCM的关键组成部分。
其中,容灾备份关注数据的备份,而容灾恢复关注IT系统的恢复。 - 高可用 是确保IT系统和应用的连续性的策略,它通过技术手段减少系统停机时间,从而支持BCM的目标。
简而言之,这些概念都关注组织在面对潜在的中断或故障时的准备和响应,但它们的焦点和方法有所不同。
转载自https://zhuanlan.zhihu.com/p/
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/124352.html