信息茧房
信息茧房这个词听说过太多次，一直没有重视。过去阅读的文章都蛮拓宽眼界的。但是近两三个月，这种情况发生了变化。
一方面是信息获取渠道的变质。疫情以及之前，摄取信息的渠道一般就是两个：知乎和瓦斯阅读。从这两个地方我基本能看到社会上正在发生的大事。上海疫情期间，以及疫情之前的一段时间，知乎上面有太多关于上海疫情的讨论，以及社会经济形势的讨论。但是这两个月，这些讨论都没有了，换成了鸡毛蒜皮的事情，如“某某明星和某某明星结婚，你有什么看法？”这种信息多了，对知乎也就失去了兴趣。他俩结婚关我屁事啊！热榜变成了这个样子，我不相信这是一个自然变化的过程。难道大家现在的生活就真的这么安逸，不需要去关心经济形势了吗？还有知乎的推荐模块，自以为很了解我。给我推荐了一些《亮剑》相关的帖子，很多还是我已经看过的。我确实很喜欢《亮剑》，很爽，刚开始看到那些帖子和答案确实蛮有兴趣，但这些只是甜品，不是主菜啊。当我吃饱了主菜，想吃个饭后甜点，点缀一下这顿饭的时候，甜点才恰到好处。但不能一直让我不吃主菜只吃甜点啊。不止知乎，几乎所有的主流软件都是这样，信息类软件的初衷应当是帮助我们找到优质资源，拓宽我们的视野，但现在所谓的个性化推荐却越来越把我们留在信息茧房里面。它们以为很了解我们。
另一方面，则是阅读量的减少，以及对信息内容需求更加精确。之前的信息需求就是了解社会上发生的事情，经济上发生的事情，而现在的信息需求则变成了了解和抖音相关的行业方面的方方面面的内容。这种信息相对于更宽泛的经济信息，更加难以获取。一般也就是发生了大事有新闻报道提一嘴。比如抖音和爱奇艺联合，爱奇艺开放版权给抖音这种信息。其它的信息则不容易获取。需要通过内部周会，双月总结会，以及各种其他的需求会议，各种各样的用户调研文档等去了解。这些文档太零碎，以及往往会有很多其他的内容，要从中捞出来自己感兴趣的内容就不容易，进一步形成体系更是难上加难。阅读量减少则一方面是因为现在自己的时间太少，没那么多时间去读书。另一方面是书籍往往存在滞后性，所做的业务又比较新，没有成熟的书籍去学习，很多时候还得看一些抖音攻略，去看看用户都是怎么操作的了解行情。
由于原先获取信息的渠道变质，而我又嗷嗷待哺，所以现在将获取渠道变成了抖音。这个决定有点反智。因为信息茧房这个词我印象里最开始好像就是说的抖音，因为推荐算法太强了让用户只能停留在感兴趣的内容上面，形成了信息茧房。但这个茧房有好的有坏的，如果推得一直是娱乐没什么营养的内容，那信息茧房对我们就是有害的。但如果我们通过主动搜寻新的内容，在知识类的内容上看的更多，就会形成一个对我们有利的信息茧房。
格局
内部有很多的分享，有一些是技术分享，更多的则是业务层面的分享，领导层直播分享各种观点，还有双月总结会，项目进展会，和直面用户的反馈沟通会议等。
业务层面的分享让我对业务有了更立体的感知，因为是做数据层面的，其实只会聚焦在产品的数据模块，但是实际上对用户来说可能他对数据模块其实并没有很深刻的反馈。而整个产品在抖音体系中的位置，在他利用抖音体系挣钱的链路上所处的环节，在这些方面对他来说可能有更深的痛点。而如果只是聚焦在产品中的数据模块，其实格局不够大，闭门造车，完全看不到外面的世界。这时候我们可能在反思自己的产出的时候，可能比较骄傲的说自己做了什么功能，性能怎么样。但这又有什么意义呢？它对用户的价值在哪里呢？性能做的再牛逼，但根本不是用户会使用的功能，这不就是没有ROI的自嗨吗？
而且过分聚焦在产品内自己做的模块还很容易给自己过大的压力。就像我们坐在飞机上俯视一座城市，会觉得这座城市好美，特别是夜景，灯火琉璃。而降落下来就没这种感受了。聚焦在一个模块内部，视野就那么大，也就领略不到整个业务的美妙。
有一段时间我过的很痛苦，因为一直忙于实现各种需求，忙着优化一段代码，直到听到一些大佬的访谈，参与到跟用户的反馈沟通中，听到用户和产品同学在业务层面的探讨，我才意识到其实我痛苦的根源就是太过聚焦在一个点。把自己的高度提高，视角代入整个业务，我又快乐起来了。
时间
时间越来越不够用了。
工作日白天基本没什么时间可以留给自己，很多时候连午休时间其实都用来工作了。晚上的话则到家休息会儿就到了十点半左右，出去跑步大概一小时，回家在休息会儿洗完澡就十二点了。有时会拿出来电脑继续看会儿工作相关的事情，有时就是自己休息会儿，看会儿游戏直播，大概十二点半到一点的时候睡觉。
周末的话，周中工作实在太累，所以会拿出来一天放纵自己，允许自己玩游戏，看视频等。另一天则可能陪女朋友出去玩玩，或者一起窝在家里吹空调，她工作，我学习。
有句话说，时间像海绵，挤一挤就会有的。但时间有时候真不是能挤的。需要有一定的时间去放空自己，让自己能够得到充分的休息。否则连续高压连轴转，就容易有崩掉的那一天。
对产品设计的一些思考
在体验一些产品时，总感觉不够爽。为什么呢？如果我是用户，我的需求最好是直接能看到过去挣了多少钱，是怎么挣得，哪些视频，哪些商品给我带来了最大的收益，我的收入趋势是什么样子，和其他人对比是什么样子，如果收入不尽人意，那么是哪方面有问题，是不是我选择的达人有问题，是不是我带的商品有问题，如果是后者，那我应该带哪些货，跟哪些商家合作，才能给我带来最大的收益？
但我们很多产品都给不了我这个信息。只有一个冷冰冰的数字，从这个数字上我得不出任何结论，不知道如何优化。那这个数字对我就意义不大。就像用户增长这件事，如果只说抖音用户增速是xxx亿，而不考虑人口数量，人口分层，人均设备数量等因素，那这个用户增速数据就带不来任何价值。我们不知道增速到底是高是低。更无法进一步探查为什么会更高或更低。
这方面我看的最好的案例是阿里的生意参谋，内部其他业务也有一个产品做的不错。可能是其他产品都处于早期吧，主要精力还是放在完善功能上，数据相关模块优先级没那么高，先往后放一放。
不管是什么产品，用户肯使用我们的产品，并形成粘性，原因无非是从产品里得到了收益。这个收益可以是钱，可以是信息，可以是愉悦的心情。如果不会给用户带来收益，再花里胡哨的产品也不会形成用户粘性。那我们在设计产品，在考虑提升用户DAU的时候，就需要看是否能给用户带来收益。做完之后要根据用户反馈以及埋点数据看是否达标，必要时直接跟用户对接，去做一个复盘，看哪里没有做好，用户体感如何，怎么去改进。这方面字节做的还是挺不错的。
复盘
这个月过得怎么样？自己是否满意？
本月技术方面进步明显，业务方面也有很大的进步。业务上的主要进展为理解了用户如何利用抖音生态赚钱的链路，关注的重心也从数据模块转变到了用户使用上的核心诉求，卡点，这个转变让我不仅可以快速理解数据方面的需求，在面对一些其他跟我关系不大的需求时，也能理解做这件事的背景，跟用户面对面调研时用户的反馈是什么，做这件事能解决用户哪些痛点，能带来什么收益，对整个抖音生服又会带来什么价值。在需求评审或者测试用例评审的时候，也开始能够从业务角度提出一些疑问了。
工作方面，已经逐步接手了一个大方向。本月上半旬理解平台过程中整理的一些文档，在日常中发挥了很大的作用。比如做了一个平台功能对应代码仓库，以及接口的地图。这个地图我几乎每天都会看，除了在有新的需求来的时候我可以快速定位到哪些地方做修改，也可以帮助其他一些新同学快速熟悉代码。而且这个地图在我建设领域组件的时候也发挥了重要作用。它让我能快速定位到对应的代码，进而能进一步确定数仓表都有哪些。让我了解了数仓在该领域的底表建设都是什么样子。日常工作沟通也让我理解了数仓表的产出逻辑，数据的口径。
本月经历了代码迁移，代码治理。一方面将原先的一个大仓库拆分为各个产品对应的小仓库，不仅减少了理解成本，也让我们在开发新需求时能够有的放矢。另一方面，原先没有接入内部trace平台，导致无法量化平台的稳定性，只能大致靠报警日志猜。而本月将入职时参与的商家方面以及现在负责的达人方向全都接入到trace平台，能够清晰的从trace平台上看到平台稳定性。也就给我们平台治理提供了依据。后来经过我们的治理，目前稳定性已经能达到4个9。
中旬由于熟悉新业务，以及接受该方向导致开发工作激增，基本没有时间去抬头望望天空。好的方面是经历过这一波目前我对该平台的代码都比较熟悉了。后来我们这边的新同学释放出来之后，已经可以承担一部分开发工作了。所以就给我留了一部分时间去做一些长期来看重要的事情。比如领域的建设，长期来看能减少我们的开发成本，提升我们团队对接需求的效率。再比如数据口径的治理，平台多了，同一个指标可能用在多处，它们的口径可能都不一样，这就会带来很多的沟通和排查成本。目前我看下来涉及到我们这边的oncall基本都是口径问题。
总体来说本月对自己的进步还是很满意的。下个月主要重心就放在领域组件的建设上，同时通过leader要求分享业务认知的契机，分享这一个多月以来搜集多方资料对业务形成的认知，大组上通过分享时leader或其他同事的反馈查漏补缺，小组内则是通过分享拉齐业务认知。
技术方面有哪些进步？还有哪些可以改善的地方？
本月深入学习了ES，阅读了《ElasticSearch In Action》这本书，并且工作中也经常用到Kibana去编写需求需要用到的DSL，所以现在对ES的语法已经挺了解了，实现需求没啥问题。
但是ES用起来还是蛮麻烦的。比如有时候需要对数据进行聚合然后排序，然后再分页，ES中倒是能实现，但是性能可能就不达标。还有就是ES聚合时bucket最大10000个，但是很多场景，比如我们用两个字段进行聚合，就可能超过这个限制，要增加bucket的数量的配置。但是这个修改就涉及到整个集群，可能有较大的影响。
最简单的场景是固定的场景，如就查一个用户近30天的数据，这样可以对数据做预聚合，排序和分页不仅实现简单，而且性能也很好。而困难的是不固定的场景，如用户可以随意选择查询哪段时间的数据，并且有复合指标，并且需要再根据这些指标去做排序，分页。这种实现起来就可能需要用到script，而它的性能可能就不是很好。
有一种解法就是第一次查询时将数据都查出来，放在缓存里面，然后后面不管用户怎样查询都从缓存里面取，进一步做排序和分页，这种性能上来说一般都是最好的。但是有几个问题：
- 用户数据可能太多。那如果先聚合并排序塞入缓存呢？那聚合时size设置多大呢？设置大了容易出现桶太多导致查询失败。设置少了，用户数据实在太多，又可能出现查询出来缺失数据的情况。这种情况我们可以跟产品同学约定只取TopN的数据，因为其实就算我们取全部数据，对用户来说也没多大意义。一般没什么人会扒拉到几千条数据吧。
- 引入缓存，就引入了数据不一致的风险。但我们可以通过设置缓存的过期时间，如30分钟，来解决这个问题。一般来说也没什么问题。
我在做方案的时候，倾向将那种QPS高的需求，ES层面尽可能简单，QPS低的需求，内部用户的话，可以ES层面做一些聚合等重一些的操作。
还有过去有一个误区，就是总是觉得接口的P99越低越好。当然这句话也没毛病，但是有时候可能要求是1s内返回结果，有通用的解决方案可以在1s内返回结果，还有另一种不通用，定制化的方案可以在100ms内返回结果。如果我们只追求P99越低越好，而采用了定制化的方案，就很有可能到处都是烟筒。当然这个也跟场景有关。如果是2C的场景，用户体量巨大，我认为定制化这种方案没什么问题。因为它时间快往往也意味着用的资源少，对存储和计算引擎的压力更少，能支撑更高的QPS。但是如果是2B的场景，那么就没什么必要。
而到处都是烟筒一方面会造成我们重复开发，浪费研发的人力，还会造成各处口径的不一致。如果我们能抽象通用组件，面向领域建模，就可以解决这个问题。实际操作起来也是一个蛮复杂的问题，要从底层数据就开始面向领域，然后是接口层。然后将领域组件提供给业务方使用，而不是每来一个需求都是数仓去取很多表产生对应具体需求的表。让业务方去调各个领域组件，然后将结果拼接一下就好了。这样才是优雅的设计吧。
具体场景怎么用，就见仁见智了。通用性和性能这两者仿佛是鱼与熊掌，要通用性就得牺牲一定的性能。还是看具体场景选择吧。
这不是一个容易的过程。我们设计时往往要么设计不足，要么设计过度，这都会有问题。设计不足的意思是说，比如预期延时在100ms，而我们在设计的时候由于底层表格式不对等原因，其实极端可能到10s，而自测或者测试阶段由于使用的数据过少，确实能满足100ms的需求，所以我们认为它没问题就上线了。设计过度的意思是说，预期是100ms，我们测下来也确实极端情况下也能满足100ms之内，但我们仍然不满足，想方设法把它优化到50ms以内。表面上看起来可能有收益，但其实算起来ROI可能是负的。从研发人员的角度看，为了提升这个性能，往往想方设法钻牛角尖去优化，会压力特别大。从架构角度上看，最终的方案可能和该场景过拟合，导致后续无法复用，无法扩展。我在这一个月就一直陷入设计过度的泥潭里。想优化这个，想优化那个。但实际优化的过程中又发现存在即合理，有些地方过去那么写真的是没其他办法。优化的话就涉及到架构层面，包括数仓表等的更改，伤筋动骨了。直到后来我想明白痛苦的根源是格局太小，一直盯着优化这一块，实际上已经能满足需求了，我没必要去过度设计，应该把精力腾出来去更多的理解业务，从用户的实际使用场景出发，而不是只看到数据模块，这样才是正确的。
业务方面有哪些进步？还有哪些可以改善的地方？
了解了五六双月业务方面的进展，以及七八双月的规划。对业务整体如何运作，如何形成一个闭环有了更深的了解。同时因为方向的转变，在达人运营这方面了解也从月初的雾里看花变的清晰起来。
需要改善的地方是需要形成一个垂直的业务认知体系，从业务营收总览下钻到具体的品类/地域，形成这样一个认知体系，在理解业务闭环的同时深耕一方面，日后才能游刃有余。
是否尽自己最大努力了？现在的自己能否成就三十五岁的自己？
是。
你的三年计划完成的怎么样了？有哪些进步？有没有偏离？
没有偏离。
待人是否做到真挚诚恳，和朋友们的关系是否更加紧密了？
本月有一次团建，所以和公司内朋友的关系是更加亲密了。而且团队氛围偏活跃，大家会一起吃午饭，一起吃晚饭，吃饭的时候也会聊一些时事，每个人聊对这件事的看法，由于很多朋友之前都是来自其它大厂，所以在吃饭的时候也能听到其他大厂之前的做法和经验。对个人视野有了一个很大的补充。
本月没刻意周末去约朋友见面吃饭，倒也见了一些朋友。家附近有家叫麦育堂的糕点铺。和女朋友第一次吃他家的绿豆糕就被种草了。后来几乎尝遍了他家的其他糕点，都很不错。绿豆糕吃的最多，印象最深刻。他家的绿豆糕口感很细腻，很希望朋友们也尝一下，所以每次周末见朋友都会去他家买了绿豆糕带过去。
下周就要去北京了。给北京团队带一些绿豆糕也是一个不错的选择。
今天去他家买绿豆糕，发现他家入驻抖音了。下次要从抖音上下单买，给我们本地生活贡献一笔。
四十岁的自己期望是什么样子？如果按照现在这种状态继续下去，会是什么样子？两者是否吻合？
符合。
是否有保持阅读的习惯？从阅读中汲取到了哪些新的力量？
读了两本书，一本是莫言的《生死疲劳》，一本是俞敏洪的《我曾走在崩溃边缘》。
《生死疲劳》没什么可说的，就是一个人轮回了几世，分别投胎为不同的动物，描述自己看到的东西。其实就是通过一个村落的变化讲述中国过去几十年的历史。文笔蛮幽默的。
《我曾走在崩溃边缘》这本书则讲述了新东方创建的过程，以及发展过程中经历的一些事情。从中可以看到，利益是最好的朋友，新东方高层吵吵闹闹，闹了好几年，就是在权利和利益这个点去争吵，当涉及到所有人利益的时候，大家都统一了。
新东方发展过程中一个很重要的点是《民办教育促进法》的出台。之前是学校和机构不能扯上关系，所以新东方办学校就只能挂在个人名下，如去上海开分校就只能是以个人名义开，这其中有一个很大的风险就是万一那个校长说学校是他的，跟新东方没有任何关系，新东方其实是没办法的。但《民办教育促进法》出台后，机构可以出资办学校，只要缴税就好了，就规避了这个风险。如果没有这部法律，新东方到现在说不定还是各地割据为王的一种局面。但时来运转，新东方这两年转型做带货直播，也是国家政策搞得。真可谓是成也萧何败萧何。
从这本书中可以看到，俞敏洪在新东方很多节点确实都发挥了极大的作用。比如刚开始新东方是家族企业，有很多裙带关系。俞敏洪坚决清除了家族关系，这个过程不容易的。家族企业就很容易出现内耗，大家不知道听谁的，效率不高。很多有名的家族企业之所以成功，是因为有绝对的权威。而当时新东方可不是这样的。还有一个很重要的点，就是上市要不要借壳上市这点，俞敏洪坚持了自己的观点，就算不上市也不借壳上市。后来他意识到当时投资方是资金出现问题，希望新东方借壳上市，将股价炒高几倍，他们抛售回血。这对新东方的发展是很不利的。如果当时俞敏洪随大流，只图眼前的利益，借壳上市，那后面新东方可能也就凉了。
复盘下来的方案，是否真正有去落实？是否被同一块砖头绊倒两次甚至多次以上？
本月基本没有复盘。但让自己痛了就会去想要怎么办。倒也相当于一个小复盘吧。想出来的方案是真的去落实了。
是否有关注社会发展？特别是经济方面的发展？有哪些感悟？讲给我听一下
月初有点心动要不要买基金，因为势头确实发展不错。后来就把这茬忘了。
回过头来看的时候，发现这个月基金收益率又成负的了，又下降了很多。而且看基金的资金流向，又是流出更多。可能是国外资金来吸了一波血撤退了吧。
在中国股市挣钱真是一件特别难的事。俞敏洪在书中也多次提到中国股市是投机。中国股市难在它不是价值驱动的。像上个月上涨我判断它由于驱动力量不是经济形势好，而是由于国外更差，所以国外的资金涌入中国，导致上涨。像我们都知道这几十年老龄化社会越来越近，医疗/保险方面的基金理论上应该发展的更好，但实际情况是除了2020年牛市涨势不错，其它时间都是不温不火。
本月有一些重磅新闻，如每日优鲜破产倒闭，滴滴也在走破产审核程序。真是突如其来。在生鲜这个领域，第一是盒马，第二是叮咚买菜，第三应该就是每日优鲜了。每日优鲜和叮咚买菜在一周内相继上市。一直以来我的认知都是这两个势均力敌，北京市场每日优鲜占优，上海市场叮咚买菜占优。这突然就倒闭了真的是措手不及，唏嘘不已。
滴滴这事也挺突然的。就算滴滴前段时间APP下架，我还一直都用滴滴打车。应该是惯性吧。午饭时听说滴滴价格高，美团打车很便宜。也换到美团打车吧。
到处都在继续的裁员也在提示我们经济依然不容乐观。前有名校学生毕业找不到工作继续选择读书/考编，后有各个企业的裁员。字节也要缩招的消息已经传的铺天盖地。在悲哀时代背景的同时，也在暗自庆幸自己逢此乱世还能在合适的时机加入这个高速增长的赛道。
兴趣爱好方面是否有进步？
兴趣爱好方面已经从音乐/烹饪转变为了对业务全局认知的渴望。可能音乐这辈子我都不会重启了吧。
是否有过度关注兴趣爱好而荒废职业发展的现象？
没有。
一年计划完成进度如何？
主要目标进展顺利，音乐方面暂时搁置。
时间是否都被高效地利用了？是否将过多时间花费在了娱乐上面？
合理。
是否有像owner一样去思考问题？
是。
体重如何，达到目标了吗？
预期168斤，截止目前172斤，中间有达到170左右。但是没有管住嘴，跑步次数也相对初期少了，特别是天实在太热的那几天，反弹了。这方面做的不够好。
八月份计划
- 建设领域组件
- 整理数据口径
- 内部业务分享(✓)
- 阅读《数据驱动：从方法到实践》，学习数据驱动业务的一些案例(✔)
- 阅读《长期有耐心：美团的成长与进化逻辑》，了解美团在本地生活的发展历程(✔)
- 减肥到168。高低得减下去！
- 是否还记得愿望？
