数据价值与数据产品孰轻孰重？ 大数据科学家飞林沙的年度总结

文 | 飞林沙

2015年底，我和朋友讲，我从未经历过这样忙的生活。

2016年底，我和朋友讲，2015年的忙，那算个屁啊!可是相比于如此忙，我从未经历过如此不开心的生活。

入职公司两整年，看着公司从即将B轮后的公司，走到今天即将D轮的公司;看着公司从几十人变成几百人，感觉像是一眨眼的事儿。

婚后生活的第一年，我不想为自己找工作忙这类的理由，也许自己就是个自私的人，爱到最后，要么伤人，要么受伤。我更是自私地希望对于我而言是后者，不是因为善良，而是这样我可以不必太过自责。

和以前一样，想到哪儿写到哪儿。

1. 网络 & 容灾

对于一个互联网服务而言，尤其是对于一个企业级服务而言，网络的稳定性以及容灾策略成为重中之重，开发者服务发展至今，性能本身往往不再是评估标准，尤其是对于大部分中小客户而言，云服务往往不会因为性能指标不达标，而多是因为后续的稳定性，以及在处理中国糟烂的网络环境上，当然这其实也是稳定性的一部分。

毕竟这不是一篇技术文章，更不是一篇广告文，没必要写的太细致。简单说说，是希望明年，后年我可以进步到打自己的脸，或者嘲笑今天自己方案的肤浅。

在中国，最突出的问题就是南北互通的问题，对于大部分互联网服务而言，完全可以靠大量的CDN来解决问题，但是对于云服务这种基本没有静态内容的情况，CDN变得不再可行。对于我们而言，南北互通主要体现在两点，第一是全国各地，或者说世界各地终端用户与服务端的长连接维持情况，第二是全国各地客户分散在不同区域的机房到服务端API的网络连接情况。

对于前者而言，解决方案其实很固定，就是尽可能多的接入点，然后通过服务端与客户端的配合来为客户端找到最佳接入点，这里后续会再提一小点心得。后者其实是最麻烦的，客户的机房情况多种多样，从南方机房到北方机房的时延在高峰时段往往延迟都会达到100ms以上，更不要说很多客户在一个什么鬼机房里或者某些不靠谱的云服务厂商那。

为了解决这个问题最简单想到的就是建设南北双机房，这样可以同时解决网络和多机房容灾的问题，不过折腾了一段时间后发现这个事儿完全不靠谱，南北拉专线的成本是我们负担不起的，那么中间庞大的数据同步，同步过程中各种由于网络波动引发的失败就成了我们短期内没办法完美解决的问题。

这个时候我开始思考两个问题，如果南北专线我们拉不起，那么同城专线我们拉不拉得起;如果南北数据互通我们解决不了，那么不互通到底能不能解决我们的问题。顺着这两个思路想下去，一个技术上不完美但是足够高可用的实用主义方案就产生了。

其实问题如何解决并不重要，不同的公司不同的业务不同的方案，更重要的是通过上面的问题我产生的是两个思考。

2. 服务端 & 客户端 => 架构师 & 技术委员会

我先举两个例子吧：

A. 所有人都懂的失败重试 。客户端每当连接不到服务端的时候，就会采用失败重试策略。如果这个时候正巧这个机器过载，那么反复的重试会导致这个机器彻底崩溃掉。 再进一步，如果客户端再尝试连接某个IP的时候失败，然后他会做的是什么呢?连接IP列表里的下一个IP。如果正巧这个IP所在的机器挂掉了，然后所有连接该IP的机器都开始连接下一个IP;下一个IP的机器也不堪重负也挂掉了，这就是雪崩效应。

B. 服务端通过客户端上报的信息为客户端找到最为合适的接入点。 但是IP信息往往是不可靠的，那么如何通过客户端和服务端的配合找到最合适的接入点，而客户端连接后是否可以提供合适的样本数据为服务端作为训练参考，为后续连接客户端提供更好的接入服务。

在一个公司中，同样的问题会有很多，不仅仅是客户端与服务端的配合，还有服务端与运维的配合，运维的职责是保持整个服务高可用，自然希望把上线节奏放缓走完整流程充分测试;而对于服务端来说，快速迭代却是他们所希望的，我相信没有任何一个工程师愿意在上线前走一遍冗长的上线流程，整个时候怎么办?

如果说这些还都是相通的，那么涉及到业务端和数据端配合就显得更复杂，数据端大多是数学系背景，精于数学模型的计算，而在工程能力上欠缺;而业务端计算机系的背景会导致和数据端的思维方式的不同，而在数据存储、交互模型，尤其是在线推荐引擎上，往往会产生巨大的意见分歧。

针对这个问题我请教了几个不同公司的人，大家的解决方案无外乎两类：

A. 让利益双方自己去撕逼 ，最终总是能得出一个不好也不坏的折中方案。这明显是一种被迫的方案。

