随笔
不知不觉入职四个月了。
这段时间，每天都很忙，每天都要满状态战斗到凌晨。但说实话没感觉多累。每天都会灵魂拷问自己，我对团队的价值是什么？我们小团队对整个大的Team的价值是什么？我们对用户的价值又是什么？这样来确定工作重点。
这个月，也终于发现如果只靠工作时间，就只能完成分内的事，可能做的不差，但也说不上出彩。像那些重要但不紧急的事，如对业务更加深入的理解，如稳定性建设的进一步探索等，都需要等到周末没人打扰的时候去完成。这些事情虽然不紧急，但远比开发工作重要。刚好觉得自己周末过得实在颓废，所以本月跟女朋友探索一种新的周末生活方式。我们会拿出来半天工作，然后拿出来半天去读书。不喜欢在家里，一般都是去咖啡厅或者书店。周末过的更有意义。
这样下来自己的压力小了很多。什么时候会有压力呢？就是知道自己有很多重要的事情没做焦虑，所以就会有压力。而现在每周末都会去思索这些事情如何去搞然后实施，就不会一直焦虑自己做的不够好，该做的事没做。而且实践下来发现其实不需要周末占用太多的时间，半天就足够了。周末一般没人打扰，效率也比较高。两三个小时能做很多事情。
我觉得这是比较好的生活方式吧。刚开始强调工作生活分离，下班之后就完全不要考虑工作的事情。但是真正做自己喜欢的事情，或者自己肩负着一些责任的时候，是做不到工作生活分离的。而工作和生活的结合，看到事情的进展，事情的推进，也是幸福的一种方式。
阅读
这个月没规划要读多少书，反而读的比较多。读完了《高效能人士的七个习惯》，《轻松主义》，《人性的弱点》，还去书店读了一些推理类的书。
治愈我内耗的，不是二舅，而是这些书。
首先，《轻松主义》这本书，改变了我的工作方法。书里倡导的观念是，比起做正确的事，如何正确的做事也很重要。那么如何正确的做事呢？对我最重要的一个启发是，做事不要等到万事俱备再开始，而是应该有一个想法，有一个雏形就开始做，否则一直想做到完美就极容易在这个过程中内耗。而在读这本书之前，我其实已经为了把一件事情做到完美而精神内耗了很久。后来在这个原则下我开始启动这些事情，最终取得的进展反而极大的超出我的预期。
给我帮助最大的第二本书是《高效能人士的七个习惯》，第二次读这本书，依然给我不少的收获。首先是第一个习惯，积极主动这个习惯，在做事这方面我做的还不错。但积极主动其实更重要的是一种心态上的转变，即用乐观的心态去看待事情，去做事，这个是我要提升的地方。还有第三个习惯，要事优先，也有了新的体会。首先，我们要区分重要和紧急的区别。看起来就是两个概念，但如果不区分清楚其实这条原则没法执行，而我过去其实一直没有很好的区分出来重要和紧急的区别。
我们应该多做重要但不紧急的事情，而少做紧急不重要/重要且紧急/不紧急不重要的事情。很多重要但不紧急的事情，如果不处理，最终就会演变成重要且紧急的事情，消耗我们的精力和时间。
举例来说，假如我们每天都要处理报警问题，这些报警对我们就是紧急且重要的。那这个问题的根本原因就是重要不紧急的。我们做的重要不紧急的事情越多，就越能减少重要且紧急的事情，就越能提升我们的幸福感。
这条原则也给我带来了很大的收获。现在我们重要且紧急的事情越来越少了。
复盘
这个月过得怎么样？自己是否满意？
在技术上和业务上的进展比较满意。对体重方面的不满意，也是一直被督促但收效甚微的一个方面。应该作为一个专项去解决了。
技术方面有哪些进步？还有哪些可以改善的地方？
技术方面的进步主要有两方面：框架层面以及稳定性方面。
框架层面实践了公司内部自研的ES。开源版本的ES有一些缺陷，如聚合+排序+分页的时候由于它为了性能考虑，牺牲了准确性。比如terms查询当term太多的时候构建bitmap的时常就很长，就导致查询时间特别长。而内部自研的ES版本解决了聚合不准确的这个问题，并且在性能上也有不少的提升。在建设领域组件的时候，我们应用了这个特性，现在该功能P99只有40ms。
但性能提升，很多时候也不能仅凭技术层面去优化。很多时候还要考虑到用户行为。如设计该功能时，参考了另外一个类似的功能，通过分析该功能一周以内用户的行为数据，得到了用户绝大多数行为是使用预聚合数据的结论。所以在开发时便推动数仓同学对数据做预计算，而不是查询时从头计算。但为了保证灵活性，页面上依然保留灵活的筛选条件。该功能上线之后，我们发现用户的行为依然是绝大多数使用预聚合的数据。这是P99能维持在40ms以内的秘诀。同时也极大的减少了集群的压力。
稳定性层面，把负责的几个平台，特别是对外的几个平台，如抖音主端相关数据模块，稳定性都提升到了四个9。五个9我估计也没啥问题，但做到四个9已经足够了，就没必要钻牛角尖了。这是狭义上的稳定性，广义上的稳定性还包括数据准确性/数据产出时效/数据一致性/用户进线量等。这些也是我们需要去提升的。当前我最重要的工作就是减少用户进线量，所以我分析了用户一周的进线量，找出他们的痛点，后续推动相关解决方案。
本月另一个产出是规范了开发设计文档。在一次上线过程中，我们发现由于接口设计的没那么兼容老接口，导致服务一段时间不稳定。这引起了我的反思。我们明明review过方案，但为什么上线还会出现这种问题。而且上线之后，为什么会出现一些低级的口径问题，为什么会发现有些性能就直接直线下降？所以就设计了一版开发设计文档，包括流程图/Schema/兼容性/数据口径对齐/上线Check清单/数据准确性检验/性能测试报告/上线之后效果回收，从开发到上线全流程覆盖。在mentor进一步优化以后，推广到我们整个组使用。能够看到，我负责的这个方向，我们的产出质量有了明显提升。
领域建设这个月也真正做起来了。领域建设初衷一方面是解决口径太多数据不一致的问题，另一方面是提升我们的开发效率。本月建设完成最重要的一个子领域，顺便优化了之前的一些代码，改到直接调用子领域代码，极端场景下性能直接提升了10+倍。不仅提升了性能，也解决了过去由于性能太差引起的稳定性问题。这个子领域，能够看到，目前提过来的需求，能够覆盖很多，最近的四个需求，其中两个可以用这个子领域去解决。就可以将口径都收敛过来，减少口径不一致的问题。
另外一个技术上的进展就是搭建起了测试环境。这个也意义重大。众所周知，数仓一般都是只有生产环境，对测试很不友好，比如要测试一个视频的gmv，测试需要去线上真正发视频，真正下单，然后才能测试数据。这对他们很不友好。而且，由于他们要去线上构造数据，就导致不可能构造多的数据，就很多数据问题测试不到。本月就是搭起了我们这边的测试环境。测试同学可以通过直接在存储引擎中构造测试数据，测试我们代码有没有问题。提升数据测试的效率以及准确性。但这个测试环境也只能覆盖到从我们存储引擎到前端的数据，覆盖不到数仓生产的过程。但这也是没办法的事。
技术上的另一个进展是接入内部oneservice平台。由于抖音端上所有数据需要收敛到我这边，而我这边人力很少不足不足以支撑这么多数据研发工作，而且这些数据提供方式很简单，大多是点查。刚好我们团队和oneservice团队在共建数据应用，所以把这些需求都直接通过oneservice来支撑。在这个过程中，发现了一些oneservice的问题，也给他们提了反馈，他们都提需优化了。当然，抖音端上的数据这么重要，贸然接入肯定有很大的风险，所以我们在接入之后需要对它做严格的压力测试，并且配置严格的监控，防止出现问题。
数据提供方式多种多样，除了通过oneservice，还有一些其他的方式。对于其他的预估qps过高的，如qps预估能达到1w/s的，我们通过其他的方式提供服务。
业务方面有哪些进步？还有哪些可以改善的地方？
业务方面进步主要集中在对业务细节的深入。
罗列了一个清单，里面包括我感兴趣的十几个业务数据问题，如达人的各种问题，通过分析各种数据，对这些问题有了一个了解。
通过分析数据，也能摒弃偏见。本月跟着一个达人去探店，跟她访谈了各种问题，从她口中得知了很多信息。但也给我形成了一些偏见，以为她说的就是对的。但真正分析数据之后能发现，或许她说的是对的，但她代表的是高等级达人，还有一些腰尾部达人的生态跟她们完全不一样的。这也引发了我关于达人跃迁的思考。
了解了腰尾部达人在整个平台中的位置，才能重视他们。这也是让我去挨个查看几百个达人进线，花费这么多精力去真正了解他们痛点的动力，并跟相关产品同学去沟通我们能做点什么。
和达人沟通过程中也发现，如今视频号也挺强大了。
但还有比较大的进步空间，如没有像server研发那样了解业务，如没有去跟电商，跟快手/视频号去做全方位对比了解大的层面上的业务。
是否尽自己最大努力了？现在的自己能否成就三十五岁的自己？
是。
你的三年计划完成的怎么样了？有哪些进步？有没有偏离？
没有偏离。但应该时刻督促自己做的更好。
待人是否做到真挚诚恳，和朋友们的关系是否更加紧密了？
是。
四十岁的自己期望是什么样子？如果按照现在这种状态继续下去，会是什么样子？两者是否吻合？
是。
是否有保持阅读的习惯？从阅读中汲取到了哪些新的力量？
阅读治愈了我。
复盘下来的方案，是否真正有去落实？是否被同一块砖头绊倒两次甚至多次以上？
有落实。
是否有关注社会发展？特别是经济方面的发展？有哪些感悟？讲给我听一下
没有过多关注。
兴趣爱好方面是否有进步？
无。
是否有过度关注兴趣爱好而荒废职业发展的现象？
没有。
一年计划完成进度如何？
进展顺利。
时间是否都被高效地利用了？是否将过多时间花费在了娱乐上面？
合理。
是否有像owner一样去思考问题？
最近对Owner意识的认知得到了进一步升级。意识到仅仅在数据端的Owner意识不够，应该从前端到后端到数据全链路的Owner意识。
体重如何，达到目标了吗？
没有达标。
十月份计划
还是不设立计划。用本月的节奏去做事情，进展就很不错。
