作者文章: Fenng

从 Twitter 运维技术经验可以学到什么

没有一个网站的性能像 Twitter 这样这么令人牵肠挂肚，看见那条大鲸鱼总是让人感觉很无奈。Twitter 的运维专家 John Adams 在 Velocity 2009 上做了一篇题为 Fixing Twitter 的技术分享(PDF)，人家也是一直在努力阿。John Adams 在 2008 年七月加入的 Twitter ，对于 Twitter 的站点稳定的确做了不少工作。

Twitter 运维团队的职责：

软件性能(后端) Software Performance (back-end)
可用性 Availability
容量规划 Capacity Planning (metrics-driven)
配置管理 Configuration Management

看完这个接近 50 页的 PDF ，除了满足我们一小部分技术窥探的癖好，或许也可以学到点什么。

不重复发明轮子

对于监控，Twitter 用的就是 RRDtool，Ganglia、MRTG 这些已经成为很多网站标准配备的组件。而不是自己写一大堆功能重复的东西。值得注意的是， Twitter 也一直在用 Google Analytics 进行业务分析。

不重复发明轮子，可以打磨轮子，比进行如一些功能脚本定制之类的工作。

发明不重复的轮子

Twitter 开源了他们自己用的一个 Apache 模块 mod_memcache_block（a distributed IP blocking system），这个模块根据 HTTP 代码请求限制访问频率。熟悉 Twitter 的朋友会知道这是针对第三方应用程序的必须的一个功能，否则的话，会产生类似 DDos 的效果 :) John Adams 说这个模块是他多年以来就期待的东西，我相信，如果有人已经做了同样的事情，他们肯定不会自己再写一个。

尽可能的自动化

无论是配置管理还是针对各项功能的”开关”，都尽可能的自动化。依赖于人来控制一些事情容易”规范”，但是流程冗杂，节奏变慢。

更好的理解硬件

拥抱新技术体系，使用更有经济效益的硬件(比如对 8 核 CPU 的选型与更换)会带来更好的收益。而这个要建立在对硬件体系的正确理解上才行。

另外几句话要记住：

Disk is the new Tape. (内存是新类型的磁盘. 磁盘是新类型的磁带)
Kill long running queries before they kill you. (问题是如何提前发现? 有效的监控!)
Use metrics to make decisions, not guesses.
“Cache Everything!” not the best policy

或许还应该学到更多…

–EOF–

网站优化应重视 DNS 预获取(DNS Prefetching)

网站优化技术总是在进化。今天重新阅读了一下以前的前端优化笔记，发现对于 YSlow 优化 34 条准则关于减少 DNS 查找 (Reduce DNS Lookups)的部分或许应该修正一下了。

DNS 作为互联网的基础协议，其解析的速度似乎容易被网站优化人员忽视。现在浏览器厂商已经有在针对 DNS 进行优化，典型的一次 DNS 解析耗费 20-120 毫秒，减少 DNS 解析数是个优化的方式，而能够缩减 DNS 解析的时间也是有经济效益的事情。这就是浏览器厂商重视 DNS Prefetching 的主要原因。DNS Prefetching 对于性能的收益可以简单的用”DNS 同步请求到异步”来解释，也就是具有此属性的域名不需要用户点击链接就在后台解析，而域名解析和内容载入是串行的网络操作，所以这个方式能减少用户的等待时间，提升用户体验。

Google Chrome 内置就有 DNS Prefetching 技术(注意之前有几个小版本因为这一特性反而带来了性能问题) ，而 Firefox 3.5 也引入了这一新特性。至于 IE 8，暂时还看不到有什么举措(或许是我没注意到?)。

对于一个网站来说，如果希望能充分利用用户浏览器端的这个功能，可以在页面添加 link 属性的锚点来做到。类似：

<link rel="dns-prefetch" href="http://www.google-analytics.com/">

另外还有这个 x-dns-prefetch-control 也有必要适当用一下。对于某些站点引用了 Google 的某些服务脚本，可能这尤其有用。

另外一种加速 DNS 的途径是考虑使用 pdnsd 之类的缓存 DNS 代理服务器来加速某些 DNS 请求。

