原文出
处：http://blog.devtang.com/blog/20
data/
作者：唐巧
Monitor your data（监控你的数
据）
前言
由于科技的进步，以及数据「数字
化」地存储，使得现代人类可以获得
海量的数据。而有了这些海量的数据
之后，借助于一些数据分析工具和方
法，我们就可以从数据中找到社会运
行的「秘密」。
在工作中，借助这些「秘密」，我们
有可能发现商业中的新机会，也可能
验证或推翻自己的一些猜想。数据分
析，使得我们对「秘密」的探索有了
一个可靠的方法。
在本文中，我想分享一下工作中学到
的发现数据中秘密的心得。
稻盛和夫的故事
我们先看看 稻盛和夫 挽救日航的故
事吧。他的这段传奇经历曾经被很多
媒体报道，我将故事摘要如下：
2
010 年 1 月 19 日，日本航空公司
申请破产保护。日航有 58 年历
史，一度被视作日本战后经济繁
荣的骄傲象征。
2
010 年 2 月 1 日，受日本首相邀
请，稻盛和夫答应出日航董事
长，一年之后，日航扭亏为盈，
利润是对手全日空的三倍。 仅仅
用了一年时间，日航做到了三个
第一，一个是利润世界第一，一
个是准点率世界第一，一个是服
务水平世界第一。
在日航重新上市之后，稻盛和夫分享
了他 挽救日航的秘密。这里面涉及
的内容很多，其中有很重要的一条，
就是稻盛和夫非常重视日航具体的运
营数据，他花了很大的力气来优化数
据的获取，从而能够对日航的现状进
行判断。
稻盛和夫是这样说的：
我担任董事长后，最为吃惊的
是，公司的各项统计数据不仅不
全，而且统计时间很长很慢，往
往需要 3 个月之后才能搞全数
据，以至于经营者无法迅速掌握
公司的运营情况。 所以，在对企
业内部进行改革时，我特别关注
统计工作。经过改革，现在各个
部门的数据做到即有即报，公司
详尽的经营报告，做到了一个月
内完成。
如果把日航看过一个生病了的病人，
稻盛和夫的做法其实和现代医学的做
法类似，就是首先进行各项检查，获
得病人的身体指标信息，有了这些检
查数据，我们就可以利用各种基于数
据的经验，来进行病情诊断和治疗。
所有的治疗手段又可以通过再次的检
查来验证，从而进一步改进治疗方
法。
人做为一个生命体，全身密布的神经
负责着各种信息的传递，所以我们的
大脑能够接受到各种信息，从而做出
决策，饿了吃饭，冷了加衣服，保证
着我们身体的健康。
而企业没有天生的神经系统，所以数
据收集和分析就显得异常重要了。日
航作为一家运营了 50 多年的公司，
居然在这方面做得非常差，难怪会进
入破产的边缘。而稻盛和夫用的办法
也很简单，先让数据能够收集起来，
那么后续依据数据做决策就不再那么
困难了。
Monitor your
data（监控你的数
据）
我刚毕业的时候加入的是网易公司，
当时负责做网易邮箱的底层 Restful
Api。当时我们部门的老大郭常圳常
常讲要「moni tor your data」，我当时
作为一个应届生，刚开始对这个口号
不太理解。我当时想：数据当然是重
要的，但是也不值得老挂在嘴边讲
吧？但是后来我才慢慢发现，这其实
确实非常重要。
作为程序员，我们开发一个后台服
务，大家有没有测试过以下数据：
这个服务能够承受多少的
QPS（每秒访问量）？
平均响应时间和 99% 的响应时间
是多少？
如果服务器压力增加，我们能不
能通过简单的加机器来解决，需
要加多少台机器？
当前线上服务瓶颈在哪里？
按当前的增长速度，多久我们得
需要加机器？
当时郭常圳带领我们，将我们做的每
一个服务都进行了详细的压力测试，
我们对于我们的服务承受力有着非常
详细的数据测试结果。
这一点每个公司都做到了吗？其实不
是。我还记得我们后来和网易的网站
部共同开发网易微博后台，当时我们
因为要将邮箱微博和网易微博数据合
并，需要进行在线的数据迁移。我当
时负责数据迁移工作，在我向网站部
询问我应该用多大的请求压力来迁移
数据时，对方只是回答：“尽量慢
点”。
我当时就傻掉了，谁能告诉我什么叫
“
尽量慢点”？于是我只能小心翼翼，
一点一点地增加压力，最后我发现，
他们的数据库其实一点压力都没有，
我根本就不用控制压力都不会影响线
上服务。但是，由于他们「moni tor
your data」做得不好，所以他们对任
何可能的压力都心怀恐惧，不敢乱
动。
后来我也私下和他们求证了一下，他
们果然完全不知道他们的服务器能够
承受多少 QPS。大家也可以问问自己
公司的服务器同事，自己的服务器能
够承受的 QPS 是多少，就知道自己
的公司在这一点上做得好不好了。
而现在，数据驱动的思维更加深入到
互联网开发中了。因此，国外的 New
Relic 这类公司，才可以获得上亿美
金的估值。 New Relic 的工作原理是
放很多小的探针到你的程序代码中，
这些探针收集到非常详细的程序运行
数据，就可以为你优化服务器提供有
效的建议。
产品上的「monitor
your data 」
如果说技术上的「moni tor your data」
只是影响服务稳定性的话，那么产品
上的「moni tor your data」就会决定产
品的成败了。
我认为产品上的数据分析有以下作
用。
验证想法
在互联网行业工作这么多年，我发现
了一个秘密，就是任何新的互联网产
品，都不是靠用户调研或数据分析来
的。
因为用户调研非常难做，稍不注意就
会被别的因素影响，所以乔布斯曾经
说他从来不做用户调研。而数据分析
对于一个新产品来说，会陷入无米之
炊的尴尬境地。
所以很多新产品的第一版都是创始人
或产品经理「拍脑袋」的产物。这一
点其实是非常现实的做法。「拍脑
袋」依赖于创始人的经验，如果创始
人经验丰富，那么很可能产品对了 7
分，错了 3 分。另外那 3 分的错误假
设，可以在产品上线后迅速通过数据
来验证，从而迭代修正这些假设。
所以数据分析对于产品来说，第一大
作用就是验证（或推翻）产品经理的
假设，从而使产品能够得到快速迭代
改进。
发现新的秘密
很多时候，数据分析不光会得到你的
产品本身的状态，还会发现一些新的
机会。借助这些新发现，我们对产品
产生新的认识。
拿我们的创业产品「小猿搜题」来
说，我们一直在监控它的 NPS（净
推荐值） 数据。为了把数据分析得
更加细致，我们把打 NPS 0 分的用户
行为进行了抽样分析，最终我们发
现，虽然我们的 slogon 叫「初高中拍
照搜题利器」，但是却有大量的小学
生用户在使用我们的产品。
我们并没有为小学生做任何的产品上
的优化，所以造成了这部分用户没有
被很好的满足。所以，我们最近在内
容和搜索算法上针对小学生做了特别
优化，同时将产品的 slogon 修改成了
「中小学拍照搜题利器」。
如果没有细致的数据分析，我们可能
就错过了几千万的潜在用户。
发现数据规律
一个产品会有非常多的指标，日活，
月活，留存率，年龄分布，用户使用
习惯等，产品经理应该对这些指标了
如指掌，在对这些数据熟悉之后，产
品经理就可以发现数据中的变化规律
或异常点，从而对产品带来一些改
进。
在这一点上，我喜欢讲林彪的一个故
事。
1948 年辽沈战役开始之后，在东
北野战军前线指挥所里面，每天
深夜都要进行例常的 “每日军情汇
报”：由值班参谋读出下属各个纵
队、师、团用电台报告的当日战
况和缴获情况。
那几乎是重复着千篇一律的枯燥
无味的数据：每支部队歼敌多
少、俘虏多少；缴获的火炮、车
辆多少、枪支、物资多少。
司令员林彪的要求很细，俘虏要
分清军官和士兵，缴获的枪支，
要统计出机枪、长枪、短枪；击
毁和缴获尚能使用的汽车，也要
分出大小和类别。
经过一天紧张的战斗指挥工作，
人们都非常疲劳。整个作战室里
面估计只有定下这个规矩的司令
员林彪本人、还有那个读电报的
倒霉参谋在用心留意。
1948 年 10 月 14 日，东北野战军
以迅雷不及掩耳之势，仅用了 30
小时就攻克了对手原以为可以长
期坚守的锦州之后，不顾疲劳，
挥师北上与从沈阳出援的敌精锐
廖耀湘基团二十余万在辽西相
遇，一时间形成了混战。战局瞬
息万变，谁胜谁负实难预料。
在大战紧急中，林彪无论有多
忙，仍然坚持每晚必作的 “功
课”。一天深夜，值班参谋正在读
着下面某师上报的其下属部队的
战报。说他们下面的部队碰到了
一个不大的遭遇战，歼敌部分、
其余逃走。与其它之前所读的战
报看上去并无明显异样，值班参
谋就这样读着读着，林彪突然叫
了一声 “停！” 他的眼里闪出了光
芒，问：“刚才念的在胡家窝棚那
个战斗的缴获，你们听到了吗？”
大家带着睡意的脸上出现了茫
然，因为如此战斗每天都有几十
起，不都是差不多一模一样的枯
燥数字吗？林彪扫视一周，见无
人回答，便接连问了三句：
“
为什么那里缴获的短枪与长枪的
比例比其它战斗略高”？ “为什么
那里缴获和击毁的小车与大车的
比例比其它战斗略高”？ “为什么
在那里俘虏和击毙的军官与士兵
的比例比其它战斗略高”？
人们还没有来得及思索，等不及
的林彪司令员大步走向挂满军用
地图的墙壁，指着地图上的那个
点说：“我猜想，不，我断定！敌
人的指挥所就在这里！”
随后林彪口授命令，追击从胡家
窝棚逃走的那部分敌人，并坚决
把他们打掉。各部队要采取分割
包围的办法，把失去指挥中枢后
会变得混乱的几十万敌军切成小
块，逐一歼灭。
廖耀湘对自己静心隐蔽的精悍野
战司令部那么快就被发现、打
掉，觉得实在不可思议，认为那
是一个偶然事件，输得不甘心。
当他得知林彪是如何得出判断之
后说，“我服了，败在他手下，不
丢人。”
有些时候，一个数据中的异常点，就
是一次决定性的机会。而产品经理只
有做好「moni tor your data」，才能抓
住这样的机会。
培养产品直觉
有一些产品，产品经理自己就是目标
用户，所以可以比较容易用同理心来
分析出用户的需求。但是像我们猿题
库这次创业，目标用户都是初高中
生，我怎么知道这些 00 后的需求、
想法和兴趣爱好？
除了多和他们聊天，多用他们喜欢的
产品外，分析他们的行为数据也至关
重要。郭常圳常常说：“我们做产品
要有场景化思维，要还原用户当时真
实的使用场景”。而通过分析一些用
户使用数据，就有助于我们还原用户
使用场景。
这种事情做得多了，我们就会更加了
解用户了，慢慢就形成了产品的直
觉。
总结
关注数据和数据分析能力，是互联网
时代生存的基本技能。不管是做产品
还是做技术，养成「moni tor your
data」的习惯，都可以让你将工作做
得更加出色。
本文讲完了为什么要关注数据，在下
一篇里，我将分享具体如何做。
原文出
处：http://blog.devtang.com/blog/20
1
5/09/03/how-to-monitor-data/
作者：唐巧
前言
上一篇文章中，我们介绍了为什么要
关注数据，在本文中我将分享具体如
何做。
关注宏观和细节
大多数人都能做到关注宏观的数据，
拿互联网产品来说，日活，月活，流
失率，NPS（净推荐值），这些都是
宏观的数据。宏观数据能够反映出产
品的整体状况，是值得长期关注的。
但是在宏观之外，我们还应该关注一
些细节的数据。拿日活来说，我们可
以再进一步进行分析，比如：
日活中新用户所占的比例
日活中 iOS 和 Android 的各自占
比
日活中大家集中活跃的时间段
日活中用户的会话（Session）次
数分布，时长分布
日活中用户平均使用你的产品核
心功能的次数
当你把数据拿放大镜看得更细的时
候，你可能就会发现一些问题。带着
这些问题，你进一步分析，就可以找
到更多信息。
举一个我们创业产品小猿搜题的例
子，我们发现日活中的用户，有相当
一部分用户只是注册了，但是并没有
使用我们产品的核心功能，于是我们
担心会不会有一些付费推广渠道「刷
量」。
所以，我们将新增用户中不活跃的比
例按渠道来划分。通过这样的划分，
我们很容易找到那些效果差的渠道，
从而选择更有效的推广渠道。
关注原始数据
原始数据是什么？就是那些不是通过
别的数据计算出来的，不能被分割的
数据。这些数据是最最真实的，而其
它通过计算出来的数据，因为进行了
二次加工，所以不一定能够完全反映
出产品的问题。
再举一个小猿搜题的例子，我们为了
研究 NPS 给我们打零分的用户。把
这些用户的搜索数据、操作记录都抽
样出来，一个用户一个用户看，然后
进行分类整理。最终我们发现这里面
小学生用户占比很高，从而调整了产
品的策略，在内容和算法上对小学生
进行了兼顾。
关注原始数据除了能改进产品外，还
能在技术上提高代码的质量。我们曾
经遇到过一个很难复杂的 Bug，在我
们的测试机中都无法复现，但是我们
通过分析相关用户的操作记录，找到
了具体崩溃的操作方法。
虽然该操作方法不能在我们自己的机
器上复现 Bug，但是我们却能找到相
关的关键代码。通过一些针对这些代
码的讨论，我们就找到了 Bug 的原
因。现在回想起来，如果没有这些原
始数据，要修复这个 Bug 就要困难很
多了。
关于面试
其实不光做产品要看「原始数据」，
面试一个人也是。我在面试的时候，
会选一个候选人简历上的事情，进行
深入了解。我会让他提供详细相关工
作的数据和事例。通过这些「原始数
据」，我能够更加方便地「还原他真
实的工作场景」，从而对他的工作质
量作出尽量客观的评价。
举个例子，有一个产品实习生候选人
在简历上写他运营了一个微信公众
号，「粉丝逾千，单日粉丝增量 200
以上，数篇文章阅读量超过
3000」。但是在面试中，详细追问这
些数字，我们才发现他说的「逾千」
是指 1000，而「单日粉丝增量 200
以上」是指的最高的一天，其它信息
也都是有夸大的成分。
还有一次，我面试一个技术候选人，
这个候选人说他有代码洁癖，觉得前
公司的代码「很乱，受不了」。但是
我让他具体举几个例子的时候，他却
很难说出实际的例子。还有候选人说
他喜欢看技术书，但是却无法说出他
印象最深的一本技术书以及其中的部
分观点。
通过了解细节，我们就可以揭开简历
中光鲜描述的外衣，了解到事情背后
的细节，这对我们评价候选人至关重
要。
数据可视化
数据可视化是指将原本枯燥的数据，
用折线图、饼图、柱状图等方式呈现
出来，它可以使我们更容易发现数据
的规律，也更容易发现数据的异常。
在小猿搜题项目中，数据可视化多次
给我们带来巨大的帮助，包括：
了解数据的特点：我们将小猿搜
题的 QPS 按每小时为频率画出成
一条折线图，所以我们很容易知
道我们服务器高峰期的时间段以
及访问量。
发现服务异常：我们将服务器搜
索的失败率占比画出成一个饼
图，有一天，这个饼图中显示出
失败率突然变高了。同时，每日
的 NPS 分数突然也变低了很多。
我们借此发现了新扩容的一台服
务器故障。因为那台服务器是新
加的，所以运维忘记了增加监
控，如果没有数据可视化的帮
助，这个故障可能会持续更长时
间。
监控核心质量：我们将小猿搜题
的一些核心指标画成折线图，然
后大家都努力让核心指标更优。
发现恶意攻击：一些重要指标，
我们都会可视化出来，这样当这
些数据指标变化时，我们就会进
一步分析原因，从中我们还发现
了一些竞争对手恶意的攻击行
为。
数据可视化工具
我们当然不可能所有的数据可视化都
是自己手工用 Excel、Number s 之类
的工具来生成。所以，我们开发了一
个数据可视化的平台，我们把它叫做
flyboard。
flyboard 提供了各种数据可视化的方
式，包括数字，折线图，饼图，环形
图，柱状图等。如下图所示：
我们将所有的原始数据都归集到分布
式存储 Hbase 中，然后通过配置一些
定时的计算任务，就可以以几乎实时
地方式，看到产品的各项可视化指
标。
这些指标，有宏观的，也有一些比较
细分的，如果我们对某项指标的数值
有疑问，我们就会进一步写一些分析
脚本，来从 Hbase 中计算一些数据进
行检查。
在猿题库公司，我们的三个产品（猿
题库、小猿搜题、猿辅导）的办公区
域，都挂着一个巨大的显示器，这个
显示器除了用于 Scrum 的每日站会同
步进度外，平时都用 flyboard 显示着
产品的各项核心数据。
悄悄告诉你一个秘密，我们的
flyboard 可视化平台是开源的，项目
地址
是：https://github.com/yuantiku/flyboard
，在 Github 上你可以下载到完整的
代码，我们也附有完整的安装使用说
明文档。如果你还没有使用任何数据
可视化工具，欢迎尝试一下
flyboard。
学习写 SQL
在，产品经理也可以通过一些简单的
SQL语句，就可以生
成 MapReduce 任务，进行分布式的
数据分析运算。
所以数据分析最最常用的办法就是写
SQL。在很多公司，产品经理都在这
方面能力比较欠缺，这使得产品经理
在需要数据时，需要向技术提需求。
技术会根据自己的工作排期。这样一
来一回，一般一个简单的数据分析都
需要一天时间。
这样的低效率的方式，会扼杀产品经
理的一些数据分析需求，特别是那种
需要探索式发现的数据分析工作。因
为这种工作需要不停地根据数据分析
的结果，调整各种策略来写尝试的
SQL。
所以在猿题库，我们希望产品经理都
能有基本的数据分析能力，一些简单
的 SQL都是需要自己能够写的。当
然，一些特别复杂的 SQL，产品经理
可能还是需要向技术同事咨询。
具体如何写 SQL，市面上已经有非常
多的相关书籍了，我在这里就不再展
开介绍了。
数据查看和分析一定
要方便
如果你仔细观察就会发现，很多革命
性的产品就只是让某件事情更方便了
一点点。智能手机其实只是让你上网
更方便了一点，但是这种方便使得人
们从以前有「离线和在线」的状态，
变成了永久在线。于是，移动互联网
诞生了，本质上来说，移动互联网就
是一种人们永久在线的网络，但是就
是这么一点点的方便，使得很多行业
被完全颠覆。
而数据分析也是一样，我们应该尽量
让数据触手可得，这样我们才能将数
据分析的效率最大化，一定程度上的
效率提升就会产生质变，使得我们专
注于数据做更多事情。
我们之前移动端统计用 Flurry，但是
Flurry 在中国实在太慢了，即使挂上
国外的 VPN 也很慢！如果产品经理
每次登录 Flurry 要 10 秒钟的话，那
么他就可能将注意力临时转移到别的
事情上，然后就可能忘记本来要看的
数据。
为了让数据触手可得，我们放弃了对
Flurry 的使用，我们自己开发了日志
收集平台，然后自己写日志计算程
序，将一些核心指标全部自己计算在
flyboard 上，我们也另外开发了一套
数据分析平台，实现 Flurry 中的类似
功能。现在，我们已经能够非常舒服
地分析数据了。
所以，如果你的公司不能很方便的查
看和分析数据，那么一定要想办法改
进，这些数据就像人的神经系统一
样，传递着产品的健康数据，重视这
些数据，才能够做好产品。
总结
总结一下本文中的观点：
重视宏观数据和细节
关注原始数据
数据可视化
学会用 SQL
数据查看和分析一定要方便
