很多 TikTok 团队的网络监控停留在"出问题了去查"的阶段：直播卡了才知道卡了，断流了才知道断了。这种被动模式的问题在于——观众已经流失、订单已经错过、团队已经手忙脚乱，而问题的根因可能几小时前就出现了。真正有效的监控体系的价值不在于展示大量图表，而在于能在业务受损前发出预警，并把告警送到能做决策的人手上。本文介绍 TikTok 业务监控告警体系的搭建方法，包括分层指标设计、告警规则制定与降噪处理。
<>TikTok 一、监控的三层结构>
TikTok 业务的监控应当分三层，每层解决不同的问题：
| 层次 | 关注对象 | 回答什么问题 | 典型指标 | 响应方式 |
|---|---|---|---|---|
| 业务层 | TikTok 业务动作 | 业务是否正常 | 成功率、推送成功率 | 业务决策 |
| 链路层 | 网络路径 | 问题在哪一段 | RTT、丢包、带宽 | 技术排查 |
| 资源层 | 节点与设备 | 瓶颈在哪里 | CPU、内存、连接数 | 资源调整 |
>TikTok 为什么业务层最重要> <
>在 TikTok 业务实践中，业务层指标是唯一能证明"业务真的没问题"的依据。链路层与资源层都是间接指标——它们可以正常但业务仍失败，业务也可以成功但链路指标不好看。只有业务层能作为最终判定标准，其他层的价值在于帮助定位原因。> <
>TikTok 二、告警设计的四条原则>
<>TikTok 1. 每条告警都要有明确的行动>
<
>就 TikTok 运营而言，收到告警的人必须知道该做什么。如果一条告警无法对应到具体动作，它就只是噪音。比如"CPU 使用率超过 80%"需要说明：是否需要扩容、是否需要排查特定进程、什么情况下可以忽略。> <
>TikTok 2. 告警要分级，不能一律对待>
| 级别 | 触发条件 | 通知方式 | 响应时限 | 示例 |
|---|---|---|---|---|
| P0 紧急 | 核心业务不可用 | 电话 + 群消息 | 3 分钟 | 直播推流全部中断 |
| P1 严重 | 业务明显受损 | 群消息 + 推送 | 10 分钟 | 成功率跌破 95% |
| P2 一般 | 指标偏离正常 | 群消息 | 1 小时 | 带宽利用率超 80% |
| P3 提示 | 轻微波动 | 日志记录 | 不响应 | 单次抖动 |
>TikTok 3. 告警必须能定位到范围>
一条好的告警应该明确指出"哪个出口、哪个业务组、哪个时间段"出现了问题。只说"TikTok 服务异常"的告警没有价值。
<>TikTok 4. 误报率必须可控> <
>结合 TikTok 实际场景，如果告警误报过多，团队会逐渐麻木，最终忽视所有告警。这是监控系统失效最常见的原因。宁可少报也不要滥报。> <
>TikTok 、告警阈值的设定方法>
<>TikTok 1. 基于基线而非拍脑袋>
<
>对 TikTok 团队来说，阈值应基于历史数据的分布来定，而不是直接用经验值。操作方法：>
- 采集至少两周的正常业务数据；
- 计算各指标的均值、标准差与极值分布；
- 阈值设在"正常波动上界+ 一段余量"的位置；
- 上线后根据误报情况微调。
>TikTok 2. 关键指标的推荐阈值>
| 指标 | P0 阈值 | P1 阈值 | P2 阈值 | 依据 |
|---|---|---|---|---|
| 推流成功率 | < 90% | < 98% | < 99.5% | 业务直接受损 |
| 请求成功率 | < 80% | < 95% | < 99% | 业务直接受损 |
| 链路丢包率 | > 10% | > 2% | > 0.5% | 基线分布 |
| RTT 延迟 | > 500ms | > 300ms | > 200ms | 业务场景要求 |
| 带宽利用率 | > 95% | > 90% | > 80% | 容量规划 |
| CPU 使用率 | > 95% | > 90% | > 85% | 性能余量 |
| 磁盘可用空间 | < 5% | < 10% | < 20% | 日志写入中断 |
>TikTok 3. 持续时长要求> <
>围绕 TikTok 链路，瞬时抖动不应触发高等级告警。多数指标应加"持续时长"条件，例如"丢包率持续 3 分钟超过 2%"才告警。这能显著降低误报。> <
>TikTok 、四、降噪的五个实用手段>
- 聚合告警：同类告警在时间窗口内合并成一条，避免刷屏；
- 依赖抑制：节点离线时，抑制该节点上派生的其他告警；
- 静默期：已处理的告警在恢复前不重复通知；
- 维护窗口：计划内变更期间静默相关告警；
- 分级通知：P2 及以下只在工作时间通知，P0/P1 才做全天候通知。
<>TikTok 、告警的响应流程>
告警的价值在于驱动行动，因此必须有配套的响应流程：
- 确认：收到告警后确认是否为真实问题（区分误报）；
- 定级：判断实际影响级别；
- 处置：按预案执行，切备用出口或降级运行；
- 恢复确认：业务指标恢复正常后再关闭告警；
- 记录：把处理过程记录到故障库，作为知识积累。
>TikTok 、六、常见问题与改进>
- 问题：告警太多无人处理 → 改进：按分层治理，P2 以下合并到日报，只有 P0/P1 实时推送；
- 问题：阈值不合适频繁误报 → 改进：基于基线重设，并加持续时长条件；
- 问题：只有技术侧收到告警 → 改进：业务层告警直接推送给运营负责人；
- 问题：告警了但不知道怎么处理 → 改进：每条告警必须绑定处置手册。
<>TikTok 、总结>
TikTok 监控体系搭建的核心原则是：业务层为最终判定依据，链路与资源层用于定位原因；每条告警对应明确行动；阈值基于历史基线设定；用聚合、抑制、静默四类手段控制噪音。真正有效的监控不是展示多少图表，而是能否在业务受损前把信息送到能做决策的人手上。所有监控建设都服务于合规业务的稳定运行。需要了解各区域 TikTok 出口的监控指标范围与节点分布时，可到 tiktokjiasu.com 的节点专区查看技术说明。
如果你要搭建 TikTok 业务的监控告警体系，可访问 tiktokjiasu.com 查看各区域节点的部署信息与线路参数，据此规划监控采集点与告警规则；实际配置与价格以官网实时页面为准，建议先按上表建立关键指标的基线数据，两周后再确定正式阈值。
