2022年9月第三周周报
嗯,向贵州高速车祸中遇难的同胞默哀
生活
- 本周状态还不错
- 减重计划进行中,不过还是要坚持坚持再坚持
- 不过可能因为最近作息过于不规律,我过敏性皮炎又犯了。。
- 本周娱乐时间
- 德凯第10话,梦回旧平成了卧操,人与非人种族之间的关系怎么处理。镜头处理的也很棒,演员调教的很不错,镜头的话能明显看出来是吸取了好莱坞不少巨大化 CG 的手法。我觉得是新生代里最眼前一亮的拍摄
- 本周石蒜十二话更新,在人耳朵两边开枪利用噪声让人失能。石蒜的细节做的真的很不错
- 银魂.jpg
- 小说《小阁老》,喜欢历史文的同学可以看看
- 闲书时间继续
- 本周的改善伙食:日式烤肉,简直是好吃好吃好吃
- 最近看各种新闻,也是感叹人间疾苦
- 一点小事,让我觉得父母也真是老了
本周的读书时间
- 置身事内:中国政府与经济发展
- 史上最伟大的交易
最近开始看一些政治经济学的书,发现还是很有意思的,能很有效的弥补我之前的知识面的缺陷
技术
这周忙于工作上的事,感觉社区这块的贡献不多,下周得努力一下了
- 本周还是花了一些时间在 nerdctl 上
- 本周和 AFFiNE 团队的同学聊了一下开发者社区运营的问题(迷弟也见到了雪碧大佬)
- 开源社区核心的原则还是信息透明化,利用 RFC/Proposal 来尽可能的提早公开相关的信息,能够让更多的社区的关注者拿到足够的上下文。可能很多人对于 RFC/Proposal 有一些误解。对于不同的社区而言,有着不同的治理模式,Vote or BDFL 都是可以让人接受的。 RFC/Proposal 更大的意义在于社区成员的 comment ,而不是单纯的 Vote
- 对于一些大型功能的新增/重构,尽早的提出 PR,然后合理利用 Draft 或者 WIP,让大家方便 track 一个 PR,尽可能避免不声不响一个超大 PR 进来,这点 logseq 最近有个很不错的例子 PR6475
- 对于一个组织而言,如何避免信息黑盒是个非常值得讨论的问题
- 本周又是和可观测性战斗的一周
- 在治理 Sentry 之后,业务层面的报错源能够被用数据精确的评估,两个迭代之后,线上报错得到明显收敛。进而形成一个“报错分析->反馈业务->数据反馈更正效果”的正向循环。这也说明稳定性建设中两个基本要素的重要性
- 对于稳定性的评估指标一定要可量化,不可量化的指标没有任何意义
- 稳定性项目需要持续迭代与跟进,猪突式毕其功于一役的稳定性建设毫无意义
- 本周在写一个自定义指标上报的项目,如何处理业务各种变化极快的上报需求是个挺值得思考的问题
- 在治理 Sentry 之后,业务层面的报错源能够被用数据精确的评估,两个迭代之后,线上报错得到明显收敛。进而形成一个“报错分析->反馈业务->数据反馈更正效果”的正向循环。这也说明稳定性建设中两个基本要素的重要性
- 本周和 cache/DB 战斗了一些时日
- tidb 5.x 的 DDL 设计也是一言难尽,具体可以参考我的推上的吐槽
- 本周处理了一个标准的缓存雪崩的问题。业务方存在大 key,以及所有 key 的 TTL 都是 30 的整数倍,在某一时刻集中失效后,集中写入导致 Redis 负载急剧升高,升高后的业务超时重试机制又进一步雪崩了整个系统(过于标准的八股文场景
- Redis 一定要持续治理大 key
- 对于 TTL 一定要离散化处理
- 善于利用 Cloud-Vendor 的故障转移机制(self-hosted 尽可能集群化处理),先救命,再治病
总结
父母真的老了,我也得再快点而立了(
Comments