七个故事帮你回避业务领域陷阱

标签:CIOCIO职场

访客:22470  发表于:2012-05-14 10:18:40

人无完人,我们都曾经犯下过错。不过如果大家选择了IT行业,过错就不再仅仅是一个人的事——它会迅速传遍整个企业。

这绝不是危言耸听:我就知道有个家伙在一封邮件中发泄了他对另一个混蛋的满腔怒火,文章言辞犀利、掷地有声——遗憾的是,他的无心之失让这封邮件进入2500多位客户的收件箱;而另一位倒霉蛋则刚刚坠入情网,思念的折磨令他写出如泣如诉的动人诗篇,发送时却忘了更改收件对象——这使他成为全公司各部门间的笑柄。

你可能会无意中删除了某台服务器中的全部内容,而接下来的事态却令你头皮发紧:其中保存的是政府机构近三个月以来的重要信息,且我们手头根本没有可靠的备份能够用于恢复——事情大条了!你也可能觉得今天天气不错、挺风和日丽的,于是乎随便拔根网线吓吓技术人员;结果企业与成千上万客户网络接入瞬间毁在你的手上,此所谓自作孽不可活。有时候为了向同事解释问题,我们可能随手把日志内容设为共享;而在某种情况下,我们可能会出于检测或者其它什么需要而拔掉了服务器网线。但IT无小事,这种小动作很可能给你招来大麻烦。

一旦错误已成定局,我们必须依靠自己的丰富经验对这些问题做出合理的解释——这也算是种不成功便成仁的冒险,毕竟死扛下来的话别说年底奖金,连工作岗位都可能保不住。

在本文中,我将与大家共同分享七件真实发生过的IT糗事,当然相关人士的真实姓名都做了改动,这也算是种保护措施。各位别笑,总有一天运气不好的就可能是你,看看这帮“狡猾”的前辈们是如何在逆境中将自己拯救出来的吧。

科技陷阱回避大法第一招:不关我的事,都是邮件系统的错!

这是一类几乎会让每个人大叫“妈呀”的经典状况——撰写邮件、点击发送,紧接着发现自己把邮件发给了错误的收件对象。

Joel Postman就赶上了这么一回,他现在在一家知名网络公司担任高级通讯执行官。当时是1999年,他还在Sun Microsystems公司供职。这天,他鬼使神差地陷入对女朋友的无穷思念,冲动的诗意与灵感促使他挥笔写下一封温馨与浪漫完美契合的邮件。身为市场开发部门的一员,他下意识地对默认收件人发出了发送指令——于是乎,几位与Sun公司结合战略伙伴关系的企业副总裁在第一时间感受到了Joel的浪漫主义情怀。

“当时我随手按下了鼠标左键,根本就没注意到电子邮件的收件人列表有啥问题,”他坦言。“很快就有邮件回复过来,其中一位说:‘我们也爱你,Joel;不过这么热情的服务我们有点承受不住啊,咱还是谈谈业务吧。’相信大多数人跟我一样,在这类问题上只会糊涂一次。”

不过有时候这类坏事也会起到一些积极作用。就拿Fetchnotes的联合创始人Alex Schiff和Chase Lee来说吧,这两位高人的一次失误在某种意义上甚至改变了企业的命运(Fetchnotes是一款基于云平台的记事本,主要用于记录非结构化信息类的零散内容)。

去年一月份,他们正准备向公众正式介绍这家新成立的云服务公司。不过在正式亮相前,Lee决定最后向他的伙伴发送一封电子邮件,以确保格式及服务全部合乎要求。反正是内部测试,所以他想都没想,写下“做个测试吧,二逼青年”,接着就点击了发送。

遗憾的是Lee的这封邮件不仅仅发给了Schiff;当时Fetchnotes内测版本的全部2500位用户也都成为邮件的接收人。当意识到问题的严重性时,Schiff回忆称他开始冲着电脑屏幕吼叫起来。

“我还以为自己的这次失误会彻底葬送公司的前途,”他告诉我们。“因为在五分钟内我们就收到了一百多封回复,如果不出意外,用户们一定相当愤怒。然而出乎意料的是,99%的回复都对我们表示感谢,因为这封不那么文雅的邮件给他们平凡的一天带来了些许色彩。我还记得有位用户回信说,他们注册了Fetchnotes账户后很快就忘记了这回事,而我们的邮件唤醒了他的记忆。令我欣慰的是,他表示对我们的服务很感兴趣。”

Schiff决定立刻向全体用户发送一封道歉信。今年,他在博客中详细回顾了当时的情况:道歉信获得了两万多次点击,并收到大量回复。在一周之内,Fetchnotes就赢得了五百多位新用户的青睐,而且网站上的活跃用户也较之前增加了两倍多。

