数据中心MTBF和AFR如何计算与应用?

服务器 芯片 服务器运维
避免关键数据中心出现故障始终是头等重要的任务。如何才能确信自己实施的解决方案是可靠的?MTBF是比较可靠性最常用的方式。不过,如果没有透彻地了解MTBF,可能就无法实现业务可靠性目标。

【51CTO.com独家特稿】避免关键数据中心出现故障始终是头等重要的任务。如果短时间的停机可能会对业务的市场价值产生负面影响,那么,支持这个网络环境的物理基础设施就一定要可靠。

如何才能确信自己实施的解决方案是可靠的?MTBF(MTBF,MeanTimeBetweenFailure,即平均无故障时间)是比较可靠性最常用的方式。不过,如果没有透彻地了解MTBF,可能就无法实现业务可靠性目标。如果故障定义不明确或者假设不现实或被曲解,MTBF就毫无意义。

本文说明应如何使用MTBF以及将MTBF用作规格和选择依据时的限制。本文还提供一个核对表,作为确保公平有效地进行跨系统比较的指导性原则。

一、MTBF的比较性分析的现实方式

预测MTBF有多种可用方法,似乎不可能找到使用同一方法的两个系统。不过,还是有一种方法可以适用于大多数组织的各种不同过程。

现场数据评估方法使用实际的现场故障数据,因此能够提供比模拟情况更准确的故障率评估。对于小批量生产的产品或新产品,此数据可能找不到;不过,对那些已在现场获得广泛应用的产品,应该始终采用此数据。因此,对于跨系统比较,从现场数据评估开始比较是最合理也是最现实的。请注意,此方法与其他许多方法一样,都是基于第78号白皮书中讨论的稳定故障率假设。

本白皮书介绍完成此方法的步骤,列举并说明各个步骤中可能影响结果的可变因素。如果要进行比较的系统间的关键假设或可变因素发生变化,那么评估这些变化对MTBF估计结果的可能影响就非常重要。图1说明现场数据评估过程的时间线。随后的过程步骤将说明时间线中的每个元素。

数据中心如何执行有效?MTBF计算与应用全教程 
图1   现场数据评估过程的时间线

第1步:定义并估计抽样总体的大小

确定年故障率(AFR)并最终确定产品的MTBF的过程中,***步是确定要分析的特定产品抽样总体。是基于特定产品型号还是整个产品系列进行计算?此抽样总体中产品的生产时间跨度应该多大(以天或月计)?生产日期何时开始何时结束?为抽样总体选择的产品应该在设计方面非常相似,并具有足够多的数量以保证所采集数据的统计有效性,这非常重要。

第2步:确定采集数据的样本时间范围

过程的第二步是确定从抽样总体中采集故障数据的样本时间范围。通常在产品的用户给供应商报告故障时采集数据。抽样总体中产品的最晚生产日期和样本期间开始日期之间的适合时间间隔,因产品、地理位置、分销过程和库存地点不同而有所差异。例如,如果产品在工厂仓库中储存两个月,在分销渠道中历时两个月,那么最早只能在抽样总体中最晚产品生产日期的四个月后开始进行抽样。对于需要通过批发商、经销商和零售商这些环节的产品,四个月被视为是考虑上述可变因素的合理时间范围。

下面说明两个重要的可变因素:(1)抽样总体中产品的最晚生产日期和样本期间开始日期之间要有足够的时间间隔;(2)数据采集窗口要足够大,以确保结果的可信度。

如果抽样总体中产品的最晚生产日期和样本期间开始日期之间没有足够的时间间隔,那么在抽样总体中的产品得到完全部署之前可能就已经开始进行抽样了。这种情况可能会造成两种结果。***,由于尚未部署的产品不可能出现故障,所以有低估故障率的倾向。第二种结果就是样本期间很可能包括大量的安装故障或设置故障。因为新产品的故障率可能会显示为一个标准的“浴缸”型,所以包括大量安装故障可能会导致高估故障率。尽管我们知道这两种相反的效果都很明显,但也不能指望他们能互相抵消。

在抽样时间方面,另一个需要考虑的重要问题是窗口的持续时间。需要多少天才能充分采集故障数据?采样时间窗口必须选得足够宽,以便可以从样本中移除统计“干扰”。获得合理准确度所需的持续时间取决于抽样总体的大小。例如,大批量产品可能需要一个月时间,小批量产品可能需要几个月时间。

