转一篇blog，关于SQL DBA的感触的“The Loneliness of the On Call DBA”

koyuu

原帖由 JuJu 于 2012-6-21 10:26 发表
在两个fabric 里都activate了, 先activate了一个fabric, 还不知道自己选了错的zonset, 几分钟后又activate了另一个fabric的错的zonset, 然后server 纷纷出事了, 才发现.

这种主要还是操作不规范引起, 如果每次activ ...

看来你们用的是Cisco的 MDS 系列？  现在企业越来越rely on 集中存储了...  唉 SAN  admin 也是亚历山大啊  DBA 一不小心 也就 screw up 1 个DB  SAN admin  一不小心可以是整个SAN阿

JuJu

不是我们, 我们没有这么傻的人.

是我听来的事, 对的他们用的是cisco MDS

另, 心理素质是很重要, 某公司做得挺不错的一个manager, 也是tech出身, 听说她做tech时第一次派出去做项目就把客户的SAN搞down了.

但是人家最后在公司也挺成功的,而且她手下的工程师都觉得她比较通情达理, 估计是她自己也曾经感同身受的缘故.

所以, down就down了, 不要逃跑, 回来任批任骂,继续努力, 假如公司还肯给机会的话. (那个contractor 很不幸是马上被开了)

Ausbear

DBA sucks

月亮

原帖由 JuJu 于 2012-6-21 10:47 发表
也蛮同情他们的, 自己都有不够仔细小心的时候. 想想后果是很可怕.

是啊，人非圣贤孰能无错，只不过是大小问题

飞飞鱼

所以做Contractor一定要买那个损坏物品的保险,不然出了事可不是好玩的,尤其是用ABN自己做的.

koyuu

想起来 LU上看到的一篇帖子 亲历惊心动魄48小时   机房里面干活 马虎不得啊



《亲历惊心动魄48小时！》-要命的数据丢失

