Flashduty 作为功能完备的事件OnCall中心，可以接入云上、云下不同监控系统，统一做告警降噪分派、认领升级、排班协同，已经得到众多先进企业的认可。我们采访了一些典型客户代表，了解他们的痛点、选型考虑和未来展望，集成本系列文章，以飨读者。

本次有幸在邹老板支持下访谈到途游资深运维工程师高工，聊一下“途游游戏”在 Flashduty 的实践经验。另外，也欢迎大家下载途游的游戏放松一下，哈哈。

除了途游，莉莉丝、悠星等游戏用户也是Flashduty的用户，场景大抵是类似的，废话不多说，让我们一起来揭开游戏公司 OnCall 的面纱。

1. 辛苦高工先简要介绍一下您所在的团队以及贵司的业务领域特点。

我们主要是游戏项目加平台服务，以非容器环境为主，部分平台类业务有使用K8s； 游戏项目大多是 go、python、java、c# 类后端，部署运行于虚拟机或者物理机上，通过运用开源的中间件、数据库构建起来游戏业务后端环境，整体资源以多云+机房IDC构成，部分项目资源使用云服务+虚拟机，部分为自建服务；整体监控场景和需求面涉及相对较为复杂。

2. 在使用 FlashDuty 之前，贵司是通过什么方式发告警的？主要痛点是什么？

我们一直是 Falcon、夜莺系 用户，之前没有 Flashduty 之前，我们通过自研的告警发送代理服务来对接 Falcon、夜莺 进行告警发送，最开始因为无任何收敛处理，有遇到 P0 电话告警把手机打爆只能关机的情况（抖动导致的大面积告警），也有把钉钉机器人发死的情况，短信发的无法正常接收短信，后来经过一些判断收敛处理，有一定的缓解，但自已改造的收敛逻辑仍是无法更高效的收敛，且处理逻辑相对较为复杂，同时也怕逻辑处理 BUG 掩盖掉正常的有效告警；还有一点是我们自己的告警发送服务没有值班机制，所有告警所有运维人接收，对短信、电话成本也是一种浪费，更为严重的问题是全组发送严重干扰大家的休息时间。

3. 贵司应该也用了多个监控系统吧，云上的、云下的，现在都对接了 Flashduty 么？效果如何？

现在我们夜莺 V6 通过对接 Flashduty，有效帮助我们落地监控 Oncall 值班机制，同时在告警收敛上，更为便捷有效；同时我们在云平台侧的云告警也对接到 Flashduty 后就也解决了告警无法有效触达以及无法值班处理的机制。

4. 在对接 Flashduty 过程中是否遇到一些问题呢？请问是如何解决的呢？

在对接 Flashduty 的过程倒是很顺利，使用较为便捷，只是告警模板上花了点时间进行定制修改，另外在 Flashduty平 台上的告警统计分析中，我们开始查看不太方便，后来通过告警事件的不同维度聚合（告警级别、告警标题等）展示更方便我们进行值班告警事件回顾闭环，使用起来很方便。

5. 您对 Flashduty 中哪几个功能设计最为认可？哪些功能切实解决了您的痛点？

1. 多平台对接，把不同平台的告警统一一个地方进行告警发送、OnCall值班，开箱即用；
2. 告警收敛效果很好，在默认收敛配置下降噪比平均在 80% 以上；

6. 对于未来有计划采用 Flashduty 的客户，您这边有什么实践经验分享么？

利用好值班功能及对应的升级，做好告警的责任分权，谁是第一负责人谁接收谁处理谁跟进，让用户自服务使用监控，运维做好指导培训；

小编注：途游的运维工程师在和研发工程师的协作过程中，扮演的是教练和 Platform 提供方的角色，这应该是一种典型的组织架构，让研发自助服务可以大幅提升人效，当然，前提是得有好 Platform 做支撑。

7. 这段时间下来，你使用 Flashduty 感受如何？对我们是否有一些建议？

当前很好用了，后面可以加一些智能的告警分析，比如哪些告警策略需要什么样的优化，在数据运营层面给我们做一些赋能。

另外目前其实已经能接入事件源，是否能把事件墙功能集成一下在 Flashduty 中，毕竟生产环境的故障 70% 都来自变更，如果能把变更事件统一化到一个地方呈现，对于故障定位是一个极大的助力。

小编注：这个功能其实已经提供了，可能高工不清楚，回头需要单独介绍一下这个功能啦，哈哈。

关于Flashduty