Flashduty 作为功能完备的事件OnCall中心，可以接入云上、云下不同监控系统，统一做告警降噪分派、认领升级、排班协同，已经得到众多先进企业的认可。我们采访了一些典型客户代表，了解他们的痛点、选型考虑和未来展望，集成本系列文章，以飨读者。
核心要点
- 途游游戏的后端环境以非容器场景为主，部分平台业务使用 K8s，整体资源横跨多云和机房 IDC。
- 在使用 Flashduty 前，途游主要通过自研告警发送代理对接 Falcon、夜莺，曾遇到电话、短信和 IM 告警风暴。
- 接入 Flashduty 后，夜莺 V6 和云平台告警被统一纳入 OnCall 值班、告警收敛和分派升级流程。
- 途游认可 Flashduty 的多平台接入、默认收敛效果和告警统计分析能力，默认配置下降噪比平均在 80% 以上。
- 对类似游戏团队而言，关键经验是先明确告警责任边界，让第一负责人接收、处理并跟进告警。
本次有幸在邹老板支持下访谈到途游资深运维工程师高工，聊一下“途游游戏”在 Flashduty 的实践经验。除了途游，莉莉丝、悠星等游戏用户也是 Flashduty 的用户，场景大抵是类似的：游戏业务环境复杂、告警来源多、夜间响应要求高，OnCall 机制必须能把关键告警准确送到负责人手里。
下面是这次访谈的核心内容。
途游游戏的业务和监控环境
Question：辛苦高工先简要介绍一下您所在的团队以及贵司的业务领域特点。
Answer：我们主要是游戏项目加平台服务，以非容器环境为主，部分平台类业务有使用 K8s。游戏项目大多是 Go、Python、Java、C# 类后端，部署运行于虚拟机或者物理机上，通过运用开源的中间件、数据库构建起来游戏业务后端环境。
整体资源以多云+机房 IDC构成，部分项目资源使用云服务+虚拟机，部分为自建服务；整体监控场景和需求面涉及相对较为复杂。
这类环境下，告警管理不能只看单个监控系统是否可用，还要看不同来源的告警能否统一收敛、分派和复盘。
使用 Flashduty 前的主要痛点
Question：在使用 Flashduty 之前，贵司是通过什么方式发告警的？主要痛点是什么？
Answer：我们一直是 Falcon、夜莺系用户。之前没有 Flashduty 之前，我们通过自研的告警发送代理服务来对接 Falcon、夜莺进行告警发送。
最开始因为无任何收敛处理，有遇到 P0 电话告警把手机打爆只能关机的情况（抖动导致的大面积告警），也有把钉钉机器人发死的情况，短信发的无法正常接收短信。后来经过一些判断收敛处理，有一定的缓解，但自己改造的收敛逻辑仍是无法更高效的收敛，且处理逻辑相对较为复杂，同时也怕逻辑处理 BUG 掩盖掉正常的有效告警。
还有一点是我们自己的告警发送服务没有值班机制，所有告警所有运维人接收，对短信、电话成本也是一种浪费，更为严重的问题是全组发送严重干扰大家的休息时间。
从这段经验看，途游要解决的不是“能不能发告警”，而是三个更底层的问题：
- 告警风暴时，如何避免电话、短信和 IM 被重复打爆。
- 多个监控系统并存时，如何让值班人员看到同一个处理入口。
- 告警触达之后，如何明确谁负责认领、升级、跟进和复盘。
多监控系统如何接入 Flashduty
Question：贵司应该也用了多个监控系统吧，云上的、云下的，现在都对接了 Flashduty 么？效果如何？
Answer：现在我们夜莺 V6 通过对接 Flashduty，有效帮助我们落地监控 OnCall 值班机制，同时在告警收敛上，更为便捷有效；同时我们在云平台侧的云告警也对接到 Flashduty 后，就也解决了告警无法有效触达以及无法值班处理的机制。
也就是说，Flashduty 在途游的角色不是替代原有监控，而是作为统一事件 OnCall 中心，承接 Falcon、夜莺和云监控等来源的告警事件，并在后续环节做收敛、通知、认领、升级和统计分析。
接入过程中的配置经验
Question：在对接 Flashduty 过程中是否遇到一些问题呢？请问是如何解决的呢？
Answer：在对接 Flashduty 的过程倒是很顺利，使用较为便捷，只是告警模板上花了点时间进行定制修改。
另外在 Flashduty 平台上的告警统计分析中，我们开始查看不太方便，后来通过告警事件的不同维度聚合（告警级别、告警标题等）展示，更方便我们进行值班告警事件回顾闭环，使用起来很方便。
对游戏运维团队来说，告警模板和统计维度通常需要贴合自身值班习惯。接入完成后，建议优先检查两件事：
- 告警卡片是否包含值班人员判断问题所需的关键信息。
- 告警统计能否按告警级别、告警标题、业务对象等维度支持值班复盘。
途游最认可的 Flashduty 功能
Question：您对 Flashduty 中哪几个功能设计最为认可？哪些功能切实解决了您的痛点？
Answer：
- 多平台对接，把不同平台的告警统一一个地方进行告警发送、OnCall 值班，开箱即用；
- 告警收敛效果很好，在默认收敛配置下降噪比平均在 80% 以上。
这两个反馈对应了告警治理中的两个关键指标：入口统一和噪音下降。前者让团队不用在多个工具里来回切换，后者减少无效触达，降低告警疲劳。
给其他团队的实践建议
Question：对于未来有计划采用 Flashduty 的客户，您这边有什么实践经验分享么？
Answer：利用好值班功能及对应的升级，做好告警的责任分权，谁是第一负责人谁接收谁处理谁跟进，让用户自服务使用监控，运维做好指导培训。
小编注：途游的运维工程师在和研发工程师的协作过程中，扮演的是教练和 Platform 提供方的角色，这应该是一种典型的组织架构。让研发自助服务可以大幅提升人效，当然，前提是得有好 Platform 做支撑。
这条建议的重点是责任模型。统一告警平台只有和组织内的值班表、升级策略、服务 owner 配合起来，才能真正把“全组收到告警”变成“正确的人处理正确的告警”。
对 Flashduty 的后续建议
Question：这段时间下来，你使用 Flashduty 感受如何？对我们是否有一些建议？
Answer：当前很好用了，后面可以加一些智能的告警分析，比如哪些告警策略需要什么样的优化，在数据运营层面给我们做一些赋能。
另外目前其实已经能接入事件源，是否能把事件墙功能集成一下在 Flashduty 中，毕竟生产环境的故障 70% 都来自变更，如果能把变更事件统一化到一个地方呈现，对于故障定位是一个极大的助力。
小编注：这个功能其实已经提供了，可能高工不清楚，回头需要单独介绍一下这个功能啦，哈哈。
FAQ
Q1：游戏公司为什么需要独立的 OnCall 平台？
A：游戏业务通常存在多语言后端、多云和 IDC 混合部署、夜间故障响应要求高等特点。单靠监控系统发消息，容易出现告警风暴、多人重复接收、无人认领等问题。OnCall 平台的价值在于把告警收敛、值班、分派、升级和复盘串成闭环。
Q2：Flashduty 在途游主要解决了什么问题？
A：根据访谈内容，Flashduty 主要帮助途游统一夜莺 V6 和云平台告警，落地 OnCall 值班机制，并通过告警收敛降低噪音。
Q3：接入 Flashduty 后还需要优化告警规则吗？
A：需要。Flashduty 可以承接统一分派和收敛，但源头告警策略、模板内容、服务 owner 和统计维度仍需要团队持续治理。途游也提到希望未来能获得更智能的告警策略优化建议。
关于Flashduty
🛎️ Flashduty 中心化告警处理，在正确的时间通知正确的人
💸 每一分钟都很关键，降低故障时间，就是赚钱
🖇️ 您常用的监控系统，我们都可以集成
告警事件的及时处理，对于线上稳定性保障至关重要。一款中心式的告警事件 OnCall 中心，去除告警风暴，确保告警不遗漏，还能分析故障处理的MTTA、MTTR等效率指标，先进的团队需要拥有，快来免费体验吧：https://www.flashduty.com
