在福报厂干外包，吐槽一下一些项目开发的乱象

[wangbenjun5]

众所周知，一般一个公司会有很多产品，一个产品背后的服务也不止一个，也就是说有一个产品背后对应着多个项目，在某福报厂，大大小小的项目数不胜数，基本上只要写个东西都要整一个单独的项目出来。

我有时候很好奇，为什么要搞那么多项目出来，但是仔细一想，整个新项目才有新 KPI 啊

这些大大小小的项目，有些可能只是几个接口，几个定时任务。。。所以也算不上很重要的，而且都是内部项目，并不是面向普通用户。所以也没有运维、测试等配套人员，只有你自己，基本上就是想咋搞就咋搞。

1.发布全靠手动。福报内部有一个叫作 aone 的容器化发布平台，但是配置繁杂，很多 p7 大佬也不会，或者懒的搞，直接就是打一个 rpm 包，然后 ssh 到生产服务器上面手动安装发布，写一个 shell 脚本保活就算完事。

2.看日志要到生产服务器上。话说但凡是一个项目少不了业务日志，出点问题的话总要看日志排查，但是呢，我所接触的项目很多都没有对接日志平台，类似 elk 这样的东西福报厂内部也有。但是很多 p7 大佬不知道是不会还是懒。有时候看个日志就 ssh 到服务器上面 tail 。但是外包狗是没有生产服务器权限的，所以你懂的。。。

3.数据库设计很烂。所谓的核心库，里面有几百张表，建表根本没有一个统一规范，或者是有规范但是没有人监督执行。有些表没有 id 主键，有些表是复合主键，表的时间字段有叫 time，有叫 utime，还有叫 gmt_created，还有叫 created_at，一个库里面这样的设计比比皆是。

更不要说什么数据库设计三范式了，我怀疑这些 p7 大佬们压根就不懂 mysql，其实也正常，因为他们大多数并不是主要搞 web 开发，对于他们来说，mysql 就是存个数据，也不用考虑性能问题。可是倒是苦了我们这些写 CRUD 的外包狗。

以上内容纯属虚构，如有雷同，纯属巧合！

理性吐槽，主要还是个人原因，有些人有追求都搞的很好，有些人面向 KPI 编程，能用就行。别扯太远了……

再吐槽一个 api 鉴权的问题，项目内部各个系统之间难免会需要互相调用，为了安全性都会加一个鉴权。这个鉴权方式更是八仙过海，各显神通了。

有那种最简单的是数据库里面存个写死的 key，直接放 header 就行

还有那种加一个 user，和时间戳拼一下， 然后 md5

还有那种把接口的路径也带上的放进去 md5 的，有用_拼的，有用.拼的

还有的不用 md5 直接用 rsa 算法加密的……总之，每个系统都不一样，哈哈

[changchong]

外包一年能拿多少个？

[dragonszy]

关于 3 可能是接手过来的（传统行业 /上市公司 /国企 /大型民企）历史遗留数据库设计。作为只懂最基础 SQL 的业外人士经常看到某些设计也惊为天人，设计缺陷硬生生导致数据 x5，速度-10 。

[wangbenjun5]

@dragonszy 并不是接手，只是经手的人太多了，都是按照自己的风格想法来设计

[wangbenjun5]

@changchong 20 个左右

[dynastysea]

不知道你是否在别的大厂干过（对比鹅厂），如果你干过你可能会觉得福报厂做的真的是很牛逼。。。这些基建真的是很强。。。

[pigspy]

哈哈哈，我明白你的感受
大厂里面的混子真滴多

[wangbenjun5]

@dynastysea 没错，这些基础通用平台都有，福报厂一般都是拿开源的改改，内部换个牛逼的名字，但是就是很多人不用，或者用起来太麻烦。。。

[sagaxu]

存活比较久但很久没重构过的项目，可能都这样吧

[jxxz]

好奇哪家外包

[cs419]

只能说源码也是人写的
光鲜亮丽的小姑娘 可能俩星期都不洗脚

[akatquas]

@jxxz 阅读文章，提取关键字 “ aone 的容器化发布平台 ”

[EmiliatanTenshi]