只有两位用户因为受不了邮件中的冒犯口气而注销了自己的账户,他补充道。

“当然,我永远也不会因为这件事就认为咒骂用户是一种聪明的营销手段,”他解释道。“不过像我们这样的新兴企业,选择以更贴心的方式与用户交流显然值得借鉴。既然没有什么品牌号召力,不妨就以亲民作为主要卖点;以客户好兄弟、人民好儿子的角度出现何尝不可呢?毕竟大家都喜欢能和自己打成一片的合作伙伴。”

科技陷阱回避大法第二招: 一时糊涂,误删数据

除了邮件带来的麻烦,另一种经典状况大家也绝对不会陌生,这就是误删数据。

大约五年前,目前担任某金融服务技术公司产品经理的Paul Unterberg还处于年少懵懂的时期;由于一位朋友有志于从事电子音乐,对技术颇有自信的他主动请战,负责论坛这块的工作。他这位朋友技术水平有限,因此造成了MySQL备份配置失误,并最终导致论坛使用的存储空间严重不足。当时Unterberg的正式是工作是微软SQL Server数据库管理员,但他认为自己对MySQL的熟悉程度足以完成这项小任务。

“MySQL备份机制的修复工作非常轻松,不过数据库备份内容里保存着一个体积庞大的文件夹,其中还包含多个子文件夹,”他回忆道。“说实在的,我也学过Unix,不过基本上都还给老师了。不过我很清楚自己打算删除整个文件夹,因此我查了一下RM指令列表。”

浏览了一下之后,Unterberg感觉这活没啥难度,因此他自信地向朋友的服务器终端输入了如下命令:rm -rf /

接下来的状况令人瞠目结舌:服务器上的每个文件都被以递归方式删除掉了。

“好消息是硬盘空间的问题彻底解决了,”他边开玩笑边说。“不过这肯定是我见过的最愚蠢的技术决定。”

幸运的是,论坛的网络托管服务端还保存着一套最新备份。Unterberg说,他又花了三个小时才把论坛恢复到原样,而这段时间中他无奈挂出了“数据库维护中”的提示信息。

有一点我们是可以肯定的,那就是Unterberg对于他的朋友以及这个论坛绝没有任何恶意——他在接下来的四年中一直坚持负责论坛的维护工作。各位从中学到了什么吗?

“千万别在根目录下轻易运行那些我们不熟悉的指令,”他总结称。“如果真的有些不得不尝试的操作,务必在动手之前反复读几遍说明文档,务必。”

科技陷阱回避大法第三招: 为自己的行为付出代价吧,搞安全的小子

并非所有错误都是当事者有意为之。而且老话说得好,磨刀不误砍柴工。

Fitpacking/Fatpacking公司是一家专门通过组织户外探险帮助客户减肥的企业,而公司创始人Steve Silberberg也曾有过一段不堪回首的经历。那是上世纪九十年代中期,Siberberg在一家仅有四十多名员工的软件开发公司中担任程序员一职。他还清楚地记得,当时公司里管安全的家伙好像有点偏执,他对于一些与他预期不符的使用及工作习惯都极度不满,而这种激烈的态度也闹得其他员工胆战心惊。

听起来也没什么大不了?Silberberg告诉我们,这位系统管理员其实根本就没为安全事务做出过任何实质性努力,他所做的只是大呼小叫和让事情变得更棘手而已。

“当时每位员工都可以在办公空间里任意走动、访问别人的账户、进入没上锁的机房并通过任何终端设备获得root访问权限,”他告诉我们。“总之,一切该干的他都没干。对他来说,这份工作的惟一内容就是在其他员工有需要时先插上一脚,等他弄明白整个过程后再予以放行。”

为了表示抗议,Silberberg决定把他的用户名和密码通过邮件发送给办公室中的每位同事。

那位管理员发现情况后,立即锁定了Silberberg的账户,并通知他尽快更改密码。接下来就是无尽的安全会议,Silberberg和他的同事们不得不一遍又一遍复习安全知识。不过他打趣般地告诉我们,在之后的十年中他一直就没理会过这些规章,而这家公司也始终没挑出什么毛病来。

“当时办公室里的同事们分裂成了两派,”他解释称。“大部分同事站在我这一边,告诉我其实他们也早就想这么做了。我想他们一定是发现了我当时心情正无比沮丧。如果我们连业务中必要的资源都无法直接访问,那么份内的工作也实在很难做好;尤其是在这样一家小公司,及时迅速地做出反应更是促进业务的必要条件之一。”

