一种用于社交广告投放的报警方法及系统

技术领域

本发明涉及只能报警领域，具体涉及一种用于社交广告投放的报警方法及系统。

背景技术

微博社交广告投放流程十分复杂，各个环节既相互独立又相互依赖，一旦某个环节出现错误，则会导致整个投放过程失败。因此每个环节的系统的监控报警工作就十分的重要了。

目前，微博社交广告这边的系统大都采用SinaWatch监控系统进行报警，SinaWatch 是新浪自主开发的监控系统，它包括基础监控、系统监控、服务监控三种监控体系，通常业务方通过API接入服务监控从而实现报警，这种操作十分方便，支持邮件、短信报警，还支持聚合功能，即对一段时间内报警内容相同的报警信息进行聚合。

在实现本发明过程中，申请人发现现有技术中至少存在如下问题：

虽然SinaWatch监控系统接入成本低，操作方便，有基本的报警信息聚合功能，但它有明显的缺陷：当微博社交广告投放流程中某个上游环节出现差错就会导致所有依赖他的所有下游环节都相应的出错，从而使下游各个环节开发人员收到大量的报警信息，这些信息的表象可能是千差万别的，因此不满足SinaWatch聚合条件，但看似没有任何关联性的报警信息追其溯源都是同一个原因引起的，又因为各个环节消息不能及时互通，这就使得开发人员每天都被大量的重复的报警信息所轰炸着，同时也不容易找到问题的根本原因，不利于提升故障处理及时率。

发明内容

本发明实施例提供一种用于社交广告投放的报警方法及系统，通过过滤选择性的向工作人员发出报警信息，避免所有报警信息全部下发导致工作人员都被大量的重复的报警信息所轰炸，从而容易找报警对应的根本原因，提高故障处理及时率。

为达上述目的，一方面，本发明实施例提供一种用于社交广告投放的报警方法，包括：

接收广告投放系统在社交广告投放的某个操作环节出错时生成并发送的报警信息；广告投放系统为社交广告投放的每个操作环节设置报告出错的报警机制，所述社交广告投放包括依次执行的多个操作环节、且下游操作环节依赖上游操作环节的执行结果；

通过预先设置的报警规则对接收到的报警信息进行过滤；

当报警信息符合报警规则的下发要求时发出相对应的报警，当报警信息不符合报警规则的下发要求时，则不发出报警。

另一方面，本发明实施例提供一种用于社交广告投放的报警系统，广告投放系统为社交广告投放的每个操作环节设置报告出错的报警机制，所述报警系统包括：

接收单元，用于接收广告投放系统在社交广告投放的某个操作环节出错时生成并发送的报警信息；所述社交广告投放包括依次执行的多个操作环节、且下游操作环节依赖上游操作环节的执行结果；

过滤单元，用于通过预先设置的报警规则对接收到的报警信息进行过滤；

报警判定单元，用户当报警信息符合报警规则的下发要求时发出相对应的报警，当报警信息不符合报警规则的下发要求时，则不发出报警。

上述技术方案具有如下有益效果：为所述报警信息设置报警规则，当接收到报警信息时，通过报警规则对所述报警信息进行过滤，以确定是否对该报警信息发出报警；当报警信息符合过滤规则的下发要求时发出相对应的报警，而当报警信息不符合下发要求时，则不发出报警能将各报警信息。也就是通过过滤选择性的向工作人员发出报警信息，避免所有报警信息全部下发导致工作人员每天都被大量的重复的报警信息所轰炸，容易找报警对应的根本原因，提高故障处理及时率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例的一种用于社交广告投放的报警方法的流程图；

图2是本发明实施例的一种用于社交广告投放的报警系统的结构图

图3是本发明实施例的社交广告投放的报警系统的架构图；

图4是本发明实施例的另一报警流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，结合本发明的实施例，提供一种用于社交广告投放的报警方法，广告投放系统为社交广告投放的每个操作环节设置报告出错的报警机制，所述报警方法包括：

S101：接收广告投放系统在社交广告投放的某个操作环节出错时生成并发送的报警信息；所述社交广告投放包括依次执行的多个操作环节、且下游操作环节依赖上游操作环节的执行结果；

S102：通过预先设置的报警规则对接收到的报警信息进行过滤；

