《linux运维趋势》2012年5月号总第19期

主编

杨赛

审阅

煮酒品茶

出版方

51CTO系统频道

（os.51cto.com）

出版日期

每个月的第2个星期五

邮件订阅

h t t p : / / o s . 5 1 c t o . c o m /art/201011/233915.htm

RSS订阅（最早发布）

http://www.51cto.com/php/rss.php?typeid=777

iPad订阅

《读览天下》客户端

联系电话

010-68476606-8035

编者的话《Linux运维趋势》眼看着就发布到了第19期，算

上一开始的测试刊和 Linux 20 周年时推出的特刊，到现在已经走过了 21 期，22个月的时间。

“是时候做一些改变了。”

一方面，《趋势》最初以主题确立每期的内容方向，随着期数增多，却也限制了取材的范围；另一方面，原本的版式学习自横版的《Full Circles》，虽然在PC上更具观赏性，但在往专业的杂志平台推送、以及转换成电子书格式的过程中，都遇到一些问题。

这个时候，我阅读到一篇关于《Hacker Monthly》的文章，这令我对《趋势》未来的发展，有了新的想法。

所以，就有了今天这个改头换面的《趋势》新刊。如果你对此有什么想法，欢迎随时反馈！邮箱（[email protected]）、微博／推特（@lazycai）或QQ（502965602）均可。 ■

——lazycai

《Linux运维趋势》是由51CTO系统频道策划、针对Linux/Unix系统运维人员制作的一份开放的电子杂志，内容从基础的技巧心得、实际操作案例到中、高端的运维技术趋势与理念等均有覆盖。我们的所有内容均收集整理自国内外互联网，每篇文章都会严格标注出处与作者，同时编辑也会尽力联系每一篇文章的原作者进行确认。如果您认为本杂志的内容侵犯到了您的版权，可发信至[email protected]进行投诉。

http://os.51cto.com/art/201011/233915.htm




目录

专题

22 警惕程序日志对性能的影响

文／杨文博（solrex）

24 一次博客的性能故障排查

文／BOYPT

26 三招解决MongoDB的磁盘IO问题

文／ nosqlfan

28 MySQL数据库中order by的实现和 by rand() 的优化

文／丁奇

观察思考

30 阿里巴巴集团去IOE运动的思考与总结

文／mysqlops

33 挑战无处不在

文／陈皓

本月推荐

05 百度云首席架构师林仕鼎：工程师应如何突破瓶颈

采访整理／杨赛

08 探秘Facebook的交付工程团队和BT部署系统

文／ Ryan Paul 编译／核子可乐

技术分享

16 Django 托管在 Github 上的实践

文／ Perchouli

18 /dev/null 2>&1 详解

文／南非蚂蚁

19 Shell脚本自动记录登陆后的IP地址和历史记录

文／ Trespassers

20 批量下载Linux运维趋势引发的反思

文／煮酒品茶

04 本月推荐 Linux运维趋势 2012年5月号总第19期

05投稿信箱：[email protected]

百度云首席架构师林仕鼎：工程师应

如何突破瓶颈采访整理／杨赛

在今年的百度开发者大会上，百度云战略高调发布，成为开发者们瞩目的焦点。一直以来在公共领域很低调的百度移动·云事业部的首席架构师，也在当天以百度云首席架构师的身份站到了前台。在他的博客上，他喜欢谈谈架构，谈谈安全，谈谈火车票订购系统，谈谈OS的内核架构；在他的微博上，除了讨论技术之外，也喜欢晒晒团队，谈谈社会与生活。

他是林仕鼎，一位自称“西二旗跨界架构师”的资深技术男。他的成长历程是典型的研究学院派：

对于架构师的成长之路，林仕鼎先生有什么看法？近日，51CTO编辑对林仕鼎先生进行了一次采访，讨论这方面的话题。以下为采访实录：

51CTO：您最近的博客将架构分为三类：软件架构，系统架构，以及大规模分布式架构。能具体讲讲一开始接触架构设计的时候是怎样的背景吗？

林仕鼎：其实我对架构设计的看法主要还是源于项目经验，做过的事情多了，于是开始总结和提炼。架构设计不是一个单独的行为。它在系统设计和实现的过程中发生，或者在事后总结提炼生成。我觉得并不存在一个单纯的、独立的“架构设计”。

51CTO：您最初开始接触计算机和编程是什么时候？为什么会喜欢上CPU设计和内核架构这个领域的？

林仕鼎：我从95年到02年都在北航6系，真正编程始于大二。大二上半年用C做了个跳棋小游戏，暑假时帮一个老师干活，做了个基于单片机的图形化控制系统。这个控制系统大概用了一两万行的8051汇编代码，在此过程中我隐隐约约地悟出了资源管理、函数调用和模块封装等理念。虽然以今天的眼光来看，这些经验都很粗糙，但奠定了我做底层系统的基础，也从此喜欢上了这一领域。后来在本科阶段做的工作也主要与网络通信和并行程序相关，在读研时因缘巧合加入了实验室的OS小组。

本月推荐


51CTO：当时学习OS Kernel主要是通过阅读论文吗？在这种深层次的领域，有没有觉得有时候特别难懂，好像自己的成长陷入一个瓶颈，特别烦躁的情况？

林仕鼎：我当时主要通过阅读Linux kernel源码和CPU (i386, SPARC) 手册来学OS kernel的。半年多的时间，一些关键代码基本是一行一行研究的。在那个阶段，总是有新的东西可学，觉得每天都在进步，一直都很兴奋。我的看法是Linux kernel（或者Unix-like kernel）的最关键之处在于进程的创建、调度和切换，当时在把0号和1号进程搞清楚之后，真的是手舞足蹈兴奋不已。有几天觉得最复杂的程序都研究清楚了，也不过如此，甚至产生了“身登绝顶我为峰”的幻象。不过这个幻象很快就被打破了，因为有人问了我一个问题，我哑口无言。这个问题是“Linux kernel有什么缺点？如果你自己设计，会怎么改进？”后来，我开始阅读一些关于OS架构的论文，这些论文为我打开了一扇进入系统领域的大门。

在我身上，比较少有陷入瓶颈的情况，一般我都在不停地迎接新的挑战，这可能也跟我的经历有关。

51CTO：对于突破瓶颈，您个人有什么经验分享吗？有没有和导师、师兄弟们交流过这方面的事情？

林仕鼎：不同阶段工程师的瓶颈是不同的，有些人需要多写点程序，而有些人却需要从程序中跳出来。对于需要从程序中跳出来的人，我的百度空间里有篇文章，可供一读：《架构相关领域的学习材料》。

另外对于架构师的成长，我也有张图，总结了我个人的经验：

“不同阶段工程师的瓶颈是不同的，有些人需要多写点程序，而有些人却需要从程序中跳出来。”

简言之，通过写code和辛勤工作深刻理解how，通过阅读和思考逐渐体会到why，二者需要持续迭代不断升华。通常工作中得到的只是experience，思考后才会变成自己的skill；而阅读中得到的一般也只是 information ，使用后加深理解才会变成 knowledge；把skill和knowledge结合起来，才会真正形成自己的expertise。于此，才有可能具备前瞻性，知道 what to do next。

51CTO：后来接触分布式系统又是从什么时候开始的？您提到大规模分布式架构的重点是资源整合、快速交付和运维问题，而系统架构的重点是资源的分配与复用，这当中的异同具体表现在哪些方面？

林仕鼎：2002年毕业后，我加入微软研究院的系统研究组，主要研究大规模分布式系统和高性能系统架构。这段时间的主要工作是问题域研究、系统设计和原型实现，真正做出实际系统是在我到百度工作之后。


分布式架构和系统架构是两个维度的技术。从规模上来看，分布式架构通常关注的是机群或IDC，而系统架构则是单机。从目标上来看，分布式架构主要保证availability，而系统架构提供performance。在一个实际系统中，通常这两个维度的技术都会有所体现。

对于这几个类型的架构划分，都是纯粹的个人观点，不一定是成熟的或业界公认的。我的习惯是，先把一些复杂的问题解耦、分离成独立的子课题，这样比较容易找到切入点和理解问题域，然后再把不同维度的技术结合，针对具体问题和环境做出不同的折中考虑，最后形成最终解决方案。

51CTO：现在百度移动、云计算这块，您目前主要关注的方向是什么？

林仕鼎：我当前的主要工作是把面向数据处理的云计算平台、面向网络服务的应用引擎以及面向网页的浏览器平台结合，形成一个更具有普适性意义的OS平台，供WebApp运行。

现在有几个大的技术浪潮，移动、云计算、大数据以及物联网。在我看来，移动和物联网提供的是interaction和connectivity，云计算提供的是处理能力，而大数据产生智能。我们的工作就是整合这些能力，使其变得普适化，使App可以更方便地使用。然后App做什么呢？我的看法是用来 program web。Web 上有足够的 data 和 services，App可以更智能地把这些能力都串联起来，更好满足用户需求，提供更自然的交互方式。

这些技术与互联网的结合，将开启一个全新的时代，我认为这就是继PC和互联网之后的云的时代。这也是百度云战略的发展目标。

原文：http://os.51cto.com/art/201205/334675.htm

51CTO：之前看您提到过百度的绿色数据中心计划，这方面目前的进展如何？有没有计划跟其他同行，比如淘宝的工程师团队进行合作？

林仕鼎：我们的绿色数据中心计划包括三个方面：IDC、服务器和新硬件。

IDC方面，我们自行设计的M1数据中心已经运营半年多了，除了常规的直流供电和新风制冷等技术，我们还设计了冷热风道隔离和智能调节，当前的成果是夏季平均PUE是1.4左右，冬季大约1.1，这应该是国内的领先水平了。

服务器方面，我们正在设计整体机架式服务器以及基于ARM的低功耗高密度服务器。新硬件则包括自行设计的SSD、FPGA卡等。

这些设计我们都会逐步开放，也很欢迎其他同行采用我们的做法或共同研发。

51CTO：最后一个问题有关新人的培养。您现在招聘工程师主要看中哪些方面？有没有什么可以快速招到（或者定位到）合适的人的经验可以分享？

林仕鼎：就我个人而言，我最看重的是工程师的抽象能力和对问题变化的敏感性。很多年来，对于新人我只用一道面试题，很简单的数据结构建模，然后变化一些条件，看他的处理方案。

51CTO：好的，问题到此结束。感谢林仕鼎先生接受我们的采访！■

“移动和物联网提供的是interaction和connectivity，云计算提供的是处理能力，而大数据产生智能。”



探秘Facebook的交付工程团队和

BT部署系统文／ Ryan Paul 编译／核子可乐

