去年的这个时候，IT 圈哀鸿遍野，吐槽技术红利消耗殆尽，所有公司都失去了新的增长点，程序员红利到头了。
今年的这个时候，程序员的好日子确实进入倒计时了，只不过不像当初做预言的人想的那样，连他们自己的末日也在倒计时了。
中国的互联网从业者并没有把 AI 当回事，这几年来对 AI 的看法是这种基于统计和传统神经网络的技术不足为惧，因为硬件的发展让老树发了一点新芽，套上强大的核弹厂芯片加一些修修补补的算法，能帮这些批着科技外皮的牛皮癣广告公司卖出更多的广告，能让信息茧房里的人看到更多他们喜欢的信息，奶头乐吸得不亦乐乎，让整个网民群体娱乐到死，普通人失去了研究的耐心和学习发展的能力，商业公司赚到了更多的钱，着实是 win-win 麻了。
2022 年下半年，Github 的 CoPilot，OpenAI
之前在这篇 subset 限制连接数量 里，简单总结了 SRE book 书里讲到的 subset 算法的基本原理和问题。
之前还在做 mesh 的时候，也曾经想把 subset 算法在公司内落地，无奈和同事一起分析了两个星期以后，认为 subset 的：
1. 需要 paas 给每个 container 分配连续 id，且在下线时需要自动补漏，目前 k8s 其实并没有这种策略，给每个服务都做成 stateful-set
之前公司因为 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，