尽管始终坚持自己的立场,但Silberberg坦言他现在已经不会再通过这种方式处理问题了。“现在,如果我们在公共论坛上公开自己的密码,这简直像在个人电脑上使用Unix系统一样可怕。”

科技陷阱回避大法第四招: 断开连接咱们穷开心!

还有一些错误完全是由于年轻气盛造成的,既不属于意外之失、也不算是无声的反抗。在这个故事中,当事者不希望我们透露他的真实姓名,那就姑且称他为Jason Bourne吧。

九十年代中期,Bourne供职于一家国家级互联网服务供应商。他的工作是维持一大堆调制解调器的正常运行,这样服务运营商的客户们才能正常访问互联网。这些设备被安装在数个巨大的机架中,整套设施还拥有一个独立的机房,他就在这个宽敞明亮的环境中为连接业务提供技术支持。机房还配备有一个巨大的观察窗,透过玻璃我们能够看到室内闪动的调制解调器绿色指示灯。

“每一个小灯代表一位正处于连接状态的客户,”他解释道。“企业高管常常陪同VIP客户到这里视察,窗子里无数闪烁着的指示灯比任何文件和数据都更能打动外行管理者们的心。”

为了打发百无聊赖的时光,技术支持团队中的各位成员开始挑动彼此,希望搞点动静出来,Bourne回忆称。而这位如今已经成为网络新兴企业IT总监的成功人士,当初就参与过这类恶作剧。

“所有调制解调器都经过同一套控制台彼此连接并接受管理,因此我们可以从控制台发出指令,同时控制所有设备,”他告诉我们。“当时我们发明了一种新玩法,就是通过一条指令让所有调制解调器瞬间同时断开连接。”

断开之后,技术支持团队的小伙子们就兴奋地看着机架上的绿灯一个个熄灭(从左上角到右下角依次熄灭)——他们知道,这一下子就让整个城域网中的约一万名客户掉线了。

随着调制解调器重新拨号,客户们的网络指示灯再次慢慢亮起、变绿,这时大家都会捧腹大笑。Bourne说,他们甚至还在猜测客户们当时会是什么表情。

“在上世纪九十年代,互联网连接的不稳定根本可以说人尽皆知,因此偶尔出现的闪断完全属于正常现象,我们也不会因此惹上什么麻烦,”他补充道。“而且我猜几乎没人会想到,某个时段中的频繁掉线是出自一帮青年技术人员的娱乐活动。”

科技陷阱回避大法第五招: Borland公司遭遇“拔插头”事件

在刚刚迈入新世纪的头几年,Chris Barbin正担任Borland公司的高级副总裁,当时他的主要任务是帮助企业将刚刚收购起来的软件测试公司整合到IT部门当中。

“我对公司的大Boss说,咱们的数据中心简直是一堆乱麻,”他回忆道。“而头儿的回答是,‘只懂抱怨解决不了问题,你去把事情搞定吧。’就这样,我成了CIO。”

刚刚升任CIO,Barbin就对Borland公司的现有IT资产进行了系统调查。他发现,该公司在八个主要数据中心里共购置了约1100台服务器——这几乎比公司的员工还要多。更糟糕的是,有200台的用途不明,也就是说没人知道这些设备放在那是干什么用的。

Barbin通知数据中心维护人员拔掉这些设备的插头。他心里做过一番盘算,如果某些重要的服务项目停止工作,该公司的客户服务台应该很快就会得到消息。

“如果大家手头也有这么200台服务器,而且没人知道它们在搞什么,那么各位肯定也会认为它们运行的不是什么关键性业务系统,”他解释称。“所以大家就在谈笑中把插头给拔了,没人觉得这样处理有什么不妥。”

这些被淘汰掉的设备现在被堆放在“服务器公墓”里,这是Borland公司在库比蒂诺总部的七层和八层之间专门划出的一片场地。Barbin对这种效果很满意,不干活的家伙就先休息吧,有需要了组织上会考虑到你们的。

清理服务器只是对Borland公司IT资产进行合理化清点的第一步,在这个漫长的过程中,Barbin基本上实现了将现有服务项目向以Salesforce.com为代表的云平台迁移的工作。大约一年之后,他和另外三位同事离职并成立了Appirio公司,这是一家专门帮助中型及大型企业将IT基础设施向云端迁移并加以管理的公司。

Barbin指出,Borland公司的情况并不罕见。时至今日,仍然有许多大型企业拥有成千上万台未被充分利用的服务器,而且这些企业的员工甚至连这些设备在干什么都不知道。然而,他补充道,如果现在再让他负责这方面工作,他绝对不会随便就选择“拔插头”。

