我们注视的，是相同的世界吗
我们注视的，是相同的世界吗
先是一大早，跟ZHUMAO通电话，问我一大早感觉如何。我说，当然不好，本来正睡觉，被打断几次，只好起床吃饭。ZHUMAO说，那你还是来吧，不然我还得再打断你几次。
吃了上午饭，我想想，还是去到ZHUMAO现场，与其远程被打断几次，不如现场讨论来得迅速。更何况ZHUMAO为我这样的半残人士准备了可以拖到眼前的那种"臂"式的显示器架，我和他结对编程的环境很是不错。
故事1 程序设计 或者 web
11点，我们开始调代码。故事1开始。
故事1。ZHUMAO打算做一个web程序，包括上传乱糟各种东西的功能。此前几经评估，准备借助 plupload 实现上传。plupload是个支持 flash/html5 等诸多客户端平台的解决方案，我们最需要的特色是 客户端部分可以把一个大的待上传文件拆成若干个小块，在服务端再组装起来，避免通常的大文件上传方案要在服务端分配与文件相同大小内存的问题。plupload 把大文件分成的小块称为 chunk。
我们选定plupload方案以后，我和zhumao,sunqc做了一些准备工作，部署了示例程序，改了一些配置，改了目录权限，以支持 web server 写操作。然后我们传了大文件，小文件，测试成功。昨天之前，zhumao&sunqc两位同学又做了一些工作，把界面改得华丽了很多，测试了传特定格式的文件。
然后，问题来了。
我昨天去的时候，ZHUMAO描述说：plupload有个毛病，上传图片的时候，会把图片大小自动修改了，改成比较小的、质量较低的。
我说：啊。
这几年来，zhumao已经熟悉我的嘴脸了。说有什么毛病，第一件事，我肯定是要看毛病到底啥样。你光说，我是啥也不信。基本上，如果你说吃了砒霜会死，我十有八九会要求你死给我看。这一条，可以参考14条原则里不要相信客户或者任何人那一条。
其实我心里还在想些别的。我在想，这哪是毛病，这明明是特点啊。上传图片一般都是为了在web站点上展示，不需要高质量，而图片压缩以后大大减小上传的文件尺寸，多好啊。就像声学钢琴，特指非三角的那种，正常按键的时候声音比较大；电钢琴如果把音量调小，你正常按键的时候，声音会比较小--某同学，这不是毛病，这是特点，因为声学钢琴不具备这种功能。如果你把电钢琴的声音调到正常，再正常按键，那至少，刚刚提到正常按键声音比较小的问题就消失了。
不过，ZHUMAO是用户及上帝，他的要求都是合理的，而且我确实能够理解，保留完美质量照片的重要性。所以我说：这特性应该能禁用吧，这个就挺像，参数resize。
ZHUMAO说，试了，不好使。删除这个特性，就传不上去照片了。
我说：啊？
于是ZHUMAO又演示一遍。果然，客户端报IO错误多少多少号，服务端没有接收到文件。
我说：哎呀？
后来还有很多技术路线的小插曲，我们还试了一些没用的。再后来，我猜测：不是啥类型的大文件都传不上去了吧？
ZHUMAO说：没有，我们测过。
我说：啊。
于是ZHUMAO开始演示。这一次，失败了。某个图片类型以外的文件，上传也失败了。然后我们又确认，上传小的图片文件时--由于不需要chunk--可以上传成功，上传大的图片文件时--由于需要chunk--上传失败。分界线正在是否大到需要chunk。
所以，这个时候发生了一个重要的变化：1.并不是改了resize参数以后上传图片失败，2.而是目前无论什么类型的文件只要chunk，上传都失败。
同样的现象：改resize上传文件失败，现在变成了不同的原因：不仅是图片，任何文件，甚至不改resize，上传也会失败。此前之所以会误会为改了resize上传就失败，是因为改了resize参数以后，测试的恰好是需要chunk的文件。
批判性思维告诉我们，要注意，如果A与B同时或先后发生，那么，我们不能简单得出A与B的因果关系，除了回归分析，还至少需要考虑到：A是导致B的唯一原因么，A是导致B的全部原因么。甚至，在上述案例中，A根本不是导致B的原因。resize修改，只是暴露出了问题，并非导致问题。
据说西域某小城，国王喜欢杀掉报凶信的人，他显然不能区分暴露问题和导致问题是两回事。我们的文化中讨厌乌鸦，大致也是这个路子。我们甚至讨厌预测不良后果的人。
然后，我跟ZHUMAO开始着手解决为什么不能上传需要chunk的大文件这一问题。所以，以前老师总是教导我们，知道问题是什么，远比知道如何解决重要。是不是还有人记得政治课上的那些题，明明我们背得一大堆好答案，考试的时候唯独不知道问的那道题和哪个答案对应。确定了问题以后，解决起来只是体力活了，我俩拆腾了4个小时里剩下的时间，解决了。resize可以通过把quality改为100保证上传的文件大小不变，甚至还可以把resize参数删除，图片就不在客户端做任何处理。
最初和后来，我们看到的是相同的故障，但是，我们心中所想的已经非常不同。先前是图片，后来是chunk。我们先前与后来，观察的是同一个世界么？
故事2 系统维护
下午15:10，跟ZHUMAO去大哥那里做咨询，故事2开始。
大哥以前想办个乐队来着，这是他的理想。我大一的时候，在迎新晚会上看他和陈师兄弹吉他，唱《青春》。他俩是谁向谁单膝跪下来着，我眼神不好没看清。不过他们不是好基友，那是因为电吉他的拾音器线不够长，跪着的那位直接拿迈克对着吉他。大哥的乐队一直也没办成，成为了IT团队的领袖。我当初也有理想来着。我跟大哥说，等我有了房子，一定要在天花板上装几个啤酒桶，下面接上水龙头，想喝的时候，哗。真过瘾啊。我的理想也没有实现，成了今天的这个样子。
我们，各自先去做谋生的或者让我们能生存下去的事了。那些伟大的理想，让更精于此道的兄弟们去实现吧。有一些人，他们应该能靠乐队活下去，有一些人...真的会有人能靠喝酒活下去么？
昨天下午去拜访的，就是这位大哥了。咨询中间的时候，大哥在电话里说，他还需要来么。我说，当然，你得来，你难道就不想来看看我么，如此难得地见到我的机会。
大哥来的时候，某台服务器正重新启动，后来的解决路线就非常清晰了。我们从头说。我和ZHUMAO没去的时候，故障现象的描述是：当访问量上升，负载增加的时候，服务器会崩溃。
我俩分别在听到这句话的时候问了同一个问题，"什么是崩溃。"
所以，到现场以后，画了整体部署的框图，我们就要求：崩溃一个给我们看看呗。
答复是：不确定什么时候能崩溃。
那崩溃时候的日志呢？
答复是：日志有，不知道什么时候崩溃的。
有位兄弟想起个时间。我们通过他们电话的时间，及ZHUMAO查了其他的一些日志，确定了崩溃时间。再查那个时间的日志--没有任何异常。
ZHUMAO说，我用AB做一个压力测试吧，先给你整"崩溃"一下。开始同学们不同意，后来从了。压力测试几次的结果是，当时服务器似乎死了，但是无一例外地，压力一消除，服务器就能从"崩溃"中自动恢复正常。
而同学们描述的"崩溃"，是无法恢复，只能reset各个服务才能解决问题。我断言不是由于压力导致的，不然，压力持续下，reset以后，服务器会不停地在 崩溃-reset-正常-崩溃 之间震荡。而同学们说现象不是这样的。
最难诊断的，就是病人告诉医生，我疼，但是我也不知道哪疼。
这个时候救星来了，有一台服务器登录不上去了，怀疑被黑了。重启，用光盘重置登录密码，重启服务器。这时，大哥进门，好戏来了--网站无法访问了。
以前每次重启服务器或服务以后，据说，网站就恢复了。同学们说，从来也没有这样过，重启服务器也没用。
此处省略半个多小时的分析和实验。我们最后得出结论，至少这一次故障与负载压力之类毫不相关，怀疑此前的那些故障也都与服务器性能无关。这台同时有电信、网通、教育网IP的服务器上面还跑了一个DNS server，它域管理服务器架在网通IP上，而www服务架设在教育网IP上。而且，ZHUMAO说，网通线路不怎么稳定，并用实验证实了。
所以，当某个不幸的家伙要访问www.xxx.net的时候，他先问他的DNS服务器"www.xxx.net的IP是什么啊"。他的DNS服务器不知道，向.net根域服务器提出递归解析请求，.net根域服务器又去问--对了，就是在网通线路上的上述域管理服务器。然后，没问到，因为网通线路质量不好。
所以，全世界都访问www.xxx.net困难。这可以用通过IP而不是域名访问验证，当然，我们也这样做了。
问题清晰以后，解决就方便多了。我们把域管理服务器移到了教育网线路上。说到这里有个插曲。其实这些同学虽然也遇到一些困难，但是还真是挺有专业精神的。我要求修改域管理服务器的地址，那同学问我"不会带来其他的问题吗？"我心想，好问题，这谁能保证啊，然后说，"不能保证。"他越发犹豫，我故意说，"哎呀，就试试呗。"恶作剧的感觉，我都快笑出声了。结果，这位同学转头去看大哥，得到同意以后才操作。就本科生这样的年龄来说，非常专业。
还是说，问题清晰以后，解决本身就方便多了。解决，只是问题诊断的小小延续而已。
先前大哥的同学们猜测系统性能、应该做负载均衡，我和ZHUMAO看到的是DNS解析。大家一起看到故障现象，为什么会定义出不同的问题呢。因为，正如柯南道尔通过福尔摩斯说："因为我们只看到我们想看到的。"
你所看到的现象，不一定是事实，我所看到的现象，也不一定是。包师兄当年在友谊商场到校医校的路上，问我，"我们如何确定观察的是同一个世界呢。"我当时毫无畏惧地说，"唯物主义者这样证实，我们修改这个世界，你也看到了这个修改，那么这是同一个世界。"后来一些年，我开始动摇。在目录A下建立文件，目录B里这些文件也出现了，你就能保证那是两个相同的目录么。如果有个程序监听目录A，然后复制所有的操作到B呢，而且，将来某一刻，这个监听程序不工作了，这还是两个相同的目录么。或者更简单的，如果换个用户登录，发现A和B不相同呢？包师兄后来去美国继续研究康德的《纯粹理性批判》去了，他本科是物理专业的。我本科是电子的，还在这里，一步没动。
你的世界与我的世界的同一问题，与此类似的，又如何确保我说的正是你所听到的。你点头微笑，示意听懂，我又如何确认你不是在表演，而事实可能是，你用"不想听"过滤了全部内容。
人生不相见，动如参与商。
--------------------
博客会手工同步到以下地址：
[http://giftdotyoung.blogspot.com]
[http://blog.csdn.net/younggift]
更多照片，在[http://www.douban.com/photos/album/80798837/]
我经常对于CSDN里的博客如何分类颇感踌躇。比如昨天，我先是在图书馆跟ZHUAMO调了约4个小时代码，然后又跟ZHUMAO去大哥那里做服务器负载均衡的咨询。两个故障在我看来原因是相同的，那么，应该归到系统维护类呢，还是编程类？先是一大早，跟ZHUMAO通电话，问我一大早感觉如何。我说，当然不好，本来正睡觉，被打断几次，只好起床吃饭。ZHUMAO说，那你还是来吧，不然我还得再打断你几次。
吃了上午饭，我想想，还是去到ZHUMAO现场，与其远程被打断几次，不如现场讨论来得迅速。更何况ZHUMAO为我这样的半残人士准备了可以拖到眼前的那种"臂"式的显示器架，我和他结对编程的环境很是不错。
故事1 程序设计 或者 web
11点，我们开始调代码。故事1开始。
故事1。ZHUMAO打算做一个web程序，包括上传乱糟各种东西的功能。此前几经评估，准备借助 plupload 实现上传。plupload是个支持 flash/html5 等诸多客户端平台的解决方案，我们最需要的特色是 客户端部分可以把一个大的待上传文件拆成若干个小块，在服务端再组装起来，避免通常的大文件上传方案要在服务端分配与文件相同大小内存的问题。plupload 把大文件分成的小块称为 chunk。
我们选定plupload方案以后，我和zhumao,sunqc做了一些准备工作，部署了示例程序，改了一些配置，改了目录权限，以支持 web server 写操作。然后我们传了大文件，小文件，测试成功。昨天之前，zhumao&sunqc两位同学又做了一些工作，把界面改得华丽了很多，测试了传特定格式的文件。
然后，问题来了。
我昨天去的时候，ZHUMAO描述说：plupload有个毛病，上传图片的时候，会把图片大小自动修改了，改成比较小的、质量较低的。
我说：啊。
这几年来，zhumao已经熟悉我的嘴脸了。说有什么毛病，第一件事，我肯定是要看毛病到底啥样。你光说，我是啥也不信。基本上，如果你说吃了砒霜会死，我十有八九会要求你死给我看。这一条，可以参考14条原则里不要相信客户或者任何人那一条。
其实我心里还在想些别的。我在想，这哪是毛病，这明明是特点啊。上传图片一般都是为了在web站点上展示，不需要高质量，而图片压缩以后大大减小上传的文件尺寸，多好啊。就像声学钢琴，特指非三角的那种，正常按键的时候声音比较大；电钢琴如果把音量调小，你正常按键的时候，声音会比较小--某同学，这不是毛病，这是特点，因为声学钢琴不具备这种功能。如果你把电钢琴的声音调到正常，再正常按键，那至少，刚刚提到正常按键声音比较小的问题就消失了。
不过，ZHUMAO是用户及上帝，他的要求都是合理的，而且我确实能够理解，保留完美质量照片的重要性。所以我说：这特性应该能禁用吧，这个就挺像，参数resize。
ZHUMAO说，试了，不好使。删除这个特性，就传不上去照片了。
我说：啊？
于是ZHUMAO又演示一遍。果然，客户端报IO错误多少多少号，服务端没有接收到文件。
我说：哎呀？
后来还有很多技术路线的小插曲，我们还试了一些没用的。再后来，我猜测：不是啥类型的大文件都传不上去了吧？
ZHUMAO说：没有，我们测过。
我说：啊。
于是ZHUMAO开始演示。这一次，失败了。某个图片类型以外的文件，上传也失败了。然后我们又确认，上传小的图片文件时--由于不需要chunk--可以上传成功，上传大的图片文件时--由于需要chunk--上传失败。分界线正在是否大到需要chunk。
所以，这个时候发生了一个重要的变化：1.并不是改了resize参数以后上传图片失败，2.而是目前无论什么类型的文件只要chunk，上传都失败。
同样的现象：改resize上传文件失败，现在变成了不同的原因：不仅是图片，任何文件，甚至不改resize，上传也会失败。此前之所以会误会为改了resize上传就失败，是因为改了resize参数以后，测试的恰好是需要chunk的文件。
批判性思维告诉我们，要注意，如果A与B同时或先后发生，那么，我们不能简单得出A与B的因果关系，除了回归分析，还至少需要考虑到：A是导致B的唯一原因么，A是导致B的全部原因么。甚至，在上述案例中，A根本不是导致B的原因。resize修改，只是暴露出了问题，并非导致问题。
据说西域某小城，国王喜欢杀掉报凶信的人，他显然不能区分暴露问题和导致问题是两回事。我们的文化中讨厌乌鸦，大致也是这个路子。我们甚至讨厌预测不良后果的人。
然后，我跟ZHUMAO开始着手解决为什么不能上传需要chunk的大文件这一问题。所以，以前老师总是教导我们，知道问题是什么，远比知道如何解决重要。是不是还有人记得政治课上的那些题，明明我们背得一大堆好答案，考试的时候唯独不知道问的那道题和哪个答案对应。确定了问题以后，解决起来只是体力活了，我俩拆腾了4个小时里剩下的时间，解决了。resize可以通过把quality改为100保证上传的文件大小不变，甚至还可以把resize参数删除，图片就不在客户端做任何处理。
最初和后来，我们看到的是相同的故障，但是，我们心中所想的已经非常不同。先前是图片，后来是chunk。我们先前与后来，观察的是同一个世界么？
故事2 系统维护
下午15:10，跟ZHUMAO去大哥那里做咨询，故事2开始。
大哥以前想办个乐队来着，这是他的理想。我大一的时候，在迎新晚会上看他和陈师兄弹吉他，唱《青春》。他俩是谁向谁单膝跪下来着，我眼神不好没看清。不过他们不是好基友，那是因为电吉他的拾音器线不够长，跪着的那位直接拿迈克对着吉他。大哥的乐队一直也没办成，成为了IT团队的领袖。我当初也有理想来着。我跟大哥说，等我有了房子，一定要在天花板上装几个啤酒桶，下面接上水龙头，想喝的时候，哗。真过瘾啊。我的理想也没有实现，成了今天的这个样子。
我们，各自先去做谋生的或者让我们能生存下去的事了。那些伟大的理想，让更精于此道的兄弟们去实现吧。有一些人，他们应该能靠乐队活下去，有一些人...真的会有人能靠喝酒活下去么？
昨天下午去拜访的，就是这位大哥了。咨询中间的时候，大哥在电话里说，他还需要来么。我说，当然，你得来，你难道就不想来看看我么，如此难得地见到我的机会。
大哥来的时候，某台服务器正重新启动，后来的解决路线就非常清晰了。我们从头说。我和ZHUMAO没去的时候，故障现象的描述是：当访问量上升，负载增加的时候，服务器会崩溃。
我俩分别在听到这句话的时候问了同一个问题，"什么是崩溃。"
所以，到现场以后，画了整体部署的框图，我们就要求：崩溃一个给我们看看呗。
答复是：不确定什么时候能崩溃。
那崩溃时候的日志呢？
答复是：日志有，不知道什么时候崩溃的。
有位兄弟想起个时间。我们通过他们电话的时间，及ZHUMAO查了其他的一些日志，确定了崩溃时间。再查那个时间的日志--没有任何异常。
ZHUMAO说，我用AB做一个压力测试吧，先给你整"崩溃"一下。开始同学们不同意，后来从了。压力测试几次的结果是，当时服务器似乎死了，但是无一例外地，压力一消除，服务器就能从"崩溃"中自动恢复正常。
而同学们描述的"崩溃"，是无法恢复，只能reset各个服务才能解决问题。我断言不是由于压力导致的，不然，压力持续下，reset以后，服务器会不停地在 崩溃-reset-正常-崩溃 之间震荡。而同学们说现象不是这样的。
最难诊断的，就是病人告诉医生，我疼，但是我也不知道哪疼。
这个时候救星来了，有一台服务器登录不上去了，怀疑被黑了。重启，用光盘重置登录密码，重启服务器。这时，大哥进门，好戏来了--网站无法访问了。
以前每次重启服务器或服务以后，据说，网站就恢复了。同学们说，从来也没有这样过，重启服务器也没用。
此处省略半个多小时的分析和实验。我们最后得出结论，至少这一次故障与负载压力之类毫不相关，怀疑此前的那些故障也都与服务器性能无关。这台同时有电信、网通、教育网IP的服务器上面还跑了一个DNS server，它域管理服务器架在网通IP上，而www服务架设在教育网IP上。而且，ZHUMAO说，网通线路不怎么稳定，并用实验证实了。
所以，当某个不幸的家伙要访问www.xxx.net的时候，他先问他的DNS服务器"www.xxx.net的IP是什么啊"。他的DNS服务器不知道，向.net根域服务器提出递归解析请求，.net根域服务器又去问--对了，就是在网通线路上的上述域管理服务器。然后，没问到，因为网通线路质量不好。
所以，全世界都访问www.xxx.net困难。这可以用通过IP而不是域名访问验证，当然，我们也这样做了。
问题清晰以后，解决就方便多了。我们把域管理服务器移到了教育网线路上。说到这里有个插曲。其实这些同学虽然也遇到一些困难，但是还真是挺有专业精神的。我要求修改域管理服务器的地址，那同学问我"不会带来其他的问题吗？"我心想，好问题，这谁能保证啊，然后说，"不能保证。"他越发犹豫，我故意说，"哎呀，就试试呗。"恶作剧的感觉，我都快笑出声了。结果，这位同学转头去看大哥，得到同意以后才操作。就本科生这样的年龄来说，非常专业。
还是说，问题清晰以后，解决本身就方便多了。解决，只是问题诊断的小小延续而已。
先前大哥的同学们猜测系统性能、应该做负载均衡，我和ZHUMAO看到的是DNS解析。大家一起看到故障现象，为什么会定义出不同的问题呢。因为，正如柯南道尔通过福尔摩斯说："因为我们只看到我们想看到的。"
你所看到的现象，不一定是事实，我所看到的现象，也不一定是。包师兄当年在友谊商场到校医校的路上，问我，"我们如何确定观察的是同一个世界呢。"我当时毫无畏惧地说，"唯物主义者这样证实，我们修改这个世界，你也看到了这个修改，那么这是同一个世界。"后来一些年，我开始动摇。在目录A下建立文件，目录B里这些文件也出现了，你就能保证那是两个相同的目录么。如果有个程序监听目录A，然后复制所有的操作到B呢，而且，将来某一刻，这个监听程序不工作了，这还是两个相同的目录么。或者更简单的，如果换个用户登录，发现A和B不相同呢？包师兄后来去美国继续研究康德的《纯粹理性批判》去了，他本科是物理专业的。我本科是电子的，还在这里，一步没动。
你的世界与我的世界的同一问题，与此类似的，又如何确保我说的正是你所听到的。你点头微笑，示意听懂，我又如何确认你不是在表演，而事实可能是，你用"不想听"过滤了全部内容。
人生不相见，动如参与商。
--------------------
博客会手工同步到以下地址：
[http://giftdotyoung.blogspot.com]
[http://blog.csdn.net/younggift]