Facebook有一套成熟的软件交付流程，平均30分钟可完成一次升级。这套流程的背后有一个交付工程团队，以及一套BT部署系统。这个系统是如何运作的？Arstechnica网站去拜访了一次这个交付工程团队，揭开了这个系统的神秘面纱——

Facebook总部设立于加利福尼亚州门洛帕克市，这同一片园区在多年前孕育出了S u n Microsystems这家同样声名在外的高科技企业。园区入口处矗立着巨大的宣传看板，相信每一位用过Facebook的朋友都不会对上面竖起大拇指的图案感到陌生——赞，这是用户表达肯定态度的方式，可能也标志着Facebook公司对自身成就的评价。我最近一次到园区采访的时候，恰好碰上一群十几岁的少年们聚集于此，争相在宣传板前合影留念。

一部席卷全球的热门影片“社交网络”让成千上万普通用户了解到Facebook公司如何从学生宿舍内的构想成长为世界第二大巨型网站，这样一个丑小鸭变天鹅的故事本身就极具传奇色彩。然而恐怕很少有人知道这家社交网站成功的背后，有多少技术人员在交付工作方面付出了艰辛的努力：先进的高科技基础设施造就了如今每天数以百万计用户的交互式Web应用体验，而这正是无数工程师呕心沥血打造出的傲人成果。

我前几天刚刚获准对Facebook总部进行专访，全程跟踪这家社交巨头的交付流程工作。Facebook公司正在筹备并部署一项全新社交功能，即“timeline”系统。而我则以独家观察者的身份参与到项目当中，随时收集第一手信息并将资料整理发布。

在Facebook园区入口与前往企业办公地点通路的交汇处，一个交通指标牌映入我的眼帘，上面写着：黑客之路。正如该公司创始人Mark Zuckerberg在今年早些时候的首次公开募股信中所言，他希望能以“黑客之路”的方式规划企业管理理念以及发展方向。在Facebook总部逗留的两天当中，我第一次与他们的交付工程师们共同生活、携手工作，并真正了解到黑客之路这一概念如何在该网站的成长与迅速普及当中起到决定性作用。

门洛帕克市的总部园区占地面积巨大，其间排布着密密麻麻的办公建筑；与其说是企业园区，这里倒更像是一个小型城市。建筑物当中随处可见精致的涂鸦式壁画及充满幽默气息的海报装饰。与传统的封闭或半封闭式办公环境不同，Facebook公司的开发人员一般会在大片开放式空间中进行工作，办公设备也沿着公用桌面排布，员工之间没有设置任何阻碍视线的隔挡。


每座办公建筑中都配备有公文室，在这里工作人员们可以在不干扰其他同事的前提下尽情开展讨论。有趣的是，每座建筑中的会议室都会以特定的主题命名。比如某栋楼里的会议室就是以“狂蟒之灾”这部电影中的一个笑话为名。另外，我还亲眼见到一些以电视节目命名的房间。而在工作人员的陪同下进入另一栋建筑时，我发现一间名为JavaScript：The Good Parts的房间。哈哈，这肯定是来自Doug Crockford所撰写的同名著作。

最终我来到交付工程团队的办公所在地。正如Facebook公司中的其它开发人员一样，交付工程师们同样使用开放式工作环境与公用办公桌。不过他们的房间仍然具有非常鲜明的特色：这里实际是一个酒水品种相当丰富的酒吧。

Chuck Rossi，Facebook交付工程团队的领导者，正坐在Hotfix吧旁接受采访

这个房间原本在两根垂直支撑柱之间设有一面背景墙。但在交付工程团队入驻之后，他们将这块区域改造成了酒吧吧台，并在台面上挑起他们精心挑选的名称：Hotfix（热修复补丁）吧。不用问，这个点子来自关键性软件补丁更新技术。而这里的员工就在围绕在吧台周围忙活手头的工作。

我正是在这里第一次见到交付工程团队的领导者Chuck Rossi。Rossi的工作设备就在吧台对面，这样他可以在工作的同时一伸手就抄起台面上的酒水饮料。我花了整个下午与这位曾效力于谷歌与IBM公司的资深软件开发人士谈天说地，这段时光非常美妙，真的像两个老朋友坐在科技气息浓郁的后现代酒吧中畅所欲言。正是以这种方式，我了解到Rossi如何带领他的团队帮助Facebook部署更新服务，并讨论这项工作的重要性及日常运作流程。


Facebook的BT部署系统

Facebook资源代码主要利用PHP编程语言进行编写。PHP语言在开发速度方面优势明显，但在性能方面比起低层次语言及某些现代编程替代方案却颇有不足。为了让这套以PHP为基础的基础设施在可扩展性领域更进一步，Facebook开发出了一套名为HipHop的特殊转译工具。

HipHop能够将PHP代码转译为高度优化过的C++代码，并通过二次编译将其转化为运行效率极高的本地二进制代码。Facebook于2010年正式推出HipHop并开始销售开源软件使用许可，同时该公司的工程师们指出，在Hip H o p的帮助下，Facebook业务流程中的CPU平均使用率瞬间降低了50%。

由于Facebook所使用的整套代码库都通过编译转化二进制可执行文件，因此该公司的整个部署流程与我们耳熟能详的P H P环境颇为不同。Rossi告诉我，Facebook所有应用程序的二进制代码库总体积约为1.5GB。当Facebook对代码进行升级并生成新的软件包时，新的全局代码库也必须同时被推送到企业内部的每一台服务器当中。

把1.5GB大小的二进制代码分配给不计其数的目标服务器，工作当中面临的技术挑战想想都令人头痛。在摸索出几套成型的解决方案之后，Facebook公司决定将BT技术敲定为最终手段。这种人气极高的点对点文件共享协议在向大量不同服务器传输大型文件方面拥有着不可替代的优势及上佳表现。

Rossi解释称，Facebook公司创建了自己的定制BT追踪工具，其设计目的是使Facebook基础设施中的每一台服务器都能够与同一节点或机架中的其它服务器一样获得相同的分区内容，如此一来总体延迟将得到大大降低。

目前Facebook网站升级的平均耗时为30分钟——其中15分钟用于生成二进制可执行文件，而另外15分钟则花费在通过BT体系将可执行文件传输至各Facebook服务器的过程中。

当然，二进制可执行文件只是Facebook应用程序堆栈中的组成部分之一。Facebook页面中还包含诸多调用自外部资源的项目，例如JavaScript、CSS以及图形要素等。这些文件被托管在分布于世界各地的内容交付网络（CDN）当中。

一般来说，Facebook会在每个工作日进行一次非关键性更新。而重大更新则每周进行一次，通常在周二下午进行内容发布。交付工程团队专门负责管理此类更新的具体部署工作，并全程跟踪以确保更新的顺利完成。

频繁的更新及发布是Facebook在创立之初就确定下来的核心发展理念之一。在该公司刚刚迈入起步阶段的时候，开发人员利用快速迭代及增量工程手段坚持不懈地对网站加以完善。这种技术层面上的灵活性在Facebook的发展及演变当中起到了关键性作用，并成功让这家年轻的企业迅速成长为举世瞩目的社交巨子。

当初Facebook公司招募Rossi的时候，是希望他能够领导交付工程团队找到合适的途径，确保企业在快速发展的同时步伐稳健、基础牢固。对于正处于急速扩张当中的Facebook而言，其网站的规模与管理复杂性也在以几何级数式增长。要实现牢固稳妥的交付战略，传统的解决方案已经无法满足需求。正是在这时，他们想到了BT部署系统。

在与Rossi共同度过的那个愉快的下午，我在概念上基本理解了他解决Facebook部署问题的处理方式。总结起来，他希望能在客观条件与理论目标之间找到一个平衡点。他制定了一套相当严格的质量及稳定性标准要求，但具体到解决方案层面却将着眼点放在高灵活性上。资源总是有限的，他认为最好的办法是通过系统灵活性来应对各种意想不到的麻烦。

“频繁的更新及发布是Facebook在创立之初就确定下来的核心发展理念之一。”


测试工作

在最近的几篇文章中，我们已经与读者朋友深入探讨了软件应用程序步入高速交付周期所带来的挑战与机遇。而挑战当中最难以克服的一个就是，如何在测试时间远低于原先水平的前提下保证软件的质量不打折扣。

由于Facebook网站每天都会进行更新，因此质量测试也就成了压力最大、负荷最强的先锋部门。为了快速发现问题，Facebook中每一位通过企业内部网络访问该社交网站的员工，都将直接登入采用了最新代码的实验性网站架构。在这里他们能够接触到一切尚未经过测试的修改建议以及还没有在正式网站上采用的最新功能。与此同时，员工还可以通过另一个单独的网址访问与外界用户相同的正式运行版网站，这样两相对比之下可能更容易发现问题。

将测试网站设定为企业员工的默认访问对象，能够在新元素及功能付诸实践之前先经受专业人士的检测。测试网站中还包含了一些内置的错误报告工具，员工一旦发现问题，就可以利用它们轻松提供详细反馈。

为了避免回档事故并确定通用性技术问题，Facebook还部署了一套自动测试系统。该公司将这类测试分为两个独立的部分：一部分专门进行代码的常规完整性测试，而另一部分则模拟用户的日常使用情境，以确保网站的用户界面能够运转良好。

在更新全面付诸实践之前，新的代码将首先被推送到“a2”层，也就是由数台Facebook公共服务器组成的试点环境。在这个阶段的测试工作中，会有一些随机Facebook参与到更新中来。尽管参与者的数量在Facebook全局用户群体中只占极小的比例，但技术人员仍然能从整个更新流程中发现潜在问题并及时加以修复。

预检流程

Facebook利用自己的内部多人在线聊天系统（IRC）服务器保持企业中的交流通畅。大多数企业的工程人员在工作强度较大时，交流通道都显得比较冷清。但根据Rossi的说法，Facebook公司在正常运作状态下，每天会有约700名员工保持在线沟通。工具开发人员专门为IRC打造了几种业务助手软件，能够将IRC中的各类功能与Facebook开发与部署工作流程紧密结合，进而发挥巨大的辅助作用。

在新一轮升级补丁即将上线之前，Rossi会在IRC系统中启动一套检测程序。在此次更新活动中提交过代码的开发人员都将收到通知，并加入频道以共同关注更新过程。整从此更新流程将在大家的协同监控之下试作一次，当确认一切正常后才会进入实际部署阶段。

如果某位开发人员在几分钟之后仍然没有做出协作回应，Rossi能够利用助手通过多种不同的通讯渠道对该开发人员发出提醒，其中包括电子邮件通知以及短信提示。正如Rossi在与我的交谈中所强调的，他希望部署更新的时候所有与之相关的开发人员都能在场监督并发表意见。