第3步:定义故障

必须准确定义故障,确保评估过程的一致性后,才能开始统计故障。

现在假设在“故障”产品返回工厂时,是由每个技术人员单独定义故障。某位技术人员可能只统计那些出现重大故障的产品,而另一位技术人员可能统计所有出现了故障(包括重大故障)的产品。这两种极端的做法使得准确评估特定产品故障率的可能性几乎为零,当然更不能准确评估对该产品的过程控制所产生的影响。因此,在诊断任意产品之前,供应商必须对故障有一个明确的定义。在计算特定事件的MTBF时,供应商可能有多种不同的故障定义。例如,UPS供应商会试图评估导致关键负载停用的故障的MTBF以及负载能够继续运转的不很严重的故障的MTBF。

第4步:接收、诊断和修理产品

样本期间结束时间和AFR计算时间之间必须有足够的时间间隔,以允许一定的时间来接收、诊断和修理报告为有故障的产品。诊断结果确定故障类型,而修理将会验证诊断结果。体积较小的产品通常会发回供应商处,这会导致出现接收延迟或需要一定的产品递送时间。产品到达供应商处后,必须对其进行诊断和修理,这会导致另一个称为诊断延迟的延迟。大型产品通常在客户处进行诊断和修理,因此基本没有延迟。在上述任一情况下,都需要在计算AFR前诊断和修理产品。

如果是大批量产品,很可能在诊断延迟结束时仍然有需要修理的产品。在这些情况下,有时会做出未修理产品和以前修理过的产品出现故障的机率相等这样的假设。取决于待评估产品的生产量和产品类型,接收延迟和诊断延迟可以在样本期间结束时间后加上几个星期,您可以在此时间点计算AFR。

#p#

第5步:计算年故障率

计算年故障率是用来说明某个特定产品在一个日历年度内的预期故障数。计算此数值的***步是“按年计算”故障数据。将样本期间中的故障数乘以每年的样本期间数,可以得出此值。第二步就是确定整个抽样总体的故障率。将计算出来的每年故障数除以抽样总体期间安装的产品数,可以得出此值。下面是公式1:

数据中心如何执行有效?MTBF计算与应用全教程 

此公式有如下两个假设:(1)产品一年365天、每天24小时连续运转(2)抽样总体中的所有产品都在同一时间开始运转。因此尽管此公式可以用于任意产品,但更适用于连续运转的产品。如果已知要安装的产品是间断运转的,那么使用公式2计算AFR更准确。备用的应急发电机系统就是这种类型产品的一个示例。

数据中心如何执行有效?MTBF计算与应用全教程 

使用此公式,AFR仅考虑产品实际运转的时间。实际上,公式1和公式2是不同假设条件下的同一公式。下面的假想示例说明当分析一个非连续运转产品时二者的差别有多大:

本抽样总体有10,000辆汽车。在2个月(样本期间)内,要采集此抽样总体的故障数据。平均而言,一辆汽车每年运转400个小时。在这2个月内,有10辆汽车出现故障。

使用公式1:
故障率为10个故障x(每年52个星期/样本期间为8个星期)/抽样总体中有10,000台装置=0.0065或0.65%。

使用公式2:假设这些产品同时*开始运转,抽样总体的运转时间为每年10,000x400小时=每年累计4百万小时或,000,000/8760小时=累计457年。故障率为10个故障x(每年52个星期/样本期间为8个星期)/累计457年=0.14或14%

【请注意,此假设是为了简化这个示例。现实情况是产品在整个期间内都有销售,因此实际运转时间将比上面的数字小,导致AFR值变大。】

如果上面的示例是以连续运转产品为例,那么两个AFR值将相等。即使取消所有产品同时开始运转这个假设,AFR值仍然非常接近。因此,了解产品是连续运转还是非连续运转对于进行正确地分析至关重要。

第6步:将AFR转换为MTBF

将AFR转换为MTBF(以小时计)是所有步骤中最容易的,不过可能也是最常被误解的。只有在故障率稳定这一假设下,将AFR转换为MTBF才有效。下面是此公式:

MTBF=一年内的小时数/AFR=8760/AFR 公式3

使用AFR评估过程对MTBF计算结果抽样

