偶然发现了这个 NagiosChecker ，更方便的显示 Nagios 报警信息的 Firefox 插件。
这个插件几乎能搞定 Nagios Alert检查的方方面面，具备足够丰富的的过滤规则与显示条件；还能够定期调度；有趣的是，居然还提供声音报警。
一般人我不告诉他！
–EOF–
密码提示问题的设计
在公司洗手间看到一个关于“密码提示问题”的笑话。不过仔细一琢磨发现不是这回事儿。电子商务网站几乎都设置密码提示问题的。一个有趣的现象是有些 UE(或交互设计师？反正是干这个活儿的人) 工程师自己都没搞清楚这个 “密码提示问题“ 要给用户什么。
对于 UE 我是门外汉，不过我理解的这个过程就是建立公钥和私钥：公开的密钥即“密码提示问题”，是其他用户也可以看到的)，只有自己知道的叫私钥，也就是答案。很明显，既然说到私钥，那么私钥的保护就是关键。设计者有必要引导用户保护好自己的私钥。
我们先看个例子(类似的网站很多，就别说具体哪家了，都那鸟样)：
告诉我，用户需要填入”正确”的还是”错误”的答案?
就这个密码提示问题来说，如果没有直接明白的告诉用户正确的使用方式(你的用意!），那么很多用户还是输入“真实”的答案。除了第一个和第四个问题之外，其他几个问题我想在SNS 网络如此盛行、搜索引擎如此强大的今天，要得到答案是不存在什么障碍的。用户并不傻，但用户也不是都会耍小聪明，如果你去做个统计，我相信会有大量的用户输入的答案是可以猜到的。
或许有人会说，”没事啊，即使别人猜到了这个答案，密码最后也会发到原用户自己的信箱里的啊”。拜托，安全本来就是一环套一环的，这个如果被搞定了，你能确保用户的信箱不会被搞定么?
到各个站点查看帮助说明，发现原易趣的说明还是比较到位的(是否在用户设定问题的时候提示，我就不知道了)：
选择一个容易回答但其他人难以猜到答案的问题。
密码提示问题与任何其他机密信息一样重要，所以不要向其他人透露。
为安全起见，可以为问题提供并不正确或答非所问的回答。
前几天白鸦有篇文章《跟着用户走到沟里》，其实很多时候网站是设计者把用户带到沟里。
–EOF–
eBay 的存储一瞥
前年在帖子里介绍过 eBay 数据量超过 2PB，这么大的数据量管理和规划是需要一些艺术的，可惜网络上能得到的信息太少。最近又找到一篇关于 eBay 存储的介绍，这篇文章通过访问 William Crosby-Lundin (这位老兄现在已经跳槽到 SalesForce了)披露了一些数据，虽然该文距离现在有一年了，还是对我有不少参考价值。
eBay 存储团队当时 12 个人，管理 13 套存储，总容量 2PB 左右(不要刻舟求剑，现在超过 8 PB，2008-08-04） 了，8000 个左右光纤口，可用性 99.94%，工作量肯定不小。每周要起用 10TB 存储，这些存储有 75 个 LUN(也就说平均每个 LUN 135GB 左右，这个数据有些怪异)。连接到 SAN 环境的主机大约有 1000 台，数据库集群有 600 个左右，据我所知，这里的集群应该只是指 Data Guard。
这么多的数据库，I/O 开销肯定不小，如何消除存储热点呢? 该文只是笼统的说通过存储层与主机层的数据分片达到的。如果应用上 I/O 均衡做的好一些，可能存储热点问题不会成为瓶颈。
这个存储环境的部署应该有好几年了。所以最近一两年比较火爆的存储虚拟化与 Provisioning 技术都没有大规模起用。个人觉得 eBay 这么大的数据量， Provisioning 技术对于 eBay 的环境会是比较适合的。
有的时候，盲人摸象也是一种乐趣呀。
补充一下，超过 140 套集群。另外，提醒一下，这些数据是随着时间而变化的。切莫刻舟求剑。
–EOF–
Refer :
Our systems process in excess of 20 billion newly added records per day, 40TB being added every 24h, serving thousands of users and delivering hundreds of millions of queries per month in a true global 24×7 operation with distributed teams around the globe on systems over 8 PB in size (largest cluster >3PB), processing more than 30 PB of data per day.
FriendFeed 给了我们什么?
如果说 2007 年最佳小型 Web 2.0 应用是 Twitter，那么 2008 年最耀眼的 Web 2.0 应用很有可能就是 FriendFeed，虽然现在下断言还早，但是看看FriendFeed 团队的背景，清一色的 Google 帮……
个人觉得这个应用的”卡位”很好，试图在各个 Web 2.0 应用(尤其是 SNS 站点) 之上形成一个信息出口。让我想起了 Yahoo！Pipes …
我从 FriendFeed 的测试阶段就开始使用，我的 FriendFeed 原来大约有几十个订阅者，不过在 正式发布后的这几天，我每天都要收到大量的订阅通知，很多朋友也都惊呼 FriendFeed “爆发“。
FriendFeed 给我带来了什么? 用了这个服务这么久，我在 FriendFeed 站点上停留的时间可以说是非常之短。每天会检查一下每日发到我邮件里的 “FriendFeed Activity”，说句实话，到现在我才发现，几乎没有从这些 “activity” 里面发现任何”新”的信息! 很奇怪吧? 虽然 FriendFeed 号称 “offers a unique way to discover and discuss information among friends”，方法是提供了，但是并不能让我有效的发现信息热点。面对每天大量来自朋友的更新信息，用户总不能每天 “披沙简金” 吧?
另外一个比较严重的问题是大量近似的冗余信息让人不厌其烦，缺乏必要的过滤方法也容易让人对 “discover“ 更有价值的信息失去兴趣。 (BTW，Google Reader 上这个问题也很严重) 。当然，朋友们最为关注的信息很可能也是我最感兴趣的信息， 但是希望能有一个好的形式为用户展现出来，这一点我倒是比较欣赏 Techmeme 的模式。
考虑到 FriendFeed 测试阶段的改进频率，相信会逐渐解决这些问题的，毕竟这是出身 Google 的金牌团队啊。
–EOF–