同时在线|思考：数据分析与数据后台设计( 二 )_arpu|游戏

与上一例中游戏同时在线人数监控一样，SLB的监控需要极细的时间力度，且非常快速的数据计算，以便运维及服务端工程师及时的了解当前情况，避免服务产生异常。
监控数据是整个数据分析环节的基础，所有的想法均来源于每一次监控获取的信息。对于监控数据，需要达到以下几个要求方能保证监控的质量与效率：

数据计算要高时效性；
数据时间粒度小；
数据指标精简，核心；
以可视化图表体现。

前两点在举例过程中已有说明，细粒度的时间与快速的计算相应可以及时及客观的响应。由于监控是一个高频的行为，我们不可能针对实验或者产品运行中的每个关注指标都进行监控，所以监控数据时，根据目的必须挑选最为核心、重要的指标监控。
为了保证监控的效率，像我毕业设计时一样依靠人工记录数据的方式十分低效，因为单纯的数字很难直观地反应出数据的变化，因此好的可视化图表可以非常有效地帮助分析者发现问题或者评估效果。
【同时在线|思考：数据分析与数据后台设计】监控数据作为数据分析的基础，是一个看起来技术含量不高但频繁的行为，这个看似枯燥的行为需要对目标、数据极其敏感与了解，方能真正地发现问题以及客观的评估效果。
监控的关键在于让我们知道，存在问题吗？
二、观察接着聊聊观察数据。
监控数据更多在于发现问题与评估效果，由于监控数据更多聚焦于某一天的某个时段，时间周期很短，在大多数实验以及产品运行过程中，监控的数据偏少且时间短，无法作为有效且合理的参考，此时我们需要更多的数据指标、更长周期的数据来对比、评估，这个观察数据的行为建立在监控的基础上。
我们当然可以不监控直接观察数据，监控的确并不是观察的充分条件。但是少了监控，我们会缺少更加实时、及时以及详细的数据参考来支持判断。因为观察数据的目的与作用在于通过多指标、长时间的数据对比、观察数据起伏等变化来定位发现问题或是分析是否存在问题、是否按照预期发展，相对于监控的数据更加宏观的观察数据更加消耗精力，但监控依然是一个非常重要的行为。
以我亲身经历的一个小故事为例子。
曾经我所负责的游戏连续两天用户数都差不多，但是两天的用户时长却有显著差别。由于这两天并没有关注实际情况，在过了将近十天后回顾分析时一时无法得出有效的观点。
当时的我与同伴排除了产品出现异常、产品两天内有更新导致功能不同等会造成两天存在显著变化的情况。当时负责监控用户增长的同伴提供了一个线索，在后一天中由于游戏政策问题会有部分用户出现实名认证的过程，导致玩家进入游戏后被实名认证窗口卡在初始无法进入游戏。
随后我们查询了这两天的同时在线人数曲线，发现第二天曲线比前一天要明显低很多，而且从实名认证开始就出现了显著的下滑。因此我们得出了以下几个观点。
虽然用户进入了游戏，但是有部分用户未实名认证，导致他们无法进行游戏，有部分人因为各种原因未及时实名认证选择了退出游戏，因此造成了同时在线人数的下滑。
两天统计到的用户数量差别不大，是因为用户都进入了游戏，但是后一天的部分用户因为实名认证的原因很快就退出了游戏，造成这一天用户的平均时长下滑。
这是一个简单的例子，其实当时的我们完全可以凭借因为实名认证导致用户无法登录进而造成用户退出无法游戏来解释时长的下滑，但是这个观点本身就需要一些数据来支持。