Dibowitz和Pedro Canahuati是Facebook的生产工程总监，与SearchDataCenter进行了一次关于DevOps的深入讨论，并给DevOps新用户提供了不少建议，描述Facebook为何选择Chef，以及对这个工具功能的愿望清单。

　 　 Phil，在上午的演说中，你提到过“将配置作为数据。”这到底是什么意思呢？

　 　 Dibowitz:将配置作为数据是指，当你想委托某些配置系统或系统区组给某位软件工程师时，他们不一定要求是系统管理员，他们也不一定要知道Chef、Puppet或CFengine位，也无须知道自己正在使用什么。他们知道的是，“我需要x兆的文件”或“我需要将核心文件放在不同的目录”或其他东西。而这些仅仅只是数据。“我需要这么多这个。我要把这个放在这里。”诸如此类。

　 　 所以，可以提供一种方式，让他们以数据来表达，如果可以给他们某个哈希值来表示系统控制或包阵列，就可以让开发人员管理他们环境中应用程序的配置文件，这种方式和他们已经习惯了的东西配合非常好；只有代码和数据，而且每个参与的开发者都需要代码和数据。

　 　 Pedro Canahuati:我觉得可以把他的例子更进一步说明，开发人员可能需要知道，“我需要更多共享内存。”但他并不需要知道，例如，他正使用者Linux服务器，Linux服务器有一个sysctl文件在/etc目录下，开发人员无须知道在运行该文件后，还必须在系统上执行命令才可以让配置生效。

　 　 因此，将配置作为数据是我们通常的说法，“这里有一个文件，它告诉你，你想要更多共享内存。这里有个小哈希值，你需要做的就是修改它，剩下的内容就交给运维施展自动化法术了。”开发者喜欢这种方式，因为他们不需要去了解系统管理。他们只需要知道，自己需要更多共享内存。
　 　
　 　 你是否有对配置管理自动化工具做过对比？

　 　 Dibowitz: 做过。我们一开始针对Puppet、Chef和Spine进行测试。Spine你可能从来没有听说过，但这是我之前合作编写的工具，当时我还在Ticketmaster。和给所有人他们喜欢的工具相反，我们给了所有人一个工具，当时他们认为这个工具会失败，并且说，“你需要尽最大努力来推销这个工具。”我们给了所有人几周时间，接着我们满足并改进了许多不同功能——sysctl就是其中之一，这就如你可想象的——而且我们的SSH其实相当复杂。不仅如此，接着我们回溯并查看代码，我们观察尝试使用这个工具的用户体验，并记录工具如何满足我们自身模型的需求。

　 　 所有三款工具都可以满足需求，但在我们自己的环境中，Chef的灵活性与我们工作流需求最匹配。可以使用Ruby来表达和修改配置，而且还可以使用Ruby来扩展和修改Chef本身。我们修改node.save，这是Chef的内部内容。

　 　 我们可以随心所欲调整工具，而不是修改我们自己的工作流来适应工具。其他工具在这个方面就大大落后于Chef了，因为所有变化都发生在客户端，所以我们将其配置为服务端模式方便使用，其他工具也不支持这个功能。

　 　 对Chef这个工具还有其他什么改进期待吗？

　 　 Canahuati:我们目前主要是保证我们发起的变更不会产生预期之外的变化，或者意想不到的后果。Chef给我们提供了测试功能，但我更希望工具能够更加透明，降低上手门槛，比如我准备去修改某台缓存服务器，需要着重注意，不会意外修改到其他数据库服务器。这才是一个真正难以解决的问题。