| |
|
|
| 首页 淘股吧 股票涨跌实时统计 涨停板选股 股票入门 股票书籍 股票问答 分时图选股 跌停板选股 K线图选股 成交量选股 [平安银行] |
| 股市论谈 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 商业财经 科技知识 汽车百科 工程技术 自然科学 家居生活 设计艺术 财经视频 游戏-- |
| 天天财汇 -> 科技知识 -> 自己亲手引发运维事故是一种什么样的体验？ -> 正文阅读 |
|
|
[科技知识]自己亲手引发运维事故是一种什么样的体验？ |
| [收藏本文] 【下载本文】 |
|
自己亲手引发运维事故是一种什么样的体验？ 关注问题?写回答 [img_log] 运维 Linux 开发 Linux 运维 自己亲手引发运维事故是一种什么样的体验？ |
|
有一次看见个服务器，里面有个定时apt update/upgrade脚本，但apt误写成了atp，所以这脚本从未被成功执行 我非常“好心”的帮他更正，并手动执行了一次，然后可能因为太久没更新，更新崩了 项目组的人下来查看，我急中生智，若无其事的指着卡住了的apt说，“我就说闲着没事乱更新，看看，这不更新坏了” 那个大哥出了一头汗，盯着apt左看右看，说“不应该啊，这一年每天更新都正常啊，怎么今天坏了” 趁他疑惑，我赶紧跑了 |
|
这是我刚入行时引发的一起事故。 某互联网公司，有一个实时计费系统。 有一天我闲着没事干，到前台泡妞。 前台小姑娘和我说，计费系统的时间不准，慢了刚好1年。 我问他之前是不是也这样，她说是的，一直都比实际慢1年。 我估计是系统上线的时候，实施工程师把年度时间改错了。但是用了这么长时间都没有问题，说明并不影响计费系统的正常运行。 但是前台小姑娘可是个大美女，既然她提出来了，我想，怎么也得露两手，谁叫我是“专业”的运维工程师呢。 我不经思考就直接对她说：“这简单，把linux系统时间改一下就可以了。” 然后，在计费系统里熟练地输入了更正时间的代码，毫不犹豫地按下了回车。 前台小姑娘一脸微笑，但是突然，她脸色凝重了起来，指着计费屏问我：“怎么在线用户都不见了？” 我一看，也觉得奇怪，正常在线用户都有1000多人呢，现在怎么只有几十人了？ 我纳闷了好长一会，然后接到了客服部的电话，客服部急迫地问我：“是不是有什么故障？投诉台有上百个电话同时打进来，说是断网了” 我顿时脸色大变，眼睛瞪得老大了，意识到出大事了！ 监控室几乎也是同一时间，也打电话过来了，问我是不是出了什么故障了，他们监控到有大范围用户断线的异常告警。 我吓得腿都软了，站都站不稳，脑子一片空白，冷汗从额头处瞬间冒了出来。 正当我不知所措的时候，已经惊动到了直属领导涛哥，因为后台监控系统一旦有告警，告警短信就会第一时间自动发到相关维护人员的手机上。 涛哥打电话问我怎么回事，我实话实说了，是边哭边说的。 涛哥也是很有领导魅力，当下叫我先保住现场，稳住用户，他和运维组的工程师们马上赶过来。 10多分钟后，涛哥和运维组的工程师及DBA火速抵达了现场。 故障的原因是时间变快了1年导致的，所以在1年内过期的账号全部被踢下线了，而且无法重新登录。 当时DBA写了个语句查询之后发现，这些账号多达3千多个。 将时间再改回去也行不通，系统时间就会颠倒错乱，数据就全乱套了，后果更严重。 涛哥果断做了决定，直接修改数据库，将这3千多个账号的到期时间，全部改到年底。 DBA赶紧写了相关语句，同时对相关的数据表进行了备份。 语句准备执行的时候，DBA手都抖了，涉及到的账号不是一两个，而是几千个，影响范围太大了，万一有啥差错，就吃不了兜着走。 语句执行的时间很长，我们的心都在颤抖，好在顺利执行了。 之后，我们赶紧抽查一部分账号，发现这些账号已经能正常登录了，然后赶紧通知客服部的工作人员，叫用户重新登录，借口是网络波动导致的。 从故障发生到恢复，用了40多分钟。 但是，计费金额和财务账上的已经对不上号了，后续财务部算了一下，出现了40多万元的空缺。 正常情况下，故障时间超过10分钟就会被定性为事故，总部将这次事故定性为1级：严重事故，人为。 这件事结束后，我被调离了工作岗位，公司对我进行了长达3个月的重新考核，职称从T2降级到了T3，年终奖和绩效全没了... ... 我的直属领导涛哥，因管理不善，被记大过处分... ... |
|
曾经给公司的一个客户维护数据库，要删除一个掉测试用户。 输入完 delete from users ,顺手快捷键执行了。。。 最坑爹的是数据库是游戏组的老哥搭建的，用的phpstudy搞的，没有开启binlog， 数据库的几十万用户，客户花了几百万推广费。那一瞬间，就感觉背后汗水流下来了。 结果因为有外键，没删掉！！ 真是吓死爹了。。。 |
|
这个不说太详细，毕竟不能匿名了，反正三大运营商之一，上4G那年，后台需要每个4G基站都要输入单板编码，比较长有18位，需要手动填写，还要填基站单板IP，有大概60多个需要填写，太麻烦了，然后呢我看到输入界面上面有导入导出（我3G网管配置数据用的都是EXCEL导入），然后我骚操作来了，打开DHCP管理，导出全省的DHCP，然后看一下填写格式，然后新建了一个excel模板表头复制进去，把我需要填写的编码填进去，然后导入，导入前我也不知道怎么想的，就鬼使神差的备份了下全省的DHCP。 导入后我TMD才发现，全省将近上千个4G基站的DHCP没了，就剩我导入的了，网管4G大量出现掉站告警，我靠，我瞬间血压就上来了，脑子真就嗡的一下，全身汗毛直立，然后我反应过来，我瞬间又给导入了进去，大概10分钟左右吧，告警就慢慢恢复了，告警恢复过程中我真的度秒如年啊，当时要是谁给我打电话我能吓死，当时还是有点违规操作，在家使用VPN操作的。我担惊受怕的过了一个月就知道没事了。 没被发现下因为当时4G才开始，是试用期，没多少用户，基站夜里开通本来就会有告警，运营商不太关注这个，又是凌晨新的网管经常系统升级，所以我躲过一劫。 给不太懂的人解释下这个事情有多大，就这么说吧在那10分多钟内全省用户手机不能4G上网，还好当时没那么多4g用户，还是凌晨，以当时的4G发展，这事但凡出晚几个月，大家都可以在新闻上看到我了。 我当时填写我得数据的时候我想了下我第一次弄别导入错了，留个备份吧，我要是直接原表改，那就完蛋了，全省4G全部掉完，得涉及几个小时，我就这一个念头差点闻名全国啊。 我还有一次删除数据差点把全市的3G基站数据删除，他提示我确定要删除吗？我瞬间精神了，我那个否字，我整整确认了有30多秒，他连个可以点掉的X都没！！ 我现在已经不干了，但是这份工作应该是大家眼中的神仙工作，我刚毕业，进入公司的时候干了半年，刚好赶上公司接下来新运营商的活，觉得我刚毕业学习能力强，就给我扔过去参加内部培训，成了项目经理，因为没多少活，所以一个人也没给我派，就我一个人，我自己管理自己，每年5月份才上班，因为运营商签合同采购生产等设备到货基本就5月份了，然后工程队白天安装，我晚上做数据，10月份安装完我也就没事了，偶尔配合处理个故障诊断，他们会提前一天通知你，所以我天天中午12点起来，晚上有事就挂个VPN边做数据边游戏，那时候工资也高，公积金一个月都1-2千，但是那时候我刚毕业才20多岁，天天睡觉玩游戏，家里人觉得我不上进，所以跟家里人整天吵架，后来一气之下辞了，进了运营商公司，现在天天苦逼的上班 |
|
学网络的小伙伴，老师都应该告诫过你们没事别打debug all吧。 嗯 我打了，导致一台核心交换机歇了，全公司断网。 当时刚毕业头铁，全组的前辈们对我只有牛逼两个字的评价。 最后把线拔了换了冷备的交换机，等debug完了又切回去的。 |
|
2021年9月29号，我接到研发的请求，要给他们部门专用的服务器安装一个软件。 我立马用root apt install安装好了，但是我安装过程中看的有一些不认识的包怎么装上去了，装完后发现好像也没有哪里不对劲，系统能正常运行，遂交付给研发。 过了一会研发找到我说不对啊，怎么有些安装包没有了，然后我又继续安装不见的包，然后修修补补，终于把他们缺的东西补齐。 然后再试，还是不行 继续检查，研发说glibc版本不对！得赶紧解决，这个是和客户环境一致的，我们国庆的时候release！ 然后我就找办法降级glibc，找到晚上也没有办法，我领导也加入一起找解决方案。 我们把Google百度翻了个底朝天，也没看到有解决方案，一直到凌晨五点，两个人实在顶不住了，然后去睡觉。我睡的也不踏实，早上八点就起床了。 按照原计划，我在9月29号下班就开车回家，然后30号在家办公的，结果全被打乱了。 第二天继续上班后，我和领导商量要不给他们重装吧，领导去和他们商量回来，说有一些商也软件特别不好搞，不能重装，当初花了好长时间才把这套环境搭起来的！（搭建这套环境的前领导跳槽了） 然后我继续找解决方案！ 找啊找，找啊找，我搭了各种环境做测试了，就是不能把glibc给降级。 然后毫无意外的，研发的release不能在我们的环境上搞了，还好他们还有外部环境能用，不然我不知道怎么办！ 就这样胆战心惊的过了个国庆，国庆我也一直在查文档，当时还跟我妈说，我可能要被辞退了。。。 国庆回来后，我继续收拾这个烂摊子，然后研发捅到我大领导（vp）那里，为了这个事，专门开会几次，并制定了一系列针对他们部门的问题处理流程，以及当前问题该如何解决，然后得出结论，他们部门以后所有的安装软件需求，必须经过大领导审批，我们才可以动手，并且全力恢复这台服务器的环境，好吧，这个事我继续干。 当时9月份我们一个同事合同到期，因为表现原因，没有续签合同，只剩下我和领导两个人，压力特别大。 屋漏偏逢连夜雨，当时我们内网又被外部攻击，我领导全力处理那边的事，我一个人一边想办法解决该部门的烂摊子，一边处理其他部门提过来的case，忙的不可开交。 弄了一个多月后，我决定放弃，重新搭建一套环境给他们，遂向领导汇报并征得同意，用了两三天时间就把那套环境搞好了，并没有他们说的那么麻烦。 那段时间因为人员少，我领导动不动就是加班到八九点，我六点多七点这样下班（外企嘛），感觉特别对不起他，人少的情况下还给他添乱。 当时我还想着年终奖可能要变少了，结果还超出了我的预期！！！ 当时我真的是胆战心惊，干运维这么久，第一次搞出这么大的事，差点影响到他们的release。后面我领导说到：人总是会出错的，出错不怕，就怕重复出错。跟了这样的领导真好！ 去年我拿到字节的offer，和他提出离职，他特别震惊，说到：我们去年这么难都挺过来了，现在舒服了，为什么要走呢？是有什么不满意吗？然后我和他说了我的诉求，他很积极的和vp沟通，后面在他们的努力下，我又留了下来！ |
|
某个版本升级。因为服务器硬盘满了。所以顺手备份代码后格式化了下。 然后就知道了。某个版本前，有前前前任老哥竟然直接把客户上传文件放服务器上而不是文件存储服务器上。。。。。 于是公司大概400多家超过8年的老客户的附件没了。。。。。。。 是完全找不回的那种。。。。。。。 |
|
生产环境的支付全靠两个数据库，两个数据库来源网络是全开放的。 我没带脑子，给加了个白名单，于是全国范围线上线下所有的支付全部失败。 老板大晚上打电话过来骂了我十几分钟，说赔了几十万。 |
|
哈哈哈，我正儿八经的引起过一次运维事故。 那是在我刚上班不久，那时基站还用的是很老式的西门子设备，嗡嗡的那种，那时还没有专用的开关电源柜，线路保护啥的都摆设。 我有次去基站跳纤，一不小心把一个设备的电源线给整短路了，一路火花带闪电，唰的一下整个机房就安静了，所有在闪的灯全灭了，我整个人就斯巴达了，哆嗦了30秒给老大打电话“我好像把基站电源烧了” 老大什么也没说，半小时之后开车过来，把空开推了上去，机房又亮了。 幸好那时候没有退服啊之类的考核。。。。。不然实习期就要提桶跑路了。 |
|
引发过一次事故，但不是运维事故，算是医疗事故吧。 18年前后，公司做医用超低温冷冻冰箱，-86度，用来存储细菌培养、病毒样本、实验样本等等，前面有块显示屏，显示样本和冰箱的一些数据，但为了省电或者其他一些原因，2分钟左右会息屏。 其中还单独的有一个小喇叭，冰箱温度出现回升或者在某个值以上的时候会响，提醒工作人员查看情况。 我就负责装这个显示屏单元，上面有屏、固定支架、指纹模组、USB接口、喇叭等等，因为失误，一批模组(大概70多块)全部没有装喇叭。 大概3个月以后吧，突然接到一起客户投诉，说你们这个冰箱有缺陷，温度回升不报警，若不是工作人员例行检查，整箱的样本全部报废了。接着我们售后部门到客户现场开始分析，很简单就查到原因：没有喇叭！ 然后，当时组装那批模组，全部排查，已经出货的联系客户由售后上门处理，没出货的工厂内返修，我记得发出去的好像十几台吧。 再然后，处理我，虽不至于补偿公司损失，但那个月工资是没有了，当季度的补贴也没了，还给寄了个大过。 后来售后的那个负责人找到我，私下跟我说，幸好客户有例行检查，不然温度再回升，里面存放的病毒样本有了活性造成泄露，那可就是大事件了，估计我得被抓进去。 现在回想，太可怕了。 |
|
15年的时候，在一个做页游运营的公司，因为刚起步，有时候业务空窗期，官网上什么内容也没有，我就没有及时续费服务器。当时用的阿里云，就是欠费7天之内不会被清空，所以好几次我都是赶着最后的时间点再续费，想着给公司省点钱。直到有一次。。。我忘了，第八天的时候收到阿里云的短信通知我服务器被释放，我当时整个人都石化了。 |
|
干掉了生产库的200多个用户算不算？ 这事有20年了，某个值班的夜晚，搭建了一个测试Oracle库，用sql*net别名连进去，清理了一些用户。 但，高潮来了：居然有几个用户无法删除，说是用户在线。一开始没反应过来，还kill掉了几个用户继续删。后来才明白，我居然连上去的是生产库！！！一查，不知道是哪个挨千刀的，把测试库所在的服务器上的sql*net别名指向了生产库（向上帝安拉真主佛祖发四，圆明园不是我烧的）。 接下来就是大脑一片空白。冷静下来，将昨晚的备份库直接恢复到备用环境，然后比对两个库，把误删除的用户列出来，做了一堆create user脚本，在生产库给恢复了。 因为不知道这些用户的口令，cerate user时给的都是默认口令。导致的结果是，第二天上班以后，一群人打电话过来说无法登录。我只能告诉他们，肯定是你们自己改了口令，用默认口令登录后改密码就行了。这居然也能把他们蒙过去了。 那会还对oracle不熟悉，后来才知道，可以从测试库把加密的口令抓出来，create user时可以直接创建加密口令，根本不需要忽悠大家。 对了，那会的oracle还是7.3版本，不支持FlashBack。 |
|
非运维，开发人员。 之前呆的一家公司，七八年前，当时领导让我研究个东西，非常着急要用，我查了查官方文档，就拿测试服务器搭了后台服务，然后找了套开源的代码，改了改，算是实现了。告诉领导，现在后台服务是在测试服务器上搭的，转正式还得小半天(那个后台服务搭建贼费劲，依赖一大堆，现在倒是好了，官方出了docker版)，领导说没事，先用着，反正也就是给大老板看看，不一定真的用。 后来，大家把这事都给忘了，隔了好几个月，我做另一个项目，想搭个东西，发现测试服务器的硬盘快满了，于是就把某些目录直接rm -rf了。 第二天，大老板直接炸毛了，一路追责下来，领导让我做数据恢复，硬着头皮靠着谷歌找到个数据恢复的工具，但因为是免费的，再加上，我删完后装了一些其他的东西，肯定存在数据覆写的情况，所以只找回了不到一半的文件。 最后就是我领导跟运维去扯皮了，领导认为运维没定期做快照，运维认为这是测试服务器，没必要做快照。 |
|
算是间接吧（反正我是不会认的…… 给客户做的操作员培训手册和PPT是我写的，直接用了实际生产系统的地址； 然后队友拿着这俩文件去给客户的新员工做培训，直接进了客户的生产环境一顿演示…… 老板后来跟我说，如果当时不是队友在现场，我在另一个地方出差，他在公司两个都逮不着，他能用键盘把我们俩一起拍成伯邑考…… |
|
2020年10月的某一天，手欠在防火墙上把baidu和sougo的爬虫给ban了，把中关村论坛断网了三个钟 |
|
不是我，机房巡检登记资产。硬盘没标签，把两块盘拔出来看型号。 |
|
不是我干的，但是是我参与处理的，写出来给你们乐呵乐呵。 出事的地方是一个地板布线的数据中心。大概像这样。 |
|
|
上面那个白色的方块很结实，因为要承重呀，所以分量十足。 需要布线的时候用一个这样的东西把它吸起来。 |
|
|
结果有位哥们没拿稳，这块地板块就掉到下层去了，好巧不巧下面正好有根光纤，然后就一刀两断了 ━Σ(?Д?|||)━ 后面的事也不用我说了，你们脑补一下吧…… |
|
给我推这个什么意思啊。。此时此刻我正要在生产环境上给Gitlab添加mattermost组件。 我马上就要reconfigure了，这太不吉利了。 |
|
我来说一个亲身经历的吧. 赛门铁克有款杀毒软件, 想必很多人都知道. 它的企业版其实是带一个中央控制管理程序的, 也就是可以向单位网络里面的所有客户端分发病毒库和一些控制策略之类的. 然后有一次, 我看到它的应用控制策略里面有一个USB设备管控策略. 联想到前不久领导说的要控制员工使用U盘拷贝数据. 然后就把这个给选上了......它是一个通用策略 大概5分钟之内, 电话被打爆了. ...... 后来, 我就知道了笔记本的触摸板不属于USB设备. |
|
曾经重启过承载一个非洲小国家所有3G网络的传输设备。。 特别小的国家，在索马里旁边。当时好像是有一块板卡状态异常，怎么搞都不能识别，我就灵机一动，整框重启了，还好重启完板卡就正常工作了。 说是整个国家的3G网络，其实也就几十个基站，而且因为其它问题，本身也在不定期重启。所以重启完了我连个报告都没打，就这么过去了。。后来我也发现了问题的根源，重配了一些东西（不属于我负责的网元），基站就不怎么重启了:-) 当时作为项目唯一的中国人，还是有一定智商优势的哈哈 |
|
某宇宙大厂，所有员工的WiFi认证依赖于IT部的AD服务器，刚入职没几天，把这台AD服务器整挂了，全公司几w员工半天上不了网 |
|
两块屏幕，左边是内部环境的ssh窗口，右边是生产环境ssh，Alt+Tab从生产切换到内部，执行 rm -rf ./c*，清理数据，结果焦点不知道为什么没有切换，把生产环境两个目录删除了，正好是用户上传数据的目录和对应应用的目录。 瞬间从头凉到脚，人都麻了，认真回想，开始从异地备份里拉回来昨天的备份还原，加上今天的一些增量备份，还有一部分是存oss上的不用管。 嗯。。还是丢失了差不多小半天的数据，还好已经接近下班时间，客户也下班了。 然后想怎么写公告，顺便和领导说了一声。 然后开始起草公告 尊敬的用户您好，应安全规范要求，系统的文件扫描等级提高了，导致了今天的部分文件被误杀了等等，大概内容差不多，当时是写的挺多的，核心思路就是这样，其他有点忘记了。 通知一发，回家。 不过也快凌晨了，恢复代码重新发布，然后单单拉备份就拉了很久。 有惊无险，这事后面就这样平静的过去了，也没人提起。。 后面生产环境的rm就被我替换成了一个脚本，只能移动一个trash目录。 也后悔一开始就应该把跑业务的用户改成nologin，平时登录应该要其他的普通账号来查看，这样也没有权限删除，只能看，没想到登录上跑业务的用户，居然真的误操作了。 |
|
//这么多同行，关注一波，后面交流呀～ 记得刚入行不久的时候，有个乐极生悲的体验。 离周五下班还有几分钟，程序提了一个需求：升级mysql lib库（备注可以下周搞） 本着要下班的心情倍好，告诉产品里面就处理，出现了这个： 0 upgraded, 0 newly installed, 2 to remove and 217 not upgraded. 按照计算1+1等于多少的逻辑，可以说毫不畏惧的敲了一个"y" 就在敲入“y”之后，卡了3s窗口信息没更新，我看到了什么： mysql-server remove！！！！ “ctrl+c，ctrl+c，ctrl+c，ctrl+c，ctrl+c” 得嘞，自建mysql数据库被干掉了！！！！ 不是多少个“ctrl+c”能阻止得了.... 好了，准点下班是不用想了，后面的程序大哥也是盯着大眼看着我。 “莫急，我有异地备份”，我给自己缓解了一点点尴尬。 那天，我加班了，还挺晚的，还送了一套“误删数据故障复盘”。 |
|
你能想到在一个省城某运营商早上出现三四十万用户无法上网。断了两三个小时吗，投诉量剧增，直接到了省二把手。可喜得是那天早上上班，投诉量没有剧增到恐怖的程度，不然的到集团公司背书了。可能就和这行绝缘了 |
|
数据库是O，找了个DBA给搞了DATA GUARD，项目稳定跑了4年多，以至于老人只剩下一个不懂技术的运维大哥。 有一段时间服务器频繁的中毒，后来查到变矿机了。甲方爸爸不高兴啊：我花钱买的服务器让他们赚钱。 大哥找了个挖矿的哥们给处理，哥们三两下的把DOG币的配置给改了，然后跟大哥说好了。大哥不知道咋想的，大手一挥，直接上大招：重启！ O主服务器经过十几分钟的漫长等待后，应用系统不再提示数据库连接已断开的语音播报。甲方爸爸的脸上流露出满意的微笑。 过了一段时间，大佬要跑路，找了个新人来接班。毕竟是干了六七年的大哥，认真负责，把所有的服务器检查一遍，手把手的教新人。当检查O的备用机，发现CPU一直在50个点，这不正常啊。大哥又找挖矿哥们，哥们忙活了半小时，然后跟大哥说好了。大哥不知道咋想的，大手又一挥：重启！ 又过了十几分钟，备用服务器起来了，数据库也能访问。然而，数据不同步了！！！主服务器cud之后备服务器数据不变了，把我一个码畜喊过来。扔给我一个文档，就是那个DATA GUARD配置文档。我能说一点看不懂吗？十几页的命令、截图、说明，各种看不懂的名词、模式。。。 后来再找原来配置的DBA，人家已经跑路了。大哥就是大哥，打了两天电话找了一个专稿数据库的老妹帮忙。老妹也得工作啊，人家也得上班啊。只能下班帮忙给倒腾倒腾，咱也陪着看看。 整整三个晚上，我陪着大哥和新人看老妹远程调试到半夜。 第四天，老妹上班时间好像神灵附体，也没准3天的活水到渠成，还不到半个小时，通了。 我刷着PLSQL看着备用库的数据一直在更新，开心的像个200斤的孩子，好像许久不能解决的bug突然来了灵感一样，却忘了这跟我没一毛钱关系。 大佬得到我确定的答复之后，对新人说：以后没事不要重启。 对甲方爸爸说：要走了不放心，熬了一周夜把服务器都检查了一遍，还找专门的人给看了看，没问题。 我脑瓜子：？？？？？？ 从此学了个新招式。 |
|
小公司 门店的一个会员app 某天有个工单是客户充值未到账 让我看看。 我一看库里确实多了一条充值失败的记录，于是我想起服务器有个crontable的定时任务是专门处理这个的 于是就跑了一遍。 过了有一周门店管理的那边发现账不对头，核对发现这个月多了12w充值金额。 我和主管核查的过程中发现了多余的充值记录是我跑脚本那个点多出来的 顿时冷汗就出来了。问了一下 主管说 他几个月前就把那个定时任务关闭了，之前门店没充上的直接操作补充。woc ！最后缺口有4w，已经被客户花掉了 |
|
记得刚毕业半年的时候，在某银行做外包，在一个复杂业务编码中，其中一个查询功能在处理结束时忘记写关闭数据库连接的代码了。结果上线后，你懂的，没多久就数据库连接池连接数满了，很多业务点击时等侍数据库连接，也就是页面一直卡住，还好发现及时，排查发现是我写的某个查询菜单占用大量连接数，然后把连接强制kill，把菜单暂时禁用了，等下个版本更新修复。这次幸好升级后发现及时虽然没有造成损失，但事后感觉自己特别对不住自家公司也对不住甲方，痛定思痛，我之后编码异常严谨生怕再误事。 大概一年后，自己成长起来后又遇到类似的事，这次是某个业务经常走到一半就断了，而断的地方很随机，这遗留问题时间不短了，项目技术经理、两个开发组长都亲自上线排查过，头大都放弃了，我们小组组长新上任的，主动接过了这个别人避之不及的活，他自己折腾了几周了放弃的，然后仍给了我....我心里千百只草泥马在奔腾。也是自己一遭被蛇咬十年怕进绳的原因，出于对数据库连接异常关闭的敏感，我从每天40G的系统日志中find、grep、sed等硬是定位到了问题点，是一个小朋友的代码处理完业务逻辑后，关闭了别人的数据库连接，你没看错，这家伙不关自己的连接，它去关别人的、关别人的、关别人的！！！确认无误后，我把详细情况反馈给组长并给出了修改方案，我们组长兴冲冲去给项目技术经理汇报，说他加班几个星期客服各种困难终于定位到问题原因。我....又是心里千百只草泥马在奔腾。工作一年多，这类事情也见怪不怪了。总之，找出这个问题，心里上多多少少弥补了些自己前面初入职场那次错的感觉。 不写码七八年了，因为喜欢code，还是挺怀念刚毕业那7年的写码生涯，每写完一个功能都能体验到一种创造的成就感，每写完一个难度超大的业务模块都感觉自己改变了一个小小“世界”（哈哈）。现在再也不会有参加大型项目的机会了，最多也就是写点简单的小功能方便自己摸鱼，比如统计完每天数据后程序模拟登录上传日报（同事一直以为我每天手动报）、写个程序统计整理每月工单、每天自己打卡等等。写码少了，技术更新迭代日新月异，感觉自己越来越跟不上时代了。 |
|
先介绍一下我们设备的结构 计算单元A和计算单元B互为主备（均无硬盘，直接把存储单元当自己的硬盘），存储单元A和存储单元B互为主备。计算单元A和计算单元B都可以访问这两个存储单元，访问存储单元必须通过计算单元。 某次故障，存储单元A出现问题，我在计算单元A上操作，格式化存储A，失败；于是脑子一抽去计算单元B上操作，下的指令还是格式化存储A，结果顺利完成。当时就头皮发麻，觉得不对劲……直到我看到屏幕上的fatal字样，瞬间冷汗就下来了（10月份，操作间还有空调）。 经过检查发现，在计算单元A上查看，存储单元A故障，存储单元B无数据；但是在计算单元B上查看，是存储单元B故障，存储单元A无数据。说到这大家都知道为什么了，我不死心，去设备前现场检查，铁一般的事实告诉我，就是计算单元B到存储单元的两根线插反了，我在计算单元B上下的格式化存储A的指令被送到了存储B。现在两块存储，一块损坏，一块无数据…… 这是一套服务100万用户的设备，关系民生的，早上6点前不恢复就会造成重大事件。马上联系leader（实际上在看见fatal的时候就已经通知leader了）。leader去负责去联系后台支持，我在现场考虑数据恢复。 我们有专门用来备份数据的备份服务器，实时备份，这100万用户的任何数据改动都会实时传送到备份服务器里。理论上备份服务器上的数据是可以直接拿来用的。但好巧不巧，出于另外一个原因，备份服务器上的数据失效了…… 除了热备之外，还有每天一次（还是每周一次我忘了，离开那个项目很久了）的冷备份，每天手动将数据备份到移动介质中。当然这个备份是通过脚本自动执行的。由于系统过于稳定，备份从未启用过，也就没人发现实际上这个自动备份的脚本是有BUG的，只备份了索引，真正的数据其实没备进去…… 于是天塌了。 现在的情况是设备上的数据丢失，热备份失效，冷备份失效……理论上除了拆硬盘做数据恢复之外都无解了。但拆硬盘恢复数据会带来业务中断，我的职业生涯估计到头了……（就算格式化这个锅可以赖给线接错了，但冷热备份均失效这个锅是背定了的） 一筹莫展的时候，leader带来两个好消息。1是国内的第一大拿说如果现在业务正常的话，就考虑不再操作，硬抗过白天。有希望把内存中的数据重新写成硬盘文件。2是这位大拿一早就飞过来，明晚亲自上手。 意思就是说，在格式化掉硬盘的情况下，设备无盘继续运行一天，然后夜间通过内存里的数据重建硬盘文件。 后面事就是一早我踏上了回家的火车，在大拿施展本领的时候，我在家乡完成了我的求婚（这个确实有点狗，按理说现场工程师此时必须在现场。感谢项目经理）。 结果就是求婚成功，大拿也顺利的恢复了数据。我们修改了备份脚本，处理了备份服务器的问题。然后排查了全部设备的线缆。我一直到今天还在继续干着这个职业。 |
|
这个哥们干过～～～当时清理了几个vmware虚拟机，去系统文件看发现没删除就文件管理内强删，然后发现删不掉就重启了再然后就是公司ERP服务器打不开了……对，因为ERP服务器改过命名，我误以为那是测试机的给删了！公司新上线一年的ERP数据连同服务器没了！！ |
|
唔，最近搞出了个大新闻，算是一半的原因在我吧。虽然最后什么事情也没出。 之前写论文投论文，然后让运维的老哥把公司的一套系统copy了一个备份，作为demo给评审看看，同时也给这个demo搞了个默认的账户和密码。 某一天，CTO看我的论文，看到这个密码的时候，很激动的问我为什么有这个密码。 我说这是运维给我的啊。 CTO：这是公司系统的超级用户的密码~~~我还以为只有少数几个人知道这个密码，结果全世界都知道了是吧。而且，超级用户的用户名就是admin。。。。 然后CTO打电话把运维喷了十分钟。 幸好，这么久的时间过去了，没人去登录公司的系统，更没人去试试密码。否则就真成了鬼故事了。 |
|
弄丢了8百多万条数据，感觉天都快塌了，结果后来领导怕我想不开，就轻描淡写的说了一下要下次注意，所有的道歉和反省总结报告啥的都是他去弄了。 我们有个写用户数据的batch，当天夜里挂了，我看日志上大概写的是 insert data 1，000，000 done 因为本身对这个处理不熟悉，加上大半夜被闹醒的有点头晕，就没多做调查，天真的以为它已经跑完了，所以就没去管它直接点了确认就完了。 后来导致其他地方出事找原因找到这里才知道，这个处理是1百万条1百万条的进行处理，正常的日志是这个insert…done的记录要重复9遍，一直到最后一条记录显示的不是整1百万才算全部处理完毕。 太坑人了。。。 |
|
那在遥远的三十年前，路过一家西北的兵站住了一天。临走时等车闲得无聊溜达进了他们的后勤/财务办公室，坐在电脑前的大兄弟对着中了毒的DOS屏幕一筹莫展，以为我是上级机关来视察工作的，向我求助。我好心帮他格式化了硬盘，还没来及装DOS，车来了，我拂袖而去。 |
|
一天下午，在给线上一个小表加个字段，发现老是加不上去，一直卡死。运维同学突然跑过来跟我说，线上数据库这半个小时一直在重启，问我是否有做什么操作。我当时虎躯一震，总共100多行的小表加个字段都加出问题了？我立马停止尝试加字段，果然数据库恢复正常了。后面查到原因，也顺利加上字段，现在来复盘总结一下。 先讲下原因，表数据量虽然小，却是一个热点表，访问频率特别高，而且该表的访问是在一个大事务中。加字段的时候一直在等待获取MDL写锁。这个等待也影响了后续表访问对MDL读锁的获取，导致后面的查询也都被堵塞了。更惨的是，客户端有重试机制，查询堵塞超过超时时间会再起一个session进行请求，导致数据库的线程池很快就爆满了，直接挂掉。 什么是MDL锁 MDL锁属于表级别的元数据锁。表级别锁分为数据锁和元数据锁，通常我们说的加锁一般指的是加的数据锁。跟数据锁一样，元数据锁也分读锁和读写锁。 MDL不需要显示使用，在进行表操作时会自动加上。当对表进行增删改查时，会自动加上MDL读锁；当要对表进行加减字段的结构修改时，会自动加上MDL写锁。 读锁不互斥，意味着可以多个线程同时对一张表进行增删改查的操作。 写锁独占，进行结构修改前，要先等待其他所有的MDL锁释放了才能获取到MDL写锁。获取到写锁后，在写锁释放前，其他线程无法获取到MDL读锁和写锁。也就是说，修改一个表的结构过程中，会阻塞其他线程对表的操作。 MDL锁的必要性 MDL锁的存在，其实是为了保证数据的一致性。想象一下，假如没有MDL锁，一个查询在遍历表数据的过程中，另外一个线程执行了ALTER TABLE t DELETE COLUMN 'col_1'把col_1这一列删掉了，那查询结果就乱了，结果中是否应该有这一列数据？ 事故复现 介绍完MDL锁，我们再来复现下事故。我们通过下面的操作序列来模拟线上情况。 |
|
|
时刻1，事务1对表t_mdl_test进行查询，注意此时事务1并未提交，所以获取的MDL读锁也不会释放。时刻2另外一个线程想要添加字段c, 由于事务1正持着MDL读锁，所以事务2会陷入阻塞，等待事务1释放读锁后获取MDL写锁。 申请 MDL 锁的操作会形成一个队列，队列中写锁获取优先级高于读锁。 所以事务2不仅阻塞了加字段的操作，也会阻塞后续对该表的所有操作。比如后面的事务3和事务4查询由于获取不到MDL读锁都被阻塞了。 这时，如果客户端有重试机制，查询超时后会重新进行请求，容易把数据库的连接池给挤爆了。 ? 表t_mdl_test建表： CREATE TABLE `t_mdl_test` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增id', `a` varchar(64) NOT NULL, `b` varchar(64) NOT NULL, PRIMARY KEY (`id`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8; 读者可关注公众号【会玩code】在获取的写库huiwan_write_x中自行实验。 ?解决办法 了解了原因，事情就比较好处理了，数据库奔溃原因是由于加字段等待时间太长导致影响后续请求，但mysql又无法在 alter table 语句里面设定等待时间. 所以当时做法是继续尝试加字段语句，语句卡住30秒就手动cancel掉。避免对后续请求的影响。重试了几次发现一直没能加上。。。，最后是通过查看接口调用监控，在请求频率较低的时间点给加上了。 反思避免写大事务，如果不是查询所在的事务太大，也不会导致后面语句获取不到MDL写锁。事务中，尽量减少加锁时间。还是这次这个例子，从t_mdl_test中获取的数据在事务最后一步更新其他表的时候才会用到，所以可以把t_mdl_test的查询放在事务的尾部。减少t_mdl_test加锁时间。对表结构修改的语句注意执行时间，长时间卡住需要注意先取消掉，避免影响其他线程对表的增删改查操作。 |
脚本里有如下的命令：看上去似乎没什么问题。 有一天其它的同事改脚本时疏忽了，让TMP_DIR变量没有赋值，然后这条命令就变成了 rm -rf /data 。 正好/data是我们服务器上一个重要的数据目录。 从那以后，我们所有脚本都强制要求在开头加上下面这行代码： 评论里提到rm的问题，rm固然是一个风险较高的命令，不过这个例子里rm不是重点。如果允许未定义变量展开，就算不是rm而是别的命令，也照样会有不符合预期甚至危险的结果。 |
|
这个我得匿名答，某个银行的项目。服务器是他们的esxi私有云。数据库是oracle，第一次出问题是数据盘只有20g，没多久就满了，一个字节都写不进去。数据库都崩溃了，而且不是lvm没法动态扩容。后来挂载了一个新的盘，把原来盘的文件内容考过去。再把原来盘umount,新盘挂载上去，算是勉强解决，没损失数据。 没多久说要升级数据库，从11g升到19c，给了个服务器做测试，装好后当备库用。拿到服务器一看数据盘还是20G，想起之前的事，就和项目经理商量扩容。查看了一下系统，发现还有个盘，就问项目经理是否可用，他说能看到应该就能用。然后就挂载上安装数据库，期间一切正常。一周左右升级完成，还原数据，项目跑起都没问题，备库暂时转为生产库，主库升级后再切换回来。运行三天左右突然说数据库崩了，项目无法启动了。发现硬盘出问题了，当时还能访问把两个很大的数据文件考出。然后总行老师开始排查，发现我挂载的那个盘是共享盘，就是其他服务器也在用。数据没法恢复，又没有每日备份。我手里的数据文件就是最后的希望，我们公司开始找高手。大神叫刘相兵，了解情况后告诉我直接用他提供软件把数据从文件中抽离出来，给报了个价，公司可以接受。软件确实牛b，数据还原了98%左右。还差些数据格式啥的问题，后续研发们处理了一下。 造成的后果就是项目停了两天左右，没有数据损失。虽然不是大功能，但也算小事故，公司认为是我挂载硬盘造成的，罚了点钱。 没多久就离职了，五千的运维天天干dba的活儿，我这能力实在不够。以后尽量少碰oracle，没那金刚钻不揽瓷器活儿。 |
|
|
| [收藏本文] 【下载本文】 |
| 上一篇文章 下一篇文章 查看所有文章 |
|
|
|
| 股票涨跌实时统计 涨停板选股 分时图选股 跌停板选股 K线图选股 成交量选股 均线选股 趋势线选股 筹码理论 波浪理论 缠论 MACD指标 KDJ指标 BOLL指标 RSI指标 炒股基础知识 炒股故事 |
| 网站联系: qq:121756557 email:121756557@qq.com 天天财汇 |