在 Chrome 中，可以通过在地址栏输入 about:histograms/DNS 来观测一些有趣的 DNS 性能数据。

–EOF–

登陆框的密码遮盖问题以及其他

几天前看到的这个关于密码遮盖（Password Masking) 问题的讨论，顺着链接有找到了一些讨论来看，继而发现相关文章已经有人翻译了(refer)，但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。

这是个令人印象深刻的话题，因为挑战的是习惯性的设计方式。放眼看去，所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见–用户的输入成了盲区，不知道自己输入的是否对，点击登录变成了变相的试错操作，产生比较多的再次登录操作，对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新，要不怎么说人家 Jakob Nielsen 是用户体验方面的大牛呢，要从别人口中出来这个论断可能会被人笑话，而大牛就敢于挑战常规，弄个问题就给大家带来思考了–扯远了。

似乎多数人赞同添加一个额外的检查框（CheckBox），安全性要求不高的应用，默认不遮挡，用户输入完毕之后，再选择旁边的检查框对密码进行遮挡；对于安全性要求比较高的应用，默认密码遮挡，但可以选择显示一下密码明文一下，方便用户检查是否有拼写错误。

如果你用过苹果的产品，比如 iPhone 新 OS 3.0 的版本，你会发现密码的处理又进了一步，密码输入时是显示明文的，方便用户确认没有输错，在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)

(截图有点喧宾夺主，对付着看吧)

这个想法真的很让人欣赏，对于手持设备能够比较有效的防止了窥探(peeking over your shoulder)，也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说，窥探的可能性有多大？缺乏数据支持，很难说明。或许，这里的安全专家的分析对质疑者也会有点帮助。

其实我觉得密码遮盖问题在用户初次注册的时候带来的问题尤其严重。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ，否则的话，用户要的密码可能不是自己输入的，短时间内连续两次输入，出现键入错误的几率并非不存在。

好吧，现在开始审视一下自己的网站登录框设计以及注册页面吧…新的问题或许是，你有勇气做点修改麽?

如果觉得上面说的都是废话，那么不妨考虑这两个问题：

为什么我们之前就没考虑到这一点?
如何才能先于别人一步想到这一点?

–EOF–

延伸阅读：Better Password Inputs, iPhone Style

关于信息的五分钟问题

最近一直在考虑这个关于信息的”五分钟”的问题。搜索了一下，发现还很少有人考虑这个现象，思路还没有完全理顺，先抛几个观点等待大家的补充吧，期待能引发一些对信息处理的思考。

最早注意到这个现象是每次我 BLOG 更新之后，在大约 5 分钟左右，通过 Google 的 BlogSearch 就可以看到内容。这个倒很容易理解，因为我用的 Movable Type 在发布文章的时候会自动通知一下 Google 服务器。接到通知之后，Google 能够较快的把信息合并(Merge)到当前的索引中，但是应该还没加上非常严格的排序(Sort)，这是个很经典的处理技巧。

不过，Google 获得信息绝大部分是通过爬虫”抓取”，也就是”拉”(Pull)数据，只有少部分是用户”推送”(Push)的。这就导致 Google 在信息处理上节拍总要慢一点。Google 的目标是处理地球上的所有信息，无远弗届，但信息的及时性或许是最难解决的。

而 Facebook / Twitter / FriendFeed 等具备面向”实时信息流”(Real Time Lifestreaming)功能的网络应用，大部分信息都是用户”推送”上来的，所以也有天然的优势触及这五分钟之内的数据，并经过简单的局部计算之后呈现给用户。得到”即时”信息似乎是人的天性（另一个侧面的印证是人们无法摆脱手机而全部使用 IM 和电子邮件），所以五分钟之内的数据处理能力是对普通用户来说有着难以言明的吸引力。

“五分钟”只是个大致的说法，相信随着技术的发展，会缩短到三分钟，乃至更短。但这部分始终是 Google 无法完全覆盖的地方，技术没办法打败时间，这也是信息暗网的也无法解决的问题。最终我们发现，信息处理的巨人和信息处理的快刀手一起相处的比较融洽。

–EOF–

注：很明显，这个”五分钟”问题和我之前说的关于 I/O 的五分钟问题是不搭界的。