“我们自己一台服务器都没买过,”他说。“我们100%使用云资源,并承诺帮助企业客户减少其服务器的数量。我们刚起步的时候只有四名员工,但现在已经坐拥五百之众。也许有一天,我们会成为拥有两万五千名员工这样的超大型企业,但我们坚信自己无论到什么时候都不会使用自有服务器。毕竟我们最擅长的就是使用云资源,而且服务器带来的麻烦与高昂成本相信没人比我们见的更多。”

科技陷阱回避大法第六招: 备份内容看着有、用着无

这又是一个堪称经典的案例:备份用的磁带堆积如山,却从来没有人去过问——直到某一天这些东西该派上用场了,结果却令人叫苦不迭。

早在九十年代中期,Mike Meikle为一家不愿透露名称的机构担任系统管理员,当时的他可谓无所不知、业务娴熟。就在入职后不久,他发现该机构的服务器从来没有进行过病毒扫描,而且杀毒软件也已经很长时间没有更新过。

“正所谓新官上任三把火,”他说。“我当时刚刚入职几周,并且正在尝试融入这个新的环境。当时与我搭档的是一位已经有五年工作经验的老员工,他为人和蔼,主要负责服务器备份方面的工作。他向我保证,所有服务器上的全部内容都已经备份完成,我们可以大胆实施自己的整改计划。”

Meikle信心满满地开始扫描病毒、清除感染文件并重新启动设备。大体上没出什么问题,只有一台服务器无法重新启动——要命的是,这台服务器保存的正是大宗资金的来源及去向。像这样的关键性信息,绝对不容有失。

“我当时想了一下,觉得没问题,因为可以从磁带上恢复数据,”他告诉我们。

不出意外,所有的磁带都已经损坏,但根本没人发现,因为从来没有哪位员工曾经定期检查过备份体系或者测试恢复机制。最终,这台服务器还是恢复了正常运转,但最近几个月来的记录已经彻底丢失了。

Meikle如今管理着自家技术咨询公司的Meikle说,他仍然记得在向CFO报告情况时,她脸上那阴沉的表情。可能换作是我们,反应会更为激烈,毕竟三个月来的业务信息只因为备份机制的崩溃而需要重新汇总。

“就在那一天,我学到了保持备份机制的可靠性及定期进行测试有多么重要,”他总结道。“遗憾的是我这一次花的学费有点过于昂贵了。而更悲惨的是,许多IT部门直到今天仍然没有组织起经过测试的优秀备份机制,甚至连灾难恢复计划都没有。”

科技陷阱回避大法第七招: Hex marks the spot

在编程领域有三大基本规章。第一条:用心写代码。第二条:彻底做测试。但仅仅遵循这两条还远远不够,大家务必要重视这第三条:保护好自己的敏感信息。

William Warren(化名)九十年代中期在一家大型电信公司担任软件工程师,当时他接到一项任务:制作一款应用程序,让文员可以直接将社保号码输入到数据库当中。值得一提的是,公司要求该应用程序必须彻底清除用户所输入的内容,以确保数字填写框中不会残留任何数字信息之外的字符(例如破折号等)。

但当公司的测试人员对Warren的成果进行检测时,他们发现应用程序的打印结果出现了严重问题:原本只能用于输入社保号码的数字输入框中出现了字母。他们当然立即向Warren提出质疑。

“在那个时代,蓝色巨人掌控着一切,而IBM恰好为数字配备了几个格式说明符,”他解释道。“由于我所选择的数据库函数访问参数是以字母结尾的,因此数字被以十六进制的形式存储在硬盘当中。这算不上是很严重的错误——不过是检索数量的方案将结果转换为十六进制形式——但我得承认,我把项目搞砸了。”

不过聪明而狡猾的Warren并没有把实情告知测试人员。经过一番思索,他决定将这种情况解释为“出于安全性的考量。”他告诉测试人员,为了遵守联邦法规中关于社保号码保密的相关规定,他不得不将这些信息以人类无法直接阅读的形式加以存储。出于这一目的,他才故意选择了十六进制。而且做事严谨的他在为应用程序编写说明文档时,也没有忘记将这套说辞添加进去。

这样一来Warren瞬间从罪人变身为功臣。公司不仅没有处罚他,甚至还慷慨地发了4000美元奖金,以鼓励他“在没有造成任何额外投入的情况下,创造出一套符合法律规定的创新型解决方案。”每当回忆起这件事,他都会开怀大笑:“我从来没核实过政府是否真的颁布过这样一条法令,不过这四千块钱倒是帮了我不少忙。现在每当我看到厨房的封闭窗和院里的游泳池时,我都会暗暗庆幸自己当初的灵机一动。”

原文名:True tech confessions II: Sinners and winners

来源:CIOAge 

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");