作者文章: Fenng

密码提示问题的设计

在公司洗手间看到一个关于“密码提示问题”的笑话。不过仔细一琢磨发现不是这回事儿。电子商务网站几乎都设置密码提示问题的。一个有趣的现象是有些 UE(或交互设计师?反正是干这个活儿的人) 工程师自己都没搞清楚这个 “密码提示问题“ 要给用户什么。

对于 UE 我是门外汉,不过我理解的这个过程就是建立公钥和私钥:公开的密钥即“密码提示问题”,是其他用户也可以看到的),只有自己知道的叫私钥,也就是答案。很明显,既然说到私钥,那么私钥的保护就是关键。设计者有必要引导用户保护好自己的私钥。

我们先看个例子(类似的网站很多,就别说具体哪家了,都那鸟样):

Protect_Questions.png

告诉我,用户需要填入”正确”的还是”错误”的答案?

就这个密码提示问题来说,如果没有直接明白的告诉用户正确的使用方式(你的用意!),那么很多用户还是输入“真实”的答案。除了第一个和第四个问题之外,其他几个问题我想在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

有感于 Yupoo! 被亮”黄牌”

看到 Yupoo!亮“黄牌”。Yupoo!的兄弟们估计也哭笑不得,算是被免费公关了一回。

在国内办个网站真不容易,只要是用户产生内容的,基本上都要额外的耗费很多精力去和那些人打交道,有个风吹草动的就可能被请去”喝茶”。我总觉得,在国内 Web 2.0 的创业其实比国外要难多了。第一个横在眼前的问题就是电信网通之间的鸿沟,要多追加不少投资,才能针对不同地域的用户提供一致的用户体验。第二个难题就是必须要和相关监管部门打交道,不得不花费不少心思。很多技术创业型的公司在这一块经常要吃亏。

当然,既然选择加入这个游戏,基本的游戏规则还是应该遵守的,如果纵容用户恶意利用资源,很容易就会弄出来”破窗效应“。所以,在运营上绝对不能短视,利用一些突发事件的噱头是能引来短期流量,但是无疑会改变网站的长期形象。在这方面 Yupoo! 一直挺有操守的,只是 “每天网友上传约10万张照片” ,要想 “先审后发” 的确难上加难。还没有听说在这个方面有什么”技术类”的解决方案。这是 Yupoo!的困境,怕也是很多类似网站需要面对的一个问题。

顺便说一下,“每天网友上传约10万张照片”,按照这样的计算一月 300 万张。加上不同的格式,可真的需要海量的存储空间啊。

EOF