Facebook在Chef配置管理整合中犯下的错误、最佳实践以及工具同样适合于你的DevOps环境。

Phil Dibowitz是Facebook系统工程师，他率领Chef团队在过去三年重新思考配置管理，以便与超大规模公司的数据中心保持一样的水准。SearchDataCenter.com与Dibowitz进行了访谈，内容涉及了其后端IT、迁移到Chef以及团队关闭CFEngine服务器。

Dibowits和他的团队协助独立服务业主完成了自定义菜谱的开发，并指导全公司转换到Chef。一共花费了三年时间，Dibowitz说，不是因为技术变革，而是因为结构性变化，软件工程师需要在开发方面承担所有职责。

在Chef DevOps迁移后，Dibowitz和他的团队在研究Facebook所用的操作系统。问题在于操作系统仅仅是安装一次，并不是真正拥有——Dibowitz希望改变操作系统的安装与管理方式。他称之为“与Chef的自然结合。”Chef将关联工具、模型和工作流贯通起来，接着便是对操作系统的速度与管理进行改进。

在完成DevOps模型成熟度时，你增加了哪些配置管理与自动化工具，又或抛弃了哪些？

Phil Dibowitz：我们在Chef上专门做了系统配置。应用程序配置是另外一套不同的系统。我们动用了强硬的策略和底线，应用程序的东西放在这里；系统的东西放在那里。我们已经有很好的系统与配置应用程序可以与Facebook集成。应用程序都有不同的要求和测试需求。而Chef可以实现一个、另外一个或者两者兼得，这比我们只设定一个目标来做好太多了。

2014年初我们在GitHub和RubyGems上发布了一些列工具：用于测试的Taste Tester，重新编写的Grocery Delivery，用于分发菜谱到Chef服务器，以及Chef Server Stats[一个小工具来拉取来自Chef服务器的监控信息]。它们会展示我们如何使用Chef以及我们这样行事的原因。

我同样还是第一个Chef代码库的外部提交者。Chef现在允许社区进行维护。于是我成为了正式的Chef维护着。我在Chef Client上贡献了更多东西，例如在一个资源中安装多个包的功能。

我们发布了一系列Facebook内部使用的菜谱。这些都是人们接触与学习Chef的好例子。我还会发布一系列更多的例子，只要我有时间梳理，并面向世界发布。

Facebook如何从开源社区的贡献中受益？

Dibowitz：对于Grocery Delivery 和Taste Tester，我们收到了来自社区的bug修复和功能增强。这十分有用；比如我们获得了更多的支持功能。当我们与社区对话时，能分享共同的语言，可以讨论自己的想法。

Facebook已经成为Chef用户中鼎鼎有名的角色，而我希望能够尽力做到，我们所做出来的东西能适用于任何规模的公司。我们必须解决这些问题，而且你可以使用我们分享的知识在自己的小规模领域里使用。我们不仅与雅虎合作，还与不少中小企企业、银行、大型企业、Web 2.0创业公司，Chef家庭部署爱好者等协作。我们有各种各样不同的方法来使用Chef，并且进行配置管理。

编者按：2014年6月，Facebook宣布转向FBOSS开源转发代理的计划，这是其SDN交换机操作系统以及Wegdes裸机交换硬件。

Open Compute Project的同步开发会如何影响你在Facebook做的事情？

Dibowitz：早期，当谈及自己建设交换堆栈的可能性时，我们乌托邦式的幻想与天马行空的场景都是把他们当作服务器来对待，但真正的交换机可比服务器快得多。我们如何处理交换机本身之外的所有东西，如何让它能够正常运作？我们如何让网络工作起来与之前不同？

如果这个设备看起来会向某种Linux服务器，那么就必须维护所有的内容，如系统日志。因此，我们使用Chef来解决这个问题。

眼看就要迎接曙光，却发现网络设备管理的问题在于很难实现自动配置。操作系统从根本上假设了许多管理员脑中的状态。如果你需要在防火墙之间新增六条规则，中间状态可能是不安全的，也可能把你自己挡在规则外。效率低，难度大，而且容易出错。我们使用了特定的Linux进程，它会在你写好配置文件时自动读取，这样就大功告成了。很难想象在传统的网络环境架构中要如何实现这样的方案。

我们没有使用Chef作为实际的交换机ASIC推送，但使用了与Chef工作方式非常相似的概念——更多的开源代码将发布。我们以相同的方式建立一切：先从小基础开始，然后是工程与迭代。FBOSS与Wedge提供了基础。我们现在拥有了一组基本的工具用于路由和交换。 

