贝壳找房一站式报警平台建设实践

背景介绍

KeMonitor是贝壳找房服务端一站式监控报警平台。2018年～2020年是业务的快速发展阶段，在这期间陆陆续续研发了基于CAT、Prometheus、ELK、Skywalking、以及部分自研专有数据监控平台，大大小小攻击十余个监控系统，各系统均自行建设了各自的报警能力。报警发生之后，一线研发同学就会同时打开多个平台，去看基础设施监控、应用监控、日志等，五花八门的报警也给用户带来了最多的痛点。在此背景下具有一站式体验的KeMonitor平台就应运而生了。在2021年，由贝壳找房人店技术中心牵头，联合了多个部门，针对在报警环节进行了系统性的治理，治理报警的过程中也沉淀了一套完善的报警中心以及配套的报警响应SOP机制，下面会为大家详细介绍整体的建设经验。

问题及挑战

在2020年年底进行了一次面向公司范围全体研发的用户调研，用户的诉求主要是希望项目组牵头对公司范围的研发侧同学日常收到的报警进行系统性治理。分析用户调研问卷的问题集合，一类是是报警太分散，缺少一站式平台化的能力来系统性的根治报警漏报、报警风暴、误报等问题；另外一大类问题就是在研发习惯层面对于如何补齐监控项以及报警如何治理的经验的缺失。

平台治理能力问题

主要是涉及到报警的一系列“灵魂拷问”，该如何解决？

1. 报警入口/触达太分散，报警不统一五花八门

2. 报警太多，每一天，需要很大的精力来响应报警

3. 关键的报警漏掉了，没发对人，也没有人及时跟进

4. 发给我的的报警，本身就不合理，并不适合我的系统特点，我应该如何治理？

   
   

技术运营层面问题

1. 如何快速推进大家补齐监控？

2. 如何形成一套标准的报警处理SOP机制？

解决思路

报警治理需要按照事前、事中、事后进行全生命周期的管理。

基于一线业务研发团队实践中的总结，监控/报警的成熟度，分为三个阶段：

详细的报警分阶段治理以及报警成熟度模型，如图1所示：

图1 报警生命周期& 报警成熟度阶段

报警治理到成熟阶段的数据表现如图2所示，该案例节选自人店技术中心的某技术团队，从图中我们可以清楚的看出，随着一段时间的报警治理、Review、复盘，报警量整体上会呈一个下降的趋势。

图2 报警治理趋势图

实现上述效果，在工具层面，则需要针对报警全生命周期管控的线上化平台——KeMonitor报警中心。

平台能力介绍

KeMonitor报警中心主要给大家提供完善的工具端的支持以及一套标准的报警SOP处理范式，以便大家能够更好的将报警治理进行落地。图3是报警中心的全景图，报警中心主要起到连接用户（研发——管理者&一线研发、DBA）以及监控能力提供方的衔接作用，核心解决在研发过程中，对于报警事件已经发生之后的最后一公里投递给到研发同学的痛点。

图3 报警中心能力全景图

一、统一配置（事前）

1）报警元信息标准化

在治理之前，大部分报警规则除了触发阈值之外，仅有触达方式一项可以进行配置，为了更好的治理报警，我们在报警规则元信息配置中增加了如下信息：

如图4所示，用户以及通用报警能力提供方，均可针对报警规则添加的元信息，便于在事中阶段的问题止损&问题定位环节提效。

图4 报警元信息标注

完成元信息标准化之后，报警内容中可以携带更多的定位、止损信息，减少用户上下文切换操作其他各平台的时间损耗，详细如图5所示：

图5 标准化报警文案

2）报警分级

根据不同等级的服务，报警也需要设定为按照轻重缓急去有针对性的报警，不同的报警需要研发同学投入的关注度也是不同的，因此通过合理的分级机制。

详细分级标准细则参考健康分的约束，0级报警共计2款，1级报警共计12款：健康分-监控/报警分规则

图6 报警等级

3）报警完备度度量机制

报警规则覆盖完备度，是应用建设完善的监控体系，需要首先关注的点，因为你只有覆盖的报警场景足够全面，才能够提前发现更多的隐患。在前文元信息标准化度量的功能，标注报警场景，即可具备度量能力。

通过Top健康分技术运营活动，我们也梳理出来了，能够符合绝大多数应用的监控范式：这也能够回答一系列的灵魂拷问，什么时候应该加监控？日志需要怎么记？应用监控应该注意什么？

报警场景如下：

图7 必选报警场景

图8 可选报警场景

二、报警订阅（事中）

报警的触达，并不是只有我给用户发短信、发邮件、发企微、发机器人消息，关键在于怎么合理的使用上述触达方式，避免漏报问题。

1）统一报警接收人

