FlashDuty协作空间的设计逻辑和路由逻辑

协作空间设计逻辑

简单来讲：公司每天可能产生数千条告警，如果放到一个页面处理就太混乱了，通常是以团队粒度划分协作空间，不同团队的告警互不干扰。团队成员可以关联OnCall值班表，只有值班的时候处理告警，其他时间就可以专注干一些长线的事情。

当然，如果公司业务相对比较小，所有的告警都发到一个统一的协作空间来处理，也是可以的。

故障升级逻辑

另外，如果我的协作空间中收到一个告警，比如是我的服务调用第三方服务不通了，可能是网络问题，可能是第三方服务的问题，此时需要多个团队的人来协同处理，怎么办？为此我们引入了故障的概念，使用故障来协同多个团队，你可以把服务调用不通的告警事件升级为故障，然后拉其他团队的人进来一起处理，大家可以在这个故障下面发表评论、贡献排查线索、附加止损手段等。

故障是全局的，是横跨所有协作空间的。

告警事件路由逻辑

一般监控系统都支持Webhook和第三方系统对接，FlashDuty就是利用各个监控系统的Webhook机制和这些监控系统对接。比如夜莺来举例，有两个地方可以配置Webhook，一个是全局的、一个是告警规则级别的。我们分别介绍一下这个逻辑。

全局Webhook

首先去FlashDuty的集成中心，创建一个夜莺的集成：

给集成起个名字，比如“测试环境的夜莺”，创建成功之后点击这个集成，可以看到详情页面，详情里有接口地址，一个类似于下面的地址：

https://api.flashcat.cloud/event/push/alert/n9e?integration_key=xx

注意，这个地址中有个参数integration_key，起到了鉴权的作用。然后把这个地址配置到夜莺的全局Webhook中就可以了，告警事件就可以推上来了。

但是，告警事件虽然上来了，应该进入哪个协作空间呢？这就需要在各个协作空间配置订阅规则，订阅自己感兴趣的告警事件，整个逻辑如下图：

告警策略里的Webhook

另一种接入方式是使用告警策略里的Webhook，既然是告警策略里的Webhook，理论上，这个策略触发的告警我们是知道应该交由哪个协作空间来处理。所以，直接去协作空间下面创建专属集成就可以了，如图：

专属集成的url长成下面这样：

https://api.flashcat.cloud/event/push/alert/n9e?integration_key=xx&channel_id=yy

多了一个channel_id参数，channel就是协作空间的意思，相当于推送告警的时候直接就路由到这个协作空间，无需配置订阅规则了，整个逻辑如下图所示：

寻求帮助

FlashDuty右上角有个视频教程的入口，可以查阅