下面的假想示例有助于说明整个过程。

第1步:确定抽样总体全部为“X”牌15kVAUPS系统,是在2003年的第36周到第47周(9月1日至11月21日)生产的,生产窗口时长共12周。抽样总体共2000台装置。

第2步:确定采样窗口从2004年2月2日开始,至2004年7月16日结束。选择这一采样窗口时,考虑了在产品库存和分销过程中会有10周的延迟。

第3步:将故障定义为由任何原因(包括人为错误)引起的关键负载停用。

第4步:在样本期间,总共报告了二十起故障。其中,九起故障被划分为关键负载停用故障,其他故障为非关键故障。因此,根据第3步中确定的故障定义,下面计算中使用的故障数为九。已经在计算AFR之前接收、诊断和修理了出现故障的产品。

第5步:AFR计算如下:
AFR=(9个故障*每年52个星期/样本期间为24周)/抽样总体中有2000台装置=0.00975=0.975%

第6步:MTBF计算如下:
MTRF=8760/AFR=8760/0.00975=898,462小时

#p#

二、影响AFR的可变因素

大多数情况下,用户是从供应商处获取MTBF值,不带有任何用于证实这些数值的相关数据。如上所述,当查看多个系统的MTBF值(或AFR值)时,了解分析所用的隐含假设和可变因素(特别是定义故障的方式)非常重要。比较时若忽视了这一点,比较结果出现偏差的可能性就会变大,可能会出现500%或更高的偏差。最终可能导致不必要的业务支出甚至意外停机。

一般来说,必须有明确的可变因素定义、假设定义以及故障定义,才可以比较两个或更多系统间的MTBF值。即使两个MTBF值看起来很相似,仍然有比较结果出现偏差的可能。因此,必须弄清MTBF结果后面隐含的内容,并仔细研究和领会这些数值所包含的含义。

下面将介绍每个可变因素,并说明他们可能对结果产生的影响。附录中提供一个核对表,可以用于比较两个或多个系统间的可变因素。完成比较后,必须再检查一下核对表,以确定系统间有哪些不同的可变因素。通过逐一严格分析这些不同的可变因素及其对MTBF的影响,可以确定比较是否公正并可以作为产品规格或购买决策的关键标准。

产品功能、应用和边界

在比较两个或更多MTBF值之前,验证被比较的两个产品是否同类非常重要。被比较的产品必须在功能、性能及应用方面相似。如果被比较的产品是UPS,则产品功能就是为连接的负载提供备用电源。此产品的用途可能是用来支持数据中心环境中的关键IT负载。如果没有相似的应用,就不可能进行公正的MTBF比较。例如,对工业用途和IT用途的UPS进行比较是不切合实际的。

更重要的是,MTBF比较中所用系统的边界必须等同。如果各个系统的定义方式不同,那么不可避免地会出现比较偏差。我们以使用外部电池的UPS系统为例。某些供应商可能选择不包括由这些电池导致的故障,因为他们位于系统“外部”,不是系统的一部分。其他供应商可能选择包括电池故障,因为这些电池是系统运转的必要组件。图2说明此示例。其他可能导致不一致边界的组件包括输入和输出电路断路器、旁路系统、保险丝和控制系统。用户应该向供应商咨询MTBF计算中应包括哪些组件或子系统,不应认为所有供应商定义系统的方式都相同。

数据中心如何执行有效?MTBF计算与应用全教程 
图2   比较UPS系统的“边界”


稳定故障率假设

要使计算AFR和MTBF的现场数据评估方法有效,必须假设被分析产品具有稳定的故障率。很重要的一点就是要判明此假设对于被比较产品的类型是否合理。对于电子系统或组件,这个假设通常可以成立。该产品是否属于这一类?如果不属于,计算出来的值可能不会是预期故障的代表性值,进行公正比较的可能性就很小。

抽样总体大小

在明确产品及其应用非常相似后,很重要的一项工作就是审查现场数据采集过程。在这里,定义抽样总体大小(生产的产品数量)是***个关键的可变因素。如果抽样总体中定义的产品数量太少,那么得出的MTBF估计值就很可能没用。因此,比较MTBF值时,确保每个值都是基于足够大的抽样总体大小,这是非常重要的。

