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最忙的时候是万圣节后的那天。