在Facebook公司内部存在着这样一种优秀的开发文化，大家都认为开发人员应该为自己编写的代码负责到底，直到这些成果顺利应用于产品之中。这一理念的实际体现就是“DevOps”活动，这种促进开发、技术运营及质量保障部门间沟通的方案有效消除了各团队之间的沟通障碍，并最终保证了项目的成功运转。

如果Facebook网站在实际更新过程中出现问题，编写相关代码的开发人员会立即得到提示，并马上投入到修复工作中去。

“在Facebook公司内部存在着这样一种优秀的开发文化，大家都认为开发人员应该为自己编写的代码负责到底。”


实际部署

Rossi在Facebook公司中的工作台由以下设备构成：一台30英寸戴尔显示器、一台Mac笔记本电脑以及一台分屏显示器。上周二，我花了一整天时间观察Rossi的日常工作内容，发现他的大部分工作都是在浏览器以及终端窗口中完成的。在准备部署更新之前，他在终端窗口发出指令，正式启动本次升级流程。

我们一同关注着Facebook网络系统监控工具所显示出的各项状态指标。网页的主体内容是个大大的进度条，标明企业内部已经成功完成二进制文件更新的服务器所占的百分比。随着更新的自动部署，进度条也在不断向终点推进。过程中，进度条左端出现了窄窄的红色提示条，意味着新版本在更新时发生错误的系统比例。

Rossi告诉我，这种系统更新失败的情况经常发生。在部署过程中，升级失败往往是由硬件问题所引发。举例来说，如果某台服务器的存储容易不足或者运行种子文件时遭遇网络问题，那么更新很可能无法完成。不过出错的服务器数量一般都很小，只需简单调整即可恢复正常，几乎不会惹出什么大麻烦。

尽管软件的部署对象是服务器，但Rossi告诉我Facebook的架构仍然会对更新过程产生一些独特的影响。Facebook在设计之初要求用户会话能够不依赖于任何特定的服务器设备，以分布式程度极高的无地区差形式进行运作。也就是说，Facebook基础设施中的任意一台服务器都能够处理任何给定的页面操作请求。

这种方式为全局系统提供了异乎寻常的弹性。当Facebook执行更新时，工作人员不必担心用户会话的状态会受到干扰或进行迁移。部署系统会在服务器端分批对Facebook执行流程加以重启，这样一来整个更新过程就能够以无缝化形式进行。无论是已经完成更新的还是仍然运行着旧版本系统的服务器，都能够继续处理接收到的用户页面请求，而与此同时企业基础设施的全面更新也在有条不紊地进行当中。

Facebook在更新与正常业务同时运转的情况下，系统设施将几乎处于满负荷状态。通常情况下，Facebook典型更新在部署中不需要预设停机时间，也绝不会引发任何形式的网站服务中断现象。Rossi指出，无停机更新流程是Facebook交付工作策略中的一项原则性要求。他为此感到自豪，并认为这是对网络软件工程工作优秀与否的一种检验。

事后检查

更新流程彻底结束之后，Rossi还需要做进一步审查，以确保系统变更没有对任何层面的原有内容造成破坏。他的团队为此专门打造了一套先进的分析工具，其作用是追踪Facebook网站的各项运行状态。工具的主仪表板上的线形图显示出各检测指标的变化情况，包括流量、资源消耗、产品独立组件故障率以及其它各种重要数据。

关注这些系统状态的浮动与走势，能够有效帮助工程人员辨别并修正系统中出现的问题。在故障发生之初，技术人员能够快速将当前数据与历史记录进行比照，并轻松准确地查明问题出在哪里。交付工程团队及其它Facebook工程小组会在更新结束后继续严密留意网站的运行状态，以确保一切项目及功能仍然运转良好。

一旦发现问题，例如系统中的某部分出现不合理的高故障率，那么企业中的工程师们将立即开始对错误日志进行深入分析，以找出问题发生的根源。Facebook所使用的内部工具非常犀利，在它的帮助下技术人员可以很轻松地观察并分析日志内容，并将结论与代码变更及特定错误提示相结合，最终拿出一套最为简洁高效的修复方案。

Facebook所使用的内部监控工具能够追踪大量数据源，甚至连与Facebook相关的tweet消息也涵盖在内。通过收集与汇总，该工具将分析结果以单独的走势曲线图进行表示，直观展现了网络用户对Facebook正面与负面评价的所占比例及变化。这一点非常重要，因为当我们在某种社交网络中遭遇技术缺陷或应用故障后，很可能会在其它网站上大肆抱怨以发泄怒气。对这类内容保持关注，就能帮助Facebook的技术人员迅速掌握那些可能被自己忽略掉的系统故障。

根据我的观察，当天的更新流程非常顺畅，没有出现任何技术问题或系统故障。日志消息的图表中曾经显示某个系统组件出现了小小的负载高峰，但通过Rossi及其团队的及时追踪及排查后，发现一切都属于正常现象。


Facebook公司交付工程团队在庆祝“一周一度”的更新成功

回档是失败者的行为

尽管在我的采访过程中并没有出现什么乱子，但Rossi还是非常热心地满足了我的好奇心。这个问题其实也一直在困扰着我：一旦更新过程发生故障，Facebook会怎样处理？他的回答是，如果在更新结束后有一大堆错误暴露出来，交付工程团队将与相关开发人员通力合作，力争在最短的时间内解决这一问题。当修复方案准备就绪，Rossi的团队将立即将其投付部署，并组织新一轮更新。

当某些错误太过严重时，快速修复几乎是不可能完成的任务。因此我问他此前有没有将网站恢复到旧有版本的经历。但他的回应斩钉截铁：“回档是失败者的行为！“

不过他又微笑着补充道，事实上他确实也执行过系统回档。Facebook拥有一套合理的机制，能够快速高效地将系统恢复到上一个版本，但他们只将此作为最后一项保障性手段使用。每台服务器中都保存着上一个版本的二进制文件，并能够在绝对必要的情况下立刻进行切换。

他告诉我，对于Facebook这样的大型社交网站而言，进行系统回档就像拉下火车上的紧急刹车一样；这么做并不可取，因此除非别无选择，否则他们绝对不会尝试。在他就职于Facebook的数年中，系统回档的情况也只碰上过几次。

Facebook的测试机制以及开发人员问责理念有效防止了代码编写工作中出现严重错误的机率。当开发人员的代码破坏了网站架构时，他们不仅需要立即投入修复工作，还必须承担绩效评估及人事变动等层面的惩罚。Facebook公司中的代码归属与开发人员紧密相联，因此根本不用指望在捅出娄子之后仍然高枕无忧。

该公司所使用的内部工具具备一种标志性的Facebook式灵感，而Rossi也对这种评估机制赞不绝口。这是一种评分工具，它赋予了Facebook公司中每位员工一定的“karma”值，这一佛教用语通俗一点来说可以看作是“善恶值”。善恶值与代码审查系统直接挂钩，每位开发人员在网页仪表板中都拥有自己的状态栏，Rossi可以通过点击栏中的“顶”或“踩”图标来提升或降低对应员工的善恶值属性。


在Rossi的工具中，表示“顶”的功能图标与Facebook社交网站中的那个完全一致。而表示“踩”的图标则正好是把“顶”的图形上下倒置。Rossi不无得意地向我展示了他的图标，并开玩笑说他是世界上惟一一个能使用Facebook式“踩”图标的家伙。

善恶值的设定能够帮助Facebook公司时刻掌握员工的工作状态，不过在代码审查过程中，评分机制同样能够帮上大忙。在对更新代码进行整体整合时，Rossi能够一目了然地发现哪些代码是由“善恶值”较低的技术人员所编写，这样他就会对这些代码格外关注，因为这帮家伙出错的潜在风险更高。

善恶值较低的员工可以通过自身的良好表现及工作态度逐渐提升这项评分——不过也有些人冥顽不灵，他们居然打算通过给Rossi带小点心的方式让他放自己一马。不过最令人惊讶的是，Rossi真的认同了这一做法。他告诉我，酒和蛋糕是员工恢复善恶值的首选礼品。说到这里，他又指了指交付工程团队办公室中那令人印象深刻的酒水储备：其中很大一部分就来自犯了错的开发人员。

Facebook公司交付工程部门中的Hotfix吧——以酒补过，原来这才是hotfix的真正含义

“每台服务器中都保存着上一个版本的二进制文件，并能够在绝对必要的情况下立刻进行切换。”


发展前景

我与Rossi探讨了他对于发展前景，尤其是Facebook的部署策略在企业技术基础设施发生变化之后的预期走势。他认为，随着时间的推移，他的团队在工作效率方面将进一步提高：准备过程、构建工作以及部署耗时等项目都还有潜力可挖，到时候整套更新任务可能几分钟就能搞定。

目前Facebook最重视的开发工作之一是推出一个能够取代Hip H o p转译器的新型后备项目。Facebook的开发人员正在创建自己独有的字节码格式及自定义运行环境，他们将其称为HipHop虚拟机，并希望它能成为支持Facebook运行的下一代平台。这一项目完成之后，该企业将能够把PHP源代码编译成能够为虚拟机直接运行的字节码。

如此一来，托管代码模式将更接近于Java及.NET，这样的进展能够让Facebook在保证代码一致性的前提下进一步提高系统灵活性。抛开其它各类优势不谈，Rossi告诉我这种态势将对现有部署流程产生重大影响。过去每一次更新都必须在所有服务器上传输1.5GB体积的二进制代码库，而未来他们只将与修改内容相关的字节码发出即可完成更新。Facebook网站甚至有能力将更新字节码与正处于运行状态的应用程序直接拼接，这样连进程都不必重新启动了。

一旦上述理想能够成为现实，整个大规模更新流程将能够在数分钟内完成，而Facebook也就可以借此彻底抛弃以往的更新时间表，真正按照开发思路将增量部署纳入变更模式之中。在这种情况下，企业开发人员则获得史无前例的高度敏捷性。

在周二例行的关键性更新结束之后，Rossi和他的团队开始对系统加以分析，以确保更新工作没有引发任何问题。当一切圆满结束之后，他们在hotfix吧举杯畅饮以示庆祝。

欢乐的时光总是过得特别快，在结束了一天的采访、再次漫步在Facebook园区的黑客之路上时，我不仅慨叹默默无闻的“交付工程团队”在扶持Facebook顺利发展的道路上起到了如此巨大的作用。

Facebook尽心竭力所打造出的社交平台，让我们每一位普通使用者得以在其中分享过往阅历、记录当年点滴，这不禁令人心生景仰。而在这喧闹繁华的平台背后，却有着这样一群从未出现在灯光下的技术人员。他们拥有强大的知识背景，创造着与大多数人不一样的奋斗故事。希望大家记得，正是由于这些个性鲜明、可敬可爱的人们的存在，Facebook才能始终光辉耀眼、独领风骚。 ■