引子
以前总在论坛上看见老大们写遇到什DOWN机的事情怎样怎样，多么急迫怎样怎样。但却一直没有感觉，这次真实的经历，让我终于对小型机工程师这一职业有了更深层的认识。。。
起因
某年某月某日某时。我的一个哥们准备将新上的盘阵做RAID，刚做完时钟同步。。。
只见客户方所有的技术人员全部冲进了机房，主管劈头就是一句：你们干什么了？紧接着，不待我们缓过神来，6、7个人就开始疯狂的查找各自负责的部分。“赶快，查找原因！”
在过后的情况调查的时候，我们终于知道，当时的盘阵上面存储着当天35亿的交易记录和10条要人命的信息！并且，由于系统改造，只有头一天的数据。然而，就在那个时刻，盘阵上的所有VG全部不见！。。。
查找原因
6、7个人分别查找各自的原因，数据库配置，光纤交换机，网络，主机上的应用，甚至电源、机柜都一一检查过。没有问题。于是，所有的目光都转向了我们：你们到底做了什么？“只是，只是在还没有使用的盘阵上做了时钟同步，怎么会和生产系统扯上关系？”随即，目光转向了连接KVM和盘阵的HUB。咦？上边还有两根线？这两根是。。。生产系统盘阵上的！而使用的默认IP.....我的天!这些操作是做在那里了啊？为什么没有出现IP冲突？
不管怎么样，事情就是这样了：我们将KVM连在了生产系统的HUB上，对新盘阵4800和老盘阵4300同时做了一个DEMO并进行了时钟同步，于是，所有的VG掉下去了，生产停止了。
支援
这个时候，2个小时过去了，所有的人开始打电话，寻求技术支持。在此后的4个小时中，分别有来自各方的支持陆续赶到，其中包括原设备维护厂商，新设备厂商、总代。以及7位IBM的工程师（陆续）。我们在感叹客户和经理的巨大能力的同时，也只能靠边站了，能出的不是手和嘴，而是眼睛和耳朵了。我的哥们至少20次的向各路神仙说明情况。但事情仍然陷入僵局。。。
方案
各路神仙陆续到来，使得除了我的哥们不停的说明情况之外，还有客户方不停的展示目前出现的状况，我们是被打入冷宫的，被安排在一个办公室里不能出来，更别说进机房。只是还好被允许接我们找来人和打800报修。所以有机会看了一眼，除了ROOTVG以外全都没了，就好像连在一个新盘柜上一样，我当时那个汗啊！
打800，提示音以后是长时间的废话，我一遍一遍的报上姓名地址，说明情况，无论你磨破嘴皮，只有一个结果：除了产品硬件故障不能派人解决。我狂晕！
先来的是我们找的代理商小机和存储方面的技术，分别来的3个人同一个看法，这些操作按理不会出现这样的状况，但是除了重起义下看看情况以外好像别无办法。
后来的总代技术明显要略胜一筹，从了解实情经过的方式和建议都是更加的谨慎，看得出来经验丰富。（另外，他在打电话给他的公司的时候加上意味深长的一句：记住这个教训吧）。但是结论仍然是：没有什么办法。
与此同时，公司通过其它渠道联系上派遣IBM工程师。
于是，大家苦等IBM工程师。
IBM工程师
在此之前总有耳闻，说现在的IBM工程师水平一般般。于是，在心理并没有对他们又多大的期待。心想用户就是迷信，干脆重起得了。事后4个小时，在所有人都看完以后IBM工程师到。先是2位，再来又是2位，然后是3位。分别来自不同的TEAM。有负责不同系统的，由负责小机的，由负责存储的，还有售前的。但是他们在一起却能很好的协商和达成一致，没有人口出狂言或者轻举妄动，最后，7个人没有给出任何的动作的建议，唯一的举措就是将现场情况抓图，整理，上传给2线。并说，希望有人在线，希望能有解决的办法。然后，走了。
紧急方案
与此同时，客户召开紧急会议，讨论后给我们也开了个会：冻结原存储4300，连夜在新的存储4800上RAID，建VG，将所有应用和数据转移，先让系统跑起来，数据再说。于是，电话和短信里就有了：“今晚通宵加班，我不回去了。“
节外生枝
这时回到那两台为了做它们而闯祸的4800面前，它们却吓得再不敢抬眼看我们，死活就是不合我们的manager连。。。。气得我是·##￥%……—*（——也没办法。
小插曲
说个小插曲：在阵列down的时候，我发了个帖子：http://bbs.loveunix.net/viewthre ... &extra=page%3D1
紧急求助！

小型机盘阵起不来，麻烦在线的兄弟想想原因。时间紧迫，不多写。
之后就被赶出来了。帖子确实写得很烂，因为我也不知道当时发生了什么，当然我也没想这样说能得到什么，只是抱有一线希望。但是。。。现在我能够理解那些和我写出同样烂的帖子的人当时的情况和心态了，希望他们能够得到他们想要的东西。。。
下一篇《绝处逢生》
绝处逢生
这时候所有人都傻了，客户算是有水平了，没有在这个时候追究责任。而是让我们去处理问题，如果这个问题都没处理好。那，那。。。。。
压力。
压力。。
压力啊，压力！
这个时候，我们的客户经理突然对我说：“你跑一趟，和XXX联系，这是电话，拉一台4300回来，再带6块300G的硬盘，就对他说是X总叫你来取的。”
我那个乐啊！赶紧屁颠屁颠的就打车过去了（那时都半夜了）。联系到人，也顾不得新洗的白衣服了，和司机、库管一起把机器到车上。车刚出门，经理的短信：硬盘拿了么？车还没到门口呢，老远就看见我们经理在等着了。。。。所有的人，期待。。
但是，拉来的4300却没有接上。。。。。我们要面对什么？。。。。。
下篇《又出节外》
其实我也不是很懂，可能有些地方说的不对，当时的现场比较混乱，我只注意那台CR4亮着，或许他用的是笔记本？事后也没敢问。不好意思，菜鸟，写错了大家原谅啊！

