Image via CrunchBase
学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。
现在 Flickr 的数据相比2007年的时候真是有了显著的增长：
- 24 TB 的 MySQL 数据
- 每秒钟 MySQL 有 3.2 万次写操作
- 每秒钟 MySQL 有 12万次读操作
- 图片容量 6 PB
- 每天要用掉 10TB 存储
- 超过 15000 个服务监控点
在 2004 年的时候 ，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。
除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器，用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多，而整理处理能力并没有削弱。我们总说摩尔定律，但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政，不要只冲着人下手，动手”裁”掉机器，也会省钱嘛…
Flickr 技术团队随着网站的快速发展并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢？给出了四个非常有趣的原则：
- 使得机器自动构建 (Teach machines to build themselves)
- 使得机器自监控(Teach machines to watch themselves)
- 使得机器自修复(Teach machines to fix themselves)
- 通过流程减少 MTTR (Reduce MTTR by streamlining)
自动购建上，Flickr 使用了 OpsCode 、Puppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。
Flickr 团队内部沟通工具也挺有意思，除了内部的 IRC 用于讨论之外，还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化，并且，重要的是，将这些信息弄到搜索引擎里面 … “信息查找”，是国内多数团队交流工具忽视的地方。
最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵，重新接管 Yupoo 网站，要知道 Flickr 仍然是最有影响力的网站之一，所以，有理由期待 Yupoo 团队的精彩。
–EOF–
学习 学习
都用 Chef 或者 Puppet，Cfengine 都没人用了……
24 TB 的 MySQL 数据 ，数据库结构应该比较清晰
OpsCode 、Puppet 是配合用，还是各用各？
对这方面有兴趣，但不知从何入手好…
作为开发人员管理者，部署测试机很想找一个好方法。
各用各的。
Luke Kanies 不爽 Cfengine，自己搞了个 Puppet；
Adam Jacob 不爽 Puppet，自己搞了个 Chef；
Luke Kanies 对 Adam Jacob 一声不响地搞 Chef 很不爽，就在博客上说：“你不爽 Puppet 你跟我说啊，你不说我怎么知道？哪里不爽了说出来，我们一起把它弄爽嘛，干嘛一声不响地搞个 Chef，你倒是爽了现在，但是我很不爽啊。”（不过帖子现在已经不在了。）
整个故事大概就是这样的。
@Ding Deng
验证了那句话：不满是向上的车轮.
关于机器数量的节省，有时候多一点机器可以多一点冗余，出问题的几率会少一点。做技术的当然希望能够用最少的技术完成同样的事情，但是鉴于公司申请机器的流程，恐怕实际中还是在预算的时候申请多一些的机器，也就造成机房中总是有很多空闲的机器。
如果是按电力收费的话，倒是可以不错~
@Ding Deng
没有用过Puppet和Chef，从它们的主页上来看，貌似是做到了多机多角色的可扩展管理。这里面有个问题：配置是静态的。也就是说，从一台机器“生下来”后，它注定是文件服务器，或者数据库服务器+Web服务器，都已经确定好了。另一种思路是：每台机器生来同构，由中央节点接到部署请求后，依据各slave的资源状况进行分配。在这个思路下，可能总体的利用率会下降(取决于bin-packing算法的效率)，但是维护性和可扩展性会增强不少。