员工写了个比删库更可怕的 Bug。。

我的做法是执行delete，update前先用select看看会修改到哪些数据

♥ 484 ↩ 28

生产环境和测试环境未隔离，没有双人/交叉/提级复核，暂停服务导致连续性中断，在大公司可能是重大问题了[笑哭][笑哭][笑哭]

♥ 407 ↩ 14

已经习惯了每次要update和delete都是先备份数据了然后再搞

♥ 333 ↩ 14

我觉得有的时候针对于特殊状况进行演习也是非常有必要的，在项目小的时候发生这样的问题并不可怕，如果项目逐渐做大再发生这种事，那损失比现在大的多，依我看开发生这样的事故并不是单独这个员工的错误，而且许许多多的因素叠加而成的，所以整个项目组都应该引以为鉴，也算是个经验教训了

♥ 325 ↩ 7

创业很难，互联网趋于饱和的情况下，创业公司想要活下去势必要杀出一条血路。当老板要能画饼，能忽悠到投资，关键时刻还要杀伐果决。 还没破产的xx天，说出这句话开始，其实就有些丧气了，一个成功的程序员并不一定是一个成功的管理者。写出影响很大的bug还上线了，要么扣绩效奖金，要么有人祭天，一切按照章程来。喝饮料多少有点敷衍了。 人都不傻，这次就过去了，下次呢，下下次呢，处罚轻了你吃亏，处罚重了当事人不平衡。再复盘复盘吧，我也刚毕业在上海打工，也是天天被敲，战战兢兢，写得不规范都会被敲，生怕写个bug人没了。 大家都不容易，创业的话，要多想想，问题的出现往往是有多个隐患造成的。个人的角度，还是蛮希望你成功的，对差不多岁数的我们都是一种激励。我见过天才型人物，可以肯定你不是，所以你的成功对我们这些普通人很重要。

♥ 266 ↩ 9

说个额外的关键点：一定要重视内部上报机制。当出现任何情况都要先进行上报，而不是靠外部或者其他方式（误操作后立刻上报某些时候甚至会快于监控报警的速度）。看视频当中主要提到的是预防机制，但类似上报这种公司内部信息流转机制更加重要。避免员工遇到问题藏着掖着导致更大的影响。

♥ 159 ↩ 3

我在实习，没写删除，就是把很多名称都改了[笑哭]，幸好数据库只有一百多条

♥ 155 ↩ 3

以前在做删除和更新时候，都会加上一个limit 1

♥ 146 ↩ 10

在银行干，我们接触不到生产库，包括上线都是写一个上线手册，把上线必须的东西和手册交给运维，由他上线验证.上线前要做好原环境的全量备份和回滚手册，如果出现意外，直接按照回滚手册执行回滚

♥ 129 ↩ 17

emm我们也干过过类似的操作，说出来给大家笑笑 一次是我，和视频里的老哥同款操作。刚入职的时候修复某个bug修改了mybatis的更新策略，第二天一早客户就反馈更新操作会丢失数据。接到电话我立马警觉，赶紧和主管说我修改了策略。然后就是断网，拿着update日志和数据库备份吧数据库修改回来。（数据库是我为了保险更新前备份的，没想到真用上了[辣眼睛]） 从那以后我们团队新增了条规则：原则上禁止修改配置文件。 我额外多了一个习惯：上线新版本前备份上一个版本的程序和更新前的数据库 另一次是代码库被攻破导致所有服务器和数据库密码全泄露了，然后服务器就被攻击了，有两个数据库还被攻击者拷走了，全部人忙活了一整天。 自此我们团队又新增了一条规则：配置文件中禁止存储服务器密码，密码上线后在服务器上手动修改 给老板报了风险，还申请增加防护和备份资源，防护老板勉强同意了但是备份没同意，退其次在公司整了一台式机用脚本远程登陆服务器定时备份（这也是一颗隐形炸弹，后面出过一次问题所幸没有造成损失）

♥ 125 ↩ 7

我艹, 2019年我也犯过这个没加where错误, 把所有物料ID都设成同一个了, 导致客户工厂停产, 每条产线每小时赔款2万[灵魂出窍]

♥ 121 ↩ 12

实习的时候删过一个库。。虽然是sit环境，但是还是整个人都蒙了

♥ 103 ↩ 9

发现bug的本人来了[脱单doge] y总还奖励了我一杯奶茶🥤

♥ 99 ↩ 1

没加where太熟悉了哈哈哈。前几个月同事操作测试库也忘记加了[doge]

♥ 90 ↩ 13

好家伙刚学MySQL就刷到这个视频[吃瓜]

♥ 58 ↩ 2

up,能不能讲讲你用chatgpt生成代码的思路。

♥ 57 ↩ 12

开发环境和生产环境不隔离开来的后果，

♥ 54 ↩ 1

一、公司员工写了一个严重的bug，导致所有用户权限都变成了管理员，影响恶劣。通过应急处理，员工成功解决了问题，并对其他员工提供了帮助。 00:01 - 公司员工写了一个比删库更严重的bug 00:57 - 用户权限全部变成管理员，公司紧急处理 01:53 - 管理员权限内列被刷成普通用户，停止线上服务 二、在项目中遇到问题时，需要权衡停止服务带来的成本和继续运行服务带来的价值，并介绍了使用云数据库服务和并发编程进行数据恢复的方法。 03:00 - 停止服务，衡量项目价值，防止用户流失 04:09 - 基于更新时间恢复数据，使用save or update方法 05:31 - 采用并发编程方式，多线程同时执行多组更新数据 三、一次网络故障的复盘，包括事故发生、定位问题、数据恢复和上线前的备份等整个过程，同时也发现了系统存在的问题和改进空间。 06:02 - 采用连表查询和备份表比较来定位用户更新 06:51 - 耗时两个小时，通过用户反馈和定位问题解决 08:45 - 通过事故发现系统存在的问题，虽然损失不大，但发现问题的重要性 四、在开发项目中的几个策略，包括严格控制操作权限和做生产环境的隔离，以预防类似事故的发生。 09:02 - 不同阶段团队选择适合自己策略 09:30 - 规则逐渐加入项目中，避免类似事故 10:27 - 大规模项目需提前做好，防止全量更新 五、在保护线上核心数据时需要注意的环境隔离、SOL审批、数据库审计和风险意识等要点，并分享了一个团队的责任和惩罚。 12:01 - 环境隔离，测试、灰度、发布都要标准化 12:55 - 数据库审计，记录和监控访问情况 14:06 - 数据备份，保护线上核心数据 --本内容基于视频内容由模型生成，仅供参考，由@漫天星辰哪一颗 召唤发送

♥ 42

就讨论故障处理方式吧，我感觉2小时太久了，可以直接恢复到故障前的数据，然后再启动服务，再把公告消息写一下，再逐个恢复故障后正常的数据，全都恢复后给那些受影响的用户补偿，这样影响面感觉会小很多，个人观点，勿喷[阴险]

♥ 41 ↩ 2

我也遇到过，当时在通勤，需要修改几条数据，手边没有电脑，就直接使用手机termux的ssh命令连接了，查询的时候加了条件，更新的时候没加条件，当时还诧异呢，怎么执行的这么慢，后来再一查惊出一身冷汗，所幸更新的表是个低频更新的表，近期没有新数据，备份正好可以恢复，就没有数据出现丢失。后续再修改，直接先备份，一定要确保binlog打开，再修改，否则可没有后悔药，所以非select一定要保持高度的注意力，能拒绝尽量拒绝，改删语句执行时，一定先执行一次select，再在原有语句基础上修改。

♥ 37