[quote]原帖由 [i]pyockee[/i] 于 2007-4-30 21:03 发表 [url=http://www.loveunix.com/redirect.php?goto=findpost&pid=657231&ptid=71821][img]http://www.loveunix.com/images/common/back.gif[/img][/url]
深切感受这份压力，......（曾经深夜3点打车去五百里之外，还有一次9点打车去千里之外）。。。 不过如果回家探亲的时候出事的话，跑个1 ... [/quote]


:lu1:


有钱淫哇:lol

那时候，打飞机都要去了，呵呵

好感慨呀~~   当今IT最重要的不再是计算机等这些硬件了，最重要的就是数据。用户可能不舍得多花几万块钱扩内存，但决对舍得花更多的钱来恢复他那比金子还要贵的数据。



我只是个普通的小机工程师，只是偶尔才会接触到带有数据的生产环境。一般来说都是新的系统。不过最讨厌的就是弄带数据的生产环境了。好大的压力，不停的跟用户确认各种事项，哪怕是一个最常见的最基本的最简单的设置~~~！  其待后续。


看的我是胆战心惊呀。。。。。。。。


我碰到过一回，DS4300有一块盘坏了，换完盘，做完同步后发原来的FS无法MOUNT，新建FS一切正常。最后没办法，只得让客户从备份恢复。本来是两个小时的工作，最后搞了整整一夜。还好我让用户把应用停掉后做了两份备份，一份直接FTP到别的机器上，一份是用磁带。两手准备。所以我还没有太紧张。如果只有一份备份的话，只要从备份恢复没有恢复完，我都放心不下来了。直到用户告诉我说数据一点都没少，应用也正常启来了，我都回宾馆好好的睡了一大觉。

我是做DBA的，但感觉和你们一样，一次开发人员提出一个需求，要求在线重建一个主键索引，导致锁表，所有的应用都被堵了，当时就像是油锅里炸开了一样，所有的老大，老总们电话都飞过来了，最后没办法，联系客户暂停应用，停10分钟后恢复应用，那是最惨的一次，之后再也不敢随便乱动了！

[quote]原帖由 [i]老农[/i] 于 2007-5-10 09:52 发表 [url=http://www.loveunix.net/discuz/redirect.php?goto=findpost&pid=658738&ptid=71821][img]http://www.loveunix.net/discuz/images/common/back.gif[/img][/url]
那时候，打飞机都要去了，呵呵 [/quote]


搞笑了哈哈
那几次晚上打车长途，都是老板approval才走的

真得不少钱，还是先去自助银行取得



楼主写完了阿，是不是大家可以补充一些以前经历过的或者听说过的一些惊心动魄XXX小时呢？


我说一个听说过的：
某银行，深夜，准备搞一个大动作，某高手在一个终端屏幕上开了n个窗口，好多机器，但是有的需要停机有的只是看一下

这个老哥（其实真的是个高手，后来了解的），在某窗口#提示符下，说，先把tsm停了吧，刚检查完备份了，然后，halt

这时候一声惨叫，某主机（很不幸，S85，不该停的）halt了

而那个tsm的窗口好好的隐藏在桌面上，，，，，，，，
没办法，窗口太多了，眼花缭乱，深夜精力也不是那么集中。。。。。。。。

这个case提醒大家，再复杂的工作也要按部就班一步步来，不要着急，另外，不要开那么多窗口

[quote]原帖由 [i]banker[/i] 于 2007-5-10 15:53 发表 [url=http://bbs.loveunix.net/redirect.php?goto=findpost&pid=658904&ptid=71821][img]http://bbs.loveunix.net/images/common/back.gif[/img][/url]



搞笑了哈哈
那几次晚上打车长途，都是老板approval才走的

真得不少钱，还是先去自助银行取得



楼主写完了阿，是不是大家可以补充一些以前经历过的或者听说过的一些惊心动魄XXX小时呢？


我 ... [/quote]

我在生产环境上一做破坏性操作时，总要确认再三，敲回车的时候手都会抖，比如umount一个文件系统，删除一个设备什么的，害怕一个不小心，自己就挂掉了:loveliness: :loveliness:

认真学习。安全问题时时牢记心中。

唉，做技术混口饭不容易啊:lu3:
刚参加工作，某次连续加班n个小时之后，在生产环境查询数据，迷迷糊糊把select敲成delete，幸亏语法不同不过也是吓出一声冷汗
至今不管对生产环境做啥动作，基本遵循几个原则：一是备份；二是动作比较大，影响正常业务，绝对晚上做；三是因为基本都是一个人加班，没有复查，绝对将步骤、脚本先写好，能测试的先测试

[quote]原帖由 [i]banker[/i] 于 2007-5-10 15:53 发表 [url=http://www.loveunix.net/discuz/redirect.php?goto=findpost&pid=658904&ptid=71821][img]http://www.loveunix.net/discuz/images/common/back.gif[/img][/url]
这个老哥（其实真的是个高手，后来了解的），在某窗口#提示符下，说，先把tsm停了吧，刚检查完备份了，然后，halt

这时候一声惨叫，某主机（很不幸，S85，不该停的）halt了
[/quote]

所以现在TSM新版把停TSM SERVER的命令改掉了:lol

看了楼主的帖子启发很大，我相信做这行的或多或少都遇到过这类要人命的时候。
小弟也遇到过，有一次半夜给港口的SUN T3存储换电池，因为数据量有点大，用户从来不做备份（我强烈建议甚至“威胁”都没有作用，无奈！遇到这样的用户我也没有办法！），换完电池后发现阵列起不来了，起了两遍都没有起来。
       当时脑子一片空白，用户也脑子空白了，只是一个劲的自言自语：为什么不做备份，为什么不做备份。两眼非常期待并且有点绝望的看着我，估计那时候他把所有希望都寄托在我身上了。
       当时找不到SUN的人求助（因为这台T3只是5X8服务），无奈之下我第三次重起了T3，还好老天还是眷恋我的，T3顺利起来了，没有造成任何影响。
       至今没有确定当时发生这毛病的原因，我也没有机会、也不想有机会再遇到类似的情况了。只知道那一个多小时确实难熬。只能说比楼主稍幸运罢了。
       要真是起不来了，用已经离职的同事一句话：把你和公司整个赔了都不够损失的！

       以后再遇到类似的工作的时候，凡是没有备份，或者准备工作不充分的时候一律不干。不然自己死都不知道怎么死的。

经典的帖子。

我说一个我经历的最惊险的例子：

和几个同事在某业务机上做扩容，但发现微码版本太低，结果使用软盘升级(认为更加安全)微码，结果放入第N张软盘时发现一直过不去，而且前面液晶屏出现没有任何显示的状况。

等待将近一个小时后，我们中的一个忍不住了，直接关电重开。

重新通电后，发现液晶面板的代码一直都在走一个死循环的数字。完了——当时X市的号称X万用户量的X业务数据服务器就down了(虽然有双机，但这个压力也是足够轧死几打人了)。

最后，灵机一动，由于是在第N张软盘时出问题，会不会是软盘的问题呢？——当时的情况实在是不容多考虑了，直接死马当活马医了。重新拿了第1张证明是绝对好的软盘重新做了第N张，放入后——感谢上帝，真的过去了！

回头一想，还真的是惊险无比，回到公司后赶紧第一件事就是——买500张质量最好的软盘！！！

^_^

[quote]原帖由 [i]yuyang0726[/i] 于 2007-5-10 14:08 发表 [url=http://bbs.loveunix.net/redirect.php?goto=findpost&pid=658863&ptid=71821][img]http://bbs.loveunix.net/images/common/back.gif[/img][/url]
IBM的工程师来了，并且带来了2线的方案。大意是将上面的RAID按照原来最初的重新做一遍。（具体操作他们不肯透露）。由IBM的工程师讲解方案，原维护厂商的人操刀。（IBM的工程师反复强调 ... [/quote]
其实道理很简单，就是和当初建的时候一样的重建（位置、大小一点都不能变，如果原来有记录，不难，如果都是用的缺省值，那也一般不会错），这样的事情最好别遇到，但遇到的话可以这样处理，我救过几个类似的。现在讲课我就经常强调这个，并且让学员亲自实验体会。
很多情况下，保证不了按原样建，所以，风险就存在了。IBM强调自己不上手做，就是避免直接责任。

这个事情，技术上怎么解决，不是什么看点，如果有人看这个，只能证明他还没入门。
要看的是处理事情的经验和感受。

[quote]原帖由 [i]banker[/i] 于 2007-5-10 15:53 发表 [url=http://bbs.loveunix.net/redirect.php?goto=findpost&pid=658904&ptid=71821][img]http://bbs.loveunix.net/images/common/back.gif[/img][/url]


某银行，深夜，准备搞一个大动作，某高手在一个终端屏幕上开了n个窗口，好多机器，但是有的需要停机有的只是看一下

这个老哥（其实真的是个高手，后来了解的），在某窗口#提示符下，说，先把tsm停了吧，刚检查完备份了，然后，halt

这时候一声惨叫，某主机（很不幸，S85，不该停的）halt了

而那个tsm的窗口好好的隐藏在桌面上，，，，，，，，
没办法，窗口太多了，眼花缭乱，深夜精力也不是那么集中。。。。。。。。

这个case提醒大家，再复杂的工作也要按部就班一步步来，不要着急，另外，不要开那么多窗口[/quote]
我自己也发生过:L
不过，好在是发生在我计划停机的时间，而且虽然是停错了，也还是停的备机，无所谓。但事后想想，如果不是在计划停机时间，把主机停了那就:funk:

所以我现在做什么操作，习惯都先hostname确认一下了:$

[quote]原帖由 [i]chinaix[/i] 于 2007-5-10 22:07 发表 [url=http://bbs.loveunix.net/redirect.php?goto=findpost&pid=659010&ptid=71821][img]http://bbs.loveunix.net/images/common/back.gif[/img][/url]
和几个同事在某业务机上做扩容，但发现微码版本太低，结果使用软盘升级(认为更加安全)微码，结果放入第N张软盘时发现一直过不去，而且前面液晶屏出现没有任何显示的状况。

等待将近一个小时后，我们中的一个忍不住了，直接关电重开。 [/quote]
用软盘升级微码实际上最不安全，呵呵，这是基本常识了。但是，在硬盘升级微码做不到的时候，可以用软盘。
升级微码的时候关机，那肯定是错误的。

软盘格式化后没错误的，做微码升级盘用，能有50%的软盘能用就算走运了。

“这个老哥（其实真的是个高手，后来了解的），在某窗口#提示符下，说，先把tsm停了吧，刚检查完备份了，然后，halt

这时候一声惨叫，某主机（很不幸，S85，不该停的）halt了”
呵呵，看来不止我一个人犯过这个错。。。;P

我也知道某人的一次误操作经历。那天某人太忙，中午没睡觉，下午昏昏沉沉地shutdown -Fr一台机器，按下回车时发现搞错机器了。在等机器启动的十多分钟里，他做了激烈的思想斗争，到底怎么办呢？最后此人还是决定瞒天过海。机器起来后他立刻做了三件事：
1、把当天下午他login的信息清掉，让last命令只能看到以前的信息；
2、把errpt里最近一次关机和启动的那两条信息清掉；
3、不让 history记录他上面两步敲的真实命令。

总之，没人查出机器在这段时间怎么了，当然有人怀疑机器是reboot了，但没人确信是人为的reboot。不过，事后这人的良心还是被谴责了好几天。

现在，我以一个旁观者的角度来看他的操作，发现还有三处不够完美：
1、忘了去检查有无db2start（其实是他当时不会），结果引起DBA去查db2diag，从中还是可以发现机器被shutdown的蛛丝马迹；
2、忘了处理alog，这个对AIX SA来讲是个大失误；
3、uptime他篡改不了，这个恐怕技术上实现不了（除非他再reboot一次），实际上也正是因为他一直在苦苦思索如何处理uptime，造成他忘了上面说的第2步。

我指“某人”的意思。;P

好，再说故事。

我有个朋友的800上有两个盘老是改不了pvid，用也用不了（1年后用闲云的秘笈弄好了）。当时在800的控制台上到处乱点，希望能找到硬件报错的信息，然后修复它们或者找IBM来弄。点了几下之后，到了adapter的地方，看着那种模式不顺眼，不象6000用的方式，然后看其它选项，有6000的选项，于是把它改了，还确认了。

30秒后，那朋友忽然想起：那800是大机和小机共用的，进入的界面也相同。。。。。。。。。:L

机房的门被重重地推开，大机的同事冲了进来，到处找故障灯;P 。朋友重新进入刚才那界面，发现果然是改错了人家大机的接口，连忙改回来。

中心主管也进来了，那朋友马上点头哈腰陪不是，对着灯火发誓以后再不会犯同样的错。幸亏刚好改动的是开发环境的接口，影响不大，但也吓得满身大汗了。

大汗淋漓篇 看得都吓死
有过这样的经历 :L

有过这样的经历，还在工作岗位上的，恭喜你了

唐僧可是过了99 81难

切记血的教训啊.

教训真多呀
还好我们部门的技术经理是个高手，而且原则性极强，给我们预防针打的比较多，不该做的，不能做的坚决不让做，我们还没出现过什么大纰漏，但愿永远不会出什么大纰漏。

脚踏实地安全第一。

最近心脏一直都不太好。中午，改了参数重起后数据库报错，正是算集中核算期间。下午弄好了，刚想轻松一下，没想到又被吓着了。

好帖子,顶一下.小心为上!:victory: