作者文章: Fenng

37Signals 架构

如果没有 37signals ，恐怕也没有 RoR 的如此流行。37signals 对于很多 Geek 来说，是一家非常迷人的公司。他们是网络上的另类新星。

37Signals 在 Signal vs. Noise 上披露了比较详细的运营数据，Ask 37signals: Numbers?

存储数据量

截止到 2007 年 11 月，总存储量统计：

5.9 T 用户上传的数据
888 GB 上传文件 (900,000 请求)
2 TB 文件下载 (8,500,000 请求)

这包括 Basecamp、Highrise、BackPack、Campfire总的数据统计。总的用户量其实并不多，只有 200 万。

这些数据存放在 Amazon S3 上，37Signals 用了这个服务已经一年多了，他们对此比较满意。事实上，Amazon S3 已经成为 Web 2.0 分布式存储的既定事实的解决方案。

服务器状况

37Signals 当前正在部署虚拟化软件产品，当然不用 VMware，而用开源的 Xen。当前大约有 30 台服务器，从单 CPU 的文件服务器到 8 CPU 的应用服务器都有，总共 100 颗 CPU、200GB 内存。预计 XEN 部署完毕后，服务器数量降低到 16 台，92 颗更快的 CPU、230GB 的内存量。这样做的主要目的是管理起来更方便(至于性能是否更好，我个人还是有点怀疑的–Fenng)。

关心 ROR 以及具体一些策略具体实现的朋友不防去看看那个帖子下面的留言。

之前还真的很少有听说哪家 Web 2.0 公司部署 XEN 的，37signals 的这个动作或许是个积极的信号。2007 年也是个”虚拟化”年，相信随着虚拟化的技术成熟，开源力量的壮大，会有更多的公司收益于 XEN 虚拟化架构.

–EOF–

年度回顾:这么多的数据泄漏事件

到了年底了，要预防安全事故，数据泄漏更要预防。CSO 杂志列举了 2007 年的 10 大数据泄漏事件。这里有一份比较全的数据泄漏列表。我觉得这个美农业部数据库漏洞泄漏十五万人资料其实也很有实力入选年度 10 大，但不知为何没入 CSO 杂志作者法眼。

原以为这些事件都和什么黑客入侵有关的，真实情况倒是大相径庭：有好几个是着了 “社会工程学” 的道儿：光是硬盘、笔记本被盗就有好几个。金庸老先生说了，”重剑无锋，大巧不工”；小平说了，能拿到数据的黑客就是好黑客。光盯着软件的漏洞下手，还不如奔着人下手容易(比如电影《防火墙》里描述的那样)。比如企业内部网络安全固若金汤，那可以盯着他的备份磁盘磁带下手嘛，要不盯着他出差的总裁、CTO 啥的，在机场、火车站偷丫的。所以，如果要黑某个公司的网络，还不如扮作捡垃圾的，每天检查一下这个公司的废纸。扯远了…

DBA 们，一起来评选一下咱国内的 10 大数据泄漏事件吧? 不过，我好像一个都没听说过，虽说，好事不出门，坏事传千里，可谁让咱报喜不报忧呢。

–EOF–

技术工程师居然写起诗了

话说虽然快到年底了,可公司的某个项目(不妨叫做 A 项目)正进展的如火如荼. 该项目意义非凡,工程师连续疲劳作战, 自是压力不小. 项目组成员青轩同学有感于此, 填词一首,说是要调节一下气氛:

长相思
--记 A 项目有感
争一声，吵一声，慷慨激昂闹市中，荆棘已随风。
茶已冷，杯亦空，专注凝神梦不成，皓月挂三更。

看到邮件后,不少人一边笑,一边赞叹. 妙的是, 另一位才子周瑜也很雅,立刻回邮件填词和之:

短相逢
--感长相思-A项目有感
夜重重，意浓浓，苦思冥想情已融，相知镖局中。
日相逢，夜相逢，会友对面难见容，翩然已过冬。

按: 青轩和周瑜是内部的花名. 而”会友” “镖局” 则是公司某个会议室,该项目组封闭开发所在地.

虽然从格律的角度上看,可能不那么严格. 但是信笔写出来的东西足见”有才”. 谁说工程师整天写代码没情调? 那是你没看到有趣的工程师, 我们这里这帮家伙一旦搞笑起来也不得了的.

有个同事的评论也很有意思: 厨师不看菜谱看兵书已经让很人吃惊了，谁能想到技术工程师居然写起诗了…. 就在写这篇 Blog 的时候, 还有好几个同事继续填词和之呢…

最后说一下,这个有意思的团队现在求贤若渴. 钱多人少速来, 有兴趣的朋友不妨给我邮件.

–EOF–

如何避免 Unix 环境中的 ‘rm -f’ 灾难

在 ITPub 论坛上，最近有朋友发起了一个”请列出你在从事DBA生涯中,最难以忘怀的一次误操作“话题讨论，如果有足够的耐心看下去的话，会发现很多误操作都是类似的，最上镜的就是这个操作系统级别的 “rm -f” / “rm -rf” 了。

在那本著名的 Unix 痛恨者手册上，rm 问题也作为一个罪状而提出。的确，Unix/Linux 的这个 rm 的 -f 参数是系统管理员（SA)乃至数据库管理员(DBA)最容易引发系统灾难的导火索。

如何避免这样的灾难发生呢?

如果一个人能不犯任何误操作就好了。但这是不可能的。我相信肯定有很多 DBA 或 SA 到现在也没烦过这样的错误，但不要忘了墨菲定律的诅咒。

1.有安全的 rm 命令麽?

一种比较理想的是如果编译源代码的时候把这个 -f 选项去掉，肯定能让不少人少犯错误。不过搜索了整个网络，好像还真没有具体如何操作的。Sun 的 Solaris 10 对 rm 作了一点改进处理，”rm -rf /” 是不允许的。可惜的是 “rm -rf *”类似的操作是没限制的。另外，对于其他系统也不可用。或许，将来 GNU/Linux 能有改进。

2.Alias 方式

第二个方式是在 Profile 层次上设置命令别名( alias ).

alias rm="rm -i"

这也是最常用的方式。如果脚本上直接调用了 rm 命令的全路径，还是不管用的。这其实也是如果功能上没办法完全禁止，那就提高用户的使用成本 :)

3.替代命令

第三个方法是使用替代命令。如用一个 del 命令来替代 rm. 这个就要挑战用户的使用习惯了。真的会始终用替代命令麽? 这个方式需要注意的是，无论如何不要真的把 rm 命令挪走(比如物理的 rename 名字)，如果这样，是很糟糕的策略。

4.修改权限

也有不少人直接把 rm 的权限修改，比如只允许 root 用户而不允许普通用户执行命令。这在调用一些脚本或者编译文件的时候，很容易引来很多麻烦。

任何一种策略，如果要扩大应用到一个团队的话，还需要考虑使用习惯对其他成员带来的影响。毕竟，”不爽”也会让很多人更容易犯错。

最后，友情提示，有的人经常通过层层跳板 Login 到主机上，可能会因为忘记了”身在何处” 而犯错误，最管用的方式是设置一下 PS1 环境变量。比如我在 Dreamhost 上用这样的：

PS1="\n\e[1;37m[\e[m\e[1;32m\u\e[m\e[1;33m@\e[m\e[1;35m\h\e[m \e[4m\`pwd\`\e[m\e[1;37m]\e[m\e[1;36m\n\e[m\\$ "

–EOF–