技术工程师居然写起诗了

话说虽然快到年底了,可公司的某个项目(不妨叫做 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–

Microsoft.com 后面的小道消息

微软员工 Jeff Alexander 在 Blog 上写了一篇 Microsoft.com: What’s the story? 报料了 Microsoft.com 站点的一些技术架构信息。不料，这篇文章以迅雷不及掩耳盗铃之势被删除了。还好，Google 以迅雷不及掩耳盗铃之势做了快照。

这篇文章有的地方已经做了介绍，题为微软官网Microsoft.com的一些安全防护数据。但还是漏掉了一些信息。

1) 微软的运营团队 Blog。毕竟是官方的运行团队，在 Blog 上介绍了不少经验，非常值得借鉴。

2) HBI 是啥? 才疏学浅，搜索了一下才知道是：High Business Impact 的缩写。很奇怪，很多人看了那片文章而没有对此有疑问，或许大家都已经知道了。我火星。

3）对待杀毒工具( AV，此 AV 非彼 AV，不知道上面翻译的人为啥没提)的态度。众所周知，对于 Windows 服务器的维护来说，病毒问题会让很多人很头疼。微软运营团队的是态度是：只要有可能，还是会进行杀毒的。

另外，我比较好奇的是微软用什么做 Log 解析。Linux + Perl 这一套东西估计他们是不会用的。

最后，我把英文的快照扔到本站临时目录上了，尽可去一窥全豹[请”另存为”，然后 IE 观看]。

–EOF–

Flickr 的访问统计实现以及其他

TechCrunch 前两天报道说 Flickr 针对 Pro 用户新增了一项统计功能。今天有看到 Flickr 的 DBA Dathan Pattishall 描述了一下这个统计功能的实现。

Flickr 统计功能的基本技术信息：

所有的信息统计是实时的
同时用到 MYISAM 与 INNODB 两种引擎
数据因为存储需求跨在 6 个 Cluster 上(12 台服务器，6 台提供服务，6 台做失败接管)
没有用 Memcache

Dathan 提到这是他最耗时的一个项目(似乎有点怨言呀)。因为是实时统计，并且还要不影响整体页面响应速度，所以整个项目非常复杂。一旦 DB 设计搞定后，大部分时间都花在如何创建分布锁上了。

其实就我个人而言，真的不觉得这个功能有什么必要(尤其还是实时统计)。这或许是过度设计的一个例子。Flickr 在被 Yahoo！收购之后，这段时间倒是有点颓势。

说起 Dathan 这老兄，在 MySQL 技术圈子算是大名鼎鼎了。曾先后在 Friendfinder、Friendster 做 DBA，并获得国 05、06 两年的 “MySQL Application of the Year Award“。(看他 Blog 的活跃劲儿，估计今年也差不多。)

这老兄加盟了 Flickr 后，一个礼拜解决了 40％左右的性能问题。从他的简历来看，Flickr 目前每日 DB 的事务超过 10亿，MySQL 运行在 16G 内存、AMD CPU 服务器上，存储采用本地硬盘而没有用 SAN。数据库采用联邦架构，能做到线性扩展，为公司节省成本达 40 万美元(占40%，从而估计 DB 相关硬件成本为 60万美元).

推荐国内每个 Web 2.0 公司的 DBA 持续关注 Dathan 的 Blog，当然，可能大家都已经一直在看了。

–EOF–