B. 第二种方案是包括去哪儿、腾讯这样的公司更倾向于的方案。 即引入架构师或者技术委员会这样的三方角色，他们不会投入到具体的编码执行工作中，因此可以跳出利益纷争纯粹从技术方案上来思考问题。

从我个人而言，我更认同第二种方案，只是对于一个中小公司来说，到底这个角色的工作饱和度如何保证是我最让我犹豫的地方，也许这也是我新年需要解决的问题之一。

3. 做满足当前业务的最简单方案

用过去我强调了无数的数据概念来说，模型的用处是什么?现实世界的情况复杂多变，以至于基本的规则方法无法充分解决问题，或者需要几百个甚至几千个规则才能解决问题。这样不仅难于维护，更麻烦的是这样的规则引擎无法适应现实世界的复杂变化，尤其是面对人类所难以洞察的高维数据 和 难以处理的海量数据(尤其是噪音数据)时，且不说规则引擎的覆盖性和灵活性，更麻烦的是无法区分某条规则是否是属于过拟合。

先用这个方法论来看技术方案的选型，对于大部分业务来说无外乎对应到的就是几种情况，所以不要寄望于用一种开源组件/技术组件能搬过来完全解决问题，将完整的业务场景拆分，然后思考每种业务场景的技术重心和技术难点。做数据的同学不妨把这个当成一个Boosting的过程，无外乎分成两类，第一种是按照场景选择分类器，第二种是用多个分类器共同完成同一项任务。

前者随便举个例子，比如说将同一份数据存成多份，然后分别做不同的索引结构，按照查询条件分发。 后者最常见的其实就是用Redis+MySQL共同应付查询。那么后续还能做什么事儿?做机器学习的同学肯定非常了解，就是：1. 调参。 2. 将选择分类器本身也根据一些Feature变成一个分类器，从而提高覆盖度。 3. 将简单的投票选举的组合方式变成类似AdaBoost的优化方式。

其实思路都是互通的。

4. 数据价值 与 数据产品

这一年，大大小小做了三四款数据产品，我给自己勉强打30分。在过去的时间，我过度思考了数据的价值，而忽略了数据产品的本质依然是产品。无论是数据产品、开发者产品还是用户级产品，思考的方式都不是我能做什么，而是站在用户/客户的角度，我希望在你这儿得到什么，而作为一个合格的产品经理，需要的能力是我能够将用户的需求抽象开来，用我的方式来满足。而作为一个优秀的产品经理，是让用户可以惊叹原来你居然可以这样做这件事情。

列举几个自己犯下的错误，我们在做一个应用洞察类的项目，既然是叫做应用洞察，那么自然关注度都集中在”应用洞察”这件事情本身上，于是我开始从各个角度剖析应用，现在回想起来，这真的是可笑的”name-based product”。那么回想一下做一个用户级产品的思路是什么样?先思考这个产品的目标用户是谁?这个用户有什么痛点?我们如何用这样的方式来解决问题?再接下来去看其他的同类产品是如何解决问题的，我们是否有更好的方式来解决?

一个优秀的产品 是由 核心功能 加 优秀的交互 加 用户体验共同决定的。 数据产品同样如此，当整个数据产品一直在谈数据价值的时候，可能本身就是数据产品的失败吧。

5. 大团队的管理方式

公司成长为一个近500人的公司，团队从几十人变成几百人，管理方式的调整对我而言其实是最大的挑战。

A. 在过去的几年，我花费大量的精力在技术上，因为一直努力希望自己做一个技术领导者，而不是一个技术管理者。当随着团队规模的增大，这种方式也变得不再持续。2017年，我更希望自己做番茄管理法的变体，把自己一年的时间切成若干个块，在每个时间段都集中精力深入到某个产品和技术中做一个技术领导者，避免出现精力过度分散而导致每个产品都无法观其全貌，做到满分，然后用每周的固定时间来review其他产品的进度，做技术管理者。

B. 在Google SRE的一书中，其中有一章讲到100%的可用性不说是否现实，即便能做到也是不好的，因为会让整个团队在应对错误的能力变得不足。这就像人的身体一样，如果从来不生病其实是很可怕的事情，反而是那种经常生个小病，更新下病毒库反而才更健康。最近我听到两个人说了这句话，以至于我不知道出处是哪儿。只要这个错误不会把公司搞垮，就放手让大家去搞吧，在错误中成长也许必须的事情。

C. 我和几位不同的从初创到上市的朋友聊过，在团队的逐渐成长过程中，他们都分别做了怎样的改变，各自有各自的说法，但是在一点上是达成的统一。作为CTO，其实更多是跨部门协调沟通，制定合理的部门规则，更重要其实是技术前瞻性的把握。在前几天我批评过一位部门的Leader，我很赞赏他努力的工作态度，也并不怀疑能力本身，但是恰恰是这种努力带来的问题却是缺乏了技术的前瞻性。换句话说，作为一个技术领导者而言，一定是不能让自己陷于”忙”的状态中的，否则一定会做的多思考的少，作为领导者来说，这是最可怕的事情。