第一点被人诟病很久了，套用一句老话，你看到的是一堆 p9p10 老板撕逼后平衡得出的产物，也是没办法
第二点不清楚集团什么情况，蚂蚁的合作伙伴（也就是通俗的外包）是没有生产的任何权限的，包括服务器和日志平台，所以线上问题只能正式员工查。
第三点，不是没有规范，而是规范一直在迭代，之前的 time 和 utime 应该是历史产物，蚂蚁最新的标准应该是 created_at 。

大厂要吐槽的点数不胜数，不过就跟了解技术的实现细节一样，去研究一下背后的原因，有时候也是蛮有意思的
（当然吐槽还是要吐槽，这样可以更有底气地吐槽😏

[wangbenjun5]

@EmiliatanTenshi 哈哈，肯定有原因，我不太清楚都是这样，还是仅我接触到的是这样。不过个人感觉还是开发的不作为原因居多，只图完成项目，说白了 KPI 导向，我说这些点搞好了也就那样，不搞项目照样能跑。

[ufan0]

福报厂是我所在单位的外包，你说的情况全部得到了很好的体现，其代码质量令人心累，一个项目重构五次了还是难以看下去，已经准备不签字了，要么我走人，要么他们走人。

[wangbenjun5]

@ufan0 躺平就行了，我是啥也不敢问啥也不敢说，默默填坑

[yyfearth]

积年累月的项目 这些都是很正常的
只要所有项目不是一个小团队并且人员基本上保持不变 否则不可能做到完全统一和一致
团队大了 什么人都有 而且也会有自己的风格 要保持最基本的一致只能靠一些工具来限制
像数据库这种 很难控制的 还有历史遗留问题一大堆 数据一多 迁移成本过高

[ztcaoll222]

@akatquas #11 谷歌搜这个关键字，第一条就是这个贴😂

[clearc]

题外话：p7 也配叫大佬。。。

[kerro1990]

农民工工地不一样很乱，更何况程序员也属于农民工

[wangbenjun5]

@ztcaoll222 不是吧，搜索引擎这么快的么。。。

[wangbenjun5]

@clearc 哈哈，p7 现在是主力，网上 p8 很难升了

[levelworm]

正常，其实去的公司多了就知道本质上大家都是草台班子。

[xjlnjut730]

大部分公司的历史项目都这样。就算现在新起一个项目，换了一波人，很快就变形了。主要还是看经手人的个人风格。在人员变更很频繁的情况下，显然这是不可控的。学会接受 or 改变吧～，大部分还是忙业务实现的，代码规范、数据库规范很多时候都是次要的属性。对开发而言，属于本职工作，但是很难体现在个人绩效里，除非领导是一个非常重视代码规范的人，很显然，这种领导凤毛麟角，而且一般这种领导上不去，^_^。人的精力也有限，有限的精力那肯定往有希望晋升，有希望涨薪的方向去了。

[swulling]

记得有人说过，当你充分接触社会，你会惊讶的发现大部分组织都是草台班子。

[Webpoplayer]

提取楼上#10 楼的话 “光鲜亮丽的小姑娘 可能俩星期都不洗脚”，可以说很形象了。。。

[Cbdy]

楼上都谈什么历史项目，历史问题云云，事实是新项目也是如此，不断重复历史罢了

[sadfQED2]

哈哈哈，百度员工表示代入感很强，我们这边也是这个鬼样，一个接口都要新启一个项目，人员多换几次，项目仓库都找不到了，各种 kpi 产物

[dwlovelife]

多问一句 要是 20 个服务器集群这种 怎么 tail

[wangbenjun5]

@dwlovelife 根本就没有集群，很多服务都是单实例跑

[AngryPanda]

KPI 导向问题，国内大小厂大多数都是重产出不重质量。

一种说法叫做实用主义，能用就行；另一种说法就是急功近利。

[justRua]

内部平台自己人用的估计就随便了，都单体服务了肯定是不重要的，能跑就行了

[wr516516]

不都走的 linkeE 发布吗

[dynastysea]

@wangbenjun5 不过可能也是看部门，可能有些部门业务不行，投入的也不够，据我了解到的类似淘系、阿里云、蚂蚁这些核心部门起码在你说的这些点上还是搞的比较正规的。

[Torpedo]

