15

与其给问题一个答案,不如干掉问题

 3 years ago
source link: https://zhuanlan.zhihu.com/p/360692779
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

与其给问题一个答案,不如干掉问题

神策数据首席人才官,创始人&CEO

我们在遇到问题时,首先会考虑的是给一个最优解。这可能和我们从小所受的教育有关,总是老师布置题目,学生来答题。这样导致的结果是学生会受限于老师所提出的问题,进一步导致学生提不出问题来。特别是在一些讲座场合,许多人不敢提出问题,甚至也想不到什么问题。我在 2018 年初曾经去过一次以色列游学,期间一直想要探究出以色列这个国家为什么有这么强的创新力。可能不同的人有不同的答案,但在我看来敢于提出问题,就是一个关键的驱动力。当然,这次我不是想探讨如何提出好的问题,而是最近在和一些朋友的交流中,会聊到我的做事方式。我自己做了个反思,感觉我会倾向思考如何去干掉问题,其次再考虑有没有更好的答案。

  1. 能不能干掉 RD 写统计脚本?

我在 2008 年底参与后来并主导 Log 日志统计平台的项目时,刚开始同事的思路主要还是在如果打造一个强大的日志计算和管理系统。但我感觉即使把系统打造出来,还是解决不了团队成员不愿意继续写大量统计脚本的问题。当时团队在我加入之前有两个正式员工和两个实习生,每天都在处理大量从各个业务线提交过来的统计需求。我想咱们能不能不让 RD 写统计脚本,改由 PM 自己去完成。后来经过调研,我对常见的统计脚本做了简单的抽象,抽象出计数、去重、Top N 三类统计需求,并和前端同学一起设计了一个 UI 界面。通过简单点选和设置筛选条件,就可以生成统计任务。这样 PM 自己就可以完成统计了。一下子让需求处理的周期从两周缩减到了几分钟。尽管这么改进后,仍然有一些统计任务需要 RD 来帮助实现,但大大减轻了 RD 做一些低水平重复工作的比例。严格意义来说问题并没有彻底干掉,但确实是这种思维方式大大提升了解决效率。

2. 能不能干掉 Mark 文件?

2013 年时,我负责的其中一块业务是日志数据的采集。当时用了一个百度内部自研的 BigPipe 传输系统。为了保证支持断点续传,会在本地保存一个 Mark 文件,这个 Mark 文件记录了当前所传输的文件位置,以便在机器死机重启时,可以继续按照 Mark 文件的记录进行传输。结果这个 Mark 文件带来了不少麻烦,有时候莫名其妙的丢了,更严重的是 OP 在进行机器扩容时,经常把整个文件目录复制到新机器上。这样就把 Mark 文件一并复制了过去,而新机器上的传输点显然不是 Mark 文件所记录的,于是就导致数据传输错误。而每次数据错误,进行数据恢复的代价很大。OP 同学痛不欲生。我就把相关的同学召集到一起想办法,我说既然 Mark 文件这么容易出问题,我们能不能干掉 Mark 文件?大家的第一反应是不行,没了这个 Mark 文件怎么跟踪传输位置。我说我们可以把这个位置点信息记录在数据库中,通过机器 IP 地址来作为 Key 查询和更新。最终在内部达成一致,又找存储团队的同学来协商具体方案。经过一番周折,最终上线了。上线之后,半年内就再也没有出现过 Mark 点所带来的问题了。团队小伙伴也非常有成就感。

3. 能不能干掉 ETL 过程?

2013 年前后还做过一个项目,就是构建全百度的用户数据仓库。当时为了减少业务线修改代码的配合工作,我们增加了一套复杂的 ETL 逻辑。就是将业务线产生的非结构化的文本日志,先经过清洗处理,转变成结构化的 Event,然后再导入到数据仓库中。结果这个 ETL 过程就带来了不少麻烦,包括计算复杂度和数据质量校验的问题。当时也在设计更好的质量校验系统,但这又进一步加大的计算复杂度。我们痛定思痛,觉得还是要从源头解决问题。既然 ETL 这么麻烦,我们能不能干掉 ETL?如果源头的数据是结构化、高质量的,那就不需要复杂的 ETL 了。于是我们设计了新的日志打印标准和 SDK 库,又花了一年半的时间推动业务线配合改造,最终才带来了更好的数据采集。也是在做这个项目的过程中,让我产生了对数据的很重要的一条认知:数据源很重要。

4. 能不能不依赖客户的数据意识?

过去这三年来,随着神策服务的传统客户越来越多,我们发现培养客户的数据意识真的是一件很难的事。从产生数据洞察到落地到业务行动,对许多团队来说很有挑战。在过去这一年,我们也在尝试新的思路:既然培养客户的数据意识这么难,能不能直接通过产品化的方式让客户直接看到效果,而不依赖客户的数据意识?因为看见,所以相信。这个过程还在尝试中,但我是比较有信心的,因为这是更好的解题方式。

以上讲的这些例子,都和数据技术有关系,外行看起来可能会比较吃力,我也是尽量想要表达清楚。在我的书《数据驱动:从方法到实践》中也有更详细的记录。这篇文章不是为了讲我们的数据理念,核心还是想通过例子来描述我的思维习惯:与其给问题一个答案,不如干掉问题。我前两天还把这句话发到了朋友圈,看朋友们都会联想到什么例子。有人提到言论控制,有人提到管教孩子的方法,还有人提到 Windows Phone 正在研究如何让触控笔更精准的问题,而 iPhone 直接干掉了触控笔。当然,在 iPad 时代,Cook 又让触控笔回归了,以更好的体验。希望我的这些描述,能够让你在解题的思路上,有所启发。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK