微信号:yurii-says

介绍:我是这么以为的,当然你也可以那么以为

从Macbook Pro的塑料珠说起

2017-08-26 21:29 余晟

图片摄于重庆磁器口。


前几天,有同事神秘兮兮地问我:新买的Macbook Pro笔记本电脑,不时往外掉透明的小塑料珠,这是什么元件,质量这么差?

我也故作神秘地问:你是不是背包来上班的?

然后他满脸困惑地表情:是啊,但是,这和电脑有什么关系?

我说:你去包里仔细搜搜,一定有个装干燥剂的白色小纸包。你说的“透明的小塑料珠”其实是漏出来的硅胶干燥剂。如果是其他笔记本电脑,一般外壳材质是塑料,不会撞破干燥剂纸包。但是Macbook是铝外壳,边缘相对锋利,久而久之会切开干燥剂纸包……

他仔细一查,果真如此。在一般外人看来,这么诡异的原因都能料到,真是神奇。其实这没有什么好神奇的,只是我自己也经历过,所以才知道。当时我也是一头雾水,这么想也想不明白,Macbook里到底什么元件出了问题,会往外掉小塑料珠子,直到有一天偶然看到开了个口的干燥剂纸包,才恍然大悟——虽然保存照相设备的防潮箱里,就放着这么一盒干燥剂呢。

我不知道其它行业如何,至少在IT行业,这样的笑话——如果不叫笑话,就叫“滑稽经历”吧——挺多。因为大家都很讲逻辑,逻辑往往会走进死胡同,但是现实又明明和逻辑相违背,直到那个关键的新变量被引入。

以前霍炬给我讲过一个笑话,我印象很深。电信公司接到客户的电话,说没法上网了。于是技术客服非常耐心地指导这个小白客户,一个个软件,一种种情况排查,用最浅显的语言解释各个概念。可惜还是没法定位问题,于是客服说:那么,请您看看您的调制解调器的工作状态灯。之后又费了很多工夫解释什么是调制解调器,看起来是什么样子。之后客户说“好,我知道什么是调制解调器了,但是我没法去看状态灯”。

客服百思不得其解:为什么您没有办法去看状态灯呢?

答曰:因为我的调制解调器放在我家地下室,地下室淹水了现在下不去,我还在等人来修理。

客服的反应也很快:噢,我知道问题在哪里了,因为我们提供的调制解调器没法在水里工作……

笑话归笑话,如果我们不是看客而是笑话中人,真正遇到这种问题,恐怕都笑不出来。下面我且举两段自己的血泪教训,与大家分享。

之前我在一家公司,又多个办公地点。其中一处办公地点的网络总是出问题,而且是莫名其妙的问题。具体现象是,正常上网一段时间之后,就会有少数机器不能上网,之后蔓延开来,好像传染一样,越来越多。必须把所有机器全部断网,全部重启,网络才能恢复正常。

诡异的是,这些电脑的使用都很规矩,没有装任何乱七八糟的软件。而且,查看不能上网的电脑的网络设置,IP和网关设置都没有问题,数据包就是出不去。更奇怪的是,每次出故障的电脑都不一样,没有规律可循。

当时我们想了很多办法,给所有电脑杀毒,逐台逐台判断……几乎什么办法都尝试过了,还是不行。眼看工作不断受到影响,问题始终没法解决,只能干着急。

直到有一天,和一个运维出身的朋友聊,说起这个问题。他说:“你们开发出身的人,都喜欢从系统和软件的角度去找问题,但是在我看,是不是网络上有什么名堂,如果局域网里还有其它设备会开启DHCP服务,是会产生这种现象的”。

这真叫人茅塞顿开——这不就是张国焘另立中央嘛,那必然会乱套。仔细检查,果然是有一台设备会(异常)不定期开启DHCP服务,其它电脑的DHCP租约到期之后,可能就会对接到这一套DHCP,虽然IP、网关、子网掩码“看起来”都一样,其实是怎样也出不去的。

这个事故让我反思了很多。之前我说过,CTO可以不写代码,也不必一定会写代码。因为,我还真见过运维出身的CTO呢,人家一样干得很好。重要的不是写代码,而是有没有解决技术问题的眼光、思维、素质。

另一次诡异的故障和开发直接相关。某个正常的操作,在海外员工操作的时候,经常会多执行一次,导致业务部门的投诉。一方面,已经向这位同事强调过操作规程,不要重复点击,但人家信誓旦旦说完全是按规矩来的,没有重复点击;另一方面,检查应用服务器日志,确实只收到一次请求,而且已经在程序上做了锁,仍然没法防住这种情况。

一边不停给业务部门赔礼道歉,另一边怎么也找不到思路,这种煎熬,经历过的人想必都能不愿意再回味。

