Facebook运维工程师的一天

原文地址：http://linuxsysadminblog.com/2010/09/a-day-in-the-life-of-facebook-operations/
顺便说一句，这个linuxsysadminblog.com确实不错。
文章是笔者在现场听Facebook系统工程师汤姆·库克在2010年的surge可扩展和性能大会上的讲演时记录下来的——
这是到目前为止最火爆的讲座了，还没开始就只剩下点站着的空间……
Facebook运维需要支持多大的应用环境：
1、在facebook花上每个月7亿分钟（不太明白这个意思，一个月明明只有43200分钟）
2、60亿次内容更新；
3、30亿张图片；
4、实现100万连接；
5、5亿活跃用户。
基础设施建设的发展：
1、租用IDC达到瓶颈；
2、开始自建；
3、目前已为加利福尼亚和弗吉尼亚两州服务。
发展历程：
从LAMP起步，然后拆分负载均衡，web服务器，app服务器，memcached，数据库。
最早的Facebook是一个单纯的发布在apache上的php站点。但后来php不足以支持Facebook的访问了，现在，Facebook已经开始编译一些php功能成C++程序，这就是业界闻名的HipHop。
Facebook大概拥有世上最大的memcached集群，超过300TB的数据存储在memcached内存中。
使用flashcache来改善mysql性能。
已实现支持的服务：
新闻feed、搜索、缓存。
服务使用中的编程语言：
C++、php（前台）、python、ruby、java、erlang（聊天室）
各种编程语言间如何交互数据？json？soap？都不是。Facebook专用一个为各编程语言开发服务的软件框架。所有的Facebook系统后面，都是统一的一个平台。
Facebook每天都在担心：
开发、监控、数据管理、代码上线。
Facebook使用centos操作系统！
系统管理：
配置管理；
系统管理——用CFengine；
按需管理。
开发：
前台部分——每天都有新代码上线。代码统一协调，所有人都在IRC的频道里交流。每个人都可以知道发生了什么，而不单单是工程师自己。
1、程序推送按需分发；
2、代码分发通过BT的方式；
3、php是经过编译的，数百MB的二进制文件通过极小的BT种子迅速下发；
4、完成全网更新只需要1分钟。
后台部分——只有开发和运维。开发工程师写代码、测试、演示。
1、这样能迅速得到性能数据；
2、揭露各环节的真实交互（这里翻译的应该不对，看不懂……）；
3、没有所谓的“提交、退出”；
4、全面参与应用变成产品的过程；
5、运维被“嵌入”每个开发团队。
代码的每一处修改和推送，都必须详细记录。
Facebook的服务器性能指标在线监控
ganglia监控系统：快速、便捷、超过500万的监控指标、可以通过网格和池的方式进行规划。
自主的监控系统
nagios监控系统：用来给各团队发报警，最开始是用的email。
Scribe高性能日志系统：最开始用的是syslogd，同时在用hadoop和hive。
怎么运行的呢：
1、定义要明确的依赖关系；
2、固定的失败次数；
3、服务器是第一步，系统架构设计。
4、现在重点是搞集群。通过功能不同进行逻辑关系划分（web、db、feed等）
5、下一步是数据中心。尤其是灾备。
6、不断的沟通——信息永远在共享中。
7、IRC。
8、大量的自动化数据获取和设置。
9、内部新闻更新。
10、内部工具的’headers’；
11、变更日志。
12、团队要短小精悍。
一个有趣的数字：平均每台Facebook的服务器8分钟就升级一次。
一个有趣的事实：Facebook最忙的时候是万圣节后的那天。