S103：当报警信息符合报警规则的下发要求时发出相对应的报警，当报警信息不符合报警规则的下发要求时，则不发出报警。

优选地，所述报警信息包括：报警ID、业务ID、报警内容、报警时间，所述业务ID 用于标识社交广告投放的某个操作环节内的某个具体操作事项；

步骤103具体包括：

S1031：针对任一业务ID，通过报警ID识别属于该业务ID的所有报警信息；当在预设时间段内接收到该业务ID下的第一个报警ID的报警信息时，根据该报警ID的报警信息发出相对应的报警；

S1032：针对在该预设时间段内接收到的属于该业务ID的其他报警ID的报警信息，则不发出报警。

优选地，所述报警规则包括报警处理值班机制；

所述用于社交广告投放的报警方法，还包括：

S104：根据报警处理值班机制设置值班表和故障等待时间；其中，值班表包括值班人员、相应的值班时间和备用人员，所述故障等待时间是指为值班时间内的值班人员预留的启动处理报警信息的时间段；

S105：当根据报警信息发出相应的报警时，根据报警时间匹配值班时间，将报警信息发送给当前值班时间所对应的值班人员；

S106：若值班人员未在故障等待时间内响应，则将报警信息发送给值班时间所对应的备用人员。

优选地，还包括：

S107：记录接收到的所有报警信息的详细情况并展示，所述报警信息的详细情况包括：业务ID、报警ID、报警时间、报警内容、报警标题、当前值班人员、对报警的处理转台、报警次数；

和/或；

S108：以业务ID为单位，归类统计任一业务ID下产生的报警信息并展示；

和/或；

S109：在报警历史可视化界面，通过报警时间顺序以时间轴的方式展示所有报警信息；

和/或；

S110：通过同一界面同时显示每个操作环节，且每个操作环节标记有是否报警、以及发出报警的操作环节所对应的接口。

优选地，步骤101包括：

S1011：通过报警信息接收接口接收报警信息，所述报警信息接收接口包括：应用程序接口，和/或，日志接入接口，和/或，手动创建的接口。

优选地，还包括：

S120：跟踪对发出的报警信息的处理状态，以及根据对报警信息的处理进度更改处理状态，其中，所述处理状态包括：未处理、调查中、解决中、等待中、已解决或者非故障。

如图2所示，结合本发明的实施例，一种用于社交广告投放的报警系统，广告投放系统为社交广告投放的每个操作环节设置报告出错的报警机制，所述报警系统包括：

接收单元21，用于接收广告投放系统在社交广告投放的某个操作环节出错时生成并发送的报警信息；所述社交广告投放包括依次执行的多个操作环节、且下游操作环节依赖上游操作环节的执行结果；

过滤单元22，用于通过预先设置的报警规则对接收到的报警信息进行过滤；

报警判定单元23，用户当报警信息符合报警规则的下发要求时发出相对应的报警，当报警信息不符合报警规则的下发要求时，则不发出报警。

优选地，所述报警信息包括：报警ID、业务ID、报警内容、报警时间，所述业务ID 用于标识社交广告投放的某个操作环节内的某个具体操作事项；

所述报警判定单元23包括：

报警子单元231，用于针对任一业务ID，通过报警ID识别属于该业务ID的所有报警信息；当在预设时间段内接收到该业务ID下的第一个报警ID的报警信息时，根据该报警 ID的报警信息发出相对应的报警；

截留子单元232，用于针对在该预设时间段内接收到的属于该业务ID的其他报警ID 的报警信息，则不发出报警。

优选地，还包括：

值班设置单元24，用于根据报警处理值班机制设置值班表和故障等待时间；其中，值班表包括值班人员、相应的值班时间和备用人员，所述故障等待时间是指为值班时间内的值班人员预留的启动处理报警信息的时间段；

当前值班匹配单元25，用于当根据报警信息发出相应的报警时，根据报警时间匹配值班时间，将报警信息发送给当前值班时间所对应的值班人员；

备用值班单元26，用于若值班人员未在故障等待时间内响应，则将报警信息发送给值班时间所对应的备用人员。

优选地，还包括：