直到有一天又出现了这种情况,我尝试把思维清零,按照客户的访问链路一个环节一个环节的排查。这时候才发现,在客户浏览器和应用服务器之间,还有一台用作负载均衡的Nginx反向代理。为了保证服务质量,Nginx的设置里有超时设置,还有超时之后启用Backup,把请求发给备用的应用服务器的设置…… 再检查那几次出现重复操作的日志,原来问题就在这里!

正常情况(大部分同事都在国内)下,访问速度是有保障的,后端服务的响应时间也是有保障的。但是对于海外同事,他们本来连接的速度就很慢,为了减少操作次数,单次操作的数据量会更大一些,这很可能会导致Nginx到后端服务器的通讯时间超过了Nginx里的容许值。

结果,第一次收到请求的后端服务器还在悠哉游哉地处理请求呢,Nginx已经等得不耐烦了,一狠心把请求发给备用的后端服务器。但是对两台后端服务器来说,大家都认为自己在全权处理,所以程序上的锁怎么锁得住其它服务器呢。也不用说分布式协调了,要知道,那还是十多年前,分布式协调组件远远没有如今这么流行和成熟呢。

这件事也让我反思了很多:首先,HTTP这种请求-应答式的同步通讯模型,如果要处理耗时比较长的业务,就得加倍小心;其次,程序员不能只关心代码,从客户请求到服务器处理的整个链路,全都得了解清楚,才做得出可靠的服务;再次,幂等性的重要性,无论怎么强调也不为过,如何保证幂等,几种常见的模式是必须烂熟于胸的,而面试时谈GET和POST的区别不涉及幂等性的程序员,基本是要被涮的……

关于幂等性,还可以多扯几句。前几天我们技术团队里,开发和运维的伙伴在谈论开启HTTP强制跳转的HSTS时,原有HTTP请求应当返回什么状态码的问题,为什么出现了307,而不是301或者302。观察讨论,我才发现不少人还不清楚,所以有必要做点讲解。

传统上,大家都会使用301或者302的状态码,告诉客户端跳转到一个新的地址,而且似乎一直也没有问题。然而事实不是这样的,因为301和302跳转,并没有明确规定新的请求必须保持“原封不动”。所以,如果客户端发的是POST请求,收到301或者302跳转之后,往往会改换成GET请求来发送,这样就会导致不可预期的情况。

为解决这个问题,HTTP协议新增了307和308两个状态码。307和302对应,308和301对应。主要的区别是,301和302容许跳转前后的动词变化,307和308要求严格保持一致。

借用StackOverflow的表格


今天想向大家推荐的是肯·福莱特的《鹰翼行动》。肯·福莱特的小说(这本是纪实性质)都写得很好,叙事流畅,扣人心弦。不过这本书有几点特别吸引我:

第一,故事发生在上世纪70年代,伊朗发生了政变,两名美国公司的雇员被扣押称为人质。美国政府不想出面,但这家公司的老大出于道义,决定自己组织救援队深入伊朗解救他们。如今的世界多少让人感到乏味,互联网企业家们一个比一个会包装自己,但遇到这样的事情,他们是否会挺身而出,我深表怀疑。

第二,救援队的人解决问题的能力很强,经常有一些思路让人叫绝。比如在当时纷乱的德黑兰,要迅速弄到两辆路虎车逃出伊朗,你会怎么办?他们的办法是让当地人上街四处寻找停着的路虎,看到就给人风挡上留下纸条:我们希望用2万美元换你的车。结果第二天就搞定了两辆车。换做一般人,可能能想到的就是去买车,或者登广告,而不会这样主动直接地解决问题。

第三,救援行动的总指挥,退役军人西蒙斯,对于工作的要求到了极致。大家好不容易逃出伊朗,在飞往西徳的飞机上,西蒙斯要求确认,西徳与伊朗之间是否有引渡协议。得到的答复是“应该没有”。结果被他当场否定:“我需要的是100%的确认,哪怕98%也是不行的”。美国总部详细查证之后,发现确实是有引渡协议的,虽然一直没有实行过。不过一旦落实了这点,他们必然不能以为进入西徳就万事大吉。IT行业太多的故障,是和“我以为”、“应该”之类密切相关的。

第四,我一般推荐的书都是有Kindle版,而且Kindle版不贵的。比如这本书,才4.99元,很适合花一个下午读完。



 
余晟以为 更多文章 批评无须“善意” 在路上 地心说的科学含量 Excel与微服务 面对批评的方式
猜您喜欢 「邀请函」TechCrunch 北京峰会 | 黑客马拉松 课程丨产品经理直通车,你的产品经理之路从这里开始 科技圈的一场颜值革命正在悄然掀起...... 数据分析师必需具备的10种分析思维。 【经典面试题】最长公共子串