NadeshikoManju@薫る花は凛と咲く7月5日播出

统计数据

9
文章
0
粉丝
0
获赞
27
阅读
avatar
暴论一下 AI 时代的到来，codebase 和架构将以前所未有的速度不断的腐化。 这会意味着稳定性越来越难做。之前被忽视的很多稳定性细节以及最佳实践都会在 AI 时代被放大。越来越多的初创公司比预期的更早的遇到自己的架构瓶颈或者到了技术债务的偿还时刻 而稳定性越来越难做的另外一层含义就是，能做稳定性的人也越来越少。而在 vibe coding 盛行的情况下，能静下心来做稳定性，扣指标的人也越来越少
#AI时代 #代码库腐化 #稳定性挑战 #技术债务 #Vibe Coding
avatar
打完空轨 1st 难得开心，写个杂文放松下
#空轨 1st #杂文 #放松 #游戏 #开心
avatar
到底都是什么人在喜欢nodejs
#Nodejs #技术 #讨论 #受众 #疑问
avatar
被同事赞美省心，活好 看目前看起来我自己的秉持的一定要去尝试理解业务的路子是没有错的 搞 SRE 的，一定是要把业务的体感降到最低的
#同事赞美 #省心 #理解业务 #SRE #降低业务体感
avatar
深夜说一个最近的感想 其实也不算新，还是老生常谈的一个话题“做 infra 的人必须要去贴近业务，否则一切都是空中楼阁” 我介绍过很多次鄙司是 AIGC 头部玩家，主攻二次元赛道。 我们最近面临的一个问题是 Elasticsearch 带来的。 我们用户公开发布的 Artwork 和生成任务都是可以搜索的。 最近 Elasticsearch 频繁会出现部分 Data Node 被打满然后连锁搜索出现问题的情况。 那么我们需要去怎么样快速的解这个问题？ 在进一步讨论之前我们需要思考在这个场景下，搜索这个操作的本质是什么？ 我的看法是资产管理。在 AIGC 场景下，Prompt 毫无疑问是用户的核心资产，而对应的 Task 以及 Artwork 某种意义上算是资产的预览（or 属性） 那么有了这样一个推论后，我们便能清晰的知道，至少在目前的形态下，业务核心属性必然不能为了技术结果让步。 同时我们又有一个观察，我们用户公开发布的 Artwork 其的可见性和 Task 是不太一样的，Artwork 可公开检索，也会承担 SEO 的责任，而 Task 实际上仅用户可见。那么换句话讲，两者的数据的访问频率，资源需求都是不太一样的。 换句话说，我们对 ES 的 Index 存在了多租的需求。但是很遗憾，按照目前的 ES 的设计，是不具备多租的能力的。 虽然长远来说，优化查询会是一个必然的选项，但是在当下面对超高速发展的业务，拆分 Index 为不同的集群，按照 Index 不同的属性给不同的算力/磁盘，快速试错会成为我们的首选。 目前这项工作正在进行中，效果未知，但是整个思考博弈的过程其实是我前几年会很少考虑的。很多时候技术的最优解未必是业务的最优解。 最后的最后，再打一个广告。鄙司招人，ML Engineer，ML Data/Full Stack/Backend/Marketing 等职位虚位以待。如果你想一起做一些有趣的事情，欢迎 DM，帮你老板直达
#AIGC #Elasticsearch #多租户 #业务优先 #二次元
avatar
我们准备家里添的和医院同样的设备以小猫的名义捐给医院了
#小猫 #捐赠 #医院 #医疗设备 #积极
avatar
心态崩了，没忍住在医院哭出来了 昨天早上指标都好不容易贴近正常值的下限 大家都很开心 结果下午就来了个大出血 今天上手术台最后一搏 不能哭了，要忍住 不能影响医生判断
#医院 #大出血 #手术 #心态崩了 #积极
avatar
不怕笑话 我从阿里离职的一个诱因就是 我真被钉一下搞到 PTSD 到物理意义上的失禁过
#阿里 #离职 #钉钉 #PTSD #失禁
avatar
Service mesh 一直没解决一个问题。不管是什么路线，基本上都会保持一个 sidecar 来做很多杂活。而在大规模的场景下 service mesh 没解答的一个问题就是我每个sidecar 500M/0.5 Core 资源累积起来的额外消耗能解决什么样的问题（或者说是 service mesh 独一无二的价值） 而至于小规模场景，为什么要 service mesh（疯了吗