之前公司因为 aws 的 kafka 服务上的副本数配置不正确，所以在 aws 例行重启时会导致 producer hang，连锁导致消费断连，当时总结了一篇简单的文章： aws 上 kafka 服务更新导致断连一例公司内部写 kafka 的 consumer 和 producer 使用的是社区流行的 sarama 这个库，这个库应该 bug 挺多的，之前有云厂商建议用户不要使用该 lib 的文档：为什么不推荐使用Sarama Go客户端收发消息？ 不过用都用了，

现在稍微有一点规模的公司基本都上微服务了，后端工程师在大小公司打杂的话都会碰到因为是微服务，所以在做开发的时候： * 依赖太多，没有稳定的环境，服务跑不起来 * 服务要走网络，稳定性问题难以解决 * 上下游要解耦，每次上游做修改下游都会有故障 各种各样奇形怪状的问题，每一个痛点都会涉及到不少相关的解决方案，比如环境问题，之前我分享过 https://tilt.dev/；稳定性问题，我们直接去看 Google 三步曲 https://sre.google/books/；上下游用队列解耦之后，上游的不稳定业务事件导致下游故障，有 data validation 平台和 schema registry

不知不觉已经过了靠纯代码输出来做事情的阶段，很多时候做事情变成了说服别人做事情本身的价值，自己体力输出对于公司的贡献度已经越来越小了。作为一个架构师，需要能够帮助部门和公司走上正确的路线，避免无意义的内卷和消耗，以免让一线的开发心灰意冷无所成长最终提桶跑路。 2017 年，美团在南京上线了打车业务，滴滴上下为之震惊。彼时滴滴在本土兼并收购，打跑了洋人对手 Uber，正是意气风发之时。 又因为资本和老板之间良好关系的原因(CEO 们没少勾肩搭背吧)，滴滴的高管们曾经认为美团绝对不会涉足打车领域，所以美团的决策让整个公司从上到下都很震惊。 O2O 业务在前期是笼络用户阶段，靠用户数量的增长为未来盈收的增长埋下种子，当业务达到一定规模，再以成本优势将用户对平台的依赖转化为平台的收益。 用户增长的核心引擎就是公司内部的运营系统，早期运营是大多数互联网公司的边缘业务，在大多数公司内大家一听到运营，想到的都是 CRM 系统，体感就非常之 low，

公司内部写 kafka 的 consumer 和 producer 使用的是社区流行的 sarama 这个库，这个库应该 bug 挺多的，之前有云厂商建议用户不要使用该 lib 的文档：为什么不推荐使用Sarama Go客户端收发消息？ 不过用都用了，随便换也不好，碰到问题了还是要先定位一下，然后再去看到底是不是 lib 本身的质量问题导致。贸然就说这是 lib 的 bug 会让人鄙视。 现在就碰到这么个场景： 部门内有一个 kafka 的 message

最近和一些前同事聊天，有些同事已经离开了大公司，一少部分还留在大公司里和年轻人们内卷。思来想去，我个人应该之后也不会去国内的大公司了(希望不是 flag)，有些阶段性的问题也是时候该有答案了。 刚毕业的时候年轻的我曾经问了当时公司 mentor 两个问题，一是为什么明明活儿干完了到时间却不能下班；另一个是为什么企业要用这些虚无缥缈的工时来作为员工的工作态度来进行考核。当时的 mentor 自己也没想明白，他说大家都是这样的，你别搞特殊。 这令我非常尴尬，学生时代我的考卷就没有在考试结束的时候交的，既然半小时、一小时就可以把这些事情搞定，为什么非得屁股粘板凳上陪着各位同学呼吸考场的脚臭味。企业里的潜规则却把按时下班也当成了搞特殊，让我想起了没人愿意当刺儿头的日本文化。 不过日本的职场应该也不是十年前的样子了，还有这样的电视剧能上映： 我们的主流文化时至今日依然鼓励奋斗而不是偷懒，连按时下班可能都会被划到不够奋斗的落后分子里，要以最后走出办公室为荣。上进奋斗并持续不断地加班再加班，哪怕整个社会已经陷入到生产过剩的经济危机里去。辛苦生产的牛奶，