哎呀，我好想当墙上的苍蝇，偷听甲乙双方的复盘会议。
几天前，科技新闻网站The Register发了一篇来自化名为“Leanne”的读者的IT技术支持趣事。
来，我们看看这事咋这么有意思。
Leanne曾在一家公司的IT部门的大型机环境中当过高级架构师。
这个职位需要她时不时地看看内部聊天群。
同事们会在群里面说说她需要关注的问题和奇奇怪怪的事情。
有一天，一位高级数据库管理员在聊天群里说：“好像有些文件丢了，Leanne能查查大型机吗？”
但是Leanne的大型机控制台界面告诉她，大型机一切正常。
然而没过多久，好几个聊天群都报告出问题。
而且问题都还挺严重的。
"大家都登录不了系统，业务全崩了，SEV-1的故障报修单堆积如山，警报声响个不停，" Leanne说。
但是她看到的控制台屏幕显示，大型机还在正常工作，一切安好。
深入地看一下系统日志，就发现大型机的故障，原来是对大型机的直接访问存储设备（DASD）的请求全都失败了。
Leanne和同事于是找外包维护供应商一起查看情况。
很快问题就找到了：DASD被人故意关掉了。所以，大型机访问不了它唯一的存储源。
是谁干的呢？
大型机供应商的一个实习生承认是他干的。
"我命令输错了，我意识到错了再想输正确的命令时，系统就是不让我输。"实习生说。
Leanne评估了一下，然后确定实习生"完全不知道她在干嘛，更不知道这么做会有什么后果。“
实习生就这么轻轻松松的，在周一早上，也就是一周刚开始忙碌的时候，让一家财富500强公司的大部分业务全停了。
还好，Leanne有权限重新连接DASD。
她立马重连DASD，避免了更大的问题。
"供应商因为让一个没人看着的实习生操作控制台被批评了一番。实习生也听到了她的上司因为给客户搞出麻烦而被责备，" Leanne说。
她对这次事件的评价是"真是好玩，好玩到爆。"
可能，这也是历史上最伟大的复盘会议——甲方花钱让乙方知道他们做了不该做的事情。
这篇文章的评论区居然有106条歪果仁的留言，我们看看有哪些好玩的高赞留言。
你会以为那些供应商肯定会事先警告实习生，除非他们确定自己知道在做什么，否则就别乱动。但其实，更重要的是要先确认一下客户是否真的允许实习生随便动。
说到我自己，我曾经就干过一件傻事，脑子一片空白，就把一个Exchange 2003集群的节点给关了。还好，它应该自动切换到另一个节点，我只好连上ILO重新启动服务器。
我记得当时我们得负责一堆放在客户扫帚间里的小服务器（用专线连的那种），而且这些服务器上有好多需要安装的更新，还得重启好几次（有的自动，有的得手动）。所以我们就决定在银行放假的周末来更新，这样服务器再怎么重启，也不会影响到工作了。
前两台服务器更新得挺顺利的，先连上VNC，然后装上操作系统的更新（自动重启），再装上软件更新（手动重启）。
但到了第三台，手动重启时就出问题了。我点了"开始"，再点"关机"，然后敲了"回车"。哎呀，我居然点了关机，而不是重启啊!!!!
结果我只好开车跑了200英里去按那个电源按钮。
“结果我只好开车跑了200英里去按那个电源按钮。”
...在理想的世界里，我们讨论升级后的事情，会让客户选择配有基板管理控制器的服务器，比如HP的iLO或Dell的DRAC，这样我们就可以远程搞定（几乎）所有的事情啦。
当然啦，这得多给服务器供应商支付一些费用。
同意，这绝对是供应商的过错。你可以说初学者或者实习生应该找人帮忙，而不是直接按下那个大红按钮。但是，如果你给这些新手这么大的权力和能力，但又不给他们足够的支持，那么离出问题就不远了。
可以说，当他们准备好单飞时，他们就不再是实习生了...
关键是要有足够的监督，以便他们在达到这个点时能够正确理解，而不是急于求成
但这一点，当然对于那些只看人头数而不看知识或经验（更不用说能力和胜任力）的钱串子和一般的管理层来说，是一个陌生的概念。
“但这一点，当然对于那些只看人头数而不看知识或经验（更不用说能力和胜任力）的钱串子和一般的管理层来说，是一个陌生的概念。”
所以现在看招聘广告感觉越来越搞笑，什么“初级”职位还要求你有十年的经验和博士学位...
"还好，它应该自动切换到另一个节点"
这意味着......绝不是无意义的事。你正在做的是韧性测试，确保系统按照你想的那样运行。
“你会以为那些供应商肯定会事先警告实习生，除非他们确定自己知道在做什么，否则就别乱动。但其实，更重要的是要先确认一下客户是否真的允许实习生随便动。”
你可能会这么想，但我经历过（并见证过）那种“特别的天才”管理，他们的培训理念就是对新人呼来喝去，让他们自己摸着石头过河，不要问那些“愚蠢”的问题来让大家尴尬。这样肯定会弄得一团糟，这是可以预见的。好吧，对任何人来说都是可以预见的，除了那种特别的管理者。文章读起来就像那样，也可能解释了结果...
“但是她看到的控制台屏幕显示，大型机还在正常工作，一切安好。”
如果主机的唯一存储已经离线了，但是"Leanne的控制台告诉她一切都好"，那就说明她的监控方式有问题。
除非Leanne在邮局上班。
在这种情况下，它会告诉你存储没离线，实际上是被外赫布里底群岛的80多岁的女邮局长拿去用了……
所以这个孩子有权限把存储设为离线，但没有权限把它们重新上线 - 在我看来，这有点傻
但我们不能否认，这个孩子绝对不应该在无人监管的情况下被任其发展...
把某物设为离线的"权限"挺容易获得的。你也可以用螺丝刀来做这个。但是，把它重新上线...那就是另一回事了。
几十年前，我们在给新的数据库管理员介绍数据中心，他登录到生产服务器控制台 - 他还没有拿到他的笔记本电脑 - 然后检查他的权限等。他想登出，但是他没点"登出"，这个蠢货把鼠标移到"关机"上，我们没来得及阻止他。幸好，它是个集群，故障切换工作了，所以用户只是暂时受到了影响。他一直就没走出那个阴影...
几年后，在另一个供应商那里，一位硬件工程师拿着他的工具箱和备件走向数据中心的门，伸手去按门解锁，但因为某种只有他们自己知道的原因，有个傻瓜把紧急电源放在了门附近 - 结果工程师误按了那个。突然，数据中心一片寂静，服务台被5-6个市政府和几个公司的电话淹没，引发了恐慌...
我从没见过紧急电源的情况，但我见过很多火警按钮就在门附近的灯开关旁边。
伸手去开灯...哎呀...
如果他们有Molly Guards，情况就不会这么糟了。
"数据中心一片寂静，服务台被电话淹没"
只要你能足够快地启动电源，诀窍就是告诉他们几分钟内不要接电话，然后告诉他们再检查一下，这里所有的设备都在运行，所以肯定是他们那边的通讯有问题。只要客户们不聚在一起比较记录就行。
“我也在新手阶段干过这种事”
回忆一下80年代中期，我那时候是个在一台多个6509/6502处理器的专用计算机上的高中实习生。
这台机器可是给公司提供了好几十个终端呢。会计，仓库，工资单等等...一应俱全。我就是负责给各种子系统编程BASIC的那个人。
三个月过去，我被扔了个任务，要负责系统备份。这让我有机会进入电脑所在的房间（其实就一个壁橱）。
他们告诉我怎么取出/插入磁带，怎么打包和将数据导到磁带等等。看着系统内部的线包裹面包板，我被迷住了。
机器前面有个写着 "Turbo and Normal" （加速和正常）的开关，红色的那种。
我问了关于turbo开关的事，他们就说 "别碰那个"。也没说为啥。
日复一日，周复一周，我就盯着那个开关。最后....我扳动了它。也许我抑制了我冲动的内心声音两个月吧。
结果呢，啥也没发生。
一切都很好。终端反应灵敏。一切都好。
大约两周后，系统终于挂了。
我把开关切回到正常，想把我的小动作藏起来。但是又过了一天，我们不得不从磁带中恢复。
Arthur Andersen年度审计根本就做不出来。数据被搞乱了，没法恢复。我的赞助人/老板气得要死，嘟囔着类似的话 "即使在正常模式下，这该死的东西也不可靠。起初，他们告诉我们，我们不能使用turbo模式。现在可好，正常模式也不行了"
那时，我才明白了turbo开关的问题。我18岁的自己会告诉他，我应该对此负责吗？绝对不可能。
“你的主机被无知的孩子搞砸了吗？他们有没有……”
我在国防、金融、能源、交通、医疗、食品和一般 IT 领域工作过几十年，每个领域都有一些的“新手让公司停摆”的故事。
银行交易楼因新人插入不兼容的设备而停摆？对的。
服务器房间和商务中心因新人误按大红色按钮，以为是“解锁出口门”而疏散，结果触发了 HALON 火灾系统？对的。"幸运的是"，HALON 发生了故障，新人没死。
【嘿，你知道“HALON（哈龙）消防系统”吗？这就是那种用在传统喷淋头的水可能会损坏敏感设备（比如服务器机房）的地方的灭火系统。
哈龙，就是一种叫做卤化碳的化合物，它们在灭火系统中被广泛使用，因为它们能有效、快速地扑灭火源，还不会留下任何可能损坏电子设备的残留物。
一旦启动，哈龙系统就会释放出一种气体，通过化学反应干扰燃烧过程，达到灭火的效果。
这种系统在封闭的区域内，特别是那些有精密和贵重设备的地方，非常管用。
但是，哈龙由于对环境，尤其是可能破坏臭氧层的负面影响，正在被逐渐淘汰。】
错误运行“从源树构建十六进制文件并将其复制到 EMPROM 程序员”脚本，意外覆盖了整个项目的源代码库，而且没有近期备份？对的。
以错误顺序执行测试台，结果引发了小火灾？对的。
误用全员回复功能，将尴尬（幸好只是尴尬，而不是法律问题）的信息发送给全公司？对的。
虽然细节各不相同，但问题的共同点是，一个未经训练、更重要的是，无人监管的新人被赋予了超出他们当前知识和/或培训的职责/责任/资源。期望他们有和有经验的员工一样的技能和知识。
在许多情况下，这甚至不是行业的标准做法，而是公司自己设定的，通常是深奥的流程。
他们坚信这些流程应该是显而易见和直观的，但实际上却是无人能解的难题。
看到一些灾难性的后果时，我总会想：“好吧，你们期望什么呢？”
在一个案例中，可怜的新人要执行一个脚本，其中包括像“J:驱动器有足够的空间吗？”和“M:驱动器映射正确吗？”这样的警告。
新人怎么可能知道什么是足够的空闲空间，什么是正确的驱动器映射呢？
在另一个案例中，FNG（f*cking new guy, 新手）被告知“在 G:驱动器上运行脚本”。
当他问脚本叫什么名字时，他被告知看到就知道了。
他看到脚本目录里有半打名字非常相似的脚本，选了一个最可能的，结果差点引发了灾难。
最后，结果显示 IT 错误地映射了他的驱动器字母，他的 G:驱动器实际上映射到了一个完全不同的系统。
这个可怜的家伙根本无法访问他需要的脚本，他不知道它叫什么，而当他问时，他不仅得不到任何帮助，还被说成是笨蛋，因为他无法弄清楚。
虽然大多数主管都会责怪新人为何不能无所不知且神奇地知道未记录的公司规定，但也有一些好的例子。
我看到的最好的例子是新人，因为他的行为造成了高达五位数的损失，完全以为会被经理解雇。
然而，经理的老板，副总裁，插话说，“我们为什么要解雇你？你的经理刚刚花了 80,000 美元来培训你！”
这清楚地表明，副总裁理解真正的问题在于经理。是经理提供的指导不足。
“我永远都忘不了的那个失误”
我在搞电机驱动器的时候，一不小心打了个<（小于）符号，但其实我是想打个> "大于"符号，那时候我正在写刹车的程序呢。
测试的时候要把一个“小型”（1kW）电机加速到一定的速度，然后再改变方向。本来应该是刹车停下来，然后再朝另一个方向加速的。
结果因为我那个笔误，方向一改变，它就误以为电机已经停下来了，结果就全力以赴地在另一个方向上加速了。
结果电机跳得老高，所有的场效应管都从控制器里高速弹了出来。
我们都有过这样的时刻，不管是刚入门的小白还是老到的IT达人，都会碰到一些让人措手不及的小插曲。但嘛，这些都是让我们成长的调料，让我们在挑战面前变得更硬核。现在，我特别想听听你们的小故事。在评论区分享你的IT小插曲，让我们一起从大家的经历里学习呗。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