提供的资源监控统一串联编排逻辑，以根治漏报。由于公司的监控体系众多，公司范围内发给研发的报警有8个以上（日后还有可能继续增加）的监控报警能力提供方，如果有多套报警接收主体或者如果有人员的入离调转，或者组织结构调整。这些都会产生潜在的漏报问题，实际生产过程中2021年上半年也出现过此类问题导致的故障。这里通过服务视角的应用监控|日志监控(hawk、metric-dog-dog、fast、ketrace)、服务关联的基础设施（Redis、MySQL）监控|报警体系，建立：应用、人、组织、资源的监控|报警关联关系，来系统性的解决这样的问题。编排逻辑，如图4所示：

图9 统一报警接收人编排机制

关于服务和实际的维护人员的组织关系的映射的长效治理机制，我们在健康分规则机制进行约束，考察一个服务的报警接收人，必须包含当>=2个当前部门的研发人员。这样即可保障，不会出现最低级报警人员的遗漏的问题。

承接这一数据能力的系统，由私有云以及服务云来完成，如图8所示：

图10 应用视角报警接收人

2）统一报警触达方式

报警规则覆盖面不齐，同时设计的足够灵敏之后，带来的一个问题就是报警量过多，在触达通道中如果都混在一起，很难保证能够看完每一条报警，这往往会导致报警漏报；同时，报警平台多还会伴随而来的问题，就是报警触达应用号多（10个以上），这也会导致大家难以兼顾看每一个号，这就又产生了漏报。因此在触达方式层面，有分级应用号、报警机制人两种新机制来收口触达，避免漏报。

2.1）触达应用号分级

针对第一个问题，主要通过设定不同等级的报警，不同等级的报警发送到不同应用号，这样报警的组织是按照重要性来划分，不是按照报警类型来划分，这样即可减少用户的理解成本。大家日常仅需要把主要精力投入在最关键的报警应用号，对于非关键的报警应用号，可以采取定期筛查的方式来进行处理。图9、图10、图11是分级报警应用号的截图示意：

图11  分级报警应用号

2.2）报警机器人提醒

机器人提醒的机制，最核心的价值是，机器人所在的群，在组织结构上对齐了生产过程中物理组织——研发小组（5～20人）、部门（20～50人）、业务线（50～100人）；同时形成了从总监、经理、一线员工的报警管理互相监督的管理动作，是一种精细化触达的机制，研发同学如图12所示配置完成开启哪些种类的报警之后，在报警触发之后即可出现如图13所示的机器人消息提醒。

图12 报警机器人提醒配置

图13报警机器人提醒文案

机器人消息提醒机制，不仅只是简单的增加一种触达方式，而且还增加了@人跟进报警、处理误报、填写报警解决纪要、定位问题的快捷入口、解决问题的快捷入口等智能提醒机制，这些机制会在下文详细介绍。

3）报警值班

报警联动值班机制，也是降低漏报问题的一种最佳实践，同时也能够提高跟进效率。

有了值班机制之后，每天都有专人来跟进稳定性保障。在报警响应方面，该同学会第一时间响应报警，确保报警第一时间有人相应。这样的机制，除了保证报警不会遗漏之外，还能够更高效利用研发资源，不至于研发同学都同时跟进报警，造成不必要的浪费。

图14 关联keOnes值班表

图15 报警联动值班

三、报警响应（事中）

事中阶段，最重要的是针对已经发生的报警，第一时间进行响应，并且将处理结论进行及时同步，对应如下几种情况：

1、如果是问题需要立即进行解决

2、如果是误报或者报警阈值设计不合理，则需要及时调整下线报警规则，或者调整阈值，或者进行消息免打扰操作

3、如果报警是合理的，但是影响十分轻微，只是一般性的提醒，则需要对报警级别进行调整修正，修正成2级报警

4、如果是正在处理中的报警，预计需要处理一段时间，期间会持续产生报警，则无需过多的占用大家的关注度，可以设置临时性的设置报警屏蔽，做消息免打扰操作。

这一系列机制，都通过绑定了精确的研发部门的报警机器人来承载此项能力，下面是报警跟进的流程详细操作步骤，供大家参考：

（1）报警发生时，会通过appId找到对应的企微机器人发送消息，发送如下消息，表明报警类型、内容、@人（值班人、服务负责人按优先顺序决定）

图16 机器人提醒【我来跟进】

（2）消息中可点击【我来跟进】按钮（请在当天内点击，过了当天点击无效），点下即进行了跟进（默认为当天以来到未来5分钟的当前标题都会自动跟进），在弹出的页面可以修改上述默认值（其他标题、未来时间段）。

图17 填写跟进明细

（3）同时机器人会立即发送如下消息，让群内周知跟进情况：

图18 报警已跟进消息通知

（4）被跟进范围涵盖的新来的报警（follow步骤2中的跟进时效），会显示这样的样式，说明无需再跟进：

图19 已经跟进报警再次触发

（5）如果在步骤（1）中点击的是【误报】，则会对该次报警标记成无效类型，同时可进行消息【免打扰】，临时或者永久屏蔽该报警。

图20 标注无效报警

（6）报警解决

从上述报警跟进通知的企微消息（步骤3）“填写处理结论”可以进入报警历史页面。