原文：http://arstechnica.com/business/news/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering.ars/译文：http://os.51cto.com/art/201204/328615.htm

“Facebook的开发人员正在创建自己独有的字节码格式及自定义运行环境，他们将其称为HipHop虚拟机，并希望它能成为支持Fa c e b o o k运行的下一代平台。”

http://arstechnica.com/business/news/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering.ars/


16 技术分享 Linux运维趋势 2012年5月号总第19期

Django 托管在 Github 上的实践

文／ Perchouli

Django1.4上个月发布了，有些模块换了名字，加密方式也变了，最明显的变动是目录的组织方式，manager.py和其他配置文件分开存放。这些改动导致之前的目录组织方案将不再适用。所以整理一下1.3之前在Github上的实践，今后开发的新项目再转到1.4。

requirements.txt, local_settings.py

把Django项目托管到Github上，README是给不熟悉项目的人看的，未必得能给自己省多少力气。但写requirements.txt绝对是双赢。Django项目肯定会用到一些模块(至少得装Django…)，用一个txt文件列出所有会用到的模块，以换行分割：

Django==1.3.1 django-notification PIL simplejson

在部署的时候，直接使用

pip -r install requirements.txt

就可以把需要的模块都安装上了。

local_settings.py主要是两种用途，一是用来存储一些个人设置，比如开发环境和生产环境中不同的static文件夹设置；二是存放一些不适合公开放在github上的信息，比如数据库密码。编辑settings.py，加入下面这段代码到文件底部，在加载settings.py时会检查是否存在local_settings.py，如果存在则载入：

git的分支功能很强大，所以也很容易导致混乱。在github能看到的中心版本库origin，默认能看到主分支master。其他分支被收在下拉列表里。

通用的原则是：branch用来区分feature，tag用来区分版本。所以如果每个开发者在github和本地都建一个以自己的名字命名的branch，就违背了这个原则，而且开发者超过5个branch列表就会变得很难看，merge也麻烦大。

目前尝试较好的方案是：Github上是两个branch——master和dev，开发者统一使用dev分支进行开发，代码也都提交到dev分支。需要部署的时候把代码merge到master，用master分支进行部署。本地至少是master和dev两个分支。我就是一直在dev分支上开发，出现严重错误直接reset -hard把之前写的代码全部删掉。也有代码写得很谨慎的，会新开一个分支，完成之后再merge。在本地要怎么建分支主要看个人习惯，没必要死规定。

Deploy

既然代码托管在Github上，最简单的方式自然是在服务器上git clone一份readonly的代码，然后将其部署。实际项目中表现最好的是Nginx + uwsgi的配置方式，百万级PV仍然表现良好，相应的配置方法网上都有。如果是一个每天pv不超过4000的网站——更大的我没测试过，有相关数据欢迎补充——用测试服务器跑就可以了，nginx配置文件如下页所示。

try: execfile(os.path.join(PROJECT_ROOT, ‘local_settings.py’)) except IOError: pass Branch

技术分享