又出节外
在场的人七手八脚的把这台救命稻草4300（又是4300）抬上楼。打开箱子一瞅，乐了。原来打算用6块300G做临时空间有点紧张，只能做RAID5，不能做hotspare，没想到上面整整齐齐的插着7块146G的硬盘，嘿，这下够了！
再插上6块300G,经理在这个时候不忘打趣：“慢点慢点，这可是咱们的最后一棵救命稻草，有了它就活，没它我就得从这上面跳下去了。嘿嘿。。”我们在19楼。上好架，通上电，开始练。第一个分区100G,ok!第二个分区，400G,咦？怎么出错了？再来一遍，第一个分区100G,ok!第二个分区，400G，还是不行！这时候，一直镇定的，老练的，不懂技术的经理一直直盯盯的瞅着屏幕，憋不住了问一句：“这是怎么回事？”操刀的哥们没有回答，让我把某一块盘拔出来，等一下再插上。。。。故障依旧；关掉再开盘柜。。。。故障依旧。。。。。。经理看不下去了，但是毕竟好涵养，压了压焦虑的心情，拉我到外面抽烟去了。烟雾中。。。给我讲了上次误操作将一所大学的学籍档案全部删除的事情。。。。。最后，掐灭了烟头：“走，回去看看！”
起死回生
回到机房，RAID已经做好了。问了问，原来是这样：这4300上原来的几块盘是做过RAID的，但是缺少了一块。于是盘阵总是认为后来插上的是原来的那块盘，但实际又不是，而且还不是一块，所以就出错了。将所有的盘都拔出去，再将盘阵重起，清除里面的信息，再关闭，把盘都插回去，就一切OK了。
哦，这样啊，心算是放肚子里了。
再接着就是普通的划区后的工作，忙到了天亮。
这边暂时的问题解决了，但是原来的阵列还躺在那里，里面的数据仍然没有拿出来，所有人的希望也就寄托在IBM的二线上，希望他们能够拿出最佳的解决方案来。

皆大欢喜
早上9：00。
IBM的工程师来了，并且带来了2线的方案。大意是将上面的RAID按照原来最初的重新做一遍。（具体操作他们不肯透露）。由IBM的工程师讲解方案，原维护厂商的人操刀。（IBM的工程师反复强调他们不会上手操作）
整个过程紧张阿，连插拔光纤的动作都做得极为谨慎。不过最后总算是把数据全部找回来了。当时那个兴奋啊。要是有蛋糕都能开个PARTY!然后是一些后续的工作，又忙了大半天才结束。
走出客户的大厦才意识到已经2天没有看到这轮太阳了。原来它是这样的美好！
尾声
昨天上午将借来的那台4300还了回去，仍然记得那天打车去取这台机器的紧张劲儿。心中不免还是有点那么担心：如果给的方案不好用呢？如果这台备机不好使呢？如果在后面长时间、高负荷、紧张的情况下操作失误呢？如果再有其他设备的损坏？如果。。。。不敢想象了。
如果，这件事能给所有的同行一点帮助，我就会很欣慰了。
跋
头一次写文章，不知道那里是重点。可能有些地方没有写明白，可能叙述的简单或者繁琐，不明了或者太罗嗦，希望大家见谅。
这件事对我的触动和影响很大，以致我现在每每想起还有余悸。但是当时，我却愿意往好的地方去想。或许，所有人这样的想法是这件事情得到了圆满地解决吧。
最后，谢谢大家的关注！

Fernando

听说过最牛比的恢复故事，HP的一个低端存储挂了，HP工程师到现场狂打电话，很多人搞了几天也恢复不了，美国那边的support似乎也没搞定。不过那时候中国HP里面牛人还是真牛，有一哥们用C还是什么写了个程序把磁盘上的数据读出来了。