在该appId的报警历史中，按照报警类型+报警标题+是否已处理 聚合展示条目

可判断哪几类报警是同一件事情、同一个原因、同一种解决方案，可以勾选上，点击“批量处理”，从而创建了一个处理，关联上了多个报警

图21 批量处理报警

创建的当时可填写结论：

图22 填写处理结论

结论目前有这么几种可选，能够描述大家碰到的绝大部分情况：

• 待排查 ：还待排查定位原因

• 报警不合理 ：正常现象，报警阈值或口径不合理

• 外部故障 ：本部门范围外的已知原因的故障、事件引起的联动报警，外部恢复之后自动恢复。无需处理

• 计划内 ：计划内操作引起的（例如压测），无需处理

• 即将下线 ：即将下线，暂不处理。此时建议填写计划解决时间

• 无影响 ：已知原因，无影响，暂不处理

• 未排期 ：已知原因，应该生产变更，还未有排期或技术方案不明

• 已有排期 ：已知原因，应该生产变更，已有排期，还未开发完成或上线。此时建议填写计划解决时间

• 已处理 ：已通过生产变更解决

填写结论并且提交之后，企微机器人会发送通知：

图23 报警已解决群提醒

2）多级onCall机制

多级onCall机制主要针对最重要的报警，这类要保持足够的关注度，是保证最核心的报警不会发生漏报的“核武器”，如未能保证在规定的时效内跟进动作的完成，则开始通过精细化的按照组织结构层级进行逐级电话通知，第一级oncall通知【值班人】/【服务owner】，第二级通知经理，第三级通知总监，每一级默认3分钟。通过这样的机制，即可保证从一线研发再到以上的研发组长、研发经理、研发总监以及各稳定性保障角色，均能够第一时间知晓潜在，保持信息通畅。

3）报警屏蔽

报警屏蔽，主要解决的问题是治理无效报警、减少误报，或者用于减小报警信息对于研发的不必要打扰。报警屏蔽，业务层面适用于临时的屏蔽掉由于某些原因，临时不收报警机器人群提醒或者报警消息（定点给某个人发送的，短信、邮件、企微应用消息、回调等），典型案例如下所示

1、某台机器下线，先临时屏蔽这个报警，避免轰炸

   如：企业微信和短信收到报警，只想屏蔽该服务这条类型的报警 5分钟

图24 临时屏蔽报警

2、由于某些原因，某些发送到群内的消息提醒，如：业务报警、或者提醒类型的报警，无需转发到大群

3、某些通用型的报警规则，由于业务特点，不适用该应用的所有的应用场景。比如：GC STW时长的报警、或者kafka消费积压超过2000报警

   如：服务操作的传统机器“停服”，之后越来越多项目上云后应该会有同样操作。这应该是预期内的正常停服下线，不用报警，所有相关的通用报警信息全部屏蔽

图25 字段屏蔽报警

4、上线过程中，比如：KeMonitor上面有个checkServicePort的检测，默认是3分钟，我们有的服务起来要大于3分钟，导致就会在监控群里误报，可以进行字段粒度的屏蔽。

4）报警自愈

如果报警期间，已经出现了故障，此时最重要的举措就是执行预案，做止损/恢复的动作。绝大多数情况，一个系统的常见的止损/恢复动作，都是固定的，有固定的操作步骤，如：重启、摘流、熔断、开关等；同时，一般情况也能够从一些报警能够反映出来，如系统依赖下游长时间响应慢，这种需要执行降级。在报警文案内叠加上止损恢复的快捷入口，能够大幅减少上下文切换（浏览器输入地址切换专有止损/恢复系统）的时间，从而达到提效的效果。

图26 报警自愈快捷入口

四、报警复盘（事后）

事后阶段，主要是用来系统性的分析，一个长跨度时间范围的报警以及解决情况，分析系统瓶颈点，这里就需要在报警解决环节，填写完备的原因以及举措，详细如图26所示：

图27 报警解决纪要

五、自助化接入

报警中心面向监控/报警能力提供方（如：DBA、SRE等基础服务提供方等角色），还提供了报警规则等的一键导入、报警消息触达的一站式联调能力。

图28 报警自助化接入

在接入平台化改造之前，需要一人周时间的报警规则列表、报警触达的对接集成，目前最快仅需要10分钟即可完成自助化接入。

总结

通过对于报警的系统性治理，沉淀而来的报警中心，系统性解决的治理漏报、治理误报/报警风暴等问题，同时提升了报警响应、止损恢复、定位问题等环节的效率。下面三点，是最具贝壳特色的几点举措。

KeMonitor平台的下一步建设重点就在于进一步提升平台体验体验。在报警报警套餐的基础之上，进一步对监控指标进行模版化、”傻瓜化“的治理，会基于贝壳技术体系的基础设施以及技术栈进一步细化梳理指标口径定义、指标释义、报警阈值设定建议、定位问题、快速止损恢复专家建议，以及增加模版化配置能力，形成完备监控指标集市，便于用户更方便获取全面的监控能力。