[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f17o5g4h44w2t7":3},{"_id":4,"slug":5,"title":6,"subtitle":7,"kind":8,"cards":9,"tags":58,"categories":59,"source":60,"lang":63,"author":64,"audioState":67,"stats":68,"publishedAt":71,"renderer":72},"6aba214bca21c797c7e98206","it-03-97e7a700","IT风云录 03 | 大公司里老技术部之困境","上一篇承接 IT风云录 02 | 中年程序员，看不惯大公司，去小公司了，说到我无法忍受大公司极致的办公室政治，离开了大公司去小公司。今天再加一篇大公司技术部里的其他问题。 其实，除了办公室政治之外，技术部在规范体系下，也陷入了一种无法跳出的循环。","news",[10,13,18,23,28,33,38,43,48,53],{"headline":6,"body":7,"imageUrl":11,"images":12},"\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F0.webp",{"local":11},{"headline":14,"body":15,"imageUrl":16,"images":17},"年会如期进行，在今年严峻的经济形势下，公司今年的营收和利润，相比去年都有大于30%的增长。这主要得益于老板有个原则：员工要比公司挣得多。也就是今年公司增幅10%…","年会如期进行，在今年严峻的经济形势下，公司今年的营收和利润，相比去年都有大于30%的增长。这主要得益于老板有个原则：员工要比公司挣得多。也就是今年公司增幅10%，员工收入也要比去年增10%。但是，这个增长不是针对所有人，而是那些挣钱的部门。 老板拉来一堆现金，在年会现场分发。张三，3万；李四，13万；王五25万。销售1部，10万；客服2部，5万……很遗憾，IT研发部，不管是团队还是个人，都榜上无名。 不得不说，确实存在这么一个现象，销售类的岗位是盈利部门，像行政、人力、财务这类属于成本部门。而研发类的岗位，则视情况而定。可以是盈利部门，也可以是成本部门。 这个技术部几十个人，其中老员工很多。这里说的老员工，一方面是指在公司待得久，入职七、八年的大有人在。另一方面，年龄也都很大，40岁的也不在少数。公司很重视老员工，常将入职10多年的立为榜样，这让新员工入职后，感到不可思议以及安全感十足。 很多技术部老人看到发奖金，都会很失落。他们说，每年都这样，热闹是别人的，和自己没关系，连保洁、保安都有个“勤勤恳恳奖”，而程序员啥都没有。干技术没有前途。 作为刚入职的员工，我了解的不是很多，不过也稍微有点旁观者的视角。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F1.webp",{"local":16},{"headline":19,"body":20,"imageUrl":21,"images":22},"公司对于技术部很有成见。各个部门也都有意见，尤其是老板。首先体现在系统的脆弱性上，基本上每年在最关键的营销活动时，服务都会宕机。每次宕机，老板都很着急，事后想让…","公司对于技术部很有成见。各个部门也都有意见，尤其是老板。首先体现在系统的脆弱性上，基本上每年在最关键的营销活动时，服务都会宕机。每次宕机，老板都很着急，事后想让技术部避免此类情况再次发生。而技术部每次都有理由，也会提出新的解决方案。 老板配合技术部，从云服务器改为自建机房，从自建机房又迁移上云服务。 我来公司后，经历过两次宕机。第一次是一个大型活动，技术部说本来是没事的，结果因为运营人员在活动还没结束，就登上后台去查看汇总数据。这个汇总，会导致大量实时计算，结果数据库就顶不住了，停服务也停不掉，死机后数小时才重启成功。 领导说既然是数据库差，那就买数据库。技术部讨论后，感觉不能买。买多少？如果买了之后，还出现问题，那么就会处于舆论的被动面。 第二次，不算是宕机，只是限流。就是很多人来访问，将一部分人挡在外面。体现在app上是一直弹出500错误、服务器内部错误的提示。弄得营销人员都不敢推广了。来了很多人，进不了门，错失很多客源，浪费了营销成本。 后来，技术部又开始总结。原因是APP在一个页面调用了12个不同的接口，而且还有一个接口被连续调用了35次。这导致数据库压力加大，直接100%。幸好禁止用户访问，才没有崩溃。 技术部总监很着急。但是这个总监是App开发出身，不了解服务端。服务出问题了，他就去找后端开发。后端开发则感觉，架构设计是你总监的事情。我就算干好了，那也是你的功劳。因此不优化是本分，优化是情分，有些消极和抵触。 那么为什么不让后端当总监呢？刚才也说了，年龄偏大。第一，技术栈比较旧；第二，人也有些固执。其实这两者是统一的，因为固执所以技术守旧，因为凭老技术能活，所以可以保持固执。而作为一个部门领导，起码的底线是在行政能力上要过得去。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F2.webp",{"local":21},{"headline":24,"body":25,"imageUrl":26,"images":27},"目前后端Java服务还是单体架构。平台功能也就是Java连数据库读写数据，运维经常检测出大量慢SQL查询。另外，也没有用到什么Redis、Mango、ES，更别…","目前后端Java服务还是单体架构。平台功能也就是Java连数据库读写数据，运维经常检测出大量慢SQL查询。另外，也没有用到什么Redis、Mango、ES，更别说Flink、MQ、CI\u002FCD这些了。他抵触微服务，说微服务没用。性格上也比较固执。产品想要一个简单的功能，版本号升级，想从“3.1.19”的版本升级到“3.2”版本。他说不行，版本号必须得是3位数，要不然实现不了。产品问“3.1.19 beta”行吗，他想统计下测试版的用户数据。后台说不行，没法做比对，因为它要按照每个点切分出数字，挨个比对数字的大小，这样才能知道谁新谁旧。产品说，直接比较版本号字符串不行吗？他想了想，感觉行。不过，他说，既然当时定好了规则，就不要再变了。 最终，产品放弃了版本号的规划。 总之，老技术们有些抵触新技术，复杂的不愿意尝试。简单的又想靠着完全掌控的能力，去拿捏别人。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F3.webp",{"local":26},{"headline":29,"body":30,"imageUrl":31,"images":32},"让各个部门吐槽的，还有跟技术部提需求。技术部一直说活多，排不开，响应不了需求。但是，很明显多数人，看起来并不忙，也没有人加班。于是，这几个业务部门领导一碰头，发…","让各个部门吐槽的，还有跟技术部提需求。技术部一直说活多，排不开，响应不了需求。但是，很明显多数人，看起来并不忙，也没有人加班。于是，这几个业务部门领导一碰头，发现都没有开发他们的需求。那他们忙什呢？其实需求提到总监那里，当总监去安排任务时，结果安排不下去，各个组都说自己很忙。最后，总监就向上反馈说自己部门的人都很忙。实际上，可能是几个组长很忙，忙的很烦，不愿接需求，而组员并没有事情做。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F4.webp",{"local":31},{"headline":34,"body":35,"imageUrl":36,"images":37},"整体情况就是这样，老技术们，感觉自己很辛苦，老板也不加钱。不加钱，我没有优化系统的动力，而且你也没有具体的详细策略，出架构那不是我的职责。老板感觉技术部问题频出…","整体情况就是这样，老技术们，感觉自己很辛苦，老板也不加钱。不加钱，我没有优化系统的动力，而且你也没有具体的详细策略，出架构那不是我的职责。老板感觉技术部问题频出，系统不稳定，不愿加钱。你干出成绩我才加钱，比如做到今年不宕机，原来需要100万的成本，通过你们技术研发，成本降低到50万。这才叫成绩。 技术：不加钱，我没法努力。老板：干不好，怎么加钱？ 两者陷入如此的循环。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F5.webp",{"local":36},{"headline":39,"body":40,"imageUrl":41,"images":42},"老板为了解决技术部的问题，就经常给技术部换领导。因为你告诉老板，宕机的原因是一个接口被调用30多次，他听不懂，也没有解决方案。要钱、要人都好办，你说接口调用太多…","老板为了解决技术部的问题，就经常给技术部换领导。因为你告诉老板，宕机的原因是一个接口被调用30多次，他听不懂，也没有解决方案。要钱、要人都好办，你说接口调用太多，他懵了。他只能找一个能对得上话的人去解决。技术部内部是找不出来的，他认为如果存在这样的人，问题就不会发生了。实际上，技术部里的人，都觉着自己能解决，但是前提得加钱。多少钱办多少事，否则我就静止不动，装傻充愣。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F6.webp",{"local":41},{"headline":44,"body":45,"imageUrl":46,"images":47},"结果，就空降了很多领导，换一个不出成果，换一个还是没有起色。但是，每一任领导都会推翻上一位的设计。比如云服务有问题，那我们就自己建机房。下一任领导来了，听说自己…","结果，就空降了很多领导，换一个不出成果，换一个还是没有起色。但是，每一任领导都会推翻上一位的设计。比如云服务有问题，那我们就自己建机房。下一任领导来了，听说自己的机房不行？我们上云服务不就解决了！这就造成技术部架构经常变，也没有什么积累。更严重的是，员工也倦了，变来变去，反反复复，再有新的改革措施，大家也不愿认真执行了。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F7.webp",{"local":46},{"headline":49,"body":50,"imageUrl":51,"images":52},"并且，在这个过程中，业务还是不断积累和发展的。这也堆积了形形色色的病态业务系统。而这些系统，只有老员工能掌握，里面的机关埋伏，根本没有文档，全在他们的脑子里。想…","并且，在这个过程中，业务还是不断积累和发展的。这也堆积了形形色色的病态业务系统。而这些系统，只有老员工能掌握，里面的机关埋伏，根本没有文档，全在他们的脑子里。想改什么东西，复杂不复杂，里面到底怎么个逻辑，老技术说啥就是啥。你想维持生命，又不能让老员工过于动荡，否则会导致业务断层。 倒是也会新来一些空降的技术领导。所有的空降领导，都能发现问题所在。问题大家都知道，实习生都看得出来。 比如缺乏技术领导力，团队没有激励机制，缺乏考核流程，技术债积累严重，技术体系稳定性缺失，业务混乱，人员消极等等。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F8.webp",{"local":51},{"headline":54,"body":55,"imageUrl":56,"images":57},"但新领导也只能做一些表面上的改善。比如，基层管理说员工都不听他的，多次强调要交周报，底下员工就是不交，导致自己不知道他们每周都在干什么。空降领导说，周报写不好，…","但新领导也只能做一些表面上的改善。比如，基层管理说员工都不听他的，多次强调要交周报，底下员工就是不交，导致自己不知道他们每周都在干什么。空降领导说，周报写不好，扣工资，看他们交不交。稳定性缺失？把稳定性纳入考核，谁写的代码不稳定，扣工资。说一直忙还不加班？压缩工期，原定10天的任务，让6天干完，这不就忙起来了。 对于系统BUG多，领导说好解决，发现bug，按照数量扣工资，肯定就没有bug了。","\u002Fapi\u002Fmedia\u002Fposts\u002Fit-03-97e7a700\u002F9.webp",{"local":56},[],[],{"name":61,"url":62},"Juejin","https:\u002F\u002Fjuejin.cn\u002Fpost\u002F7689883764008239142","zh",{"handle":65,"displayName":66},"spots","Spots",null,{"views":69,"likes":70,"saves":70,"shares":70,"completions":70,"opens":70,"skips":70,"depthSum":70},6,0,"2026-09-28T08:11:55.888Z","local"]