尽管被比较产品的生产率可能不同,但需要着重考虑的是抽样总体中的产品数量。如果某个产品的生产率较低,那么此产品的生产时间范围应该比较大,以便能够达到一个合适的产品数量。例如,供应商“A”在一个月内生产1000台产品,而供应商“B”在一个月内生产50台“同类”产品。对于供应商“B”,抽样总体中应包括若干个月生产的产品,以确保结果的统计有效性;对于供应商“A”,一个月内生产的产品就够了。

抽样总体中产品的最晚生产日期和样本期间开始日期之间的时间间隔如果抽样总体范围的结束时间和样本采集期的开始时间之间没有足够的时间间隔,那么AFR和MTBF值可能是不准确的。被比较的每个系统的供应商必须为其抽样总体提供足够时间,以便在开始采集故障数据之前系统可以完成库存及分销过程。

例如,如果某个特定产品通常在库房中存放一个月后,进入分销过程(历时一个月),那么评估故障前设定的最短时间应该是两个月。总“等待”时间因产品类型而异。由于要进行比较的产品类型应该相似,所以总体期间和样本期间之间的时间应该相似。如果某个供应商明显没有足够的等待时间或根本没有等待时间,那么他们的系统AFR可能会低于实际值,在比较这些值时要特别注意。

样本数据采集期

正如在此过程第2步中所指出的那样,选择合适的样本数据采集期非常重要。如果被比较的系统具有相同长度的采样窗口,并且具有相似的生产量和/或销售量,就可以进行公平比较。不过,情况并不总是这样。如果各个系统的数据采集期时间不同,那么单独地评估每个系统,确定其是否能够反映准确的故障率就很重要。

产品数量越少,窗口应该越长。例如,如果某个供应商每个月的产品产量为10台,用一个月时间来采集故障数据,时间就不充分。因为产品数量少,所以用这个月内报告的故障(如果有)来推断前几个月的故障率,可信度很低。

故障定义

如果两个可比较产品间的故障定义不同,那么进行故障分析就象比较苹果和橙子一样毫无意义。因此,要进行有效的MTBF比较,一项基本任务就是准确分析每个被比较产品的故障组成。因此,对于MTBF计算,供应商应该将哪些故障统计在内?

将用户误用导致的故障统计在内是否有用?设计者可能忽视了许多人为因素,这将导致用户很容易误用产品。

在电源保护行业中,UPS故障的最常见“定义”是“负载停用”故障。这表示向负载供电超出了可接受范围,导致了负载停止运转。不过,将由供应商维修技术人员导致的负载停用统计在内是否有用?产品设计本身是否会提高风险程序出现故障的可能性?

如果计算机上的LED(发光二级管)出现故障,是否属于故障(虽然它没有影响计算机的运行)?

如果耗材(例如电池)的使用期比预期的时间要短,是否属于故障?

运输造成的损坏是否属于故障?这可能表明包装的设计不当。是否将重复出现的故障统计在内?也就是说,对于同一用户使用的同一系统内诊断结果相同的故障,是重复计数还是仅计数一次?

安装过程导致的故障是否统计在内?此故障可能是供应商技术人员引起的。如果用户没有购买推荐的维护合同或监视系统,是否将故障统计在内?如果地震导致建筑物损害,使得系统出现故障,是否将故障统计在内或将其视为“天灾”?

是否将系统外某些组件的故障统计在内?对于UPS系统,系统外组件可能是电池或旁路开关。如果出现连锁故障,导致后续系统停机,是将每个系统的故障都统计在内还是仅统计***个系统的故障?

如果某个系统进行了“自定义”设置,是否将该系统的故障从抽样总体中排除?

工业中用来计算MTBF的实际故障定义可能会有一些衍生情况。上面列出的只是一小部分。因为将许多异常情况统计为故障,所以MTBF值所反映的系统性能比实际使用情况更可靠。要为合作伙伴和用户提供AFR和MTBF值,比较MTBF值时需要一个明确的故障定义。

有三个直观定义:
类型0 该产品有一个妨碍其运转的缺陷或故障。
类型I 产品整体失效,无法实现其所应实现的功能。
类型II个别组件失效,无法实现其应实现的功能,但不是产品整体失效,无法实现该产品应实现的功能。