第一展示单元27，用于记录接收到的所有报警信息的详细情况并展示，所述报警信息的详细情况包括：业务ID、报警ID、报警时间、报警内容、报警标题、当前值班人员、对报警的处理转台、报警次数；

和/或；

第二展示单元28，用于以业务ID为单位，归类统计任一业务ID下产生的报警信息并展示；

和/或；

第三展示单元29，用于在报警历史可视化界面，通过报警时间顺序以时间轴的方式展示所有报警信息；

和/或；

第四展示单元30，用于通过同一界面同时显示每个操作环节，且每个操作环节标记有是否报警、以及发出报警的操作环节所对应的接口。

优选地，所述接收单元21具体用于：

通过报警信息接收接口接收报警信息，所述报警信息接收接口包括：应用程序接口，和/或，日志接入接口，和/或，手动创建的接口。

优选地，还包括：

状态记录单元30，用于跟踪对发出的报警信息的处理状态，以及根据对报警信息的处理进度更改处理状态，其中，所述处理状态包括：未处理、调查中、解决中、等待中、已解决或者非故障。

下面结合具体的应用实例对本发明实施例上述技术方案进行详细说明，实施过程中没有介绍到的技术细节，可以参考前文的相关描述。

本发明为基于社交广告系统的报警追踪系统，基于SinaWatch服务监控系统进行二次开发，实现了报警信息智能分级，报警通知自动流转，报警信息持续状态追踪、报警信息关联性可视化、报警历史可视化、报警大盘等功能，并支持API接入、日志接入、手动创建等三种接入方式。架构图如图3所示，报警流程图如图4所示。

下面本文介绍功能实现方式。

1、报警信息智能分级(报警规则设置模块，相当于规则设置单元)

支持给每条报警信息设置报警规则，报警规则包括报警ID、业务ID、报警基本信息、值班表、故障等待时间、报警频次以及业务自定义规则等，当有报警信息到来时，系统将通过报警ID识别报警信息，根据其业务ID，按照报警规则进行报警。无论报警内容如何，一段时间(预设时间段)内同一业务ID的报警信息只报警一次，这个时间段内所有报警信息都会被记录，这样可以有效的减少同一时间段内相同原因的引起的重复报警，减少过多报警量对业务干系人的重复打扰。每次报警信息详细情况可以在报警信息展示模块查看 (第一展示模块)、报警次数与报警时间可以在报警历史可视化界面查看(第三展示单元)。

针对，同一业务ID的报警频次通常设置为：一个业务ID下面有多个报警ID，假设A接口挂了(出现问题了)，A接口的业务ID是A1，它以每分钟1次的频率报警，那么 5分钟以后，报警平台收到的报警信息ID 5个分别是1、2、3、4、5，第一条报警内容是：ID 1，业务IDA1，A接口挂了原因是XXX，时间是2020-09-03 11:50:00，第二条是ID 2，业务ID A1，A接口挂了原因是XXX，时间是2020-09-03 11:51:00以此类推。然后，假设我们设置A接口(业务IDA1)报警规则是:4分钟之内只报警给值班人员一次，那么值班人员收到的就是第一次报警内容是ID 1,业务ID A1，A接口挂了原因是XXX，时间是2020-09-03 11:50:00和距离第一次报警时间4分钟之后的第五次报警，报警内容是ID 5,业务ID A1，A接口挂了原因是XXX，时间是2020-09-03 11:55:00，其他报警信息只会记录在库不会通知值班人员。

报警判定单元，用于当报警信息符合过滤规则的下发要求时发出相对应的报警，而当报警信息不符合下发要求时，则不发出报警。

2、报警通知自动流转(值班配置模块，相当于值班匹配单元以及值班备用单元)

支持值班机制的配置，当有报警信息接入时，会第一时间通知当前值班人员，若当前值班人员未在故障等待时间内响应，则会通知备用值班人员，比如：其他值班者或其直属上司，保证任何故障都可以及时响应处理。

3、报警信息持续状态追踪(状态持续追踪模块，相当于状态记录单元)

支持报警的状态有未处理、调查中、解决中、等待中、已解决、非故障等6种状态，当报警刚产生默认为未处理；值班人员收到报警可将其更改为解决中；若需要依赖其他流程或者其他业务节点处理的，则可当前处理流程人为hold住，将其更改为等待中；若问题解决则更改为已解决；若判断不是故障则更改为非故障。这样可以保证任何报警信息都能得到及时响应处理并产生最终处理结果，也方便其他人员了解故障处理进度，为后续开发者对报警原因、解决办法进行复盘提供故障快照。

