我们公司有的架构师，一个人的代码量和bug fix率顶10个人，即便离开项目组好几年了，真正遇到疑难问题的时候，还得找他。他还能给你解决了。

还有的架构师连你的code在哪里都不知道。
每次向上汇报，需要先问engineer温习一下。要不然就忘了

- 来自 水木社区APP v3.4.2
【 在 wallyz 的大作中提到: 】
: 我并不算是互联网行业的
:
: 但这几年，因为产品向虚拟化，然后再往云原生转型，确实也经历了不少或深或浅的坑
:
: 比如，2019年，RHEL/CentOS 7.X kernel里面一个multiqueue的深坑，在虚拟环境下打开virtio-net的multiqueue，会造成发出去的包乱序的问题，就把产品以及我给狠狠的坑了一下
:
: 去年疑似被k8s环境下，CFS quota over throttling给坑了一把
:
: 今年早些时候又被openstack的NUMA问题给扰了一小段
:
: 其实我不愿意给自己扣一个架构的帽子，我也看不上不接地气只会PPT的架构，至于前面那种，以项目管理的方式作架构，出了问题，让工程师出方案的，就更匪夷所思了。
:
: 产品在现场出了问题，那时候，什么样的人能出的上力，这是很清楚的。这时候，需要从很底（操作系统，网络协议，计算机基本体系结构），到很顶（产品实现的原理甚至细节），都要有挺多的理解，或者去做挺多的调查，才能在各种纷繁复杂的线索中，找出可能的问题，当然，也需要运气。
:
: 无论如何，不接地气的架构，大概不是一个好架构，至少，对这个产品来说，不够好。
:
: 有人说，出了问题不应该是架构来搞；那可能是没经历过实战，那时候，老板手里能抓住什么稻草，就会抓住什么稻草，何况，产品出了严重问题，哪有人可以独善其身。
: 所以，产品出了问题，懵逼的架构，装死不吱声的架构，或者指望别人出方案搞定的架构，在我眼里，都不是好架构
--
FROM 116.88.151.*