除了了解每个供应商选择的定义,还必须明确是否包括人为故障。在MTBF计算要包括人为失误的情况下,比较MTBF值可能更困难。这是因为有多种可能导致故障的人为失误,使得供应商需要筛选出与人为失误相关的故障。如果所有供应商都没有筛选出相同类型的故障,那么系统比较结果就很值得怀疑。

要说明这一点,我们仍然以上面的“X”牌产品为例。表1比较当存在不同的故障定义时的MTBF值。

系统“A”是“X”牌产品,其故障被定义为严重(类型I)故障,包括所有人为失误和耗材故障类型。系统“B”是同一“X”牌产品。其故障同样为仅有类型I故障,但不包括人为失误导致的故障、连锁故障以及耗材故障。根据MTBF公式的性质,在样本期间即使一个故障差额也可能对MTBF结果产生很大影响。在此示例中,有5个系统故障差额(系统A有9个,系统B有4个),MTBF按125%变化。故障定义很容易且常常被误解,就象此示例中所示,可以看出有效比较和无效比较的差别。

数据中心如何执行有效?MTBF计算与应用全教程 

数据中心如何执行有效?MTBF计算与应用全教程 

为了减少这种不一致性,APC为您建议了一种***方案,用于定义MTBF值所包括的内容。此***方案是基于向用户展示所有合理故障这一目标而建立的。这些故障应该代表供应商控制的所有故障情况。例如,如果故障是由供应商的维修技术人员引起的,MTBF应该反映这个情况,因为此故障属于供应商的责任。另一方面,如果用户选择雇佣第三方维修人员,是维修人员引发了故障,MTBF不应该反映此情况,因为它已经超出了供应商的控制范围。附录中的对照表指明哪些定义是此***方案的组成部分。

只要有可能,此故障***方案定义应该用于比较供应商间的产品。如果供应商只能够提供此定义的子集,那么从其他被比较的供应商获取同一子集是很必要的。再次说明,此一致性对于公平比较是非常必要的。不过,尽管这可以促成“公平”比较,但并不能很好地反映现实。供应商包括的故障子集越小,MTBF值与实际情况距离越远。

样本期间结束日期和AFR计算日期之间的时间间隔

如果某个供应商可以接收、诊断和修理样本期间内报告的所有产品故障,则可以立即计算AFR。事实上,对于在客户处进行诊断和修理的少量产品,这是可行的。但是,如果是运回制造商处的大量产品,就不能这样。对于相似产品类型的MTBF比较,样本期间结束日期和AFR计算日期之间的延迟应该相似。例如,假设供应商“A”在样本期间结束的一个月后计算AFR,供应商“B”在样本期间结束的四个月后计算AFR。如果被比较的产品是大批量产品,供应商“A”报告一个令人满意的AFR的可能性更大。这是因为某些“故障”产品(尚未接收、诊断和修理)不计入AFR计算之内。

在某种条件下,系统之间的时间范围差异未必会导致无效比较(其他所有情况都等同)。这个条件就是,当所有供应商都假设未修理的产品与以前修理过的产品的故障率相同并且已经接收、诊断和修理了大部分返回产品。

#p#

制订的数据采集和分析过程

要评估MTBF比较的可信度,很重要的一点就是要了解每个供应商已制定好的数据采集和分析过程。一个明确定义的已文档化的过程对于实施稳定的质量控制系统至关重要。有助于确保整个分析步骤的一致性和准确性。以下三个示例说明需要特别注意的过程问题。当上述问题或其他问题很明显时,应该严格地检查这些问题对MTBF估计结果(及最终比较结果)的影响。
供应商无法准确跟踪全球范围数据,因为全球不同地区使用的故障及修理数据的跟踪系统或存储系统不尽相同。数据缺失或不正确可能会导致评估全球产品的AFR时出现错误。

对于已归类的返回产品,供应商没有明确定义的过程。如果因无条件退货返回的未使用和未开箱产品被分类为因故障返修,将导致AFR变大。

供应商的跟踪系统大部分都是手动的。过程中涉及的人为因素越多,数据出错并最终导致AFR计算出错的可能性就越大。通常,过程的自动化程度越高,结果就越准确。比如,自动扫描序列号,而不是手动向系统中键入号码,这就是一种自动化。

计算中使用的AFR公式

取决于产品的不同,各个供应商使用的AFR公式(公式1或2)可能会使得MTBF比较无用。比较连续运转的产品(一旦启用)可以使用两个公式之一,但比较间断运转的设备仅可以使用公式2,否则该比较无效。