4、报警信息关联性可视化(第二展示单元)

支持将多个报警信息通过业务ID关联起来，可以在报警信息展示模块进行查看，这样方便开发者快速定位到多个故障的根本原因，从源头上解决一系列关联报警问题。

5、报警历史可视化(报警历史可视化模块，相当于第三展示单元)

将报警历史通过时间轴的方式呈现给开发者，方便开发者对故障详情、故障发生原因、故障发生频率、故障发生时间、故障影响面有一个更具体更直观的判断。

6、报警大盘(相当于第四展示单元)

支持报警大盘功能，界面端如同显示设备，能够观看报警系统服务对象的所有环节，后台则进行相应的统计，使得开发者可以在大盘上查看同一时间内正在报警的系统、接口有哪些，方便开发者第一时间找到报警业务和系统，定位问题，也方便相关业务关注者和上层管理者了解整个广告投放流程系统的运营情况。

7、所述接收单元

通过报警信息接收接口接收报警信息，所述报警信息接收接口包括：应用程序接口，和/或，日志接入接口，和/或，手动创建接口。

本发明所取得的有益效果如下：

与SinaWatch监控系统相比，本设计实现了报警信息智能分级，报警通知自动流转，报警信息持续状态追踪、报警信息关联性可视化、报警历史可视化、报警大盘等功能。优点如下：

1、报警信息智能分级

能将各报警信息按照业务ID、报警原因(报警内容)、报警值班人、故障等待时间、频率分级，同时结合系统自定义优先级，将业务发生故障后，第一时间推送给值班人员以及相关订阅责任人，简单描述报警原因。在设定报警频率内，同一报警内容不会被重复推送到值班人员，保证减少相同报警信息的打扰，避免“开发人员每天频繁面对海量的报警信息很容易产生麻木感，导致忽略一些重要的报警邮件，或对一些小问题响应的不及时，最终埋下安全隐患”。同时报警信息会被记录，在未解决问题前，报警信息待解决时间持续增加。另外，本次报警信息详细情况可以在报警信息展示模块查看，避免“没有可视化界面，只能通过邮件、短信查看，面对大量的报警邮件、报警短信很难从中进行报警原因的整理和复盘，不利于开发人员进行系统维护与优化”。

2、报警信息自动流转升级

在报警时间持续增加，问题未被标记正在处理或者处理完毕等下一状态前，能结合业务设置的报警级别信息，自动将报警推送给值班人员或者业务责任人上一级负责人或者 backup，保证问题能得到及时响应解决。避免“各个系统报警信息各自为政，开发者很难第一时间判断报警是由自身系统引起的还是上游系统引起的；上层管理者很难对整个投放流程的系统的运营情况有个正确的认知”。

3、报警信息持续状态追踪

除了更多的报警状态设计，也将这些状态转化成状态机，循序向下流转，便于每个流程节点追溯处理情况。同时，增加业务原因溯源标记，将引起本业务故障原因追溯，若非本业务引起报警而由上游引起，可将报警原因推送至上游业务负责人，由上游解决，同时本级降级处理。

4、报警信息关联可视化

可将本业务多个报警信息通过相同业务ID和模块ID通过视图形式关联起来，展示各报警异同信息，便于问题快速定位解决。

5、报警历史可查可视化

能追查历史节点各报警信息，并做成相关统计视图，可按照时间轴和故障曲线查看本业务出现的各种故障统计。同时，支持按照故障影响级别和故障类型对故障进行分类统计。

6、报警大盘

将所有业务做成报警大盘，对正在报警的业务、接口、系统进行统计，同时对所有业务运行情况进行诊断，给出各时段业务系统的水位情况。从大盘中可以直接进入到某一业务系统或者接口，查看相关报警设置信息等，方便各业务干系人查看，也方面全局查看公司广告业务情况。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本文给出的实施例，而是与本申请公开的原理和新颖性特征的最广范围相一致。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrative logical block)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrative components)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。

本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM 存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。