chinara

原帖由 bulaohu 于 2012-6-20 17:17 发表


update without WHERE...end of world ;)

遇到过，不过不是我。

chinara

原帖由 JuJu 于 2012-6-20 22:28 发表


你这个不算太可怕,

几件最近的事, 悉尼某大公司招的 SAN contractor 把一个错的zoneset activate了, 结果联到SAN的那些重要系统全部down, 我估计那个人一发现自己干了啥, 心脏都停跳几下的了.

另外是一个 ...

作production 系统的任何相关工作，都要有过硬的心理素质。

superblue

前不久刚出的问题，不过不是存储，是网络，两台防火墙同步有问题，TAC上来二话不说，先把active config清除了。。。晕，老印工程师说木事木事，还有standby,然后开始同步，我靠，就看此人很潇洒把Active的配置给同步到standby了，可是active的配置已经清除了啊。。。。

然后就是几个小时的恢复，测试，再恢复，再测试。。。。都不容易啊，很理解存储行业的xdjm...

zzgirl

话说，我们公司一个月前近乎所有系统全部down掉，不知道是不是和某个DBA有关。最后，用了1天DR，又2天把数据弄回来......归根结底的原因至今没有公布，不知道砍了几个人.....要么就是硬件猝死，皆大欢喜？

北风

应该是data center的问题，数据库没了一般不会这么久的

原帖由 zzgirl 于 21/6/2012 20:12 发表
话说，我们公司一个月前近乎所有系统全部down掉，不知道是不是和某个DBA有关。最后，用了1天DR，又2天把数据弄回来......归根结底的原因至今没有公布，不知道砍了几个人.....要么就是硬件猝死，皆大欢喜？

zzgirl

outlook也没了，确实比单纯数据库崩溃严重些。

Fernando

多数是SAN连锅端了

JuJu

这行业保持好的口碑太重要了, 目前outsource 风潮中, 一边听很多人抱怨这行业suck到处裁员, 一边看一些人赚得钵满盆满, 很多项目只求顺顺利利表出这种事, 对于口碑好的人才出价都是非常大方爽快.

住在我们的区的一个前EDS 的executive, 本来已经退休业余卖房地产几年了(没有合适的位置), 现在也又出山找到好位置了.

sqfo

原帖由 bulaohu 于 2012-6-20 17:17 发表


update without WHERE...end of world ;)

best practice is replacing update with select in the initial run
fei DBA liu...

[ 本帖最后由 sqfo 于 2012-6-22 13:26 编辑 ]

大饼

原帖由 sqfo 于 2012-6-22 13:13 发表


best practice is replacing update with select in the initial run
fei DBA liu...

我每次都是先select, then replace select with update

roo81

原帖由 JuJu 于 2012-6-20 22:28 发表


你这个不算太可怕,

几件最近的事, 悉尼某大公司招的 SAN contractor 把一个错的zoneset activate了, 结果联到SAN的那些重要系统全部down, 我估计那个人一发现自己干了啥, 心脏都停跳几下的了.

另外是一个 ...

如此重要的工作，难道没有人再把道关？

JuJu

这个很难把关的, 除非再派一个人跟着每步检查, 多少地方能有这么奢侈的资源. 而且出这些事也都不是新手了.

control management 怎么做好是个学问, 越是大的地方往往越是control management看上去不错, 其实该review的倒不review, 不关紧要的东西倒是一堆外行在挑毛病.

飞飞鱼

这就是do thing right和do right thing的问题了。

Change Control是流程控制的管理手段，没法预防技术上的失误。

每一个签下来的support单，SLA都会有允许意外outage的额度，就是用来cover这些的。

JuJu

预防还是有能预防一些的.

步骤每步都写下来, 由别的有经验的人review再严格按照步骤运行.

比如, erase data 的, 想必步骤里除了检查rack 所在房间和X Y 位置, 还起码应该有检查array serial number这一步吧?

