周末了，给大家分享一件趣事！让大家乐呵乐呵。

[laobobo]

应该是上上周的事情了，我是前端，公司内部用的一个系统上线了一个功能，比较简单，就一个 table 展示。运营反馈说页面没东西，我看了下接口报错了，就去找后端，后端检查了一下，发现数据库表没了。

当时我就在想，表怎么可能没了呢。东问西问，最终找到数据组，然后他们反馈说：昨天晚上同步数据有一个表特别慢，卡了 1 一个小时没过去，也不知道是谁在用，然后索性就线删除了。

我当时就很震惊，这玩意这么随意么，而且是生产环境，不过庆幸是内部系统，晚上没人用。没有多大影响。

离谱！

[hidder]

都是草台班子

[ooxx2123]

确实乐呵了

[smartruid]

牛

[pxiphx891]

牛逼

[www5070504]

一个展示系统用到的表会引起数据同步特别慢 本身也值得查一查 估计是他们着急下班 就这么干早晚出事

[0x663]

太逆天了吧，这不妥妥的 T0 级事故。

[vx7298]

内部了，又不是外部

[Pinealxx408]

6

[JoeDH]

数据组 这帮人 是什么成分

[Smilencer]

前端仔，真 bug router

[Pinealxx408]

我也分享个先一阵的趣事吧；
我们负责研发音响的软件，DQA 人突然在群里 @我们，告诉我们新版本软件无法找到设备蓝牙，属于重大事故。开关机重启动设备，恢复出厂设置都无法恢复，让我们快速派人去检查。经检查，发现是因为附近蓝牙设备太多，手机配对的时候，蓝牙名称在最下边显示不全，需要滑动手机屏幕。得到真相的我有点无语，但是不知道该骂谁。

[yjppeng]

@Pinealxx408 #11 哈哈哈哈 骂发现问题的人

[Bigbelly]

@Pinealxx408 #11 骂产品设计哈哈，设计需要引导出列表展示未完#滑稽

[C4D4zRNpq9vFSlJW]

想起以前，有个 PM 妹妹，数据报表不对，给前端提 bug ，气笑了。
后来过了一段时间她被裁了，看来老板也不完全瞎。

[user23125]

gitlab 的生产数据库曾经被误删，s3 等备份全部失灵，最后在测试环境找到的备份数据。

[wusheng0]

蜜汁操作，
我是后端的话要骂娘了

[didyoudo]

@Pinealxx408 #11 我们底层开发人员搜索蓝牙时都是用的 MAC 地址

[user23125]

@user23125 细节 https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident/

[darkengine]

@Pinealxx408 其实可以避免，1 按照音响的设备的 service UUID 还是什么 UUID 来过滤（具体忘了是什么 UUID 了，但是可以代表某类设备或者某个品牌的设备）。2 页面加滚动条 。。。

[terrysnake]

@darkengine 避免啥啊，蓝牙列表是系统级的，在手机厂商手上啊😅

[tim9527]

哈哈哈哈哈 一楼说得对。我公司之前有个 00 后小伙也是，出样品给一个台湾大客户，老板拉的关系给人家测试，基本稳成的项目。那小伙就测试了一个，但是正好没测两个是坏的。笑死，测试 3 个其实加起来就 3 分钟，就这都懒得测，项目黄了，小伙纸也被开除了。

[Pinealxx408]

@didyoudo DQA 测试一般是消费者角度来测试，只关注 BT 的名称，DQA 也不清楚是哪一个。

@darkengine DQA 测试时，我们产品已经小批量量产，产品 BT 名称已经固定了，如果是多台同样产品，没办法从名称中分辨是哪个蓝牙。 如#20 所说，BT 链接界面应该是手机厂商处理的问题，不是我们的问题了。

[lightattractbugs]

前几天我还遇到过代码丢失，整了那么久的代码，还是我全权指导，后续我要几个配置信息填表跟我说代码没了，我真的是晕死

[didyoudo]

@Pinealxx408 #22 我的意思是排查问题阶段，首先想到的就是看 MAC 地址在不在

[happyGuo]

数据组真随意啊。数据表说删就删，牛逼

[darkengine]

@Pinealxx408
@terrysnake

那跟我们的产品不一样，我们调用系统搜索 API 拉回列表，筛选出公司的产品再展示给用户选。

[Vitta]

乍一看很炸裂，仔细想想也合理