D. 专人做专事，至少专人在专时做专事。在小团队中，人少事多，每个人都背着繁重的需求压力。但是当团队成长到一定规模，公司发展到一定阶段时，必须要将业务工作和平台性工作分开。例如数据开发和数据平台必须剥离，否则必然出现大家都忙于应付日常的需求处理而缺乏平台性建设;例如高端职位招聘必须与常规职位招聘分开，否则必然会出现高端招聘被搁置。简而言之，简单的事情必须与复杂的事情分开，否则必然会处于一直忙于简单的事情，而缺乏时间建设平台，然后导致恶性循环。

6. 关于加班

有几位候选人都问过我，你们公司加班么?我都讲，确实加班，但是我希望公司不要加班。

今年公司的某几个部门加班加的有些过于疯狂了，我在感激大家的同时其实更多的是自责。一个公司频繁加班无外乎有几种可能：1. 员工能力值与公司现有的项目难度不匹配，以至于无法按时完成任务。 2. 公司项目进度规划不合理，以至于产生很多突发任务导致加班 3. 公司的基础设施建设不够以至于大家一直在填坑。 4. 白天的八小时利用率太低。 无论是哪种原因，作为CTO都应首先被问责。

频繁加班的坏处是显而易见的，无论是恶性循环，还是缺失学习的时间，还是当被需求赶着走的时候缺乏对于基础设施的积累。

这算是我新年最大的愿望吧，希望无论我做怎样的改变，都希望团队不要再加班得这么凶。

7. 关于生活

关于生活，是我可能最不想讲也不想总结的话题。

读了27本书，创了近年来的新低，一方面是因为时间被打的太散，没有足够的时间，一方面也是心里压力过大，没有办法静下心来高效地读书，这实在是很可怕的事情。

30几部电影，同样创了近年来的新低，这一年，走入影院的次数屈指可数。

美食?今年一年吃过的餐馆数量同样创下了近年来的新低，一方面是结婚后不太方便再约人一起吃饭，一方面我下班的那个时间只有楼下的早餐包子铺还在开张了。想想，也好可悲。

朋友?这一年来新结交的朋友一只手都数的清，好吧，也许砍掉几个手指都没问题。已有的朋友有的去了其他城市，有的断了联系，又没有新的朋友认识。我还真是可笑。

那生活?我好像真的快没有生活了。我和老板讲，能不能给我在公司装一个浴室，我自己带个床，然后我就把我租的房子给退了。也许他以为我在开玩笑吧，可是我是认真的。

有人问我，那你开心么?我说我不开心。他说人生就那么短，你要让自己开心得活着。我说我不知道怎么样能让自己开心，对于生活，我感到绝望。他说，那你打算怎么办?我说，我想得绝症，那种可以马上死掉的绝症。 我去体检，不是希望自己没事儿，而是希望能查出自己有些什么问题，可能我会更加开心。

我在清理自己的朋友圈，一年前我写，我希望有个女朋友，可以陪我深夜泡咖啡厅，可以陪我加班，可以陪我写代码，陪我解数学题，可以陪我聊娱乐八卦，也可以陪我聊文学历史。可是这些似乎离我越来越远，我有过这样的女朋友么?也许曾经有过。可是我们吵架吵的很凶，因为解题思路不一样，因为历史观点不同，因为，当然因为我们都太自信了。所以即便出现了，我想自己可能也不会幸福。

是的，所以我对感情也绝望了，我觉得自己不会幸福了。当然，我现在无比享受一个人的生活，一个人加班，一个人逛图书馆，一个人去咖啡厅，一个人吃饭，一个人看电影。我在想，我到底讨厌的是两个人的什么呢?

做数据做了太久，自然会用数字化来思考问题，我们没给对方带来了任何收益，而又让对方增加了责任、牵绊和压力。那收益就是负的，我们为什么还要在一起呢?

可能我太过于自私了吧，工作对我已经是最重要的事情，耗尽了我大多的能量，也许我不再想在生活中再给我添加一点点不快乐了吧。

8. 写在最后

之前每年的年终总结，我都是开开心心地，然后丢下彩蛋，那我许一个新年愿望吧，希望明年的年终总结，是有彩蛋的。

更多数据科学家飞流沙文章>>>

飞林沙：企业级服务公司如何赚钱？只有平台级产品才有大数据的理论

重磅推荐：大数据工程师飞林沙的年终总结&算法数据的思考

飞林沙：商品推荐算法&推荐解释

需求与匹配 从数据挖掘角度看世纪佳缘推荐系统

36大数据(www.36dsj.com)成立于2013年5月，是中国访问量最大的大数据网站。36大数据(微信号:dashuju36)以独立第三方的角度，为大数据产业生态图谱上的需求商 、应用商、服务商、技术解决商等相关公司及从业人员提供全球资讯、商机、案例、技术教程、项目对接、创业投资及专访报道等服务。

End.

转载请注明来自36大数据（36dsj.com)： 36大数据 » 数据价值与数据产品孰轻孰重？ 大数据科学家飞林沙的年度总结