如果是具体做的人又不严格按步骤执行, 那是真的很难预防, 所以我说除非再派一个人跟着检查才行了.

飞飞鱼

这个看你怎么定义了,我不把失误作为Risk,也就没有对应的Mitigation.这个更多的不是针对性的措施,而是直接从避免SPOF(Single Point of Failure)上来做,但即使是SPOF也招架不住神一样的队友的.

我工作中碰到最搞笑的例子是一个刚入职的筒子在大白天毫无原因的把生产机重启了,本来大家还大张旗鼓要分析下是什么高级Root Cause,结果是他在编辑一个文档的时候拷贝了重启指令,而且连回车也拷贝进去了,好死不死他还开了个Putty Session,而且还是root,而且他还无意中按了右键粘贴.

你要分析起来,
如果他没有没事开生产机Session,而且一直在Root的坏习惯;
如果他拷贝指令没有连回车一起拷贝的坏习惯;
如果写文档的人有在指令前放注释#,在指令后放Sleep 5的好习惯;
如果他有谨慎的在Putty中定义特殊粘贴的习惯;
如果原来的管理员有设定root session定时time out;
如果原来的架构师有努力的争取生产机双机备份的budget;
如果有一天,世界已改变,当沧海已变成桑田..........

所以老人家常说做什么事情做人最重要就是这个道理.有一些系统工程师,你只要稍微接触下就明白出事是早晚的事情,只是什么时候出的问题.技术很重要,但技术可以学;做事的习惯和思路改起来就辛苦的多.

扯的多一些,这里面也有对于Contractor和Permy两个不同用工类型的管理思路问题;单纯从技术管理者的角度,我个人是倾向于Contracor做中小的OT Change;大的的Change要交给年长一些的Permy做.

通常而言,Contractor技术更好,新,肯干ermy垂垂老矣,赫赫.但往往因为Permy技术上弱一些,会谨慎很多,而且知道很多History,Background,说的更庸俗一些,出了问题Permy更知道怎样在规则范围内保护自己,保护部门的利益.

JuJu

出事是早晚的事情, 这种人还真不少.

北风

其实是个人都会犯错的，再仔细的人都难免，尤其是在压力之下
写好步骤是最基本也是最有效的方法
我以前做release，前N次，都是按写好的步骤的。但是久而久之就觉得可以抛开步骤了。果真就错过了一个步骤，导致release失败了。还好是staging的

无视

原帖由 北风 于 2012-6-26 10:38 发表
其实是个人都会犯错的，再仔细的人都难免，尤其是在压力之下
写好步骤是最基本也是最有效的方法
我以前做release，前N次，都是按写好的步骤的。但是久而久之就觉得可以抛开步骤了。果真就错过了一个步骤，导致release失败了。还好是staging的

automated release是解决方案，出了问题再人工干预。

helloall

足迹高手真多啊。

zzgirl

原帖由 北风 于 2012-6-21 20:40 发表
应该是data center的问题，数据库没了一般不会这么久的

承你吉言，上周六，我们公司的data center因为power off又当掉了。这次的根本原因是火警。CIO也纳闷了，那么完善的供电系统被疑似火警给搞定嘹！

大饼

我们单位n月前出了大漏子。数据中心丢失了所有电脑的mac，导致统统拿不到IP不能上网。好几干台电脑啊。居然还没有备份，需要每个用户自己打电话去告知maC。caLL center被打暴。好在实验室电脑mac有另外的备份，不然不知道会有什么结果

[ 本帖最后由 大饼 于 2012-6-26 22:32 编辑 ]

bulaohu

dhcp server自己没有db？这个比较奇怪...

大饼

原帖由 bulaohu 于 2012-6-26 22:31 发表
dhcp server自己没有db？这个比较奇怪...

这个我也没想通啊,虽然我现在都不是做IT的了.
后来也没有什么跟进消息,没听说有谁被炒,被K什么的.
半ZF部门,你懂的.