表2说明在何种情况下进行的比较有效。

表2–AFR公式比较表

产品运转方式 使用的AFR公式1  使用的AFR公式2

连续运转产品比较,
即UPS“A”与“B”(二者都作为关键负载的备用电源)

有效比较 有效比较

间断运转产品比较,
即膝上型计算机“A”与膝上型计算机“B” 

无效比较 有效比较

一年内的小时数

只有在稳定故障率的假设下,将AFR转换为MTBF才有效。在这种情况下,可以使用公式3,不过请确认要比较的所有系统使用的小时数(一年内)相同,这一点很重要。例如,某些供应商每年使用8,000小时,而有些供应商则使用8,760小时。

三、除MTBF外的决策标准

尽管MTBF可以作为产品规格之一,并作为选择产品(当方法、可变因素和假设对于所有要比较的系统都相同时)的有力依据,但它决不是唯一的标准。当评估多个供应商的产品时,还有许多应该考虑的其他标准。例如,供应商的整体质量控制过程的稳健程度如何?生产产量如何,处于何种环境下?是否通过ISO9000认证?满足这些标准就会提供一个优化质量和可靠性的标准化过程。每个产品满足用户需要的程度如何?这可能需要考虑诸如产品灵活性或模块性、快速故障恢复能力(MTTR)和产品的总拥有成本(TCO)。其他比较方式可能着眼于客户推荐产品或产品评估。

最终,可以考虑对两个或多个系统使用公正的第三方评估,以确保可以选择到最适合的产品规格并制定出***的购买决策。

结论

比较多个产品时,MTBF通常是关键的决策依据。不过,比较这些值时,需要注意以下事项。首先,预测MTBF值的方法必须相同。另外,在采集和分析现场数据过程中将用到许多可变因素和假设,其中的每一项都可能对结果产生重要影响。如果可变因素和假设不一致,那么就不可能进行公平的MTBF比较。实际情况是这些可变因素和假设通常都是不一样的。附录中的对照表可以帮助您确定属于哪种情况。另外,使用MTBF在线计算器可以确定关键可变因素对MTBF值的影响。

了解本白皮书提供的基础内容后,现在可以更公平地比较MTBF。如果使用了相似的假设和可变因素并且故障定义相同,那么比较结果就具有一定的可信度。

只需4分钟,就能清楚的了解您的数据中心效率是多少,点击下面连接即刻参加数据中心效率测试
https://www.apcc.com/tools/registration/promo/RegisterCustomer.cfc?ISOcountrycode=cn&method=getPromo&keycode=45545f

下载《适用于高效率、高密度数据中心的改进型架构》技术白皮书

https://www.apcc.com/tools/registration/promo/RegisterCustomer.cfc?ISOcountrycode=cn&method=getPromo&keycode=45547f

【编辑推荐】

  1. 调查显示机柜部署面临难题 成本问题最受关注
  2. 数据中心未来负载的估算方法(图)
责任编辑:老杨 来源: 51CTO.com
相关推荐

2015-06-30 13:27:26

数据中心云计算

2015-11-04 09:43:12

数据中心欧洲美国

2023-12-04 14:05:26

数据中心边缘计算

2018-10-28 15:33:29

边缘计算数据中心网络

2022-07-06 13:55:57

数据中心云计算存储

2024-01-30 00:42:29

数据中心IT基础设施

2011-10-31 17:56:11

互联网

2014-02-13 09:03:15

数据中心云计算

2018-07-28 05:07:27

云计算数据中心公共云

2023-04-12 16:21:00

数据中心云计算边缘计算

2024-03-12 11:54:50

数据中心量子计算

2020-08-03 10:42:03

数据中心环境电源

2023-09-21 17:28:38

数据中心

2024-03-12 14:45:07

边缘数据中心服务器能源消耗

2020-06-11 09:32:39

数据中心IT技术

2021-03-02 09:11:56

云计算边缘计算数据中心

2021-01-15 10:28:19

数据中心边缘数据中心

2012-07-06 13:31:05

EVB虚拟化数据中心

2015-07-02 13:36:58

数据中心云计算

2022-12-30 14:47:36

数据中心架构
点赞
收藏

51CTO技术栈公众号