数据库设计我的感觉是，你看着一堆表，都是一堆人不断往上面加的结果，没有一个人做通盘考虑的

[wangyzj]

见过 P7 不会 git 的吗

[sgissb1]

p7 不会这不会那怎么了？会写 ppt，精通各种黑话，影响了评级么？价值观考核只要不及格，你就算会造火箭又能奈何？

要搞清楚抓手是什么，摸索的过程中要新城一套核心的打法！

[arthas2234]

高情商：在不断尝试中寻找突破
低情商：瞎折腾

[defage]

都说是小项目了，你都说是不知名了，很可能都没成气候，整的人模人样有什么鸟用。怎么快怎么方便怎么来也是种项目节奏

[NCZkevin]

大厂几万人，不同组情况完全不一样，你这种情况都是边缘部门无关紧要的服务，毕竟这种服务也就是 KPI 产物，随便糊弄下就行了，淘系那边对服务，日志这些方面要求还是很高的，基本都是按照规范来做。

[dejavuwind]

有没有 Google MS AWS 的大佬爆料一下，国外大厂也这样吗？

[mengjue]

这个其实也就是你是外包的原因了，只愿意吐槽，没有想过为啥这么做，或者我要怎么做的才能更好？举个例子好了，你说的 ELK 系统为啥没有像外部那样搞的原因时 ELK 没发容纳这个平台级别的日志，所以他们搞了一套自己的，通过 hadoop 归集，然后放在一个统一的平台搜索。

[x940727]

@Torpedo 通盘考虑的人不是离职了就是升级了，想找一个能通盘接手的人的难度可是非常大的，尤其是在大厂内部 KPI 还逼得紧的情况下就更难了。

[matrix67]

@dejavuwind #40 特斯拉之前的员工有爆料过的 https://news.ycombinator.com/item?id=17835760

1. 我曾经在 SpaceX 的团队中工作，该团队开发了一款名为“WarpDrive”的软件。它是一个庞大的单体 ASP.NET 应用程序，大量使用 ASP.NET WebForms 完成，而当我在那里工作时，ASP.NET MVC 的缓慢前沿逐渐增长。该应用程序几乎负责运营工厂的所有工作：库存、供应链管理、成本分析等。Elon 是 Windows 的忠实粉丝，并努力推动使用 Microsoft 技术运营整个商店。值得庆幸的是，火箭通过高度定制的 Linux 安装飞行。

2. mode x 和 s 和后端之前通信是挂着 openvpn 的。

3. centos 6 上跑着 ruby on rails

4. 。。。。等等 不翻译了

[x940727]

@mengjue 内部人都不搞，指望外部人搞？服务器怎么申请？而且搞出来谁维护？外包没有责任去帮甲方变的更好，而且也基本上没资格查询线上的日志，你这种结果论的人是真的令人害怕。

[OMan]

人和代码，有一个能跑就行。

[mengjue]

@x940727 今天闲的慌，再回复你一次好了。我讲这个实例的意思是，每个决策都是有背景和 tradeoff 的，仔细研究这些决策背后的根本原因，有利于帮助自己成长，比如说日志这个事情，如果跟多 infrasture 那边的人交流下，就会明白原因了。阿里系虽然名声不堪，但是里面的技术牛人还是外边不能比的，更不要说跟一个外包比。

[wangbenjun5]

@mengjue 兄弟，你这话说的，我要是能搞早就搞了，主要是没权限。

[wipbssldo]

@mengjue 看完你写的，我也不太明白「发布全靠手动。看日志要到生产服务器上。」这些决策背后的根本原因，有哪些利于帮助自己成长

[dejavuwind]

@wangbenjun5 盲猜一下 @mengjue #46 这位怕是利益相关吧？在线答疑？

[dejavuwind]

看了半天才知道 infrasture 其实说的是 infrastructure 基础设施

[zjuster]

阿里的这些数据库设计结构，是现实，但是没人能解决，或者说没必要解决。实际上在这种数据结构下面还能稳健运作，是阿里的技术功底。

这么多年技术迭代、业务变更下来，在人员变动较频繁的情况下，数据库设计规范是不可能实现的，你看到的一个数据表可能是三四个人接手过的，或者有十年历史的。

aone 本身是很强大的工具，上手太难，业绩重要的情况下，很少有人会好好用。