server { listen 80; server_name .dmyz.org; access_log off; location / { proxy_pass http://127.0.0.1:8010/; proxy_buffer_size 8k; client_max_body_size 25m; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffers 8 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; proxy_headers_hash_bucket_size 128; proxy_headers_hash_max_size 512; proxy_set_header X-Real-IP $remote_addr; } }

如果要换成uwsgi的时候，把proxy_pass改成uwsgi_pass就可以了，测试服务器功能很弱，不能多线程，控制超时，所以尽快更换过来比较好。

Update

现在服务器上是master分支，本地是用来开发的dev分支，和默认的master分支，在dev上开发，代码更新到github上，确认没有问题，merge并提交到master分支。这时候最好是服务器能自动知道master分支有更新了，自动 p u l l 代码。github提供了很方便的接口用来调用数据，以下是可运行的例子，在服务器上用cron运行或者是django-celery来跑

#通过github的api获得当前github上最新的sha

response = urllib2.urlopen(‘https://api.github.com/repos/github_user/github_repo/commits’).read()

json_data = json.loads(response)

remote_sha = json_data[0][‘sha’]

#如果不相等，用git pull命令更新代码

if not local_sha == remote_sha: subprocess.Popen([‘git’, ‘pull’]) else: print ‘Already the latest’ Reload

说了代码更新，顺带说一下重新加载代码的问题。如果是直接用Django的测试服务器，会自动重启；如果是用uwsgi，需要进行额外的设置，但这和Github没太大关系，就不列在这篇文章里了。 ■

都可以：

# -*- coding: utf-8 -*- import urllib2 import json import subprocess

#通过git log命令获得最新的sha

run1 = subprocess.Popen([‘git’, ‘log’, ‘-1’], stdout=subprocess.PIPE)

run2 = subprocess.Popen([“grep”, “commit”], stdin=run1.stdout, stdout = subprocess.PIPE)

commit, error = run2.communicate()

local_sha = str(commit).rstrip(‘\n’).split(‘ ‘)[-1]

原文： http://dmyz.org/archives/381

http://dmyz.org/archives/381


/dev/null 2>&1 详解文／南非蚂蚁

shell中可能经常能看到：>/dev/null 2>&1

命令的结果可以通过%>的形式来定义输出

分解这个组合：“>/dev/null 2>&1” 为五部分。

1：> 代表重定向到哪里，例如：ec h o “123” > /home/123.txt

2：/dev/null 代表空设备文件

3：2> 表示stderr标准错误

4：& 表示等同于的意思，2>&1，表示2的输出重定向等同于1

5：1 表示stdout标准输出，系统默认值是1，所以”>/dev/null”等同于 “1>/dev/null”

因此，>/dev/null 2>&1也可以写成“1> /dev/null 2> &1”

那么本文标题的语句执行过程为：

1>/dev/null ：首先表示标准输出重定向到空设备文件，也就是不输出任何信息到终端，说白了就是不显示任何信息。

2>&1 ：接着，标准错误输出重定向到标准输出，因为之前标准输出已经重定向到了空设备文件，所以标准错误输出也重定向到空设备文件。

说清楚了吗，大家理解下吧！

顺便对比述说下这么用的好处！

最常用的方式有：

command > file 2>file 与command > file 2>&1

它们有什么不同的地方吗？

首先command > file 2>file 的意思是将命令所产生的标准输出信息，和错误的输出信息送到file 中。command > file 2>file 这样的写法,stdout和stderr都直接送到file中, file会被打开两次,这样stdout和stderr会互相覆盖,这样写相当使用了FD1和FD2两个同时去抢占file 的管道。

而command >file 2>&1 这条命令就将stdout直接送向file，stderr 继承了FD1管道后，再被送往file。此时，file 只被打开了一次,也只使用了一个管道FD1，它包括了stdout和stderr的内容。

从IO效率上，前一条命令的效率要比后面一条的命令效率要低，所以在编写shell脚本的时候，较多的时候我们会command > file 2>&1 这样的写法。 ■

原文： http://www.ixdba.net/a/os/linux/2010/0422/35.html

http://www.ixdba.net/a/os/linux/2010/0422/35.html


Shell脚本自动记录登陆后的IP地址和历史记录

文／ Trespassers

今天一台线上的服务器不知道被哪个活宝执行了chmod -R 700 /home，造成了文件权限不对，密钥认证就读不到密钥了，所有人账户都登陆不上服务器了。排查了一下原因，排除了安全问题。那剩下的就是同事的误操作了。但是！ chmod -R 执行这个可是很让人怀疑的！于是报着试一试的心态去last，然后history。其实这时候通过查看历史记录查是没有什么意义了，人执行了命令之后肯定history -c 了。果然，全部查完了，依然不知道没有查出来是谁，有几个人历史命令就几条，这种也没法问，问也白问。

算了，这次反正没有丢什么重要的数据，服务器也没什么事情。饶恕了这个大神吧。但是，万一下次又有人误操作了怎么办，有一天因为某人误操作了删除了重要的数据怎么办..

现在从两个方面入手，第一服务器安装第三方记录工具，可以记录登陆的每个用户操作的日志，第二结合行政手段，最好有相关的规章制度，如果你是运维部的老大，可以定下。有奖有法。起到一个警示的作用。

查阅了下相关资料，还是下面这个方法好：

在/etc/profile中写一个shell脚

本来记录登陆后的IP地址和某用户名所操作的历史记录

PS1=”`whoami`@`hostname`:”’[$PWD]’

(Linux系统提示符是用系统变量PS1来定义的)

history USER_IP=`who -u am i 2>/dev/null| awk ‘{print $NF}’|sed -e ‘s/[()]//g’`

(who -u am i 会显示系统中登陆进来的用户及登陆从哪个IP登陆进来的，这里后面过滤了就取值一个登陆进来的IP)

if [ “$USER_IP” = “” ] then USER_IP=`hostname` fi if [ ! -d /tmp/ruige ] then mkdir /tmp/ruige chmod 777 /tmp/ruige fi if [ ! -d /tmp/ruige/${LOGNAME} ] then mkdir /tmp/ruige/${LOGNAME} chmod 300 /tmp/ruige/${LOGNAME} fi

export HISTSIZE=4096 DT=`date ‘+%Y:%m:%d %r’` export HISTFILE=”/tmp/ruige/${LOGNAME}/${USER_IP} ruige.$DT” chmod 600 /tmp ruige/${LOGNAME}/*ruige* 2>/dev/null

以上脚本会在系统的/tmp新建个ruige目录，在目录中记录了所有的登陆过系统的用户和IP地址，还有历史命令。我们还可以用这个方法来监测系统的安全性。

注意：最好再给ruige这个目录加个t位：

chmod o+t ruige

补充：who am i和whoami的区别

login:root Password: $who am i root pts/0 2007-08-16 13:16 (:0.0) $whoami root

su tongrui #who am i root pts/0 007-08-16 13:16 (:0.0) #whoami tongrui ■

原文：http://ruilinux.blog.51cto.com/4265949/845405 。有删节。

http://ruilinux.blog.51cto.com/4265949/845405


批量下载Linux运维趋势引发的反思

文／煮酒品茶

无事闲逛的时候突然发现51CTO Linux运维趋势下载地址如下：

http://os.51cto.com/down/linuxops/51CTO_linuxops_issue1.pdf

一想，构造了个

http://os.51cto.com/down/linuxops/51CTO_linuxops_issue2.pdf

可以下载，于是就有此脚本的前提。

思路：循环后用wget批量下载。

#vim 51ctodown for((i=1;i<30;i++)) do wget http://os.51cto.com/down/linuxops/51CTO_linuxops_issue$i.pdf done #chmod +x 51ctodown #./51ctodown

不过，下载后发现文件名并不是我们想要的，故需要动手操作一下。

思路：文件名呈51CTO*.1.pdf 51CTO*.2.pdf ...方式，这个规律可找。那么我们要改完后的文件名如何来找呢？首先想到的是去官方找找有没有Linux运维趋势的目录，那样就非常简单了。

访问 http://os.51cto.com/art/201011/233915.htm 把发布通告给copy到一个文件中。命名为cc.html

以主题来查找标题并导出为cc1.html

#cat cc.html |grep 主题>cc1.html

把年份给去掉

#awk -F” ,” ‘{ print $2 $3 }’ ~/test/cc1.html>cc2.html

[root@localhost test]# cat cc2.html

《趋势》12期主题:服务器故障排除

《趋势》特刊主题:Linux开发 #这个删掉。

《趋势》第11期主题:iptables原理与常见应用场景

《趋势》第10期主题：日志分析技巧分享

《趋势》第9期主题：Puppet

《趋势》第8期主题：双机

《趋势》第7期主题：网站迁移

《趋势》第6期主题：备份

《趋势》第5期主题：内网开发环境

《趋势》第4期主题：性能瓶颈

《趋势》第3期主题：运维与开发

《趋势》第2期主题：可用性

《趋势》第1期主题：监控与报警

《趋势》第0期主题：运维自动化 #这个删掉。

把顺序给弄反过来，更符合我们的需求。

# tac cc2.html >cc3.html


Wget时就重命名：

for((i=1;i<30;i++)) do wget http://os.51cto.com/down/linuxops/51CTO_linuxops_issue$i.pdf mv 51CTO_linuxops_issue$i.pdf `sed -n “$i”p cc3.html`.pdf done

看张效果图吧：

本文只提供思路，实际操作过程很简单，高手勿笑。 ■

参考链接:(老男孩)http://oldboy.blog.51cto.com/2561410/711342/

# vim mvname

#!/bin/bash

for((i=1;i<=13;i++))

do

mv 51CTO_linuxops_issue$i.pdf `sed -n “$i”p cc3.html`.pdf

done

[root@bogon cwtea]# chmod +x mvname

[root@bogon cwtea]# ./mvname

最终结果：（略）

在写重命名规则的时候，一直找问题。mv 51CTO_linuxops_issue$i.pdf `sed -n “$i”p cc3.html`.pdf 这一段弄的我想死的心都有，sed 后变量好像是固定的。-n ‘$ip’ -n “$ip” -n ‘$i’p 都不行，一直以为脚本出错，循环出错，最后一一排查，得出sed -n “$i”p filename 才完成，原来是sed后变量出错。所以在有问题的时候百度，以及找前辈们指导才是王道。

后来，dn833提供了一个建议：

“其实你wget的时候就能指定输出名的。”

dn833的建议非常好啊，越前越好，脚本能简就简。不过得先把目录给定义好才能够下载。适于自动化吧。

原文：http://cwtea.blog.51cto.com/4500217/845004 。内容有删减与修改。

“在有问题的时候百度，以及找前辈们指导才是王道。”

http://cwtea.blog.51cto.com/4500217/845004


警惕程序日志对性能的影响

文／杨文博（solrex）

做后台系统比做客户端软件的辛苦的地方，就是不能让程序轻易地挂掉。因为在生产环境中无法容易地复现或调试 bug，很多时候需要程序日志提供足够的信息，所以一个后台系统的程序员必须要明白该如何打日志（logging）。

很多语言都有自己现成的 logging 库，比如 Python 标准库中的 logging 模块，Apache 的 log4cxx(C++), log4j(Java)。如果你愿意找，很容易能找到基本满足自己需求的日志程序库。当然，自己实现一个也不是很困难。难点不在于写这些库，而是如何去使用它们。

大部分情况下，我们关注的都是日志的级别和内容。即哪些情况下，该打哪个级别的日志，日志语句中，该怎么写。

专题


原文：http://blog.solrex.org/articles/on-logging-performance.html

在程序开发的过程中，我们需要很多的日志协助分析程序问题；但在生产环境中，我们没有那么多的空间存储丰富的日志，而且日志量太大对于问题排查反而是累赘。有些人使用预处理解决这个问题，在 debug 版本和 release 版本中编译进不同的日志语句。这样能够解决一些问题，但却使得在生产环境中无法轻易地打印更多的日志。大部分人更接受的做法是，使用配置（参数）控制日志的打印级别，在需要更多日志的时候，可以随时打开它们。为了实现日志“少但是足够”的目标，开发人员必须明白日志信息的价值，即哪些日志应该属于哪个级别。

日志的作用是提供信息，但不同的日志语句，提供的信息量却是不一样的。有的日志里会写“Failed to get sth..”，但却忘记加上失败调用的返回值。同程序一样，日志语句中有的是变量（某个变量内容），有的是常量（提示信息）。常量你总能从程序源代码中获得，但变量不行。所以在一条日志中，信息量最大的是变量，是函数返回值/字符串内容/错误码，因而变量应该尽量放在靠前的位置。常量也不是一点价值没有，写得好的提示语句，会使问题一目了然，可以免去你到代码中grep，然后重读代码的麻烦。

上面这两点，几乎所有知道 logging 重要性的同学都会了解。但关于 logging 对性能的影响，很多人没有足够的警惕心。例如有人会在一个按行解析文件的函数中写下这样的日志：

乍一看，由于 log_trace 级别不高，在生产环境中肯定会关闭，那么这样做看起来对性能没太大影响。但实际上 log_trace 可能是这样实现的：

#define log_trace(fmt, arg...) \ xx_log(LVL_TRACE, “[%s:%d [time:%uus]” fmt, __FILE__, __LINE__,\ log_getussecond(), ## arg) #endif

可以看到 log_trace 宏中自动添加了很多信息，值得注意的是时间参数 log_getussecond()。大家都知道统计时间需要系统调用，那么无论 log_getussecond() 函数是如何实现的，它的代价肯定是高于一般的简单函数。

我们本以为 log_trace 在 LVL_TRACE 级别被关闭的情况下，消耗的代价仅仅是一个函数调用和分支判断，却没有发现宏参数中还隐藏着一个需要调用系统调用的函数。当文件不大是还算能够忍受，但当这个文件是一个数据库，扫描每一行都要执行两次 log_trace() 时，它对系统性能的影响就绝不可忽视了。

所以，最佳的做法还是，在性能攸关的代码中，使用可被预处理掉的 logging 语句，仅仅在 debug 发布中才能见到这些日志，release 版本中不把它们编译进来。

此外，上面这个 log_trace，是一个糟糕的设计。logging 模块只应该干 logging 的事情，开发人员需要时间统计时会自己完成。 ■

“在一条日志中，信息量最大的是变量，是函数返回值/字符串内容/错误码，因而变量应该尽量放在靠前的位置。”

int parseline(...) { log_trace(“Enter parseline with ...”); DO_SOMETHING; log_trace(“Exit parseline with ...”); return 0; }

http://blog.solrex.org/articles/on-logging-performance.html


一次博客的性能故障排查

文／BOYPT

Ubuntu 10.04 这个版本已经服役两年，虽说是LTS，但最近起发现已经有点力不从心，主要是ppa上一些比较重要的库，如PHP 5.3，ningx的团队已经停止维护，uwsgi则总是落后半年的样子。很大一个原因是这些包在新版的Ubuntu里面已经有官方维护，ppa的第三方维护会缺乏跟进。所以在一定意义上，可以宣布Ubuntu 10.04死亡了。

但Ubuntu的包维护策略就是那样，要么自己维护所有用到的包，要么每隔一段时间就跟着官方一次大升级。觉得不爽就干脆把VPS的系统也改成Archlinux。

现象

一番大迁移后所有的东西都正常上线，但直到一个多星期后的昨天晚上才注意到博客的性能问题。因为博客那里有nginx直接读取静态的缓冲机制，所以动态执行非常慢之前都没留意到。

把缓冲关闭就非常明显了，任何一次点击的页面都要10秒才能打开。

排查

引起应用缓慢的因素是非常多的，概括来说有两种：IO慢、运算慢。

运算慢是不大常见的，虽说PHP性能一直受到诟病。但如果是这个问题是很明显的，top里面php的子进程会占满CPU，高居不下。此前排查过一个drupal的站点，是因为前端模板的组件方式存在循环引用，用profile过程看，正则替换的regrex函数占了绝大多的CPU时间。

在SSH看到，打开页面的10秒内php-fpm的子进程基本没占CPU，排除这个可能。

IO慢就复杂了，每个组件都有IO，得先确定IO的范围。

首先想到是数据库Mysql，arch的包太新，有bug？linode主机的磁盘快挂了，磁盘很慢？这些都不好判断，确定这些得借助工具。

Profiling是追踪一个应用的运行流程，记录所有的函数调用栈、记录调用时间的过程，是追查性能问题的最佳帮手。Python里面是有个repoze.profile的wsgi中间件很方便进行排查，但我没做过完整PHP开发，就暂时不大清楚有什么方便的profile方案（以前弄过早忘了），但google一下还是有很多方案的，不过我首先想起newrelic的应用监控系统就提供了这个功能。

Newrelic针对WEB应用和服务器监控服务，其中的服务器监控是免费的，但对应用的监控只有14天试用；所以我赶紧重新申请个帐号，用来监控一下wordpress。安装好监控模块后，超过2s的响应会在他们的Transaction traces记录下来。


图表数据可以排除数据库问题，几十个数据库的操作都是在ms级别完成，而在apt-blog.net的耗时花了10秒。其实我一开始对这个报告也没看懂，newrelic的直观性还有待提高，其实在这里出现域名的意思是有网络请求，比如askimet的评论、插件的更新等都要和外部请求，这里就会出现域名。

而现在出现了自己博客的域名，那问题就是，程序里面某个地方需要请求自己的域名，可能是检查状态的操作，被卡住了，直到超时才返回。

本机程序访问不到本机，基本确定是iptables规则出问题了，在filter表的最后插入这样一句：

-A INPUT -j LOG

iptables的规则一般是，除非明文允许，否则拒绝，所以经过一系列的规则后如果还没有没ACCEPT的，在最后的都是被DROP了，把这句放最后可以看到究竟是什么包被DROP了。

查看/var/log/everything.log看到这样的记录：

Mar 31 03:17:32 (none) kernel: [17554800.765033] IN=lo OUT= MAC=00:00:00:00:00:0 0:00:00:00:00:00:00:08:00 SRC=106.187.36.50 DST=106.187.36.50 LEN=60 TOS=0x00 PR EC=0x00 TTL=64 ID=31529 DF PROTO=TCP SPT=45594 DPT=80 WINDOW=32792 RES=0x00 SYN URGP=0

这里透露了重要信息：

IN=lo SRC=106.187.36.50 DST=106.187.36.50

P H P确实有访问本地网络，送了给l o网卡，SRC和DST都是本地的公网地址。赶紧检查iptables的规则，果然没了对lo设备的允许规则。一般配置机器我都是用记录在自己的Wiki的iptables那套规则的。关于lo的这几句可能一时没仔细想其作用，迁移系统那天脑抽手贱就删掉了。

加入允许lo设备的这句：

-A INPUT -i lo -j ACCEPT

至此，问题解决。 ■

原文：http://apt-blog.net/trace_on_a_performace_problem

http://apt-blog.net/trace_on_a_performace_problem


三招解决MongoDB的磁盘IO问题

文／ nosqlfan

有点标题党的意思，不过下面三招确实比较实用，内容来自Conversocial公司的VP Colin Howe在London MongoDB用户组的一个分享。

申请：下面几点并非放四海皆准的法则，具体是否能够使用，还需要根据自己的应用场景和数据特点来决定。

1.使用组合式的大文档

我们知道MongoDB是一个文档数据库，其每一条记录都是一个JSON格式的文档。比如像下面的例子，每一天会生成一条这样的统计数据：

{ metric: “content_count”, client: 5, value: 51, date: ISODate(“2012-04-01 13:00”) } { metric: “content_count”, client: 5, value: 49, date: ISODate(“2012-04-02 13:00”) }

而如果采用组合式大文档的话，就可以这样将一个月的数据全部存到一条记录里：

{ metric: “content_count”, client: 5, month: “2012-04”, 1: 51, 2: 49, ... }

通过上面两种方式存储，预先一共存储大约7GB的数据（机器只有1.7GB的内存），测试读取一年信息，这二者的读性能差别很明显：

第一种: 1.6秒

第二种: 0.3秒

那么问题在哪里呢？

实际上原因是组合式的存储在读取数据的时候，可以读取更少的文档数量。而读取文档如果不能完全在内存中的话，其代价主要是被花在磁盘seek上，第一种存储方式在获取一年数据时，需要读取的文档数更多，所以磁盘seek的数量也越多。所以更慢。

实际上MongoDB的知名使用者foursquare就大量采用这种方式来提升读性能。见此

2.采用特殊的索引结构

我们知道，MongoDB和传统数据库一样，都是采用B树作为索引的数据结构。对于树形的索引来说，保存热数据使用到的索引在存储上越集中，索引浪费掉的内存也越小。所以我们对比下面两种索引结构：

db.metrics.ensureIndex({ metric: 1, client: 1, date: 1})

与

db.metrics.ensureIndex({ date: 1, metric: 1, client: 1 })

采用这两种不同的结构，在插入性能上的差别也很明显。

当采用第一种结构时，数据量在2千万以下时，能够基本保持10k/s 的插入速度，而当数据量再增大，其插入速度就会慢慢降低到2.5k/s，当数据量再增大时，其性能可能会更低。

而采用第二种结构时，插入速度能够基本稳定在10k/s。

其原因是第二种结构将date字段放在了索引的第一位，这样在构建索引时，新数据更新索引时，不是在中间去更新的，只是在索引的尾巴处进行修改。那些插入时间过早的索引在后续的插入操作中几乎不需要进行修改。而第一种情况下，由于date字段不在最前面，所以其索引更新经常是发生在树结构的中间，导致索引结构会经常进行大规模的变化。


3.预留空间

与第1点相同，这一点同样是考虑到传统机械硬盘的主要操作时间是花在磁盘seek操作上。

比如还是拿第1点中的例子来说，我们在插入数据的时候，预先将这一年的数据需要的空间都一次性插入。这能保证我们这一年12个月的数据是在一条记录中，是顺序存储在磁盘上的，那么在读取的时候，我们可能只需要一次对磁盘的顺序读操作就能够读到一年的数据，相比前面的12次读取来说，磁盘seek也只有一次。

原文：http://www.colinhowe.co.uk/2012/apr/26/mongodb-strategies-when-hitting-disk/译文：http://blog.nosqlfan.com/html/3925.html

db.metrics.insert([ { metric: ‘content_count’, client: 3, date: ‘2012-01’, 0: 0, 1: 0, 2: 0, ... } { .................................., date: ‘2012-02’, ... }) { .................................., date: ‘2012-03’, ... }) { .................................., date: ‘2012-04’, ... }) { .................................., date: ‘2012-05’, ... }) { .................................., date: ‘2012-06’, ... }) { .................................., date: ‘2012-07’, ... }) { .................................., date: ‘2012-08’, ... }) { .................................., date: ‘2012-09’, ... }) { .................................., date: ‘2012-10’, ... }) { .................................., date: ‘2012-11’, ... }) { .................................., date: ‘2012-12’, ... }) ])

结果：

如果不采用预留空间的方式，读取一年的记录需要62ms。

如果采用预留空间的方式，读取一年的记录只需要6.6ms。■

“组合式的存储在读取数据的时候，可以读取更少的文档数量。”

http://www.colinhowe.co.uk/2012/apr/26/mongodb-strategies-when-hitting-disk/

http://blog.nosqlfan.com/html/3925.html


MySQL数据库中order by的实现和 by rand() 的优化

文／丁奇

有同学上周问了个问题“MySQL数据库里面的order by rand()”是怎么实现的。我们今天来简单说说MySQL数据库里的order by。

几种order by的情况

乍一看这个问题好像有点复杂，我们从最简单的case开始看起。

用右边这个表来说明：(10w行数据)

1、最简单的order —— order by索引字段

见下图，从explain的结果来看（Extra列），这个语句并不作排序。因为字段a已经是有顺

序的。就是按照索引a的顺序依次读pk的值(在这里是隐藏的系统列)，一个个从聚簇索引的data中读入。

2、复杂一点 —— order by 非索引字段

见下图，这里Extra列显示一个Using filesort。这里的filesort并不是指字面上的“文

件排序”，说的就是与上面一种情况相比，在Server层作了排序。至于是否使用文件，取


决于排序过程中的内存是否足够，不够则需要临时文件。

并不到此为止，我们细细想一下，MySQL数据库server层要怎么作排序呢？

一个简单的想法是把MySQL数据库表数据都读到内存，然后排序。读到内存当然可以想怎么整就怎么整。但是这个做法很耗费内存。需要占用与表一样大小的内存。

另外一个做法，只读入字段b和其对应的主键id。可以想象为这两个字段构成的结构体，按照b的值作排序。排序完成后，按字段b的顺序依次取主键id，取得结果返回。

实际上第二种作法就是这个例子中的实际执行过程。存放用于排序的字段值的结构我们称为sort_keys。

至于order by b,c这样的语句，效果与order by b相同，可以简单理解为上面结构体多了一个字段。

Extra字段里面有一个Using temporary，也就是说用到了临时表。那么Using temporary的时候操作流程是怎样的呢？

a) 创建一个heap引擎的临时表，字段名为 ”” a b c d, 第一个字段为匿名;

b) 将表tb中的数据按行读入到临时表中，同时给第一字段填入一个随机实数(0,1);

c) 按照第一个字段排序，返回

d) 查询完成删除临时表

3、字段函数排序

见上图，有这的流程，这里就简单了，还是按顺序读入所有的字段b，只是sort_keys中存的是b的长度而已。

4、 Order by rand()

按照自然想法， order by rand() 也可以仿照上面描述的做法，对于每一行，将生成的rand()的值放入sort_keys里即可。但实际上上效果如下：

分析一下这个过程，由于把数据从InnoDB存储引擎表里面读入临时表，则InnoDB存储引擎表实际上也已经读入内存，在这个过程中，若不考虑内存不够时的写文件策略，则内存中有两份表的全拷贝；另外多了从内存中将数据一一拷贝到临时表的过程。

这个查询在我的测试环境中耗时2.41s（多次次执行，不计第一次加载数据的时间）。

order by rand()的改进

我们前面说过，实际上对于这种简单的order by rand() 的情况，也可以等同于按照非索引字段来处理。在sort_array 中存入随机值即可。

按照这个思路的patch在这里，效果如下图：

执行时间减少为1.89s，性能提升21%, 这个例子单行1k，单行越大提升效果越好。 ■

原文： http://dinglin.iteye.com/blog/1507941

http://dinglin.iteye.com/blog/1507941

30 观察思考 Linux运维趋势 2012年5月号总第19期

阿里巴巴集团去IOE运动的思考与总结

文／mysqlops

预计2012年5月7日，阿里巴巴集团将正式公布技术团队合并的事情，涉及的部门：阿里巴巴运维团队、阿里巴巴DBA团队、阿里巴巴平台技术部、大淘宝运维团队、大淘宝DBA团队、大淘宝核心系统部、阿里云计算运维团队、阿里云计算DBA团队和阿里巴巴集团安全团队，从一些可以猜测到的信息分析，上述技术团队合并之后，大淘宝的员工将成为相关技术团队的掌舵者。去IOE政治运动是阿里巴巴集团首席架构师某博士主导的，阿里巴巴和淘宝的技术团队内部非常有影响力的XX负责执行，合并之后阿里巴巴集团内部所有子公司去IOE运动，将继续深化。个人就淘宝、阿里巴巴和支付宝去IOE事件，以局外人的角度进行利弊分析，希望能达到给明白真相和不明白真相群众，一个合情合理中立的分析。

淘宝和阿里巴巴去Oracle化事件引发数据库技术人员大讨论一文，只是把对阿里巴巴、淘宝等子公司内部非常熟悉的人士观点和建议分别整理出来，以及还有部分外部人士的猜测和分析，本篇文章我们从几个不同的角度综合分析阐述去IOE事件对阿里巴巴、淘宝等公司的内部DBA团队价值和意义，对阿里巴巴、淘宝等公司的业务和成本影响，对互联网行业的DBA从业者的影响…

(一) 去IOE事件中的IOE名词解释

(1).IOE事件中的I是代表IBM的缩写，也即去IBM的存储设备和小型机，主要是小型机，阿里巴巴、淘宝和支付宝主要是使用了IBM的小型机，IBM存储设备相对较少；

(2).IOE 事件中的O是代表Oracle的缩写，也即去处Oracle数据库，采用MySQL和Hadoop替代的解决方案，Oracle RAC将会被Hadoop集群替代，其阿里巴巴B2B使用的GreenPlum集群，也将会在阿里巴巴集团完成运维团队和DBA团队合并之后，采用 Hadoop集群解决方案替代；

(3).IOE事件中的E是代表EMC2,阿里巴巴B2B、淘宝和支付宝都是用大量EMC2的存储设备，也有少量DELL的存储设备，主要是EMC2,的存储设备性价比高；

(4).阿里巴巴集团内部最早进行MySQL数据库替代Oracle数据库支持数据服务的子公司，是阿里巴巴B2B用PC Server替代EMC2,存储设备，替代IBM小型机。不过替换节凑是被合理控制的，因多方面的原因内部也没有那么雄壮的决心。后来，淘宝也开始进行MySQL数据库的应用摸索和推广，并且高调宣传去IOE事件，最后造成网络上满城风雨；

观察思考


(二) 去IOE对淘宝、阿里巴巴B2B和支付宝等公司的价值

阿里巴巴集团与甲骨文公司购买的Oracle数据库是三年无限制性的License，总销价是三年X千万人民币（备注：不能告诉大家具体多少钱，属于商业机密，望理解！），这部分的开销对整个阿里巴巴集团而言并不算什么，花费最大地方是Oracle数据库的座驾，也即主要是IBM小型机和EMC2,存储设备的购买费用和保修费用。

随着淘宝、支付宝和阿里巴巴B2B的注册用户数激增，用户产生的数据也越来越多，即使采用冷热隔离的方式也解决不了大容量数据且大并发的难题，淘宝启用了全亚洲最大的Oracle RAC集群，阿里巴巴B2B中文站的数据量也因数据量大和业务要求，每年早上08:00—09:30之间CPU保持98%的使用率，LOAD也超高，即使更换存储设备不久也会再次出现这样的状况。互联网行业公司迅速发展非常快，集中式数据库系统会逐渐成为业务的瓶颈，不得不面临又喜又忧的事情花费重金升级硬件，这在企业高速崛起的时候，可能不太会在意成本，若是企业占有市场份额足够大、步入平稳发展阶段或企业资金出现问题的时候，就不得不考虑企业的成本，那么就不得不考虑采用满足企业业务发展需求，企业只需要合理地投入资金，就不得不考虑更加省钱的数据库软硬件解决方案。

大淘宝、阿里巴巴B2B和支付宝等公司，98%以上的软件系统和业务都是采用Oracle数据库提供数据服务，电子商务领域阿里巴巴集团旗下公司拥有的总数据量和用户量是其他任何公司无法比喻的，DBA团队面临的压力盒挑战也是其他公司无法比喻的，肯定要比联网其他公司更早关注此方面的资金需求和业务双重压力。

阿里巴巴集团使用License最多的子公司是大淘宝，2010年及之前，还高调地要部署更多的Oracle RAC数据库集群，但是在阿里巴巴B2B将中文站压力和数据容量最大的Offer数据库，成功从Oracle数据库+IBM小型机+EMC2,存储设备,迁移到MySQL数据库+PC Server的模式，以及大淘宝核心系统部门招聘到@淘宝褚霸、@淘宝丁奇等能修改MySQL源码和Hbase源码，其他产品线使用MySQL数据库提供服务，也使大淘宝的MySQL DBA的经验和技术大幅提高，大淘宝也就有能力把产品线的Oracle数据库迁移到MySQL数据库提供服务，采用Oracle数据库支持的数据分析业务则采用Hadoop集群替代，这是给核心系统部和DBA团队建功立业的大好时机，同时能解决大淘宝业务系统的压力和瓶颈，也能帮助大淘宝降低资金投入。搭配开发完善的自动化系统，可以大大简化数据库的管理成本，也能减少DBA团队的工作量。

阿里巴巴、淘宝和支付宝都曾尝试，将Oracle数据库的座驾AIX系统+ IBM小型机+EMC2，迁移到Linux系统+PC Server的模式。若是对Oracle数据库不拆分的话，PC Server根本无法承受这样的负载；若是对Oracle数据库拆分，将需要增加购买大量的License；故不得不考虑将业务系统的Oracle数据库迁移到开源MySQL数据库和Hadoop平台上（注释：这2种开源产品能满足业务需求，以及相对其他开源产品更稳定和成熟）。

非常遗憾的是，阿里巴巴集团首席架构师王坚推行的是全面去商业数据库产品计划，也即整个阿里巴巴集团，可能除支付宝少数业务的数据库继续采用Oracle数据库之外，其他的一切都将转换成MySQL数据库，为此可能导致阿里巴巴DBA团队、大淘宝DBA团队、支付宝DBA团队等，在Oracle数据库领域积攒十年的架构设计和运维维护经验，将瞬间付之东流，同时这些DBA团队的Oracle DBA也将会有不少人员选择离开，否则只能转行为MySQL DBA。

“搭配开发完善的自动化系统，可以大大简化数据库的管理成本，也能减少DBA团队的工作量。”


大淘宝DBA团队、阿里巴巴DBA团队、支付宝DBA团队和阿里云计算DBA团队总共拥有的MySQL DBA人数，不会超过15人，而Oracle DBA有80人以上，其中MySQL DBA团队真正能干活的DBA不会超过X个人，MySQL数据库在阿里巴巴真正支持业务发展的时间不超过3年（注释：淘宝成立初期采用MySQL数据库，能力的问题而不得不迁移到Oracle数据库平台；阿里巴巴B2B在2009年之前，也是少数边缘业务从Oracle数据库迁移到MySQL数据库平台）。多数是Oracle DBA转行为MySQL DBA的兄弟，他们在Oracle数据库方面确实经验丰富和能力超强，但是MySQL数据库方面就不多加评论…

小结：

一直为MySQL社区的发展与壮大而努力，作为技术人员要说真话和大实话，不能因个人感情而做事情。个人认为阿里巴巴集团去IOE是不得不要做的事情，但不是把所有的Oracle数据库都迁移到MySQL数据库或Hadoop平台，而应该是对业务系统有选择地进行，以及迁移的步调要合理地控制，不宜过快过急，需要等待MySQL数据库DBA团队的壮大，技术与经验的积累。否则，可能出现迁移过去之后不久，发现对业务发展和支持出现严重的问题，大淘宝内部的信息分析，他们已经基本度过危险的阶段，也有很多遇难杂症，但是支付宝的业务具有特殊性，要比淘宝的业务系统要求更高，恐怕是一个非常大的障碍。

阿里巴巴集团高调向外界传递去Oracle数据库信息之后，新的Oracle数据库License谈判将会很变得艰难，甲骨文公司本来是把把阿里巴巴、淘宝和支付宝等公司作为中国标杆用户宣传，现在公开大规模地去Oracle数据库，可能会得到甲骨文公司的报复，为此可能要偿付更加昂贵的License费用。对于阿里巴巴价值观“拥抱变化”，是无处不体现，但是要合理地使用，不要被某些人利用搞成政治运动，而影响企业的稳定与发展。

(三) 去IOE对淘宝、阿里巴巴B2B和支付宝等公司的DBA团队影响

大淘宝是去IOE最迅速最彻底的公司，相关技术人员也将会得到更多的晋升和加薪机会，阿里巴巴B2B DBA团队很早进行的部分业务系统去IOE，使得相关人员受益（注释：也包括我个人，阿里巴巴B2B对MySQL DBA的渴望而有机会加盟，机缘巧合是MySQL数据库成功使用之后离开了），而支付宝是去IOE进展最慢的公司，为此高层不得不选择派遣相关人员，加速支付宝公司去IOE。

阿里巴巴集团最后可能保留少数业务产品线，继续使用Oracle数据库平台提供数据服务，以及MySQL数据库的自动化完成之后，将导致阿里巴巴集团DBA团队出现资源严重富余，Oracle数据库迁移MySQL数据库过程与完成之后，将会出现DBA人员的流失，这对阿里巴巴集权的DBA团队而言是一种损失，往往选择离开的Oracle DBA，越是优秀和有成长潜力的，可能早就更多DBA人员处于混日子的状态。

去IOE事件对MySQL团队和核心系统部门的发展，是非常有利和促进作用。越来越多的业务系统和核心系统，采用MySQL数据库提供数据服务，MySQL DBA面临的挑战与压力将会越来越大，DBA团队的自动化水平能力也将会迅速得到提高，否则无法管理规模庞大的MySQL数据库集群和Hadoop集群。

整个阿里巴巴集团能读懂、编写和优化MySQL源码的DBA或开发人员，总数不会超过X个人，这对阿里巴巴集团去IOE也是一项挑战，毕竟开源数据库产品没有商业数据库产品那样经过严格的测试流程而稳定，购买甲骨文官方提供的MySQL服务，绝对不是淘宝、阿里巴巴和支付宝DBA团队的行事风格，一定会想办法自己修改和优化MySQL源码，相信阿里巴巴集团会投入更多的资源引进相关的技术人才，这对MySQL团队的技术提高也非常有帮助。 ■

原文：http://www.mysqlops.com/2012/05/07/alibaba-ioe.html

“大淘宝是去IOE最迅速最彻底的公司，相关技术人员也将会得到更多的晋升和加薪机会。”

http://www.mysqlops.com/2012/05/07/alibaba-ioe.html


挑战无处不在文／陈皓

面试过一些应聘者，当我问到为什么换工作的时候，他们都会告诉我，现在的工作没有挑战，无聊，所以想换一个有挑战的工作。于是我问了一下他的工作情况，发现那些有挑战的东西他还没有搞懂。我总是为有这样的认识的朋友感到惋惜，因为我总是认为有挑战的东西无处不在啊，不能因为工作上没有，自己就放纵了自己。比如，面试过一个做地图的工程师，他的工作是做计算地图上任意两点的最短或最优路径的一部分功能。我觉得这个事很有挑战，也有难度，应聘者说，没什么挑战，因为他做的东西只是调用相关的算法库。他在这个项目干了2年了，当我问他有没有看过算法库，知不知道地图是怎么存储的？他却告诉我，因为没有去做，所以就没有去了解，等做的时候再了解（我希望有这样想法的人都去看看程序员的谎谬之言还是至理名言？）。这样的例子很多，很多应聘者在面试中不能和我一起解决某个问题的时候，比如：OOD，数据库设计，系统设计，等，他们都会告诉我，不好意思，因为没有做过相关的事情，所以就不懂了，所以，他需要一个像我们这样的项目来学习和锻炼。我并不要求你能解决你所不擅长的问题，但毕竟数据库，OO，系统设计都是软件开发的基础知识，多少要懂一些吧。

但另外一方面，他们都会告诉我他们对技术充满和热情和兴趣，有着很强的学习能力，也有很能吃苦的态度。这也许是某面试宝典上看来的，面经上可能都会说，如果面对不能作答问题，可以说一下自己的态度和决心。可惜的是，我并不这么想的，我在我的两篇关于招聘的文章里（我是怎么招聘程序员的，再谈我是怎么招聘程序员的）都说过一些我对如何择人的想法。这里重点说明一下其中两个观点：

关于热情和态度，说白了就是不要给自己找借口。比如：“工作忙事多没时间学所以可以不懂”，“工作中没用到所以可以不懂”，“工作没有挑战，一直没有遇到合适的项目”等等。时间可以挤，工作之余可以学，随时随地去思考，挑战是无处不在的…… 想想那些你有热情的事，你会发现，几乎没有什么可以阻止你去做那些事。

对于某些事情，如果以前没有在你身上发生过，那么这个事情在未来也不会发生。如果你以前没有对你接触过的东西去学习，去深挖，去思考，去改善，那么我不会相信你会在未来面对新的东西的时候也会有这样的态度；如果你以前没有用业余时间学习一些项目之外的东西，那么我也不会相信你会在未来会这样做；如果你以前没有把你的热情和态度转换成你的知识，经验和成果，那么我也不会相信你会在未来能做到。

这两个观点可能太刻薄了，但是，当我回想我自己的经历的时候，观察程序员的成长过程的时候，我发现，优秀的程序员都是相似的，当他们还在是一个菜鸟的时候，就已经有各种成为高手的苗头了，这些苗头就是——他们热爱思考，喜欢解决难题，对新鲜事物非常好奇，总是找人讨论，可以用自己的业余时间狠命研究很多和工作无关的技术，会在业余的时间里写些有趣的小程序，或是会把自己的思路书写下来，等等，等等。


一些问题

我这样说，大家可能会觉得“挑战无处不在”这句话太虚了，而且可能不明白什么叫“热爱思考”，这里，我把我的或别人的思考的东西罗列一下，这些问题，有的会让我思考推敲，有的会让我疯狂地查资料，问人，或是找人讨论，询问。大家不妨可以跟着我一起思考一下。

酷壳上有一些小问题，比如：火车运煤问题，赛马问题，这些问题都不够实际，我觉得也这些问题有点无聊，我们不妨观察一下我们身边的东西，我们就可以看到很多有挑的战的东西，对于这些问题，如果是你来做，你会怎么做呢？

0）

许多年前，当我看到珊瑚虫QQ把IP转成地实际地址的时候，我就在思考，如果我有一个IP网段的数据（全球IP地址数据），我怎么来完成这个功能呢？比如：某地点的IP网段是：10.10.1.* － 10.10.5.*。我要有一个IP地址是：10.10.3.20，我怎么匹配这个网段？用Hash表吗？好像有问题。把IP字串转成整型？排序+二分法，好像更容易解决一些，但是如果有一些修改的话好像有点不方便。用树型结构（森林）会不会更好一些呢？如果我要通过地点反查IP段呢？

1）

网上短网址服务，你有想过这个短网址生成的算法是什么，如何能做到能最短？怎么查询？你也许觉得会用key-value的NoSQL。那么，如果对于同一个URL，如果要重用已生成的短网址，你怎么用key-value的NoSQL来解决？

英汉词典的检索和这个很相似，如果通过英文查汉语，又通过汉语查英文？如果是N多种语言的互相翻译呢？你的数据存储和检索如何做呢？

2）

当我看到Dropbox这样的云同步的软件的时候，我不知道你是否会和我一样会去思考，在多个设备间的文件同步是怎么做的？如果网盘上有几万，甚至几百万个文件，当要和我的本地数据同步时，他如何比较经济地知道哪些文件更改了？需要向服务端同步或是向客户端同步。更进一步，你有没有想过没有中心结点的文件同步问题？你有没有想过，文件冲突的问题？

3）

我们的新员工入职的时候，有一些公司会给新员工的帐号生成一个随机口令，然后新员工可以在登录后修改口令（我一直在想我们的银行应该为用户生成一个随机口令，而不是设置一个6个0或是6个8的初始口令）。那么，对生成随机安全口令的算法知道怎么做吗？如果你写出这个算法来了，你怎么证明这个算法是足够随机，生成的密码强度足够大的？（你会发现，测试口令是否随机是否安全的程序，会比生成器更难写）

4）

关于动态密码RSA SecurID（如下图），这个小设备上的6位数字会每60秒变一次，在你登录的时候，需要输入这6位数字，服务器上会认证这6个数字，那么这个事怎么做？再试想一下，这样的小设备我要发给我的客户，我希望我的每个客户都使用不一样的随机算法，就算是算法一样，算法的种子也不能一样。那么，如果我的客户一共有百万甚至千万，我的服务端怎么管理这些用户的SecurID？


5）

看看我们的网银或是ATM的用户登录功能，如果你登录时输错口令超过3次以上，你的帐号就会被冻结，需要去柜台重置口令。这个功能看上去很安全，因为可以防止黑客在线尝试破解你的登录口令。不过这又带来了另一个问题，如果有一个恶意用户知道你的卡号，他就上网或是造个卡故意输错你的口令，导致你的帐号被冻结，让你一次又一次地去银行排队重置。面对这样的情况，你该怎么解决？

6）

当你在网上购物的时候，你会去一些电子商务的网站，这些网站都会对他们的产品进行分类，有大分类有子分类。你进到分类后，你可以通过不同的属性来过滤不同该分类下的商品，注意，不同分类下的商品的过滤属性不一样，如，手机分类和电视分类的属性都不一样。试问，你如何设计你的数据库表结构？

7）

当你在泡各种论坛或SNS社区的时候，你会看到，用户在互相回复的时候存在一个问题，尤其是用户量很大的时候，大家的回复完全交织在一起什么也看不清楚。以前有的论坛使用树形列表来解决这个问题，树形列表好是好，但是把一棵大树放在那里还是很难看。Twitter.com给了一个非常不错的解决方式，就是所有人的回复或是回复的回复都按时间线放在一起，如果你要查看某回复的上下文的话，点击一下这个回复就可以看到了（我在我在“国内微博和Twitter的最大不同”中批评过这个事）。新浪微博在禁评论事件后也开发出了这个功能。你知道这个事怎么做吗？

更进一步，新浪微博的设计上有很多的缺陷，单说新开发的“查看评论”功能这个事来说，还是不完美，因为某些评论会随着转发带到别的地方去，他的“查看评论”功能只能看到当个贴子下的东西，不能把所有转发出去的贴子的评论一起综合起来。虽然这对于用户使用来说没有什么在不了的，但是对于软件设计来说，我们不妨做一个练习，可以思考一下，怎么样设计会更好。

再举一反三，有时候，我发现多个网友会提出同样的问题，我很想用一个回复同时回复他们。如果有这样的功能的话，我们的回复就会从一个树形变成另外一种形状了，我们又该如何设计才能支持这样的功能呢？

8）

说到新浪微博，我就想多说几句，我最近观察到了两个事：

一个是验证码的事，如果你在你的帐号设置里设置了“登录需要验证码”，你会发现，在登录新浪微博的时候，仅当你输对了口令后，系统才会提示你输入验证码。为什么呢？因为，这个“登录需要验证码”这绑定在你的帐号设置里的，所以，要取这个设置，就需要你登录成功（？！），老实说，这个功能在设计上有点二（中国特色）。如果是你，你怎么设计呢？

另一个事情是新浪微博或Twitter的用户名修改后，被他人@过的信息就再也链接不到你这里来了。我们来试想一下，如果是你，你怎么解决这个问题？（我的我的微博里讨论过这个事，不一定对，供大家参考）

“如果是你，你怎么设计？”


9）

我有时候我会发一些快递，有时候是一些小东西，有时候是一些大包裹，有时候近，有时候远。我发现一个有趣的现象，就是快递员来收件的时候，快递的价格都是快递员自己说了算的，我还可以和他们砍价。我观察到他们会以距离，重量大小来订价。于是我在想如果你要运营一个物流公司，你作为这个物流公司的程序员，你需要开发一个软件来标注快递价格，你会怎么做？比如，这个快递公司会说，在北京五环以内是一个价，以外是一个价，出省后，上海以北是一个价，上海以南是一个价，等等，这只是北京的，如果把全国的各个城市到别的城市的价格都考虑进来，还要受到重量，体积，价格，是否加急等等因素的影响，你的数据库设计要怎么做呢？

A）国内的水军太恐怖了。他们活动的刷排名，刷信用，刷积分，刷粉丝等等地方，你是否想过如何解决这个问题？还有广告联盟的欺诈问题，等等。这些东西，有的还是可以通过技术手段进行限制和计算的，你有思考过应该使用什么样的方法吗？

B）说到水军就不能不提垃圾邮件和垃圾短信。你有没有想过邮件系统怎么过滤垃圾信息的？

C）关于推荐功能，这必然是一个热点，这是软件产品从request -> response的被动方式到主动方式的进化。微博上有推荐关注者的功能，电商有推荐商品的功能，豆瓣上有推荐影片音乐书籍的功能。不同的领域的推荐算法各不相同，你有没有思考过，如果是你来做推荐算法的时候，你会怎么做吗？更进一步，推荐通常伴随着学习和匹配，学习用户的行为，匹配相似的东西，你想过怎么学习用户的行为，怎么匹配相似的东西了吗？

D）关于微博，某名人有几千万的粉丝，当这个名人发一个微博的时候，需要通知这几千万个粉丝，这个在系统架构上应该怎么做？如果某天这个名人与人发生口角，和人吵架，拼命的刷微博，那么，系统架构要怎么设计才能支持这样的事呢？

E）想想火车票的分段卖票的方式，现有的解决方案是为每个站点预留票，于是我们可以看到火车始发时，有很多空坐，这些空坐都是留给下一个站点的，我们能否开发出一个系统来，可以把一条线上的这些这站上那站下的旅客统筹规划一下，制定出一个最经济的方式，让火车运行得更有效。

F）对于地铁公交网络，我们希望这个网络既能有更多的覆盖，又能节省路线，你能不能设计出一个系统，当我们输入一些数据（如：站点，是否终点或起点站，该站的下一站可能方向（多个），该站是以上车为主，还是下车为主，等等），你的系统能自动安排出各种线路吗？

这样的问题实在是太多了，都是可以让我们去思考的，并不一定有经济效益，但是至少可以让你锻炼一下怎么去分析问题，怎么去思考，怎么去解决问题。

总结

综上所述，我想说的是：

1）只要你想，挑战是无处不在的。那怕是你现有的觉得无聊的东西，只要你想做到极致，那怕是一个简单的功能（比如用户登录的功能）也会让你充满挑战。

2）观察身边的事物，去思考，去调查，举一反三，这才是你成长的源泉。不要把你的成长推给客观原因。

3）我的软件开发的三重门中说过，第三重门是解决实际问题，让你的业务处理更为的智能，更为地强大。我不知道为什么这一两年，我们的圈子里所有的人都在关注着“云”，“海量数据处理”，“高性能架构”这样的东西，尤其是那些性能调的高性能的东西并不很难，而这些更为实际问题更有挑战性，也更有前景。 ■

原文：http://coolshell.cn/articles/7048.html

http://coolshell.cn/articles/7048.html


这里，目前是空的。

你的招聘信息可能会出现在这里，只要你——

投稿给我。

http://os.51cto.com@51CTO系统频道

《linux运维趋势》2012年5月号 总第19期

Technology

《linux运维趋势》2012年5月号总第19期