统计与埋点 · 运维与监控

监控什么

• 机器：CPU、内存、磁盘、带宽
• 服务：进程存活、接口 P99、错误率
• 业务：在线人数、开局数、支付成功率

报警阈值

不要照抄别人的阈值。先用一周真实数据算出基线，再按基线的 2~3 倍设阈值。没有基线的报警只会让人麻木。

日常动作

1. 每天看一次错误日志汇总
2. 每周做一次数据库备份恢复演练
3. 每月清理一次磁盘与过期日志
4. 每次发布前留回滚点

这套系统的运维要点

自建或第三方。注意：事件命名混乱。

容量与扩容

记录峰值并发，预留 50% 余量。扩容优先加从库与网关节点，最后才考虑升配机器——升配是成本最高的做法。

发布流程怎么定

小团队也值得做三件事：代码进 Git、发布走脚本、发布前打标签。这样出问题能回滚到具体版本，而不是「大概是昨天那个改动」。

发布窗口选在低峰，发完盯 15 分钟再离开。有灰度能力就先发一台。

备份的三条铁律

第一，备份要异地；第二，备份要能恢复（至少演练一次）；第三，备份文件不能含明文密钥。三条都做到，才算有备份。

要点回顾

• 先确认交付边界：服务端源码、数据库脚本、后台是否齐全
• 先用最小环境跑通「登录-开局-结算-提现」主链路
• 上线前准备备份与回滚，上线后建立性能与错误基线
• 统计与埋点的长期成本在运维与运营，不在首次采购

以上是针对统计与埋点的实操梳理。不同团队的基础不同，落地时按自己的进度取舍，不必一次全做。

常见误区

在统计与埋点上，最常见的三个误区是：把功能数量当成能力、把演示当成交付、把上线当成结束。运维与监控阶段真正要确认的是可维护性——半年后还有没有人能改得动这套代码。

可维护性的判断方法很朴素：让开发把「数据团队」这一处逻辑讲一遍，讲不清就说明代码和文档都没跟上。

一句话小结

统计与埋点的运维与监控，本质是把不确定的部分提前确认：交付边界、技术栈（自建或第三方）、以及最容易翻车的 数据团队。这三点确认清楚，剩下的都是执行问题。