[zjuster]

很多问题 一些毕业生会问你怎么不按照书上写的做呀？

现实就是书里、实验室里的工程项目，和业务线上运作的底层逻辑是不同的，首要目标也不同。

好的代码规范当然有用，有一个这样注重技术规范的领导，对整体部门稳定性有大好处，但这样的领导很快就会有精力牵扯项目。技术高 p，要推广技术，要考虑饭碗抢业务，给手下弟兄争利益，这样的背景下，规范优先级着实不高。

[jakezh]

据掉福报厂 P8 offer 的飘过
早就听朋友说了，不知道 infra 组整天加班在加些什么

[eric96]

@wangyzj 我司挖的别的公司技术总监过来带小团队，也是不懂 git

[Torpedo]

@x940727 互联网第一定律 0 到 1 升职。1 到 2 离职

通盘考虑，显然是 1 到 1，肯定没啥人搞的

[Joker123456789]

都是赶着发布的，使用者也不关心底层，反正又不是他们维护。 他们只想快点用起来。

这是世界通病，作为一个新时代的农民工 没办法的。

[onionKnight888]

就好奇问问，p7 升 p8 难吗

[js8510]

有时候就是没必要啊。等各位工资更高了，不这么卷了，人力成本上去了，自然自动化程度，工程质量就要被迫提上去。p7, p8 也不过是和您一样的打工仔。代码人人都会写，不是你写的多，写得好就能升职加薪的。到了这一步，你要给上头拿出来可以量化的成绩。
如果各位工资再高一点，并且不加班，招不到这么多小弟人海战术。业务需求还是那么多，那肯定有一帮 ledership 站出来我们要 better engineering 。

[js8510]

@OMan 精辟了。就是这个道理，人能跑又便宜，就不用优化代码。

[yl666]

@wangyzj #35 真的见过

[yl666]

不过人家的业务理解能力确实很强，各种切入点都想都很完美

[SlipStupig]

@clearc 最少也得是团座？

[janxin]

阿里现在 P7 比以前水多了，尤其是人员扩充频繁流动大的前提下

[xingguang]

呵，我当年两年换了三个换汤不换药的框架，美其名曰更先进的组件，两年换了有五个 leader，所以我为什么当初 20 年疫情那么严重的时候果断换工作，实在呆不下去了

[Muyiafan]

没有集群，单实例可太真实了。

[EthanDon]

笑死，怎么感觉在说我厂。。。
0. 从零开发一个项目比在老的项目上改要稳很多快很多，所以就有一堆微服务出来了
1. 这个没见过
2. 其实很多大厂业务很忙的，人员更换又频繁，配套的工具虽然多，但是得花时间去学，所以有些服务就是先上了再说，先跑起来再说，就变成 shi 山了
3. 有可能这个表是实习生建的 /有可能这个组业务太忙，没时间 review 这些 /有可能这个组压根就没有技术大佬

其实想明白了大厂的一部分体力主力军是应届生甚至实习生，就释然了

[lplusk]

同福报厂，你所在部门的情况看起来是工具效能同学和 SRE 不太称职 or 业务不太重要，所以相关流程、工具的使用做成这个样子。

[Bigglesworth]

@janxin #63 水太多了，甚至培训班出来都能上。。。

[loryyang]

有几个因素造成：
1. 短期 KPI 导向，长期看变动过大
2. 人员素质不齐（我更倾向于培训不到位）
3. 工具支持不到位
以上因素重要度依次递减

[still97]

g，怎么跟我们一个小公司一样，我每次都吐槽字段名变来变去，一个项目好几种日期名，吐了。。。

[redvoilin]

@mengjue 你这个回答就很有阿里味

[guoyuchuan]

楼主加个微信聊一聊。

[roundgis]

又不是不能用

[AltairT]

aone 和 sls 都不接嘛？ ssh 到服务器上看日志也没啥，有时可以更快定位问题。
外包不给生产权限很正常，生产权限本来就要严控。

[tuomasi]

@mengjue 你这个逼，典型的秀儿，还里面的牛人，都跟你一样鸟人吧

[Routeros]

@swulling 又是鲁迅说的

[liudengchn]

感觉在说我厂，太体面了