至少这样能够满足最低需求，并努力朝着理想前进。这是一个DevOps模型。对于Chef迁移，我们支持共同性，而且人们会发送功能请求。我们优先考虑最标准的项目，接着去解决更难或者特别情况，然后还有较小规模的迁移。不论你做什么，相同的模型都可以通用。

那些加入你DevOps行列的IT组织在今天与两年前有什么不同？

Dibowitz：越来越多不同类型与行业的公司加入。我无法想象三年前我的第一个ChefConf会引来如此大规模持续部署技术的咨询，包括很多银行、投资公司、旧世界的传统企业、航天公司等。

我仍然能收到相同的技术问题，比如“你如何通过某个菜谱来实现X功能？”或者，“你如何培养人员？”但我同样也遇到一些新的疯狂问题，如“Chef如何与审计互相配合？”还有“你的PCI审计师对此有什么看法？”

现在还有很多关于人员方面的讨论。在这一切都在改变的情况下，如何培养正确的团队，树立正确的态度并确保他们负责任而且可靠？这可能是因为越来越多的大型公司开始拥抱DevOps了。

作为一个DevOps公司开始运作时，那些问题是已知可以避免的？

Dibowitz: 我会打破他们在技术与文化上的误区。

文化：每个人都必须做代码审查。有人来审查和同意你的代码，然后才可以提交。大公司内这种模式已经深入人心。GitHub用户一样接受这种方式。但数以万计的公司说，“哦，我们规模太小了”或者“我们没有时间。”而且还有情况就是你需要花费更多时间在处理这些东西和相关流程上。有了代码审查，你可以实现更简单与可重复的协作。使用GitHub或Phabricator 来实现这个功能。

技术：使用正确的工具来发现错误，语法问题。Foodcritic是一款修正工具，还可以使用Rubocop。按人类检查语法和风格，会面临太多轮的审查并遗漏错误。这些工具可以挑出很多问题，你要做的就是如何修正。人可以专注于方法和整体代码质量。这些反馈都是人们擅于的，而且十分愿意接受。 

我希望我们能在短期内使用这些工具。我会推迟项目进度，去解决这些工具的使用问题，因为它能够让体验提升许多。

2013年，你是否担心无意义的修改——由Chef产生的变更造成意想不到的后果——并希望能够更透明的对其测试。现在如何了？

Dibowitz：这就是 Taste Tester的由来。【Taste Tester是Chef Test工具集中的一个小工具，这是专门为Facebook订制的，并没有开放。】我们创建了一个方式，就是你修改了一个菜谱之后，会有人来审阅，如果你进行提交操作，变更会在一小时内更新到全局架构。

在提交前，你需要做哪些行动？

Taste Tester现在使用Chef Zero，一个轻量级测试服务器[而不是Private Chef]。你可以从线上环境中挑选一小群服务器，并将测试组指向你的代码库。你可以查看这些代码在生产环境中的变化并观察其是否会影响工作。修改系统——可调，例如查看其是否会按你的预期修复CPU使用情况。或者测试不同类型服务器上的变化：Web服务器，数据库服务器等。所以不用担心搁浅的服务器，测试会在一个小时后失效。如果你满意生产环境小规模测试的情况，就可以将其提交到线上环境去。

我们同样还有做分片，将服务器主机名进行哈希，并将其变化成一个百分点。然后就可以告诉系统“如果我在X%的服务器上，就做这步操作。否则，做标准操作。”比如你可以进行在线变更，同样还能控制发布，在许多天内陆续发布，而不是30分钟内。这样可以帮助你移除可能存在相互依赖关系的东西，或者进行A/B测试，或者发布一个可能影响磁盘的大包。

传统方法[或测试]是经过开发、然后QA，然后生产；但测试一般没太大效果。如果你没有看它在生产环境上运行过，就不知道其实际到底是什么效果。

你的心愿是什么？

Dibowitz：我已经获得了多包支持，这个在我的愿望清单上。目前它还没有以有意义的方式退出，但它和他的上游已经存在，所以我们可以使用它。之前长时间存在着一个很大的痛点：每个包都会发起一个新事务、下载代码、等等。现在你可以一次性下载全部并解决大量配置时间。

有时候你需要在一个事务中安装两个包，否则无法正常工作。这在[多包支持]以前是一个很可怕的难题。