配置管理已死：配置管理大会万岁

每个人都去布鲁塞尔的 FOSDEM 大会，从其大量的演讲轨道（俗称开发者房间）中学习，这些轨道涵盖了各种各样的主题，从 Rust、Go 和 Python 等编程语言，到从社区、法律到隐私等特殊主题。在两天不停歇的活动之后，许多 FOSDEM 参会者前往比利时根特，加入数百人的配置管理大会（CfgMgmtCamp）。

Kris Buytaert 和 Toshaan Bharvani 运营着这个受欢迎的 FOSDEM 后续展会，展会围绕基础设施管理展开，包括黑客空间、培训、研讨会和主题演讲。这是一个对构建弹性基础设施的人员、内容和方式进行深入技术探索的展会。它于 2013 年作为 PuppetCamp 启动，但在 2014 年扩展到包括更多社区和工具。

我与 Kris 和 Toshaan 进行了交谈，他们都很有幽默感，谈论了 CfgMgmtCamp 的过去、现在和未来。我们的采访经过了篇幅和清晰度方面的编辑。

Matthew：您的开幕 主题演讲 题为“CfgMgmtCamp 已死”。配置管理是否已死？它会继续存在，还是会被其他事物取代？

Kris： 我们注意到人们正在追逐容器的热潮，试图以不同的方式解决相同的问题。但他们仍然在管理配置，只是方式不同，工具也不同。在过去的几年里，我们已经从一个专注于基础设施即代码工具（如 Puppet、Chef、CFEngine、Ansible、Juju 和 Salt）的会议发展成为一个更广泛的开源基础设施自动化会议。因此，配置管理绝对没有死。基础设施即代码也没有死，但它们都在不断发展。

Toshaan： 我们看到人们在更换工具，追逐热潮，社区也在变化；但是，基本的思想和概念仍然相同。

Matthew：很高兴看到 可观测性成为 你们主题演讲的主题之一。为什么那些关心配置管理的人也应该关心监控和可观测性？

Kris： 虽然会议的名称没有改变，但工具已经发展，我们也扩展了视野。十年前，Devopsdays 只是 #devopsdays，但它演变为关注文化——DevOps 核心原则文化、自动化、度量和共享（CAMS）中的 C。

Monitorama 填补了监控和指标方面的空白（解决了 CAMS 中的 M）。配置管理大会是关于开源自动化，即 A。由于它们都是开源会议，因此它们履行了共享部分，完成了 CAMS 概念。

可观测性介于自动化和度量之间。更进一步来说，在一些关于开源监控的演讲中，我描述了监控工具从 #monitoringsucks 到 #monitoringlove 的演变；对于很多人（包括我），对监控的热爱回归是因为我们将其与自动化联系起来。我们开始配置服务，并根据服务的状态自动调整对该服务的监控。监控工具与现实脱节的日子已经一去不复返了。

从另一方面来看，当您的基础设施或应用程序非常复杂，以至于您需要在其中进行可观测性时，您最好不要手动部署；您将需要某种形式的自动化来应对这种复杂程度。因此，可观测性和基础设施自动化是紧密相关的。

Toshaan： 是的，虽然过去我们专注于配置管理，但我们将着眼于将其扩展到所有类型的基础设施管理。去年，我们尝试了这个想法，并且我们得以举办了很多跨工具的演示。今年，我们通过提供更差异化的内容，将此向前推进了一步。

Matthew：我的一些虚拟化和 Linux 管理员朋友反对说，可观测性是开发人员的责任。如果不只是说“DevOps”，您会如何回应？

Kris： 您所描述的是我所说的“Ooops Devs”。这是一种趋势，即运行平台的人并不真正关心他们运行什么；只要端口 80 正在监听并且节点可以 ping 通，他们就很高兴。这与“Dev Ooops”一样糟糕。“Ooops Devs”是指开发人员抱怨运维人员，因为他们速度慢、不敏捷且反应迟钝。但是，对我来说，您作为运维人员或 Linux 管理员的工作是保持服务运行，而实现这一目标的唯一方法是以团队的形式承担这项任务——与具有不同角色和见解的同事、编写代码的人、设计人员等一起。这是一个共同的责任。而躲在“那是别人的责任”背后，闻起来就不像是在进行协作。

Toshaan： 即使在信息孤岛的黑暗时代，我也认为真正的系统管理员应该关心可观测性、监控和自动化。我认为 DevOps 运动使这一点更加普及，并且更容易获取和公开这些信息。另一方面，我认为纯粹的运维人员或系统管理员已经学会成为团队合作者（或者，他们可能已经消亡）。我喜欢将此比作由不同专业士兵组成的军队单位，他们共同努力完成一项任务；我们有工程师致力于交付产品或服务。

Matthew：在 Devopsdays Zurich 的一次演讲 中，Kris 提出了一个观点，即美国人构建软件是为了收购，而欧洲人构建软件是为了弹性。从这个角度来看，对于想要构建有意义的基础设施的人来说，最好的技能是什么？

Toshaan： 我认为仍然有些人不理解代码蔓延的复杂性，他们认为一些新的炒作会神奇地解决这个问题。

Kris： 今年，我们邀请了 Steve Traugott，他是 1998 年 USENIX 论文“引导基础设施”的合著者，该论文帮助启动了我们的社区。很多人从未阅读过 Infrastructures.org，从未经历过构建镜像和镜像蔓延的痛苦，也不理解我们经历过的演变，这些演变使我们以现在的方式从源代码构建事物。

人们应该学习诸如幂等性、弹性、可再现性和通过十楼测试等主题。（正如“引导基础设施”中所解释的：“我们在设计基础设施时使用的测试是‘我可以抓住一台随机机器并将其从十楼的窗户扔出去，而不会对用户造成超过 10 分钟的不利影响吗？’如果答案是‘是’，那么我们就知道我们做对了。”）但是，只有在他们理解他们正在构建的服务（服务是绝对优先事项）之后，他们才能开始研究诸如以下内容：我们如何运行它，我们如何确保它持续运行，它会如何失败以及我们如何防止这种情况发生，如果它消失了，我们如何才能快速重新启动它，而最终用户不会注意到。

Toshaan： 100% 正常运行时间。

Kris： 我们面临的挑战是，很多人还没有这种经验。我们已经看到了 YoloOps 的兴起——只需启动一次，发射，然后忘记——这会导致安全问题、稳定性问题、数据丢失等，他们经常抓住 YoloOps 中的解决方案，这是一种快速完成某事并继续前进的简单方法。但是，理解事情最终将如何失败需要时间，这被称为经验。

Toshaan： 嗯，当我还是学生并且在 FOSDEM 负责 CentOS 展位时，我记得有一个人走到展位前抱怨说，由于 CentOS 的“发射一次就忘记”策略，他无法进行咨询，而且它运行得太好了。我喜欢称之为 ZombieOps，但 YoloOps 也可以。

Matthew：我看到您也在领导第二年的 YamlCamp。为什么一种标记语言需要自己的大会？

Kris： YamlCamp 是一种模仿，这是一个玩笑。去年，Bob Walker (@rjw1) 发表了一个题为“我们现在都是 YAML 工程师了吗？”的演讲，这引发了更多的笑话。多年来，我们一直在讨论重新命名 CfgMgmtCamp；问题是人们知道我们的名字，我们有足够大的受众可以继续下去，而更改名称意味着要花费精力在徽标、网站、DNS 等方面。我们不会更改名称，但我们开玩笑说我们可以重新命名为 YamlCamp，因为出于某种奇怪的原因，很多演讲都是关于 YAML 的。:)

Matthew：您认为系统工程师应该在他们的简历中将 YAML 列为一项技能或一种语言吗？公司应该招聘 YAML 工程师吗，还是您在网站上“YAML 工程师万岁”只是开玩笑？

Toshaan： 嗯，真正的问题是人们是否愿意自豪地称自己为 YAML 工程师，因为我们已经有足够多的 DevOps 工程师了。

Matthew：哪些 FOSS 软件帮助您管理活动？

Toshaan： 我用 Hugo CMS 重做了网站，因为我们花费了太多时间手动维护网站。我选择 Hugo 是因为我正在学习 Golang，并且因为它已成功用于其他会议和我自己的网站。我还想要一个静态网站和 iCalendar 输出，这样我们就可以使用诸如 Giggity 之类的日历工具来获得一个好的日程安排工具。

现在网站构建得非常好，虽然我仍然有一些改进的想法，但维护现在容易得多。

对于征集提案 (CFP)，我们现在使用 OpenCFP。我们希望优化提交、投票、选择和提取过程，使其尽可能自动化，同时对潜在的演讲者、审阅者和我们自己来说都易于使用和舒适。OpenCFP 似乎是有效的工具；虽然我们仍然有一些功能需求，但我相信，一旦我们有时间回馈 OpenCFP，我们将拥有一个功能齐全且易于使用的工具来运行 CFP。

最后，我们从 EventBrite 切换到 Pretix，因为我想符合 GDPR 标准，并能够运行我们的问题、优惠券和额外功能。Pretix 允许我们控制与会者、演讲者、赞助商和组织者的注册，并对所有参加活动的人员进行单一概述。

总结

对我来说，配置管理大会的美妙之处在于它不断地与其受众一起发展。配置管理当然是工作的核心，但它是为弹性基础设施服务的。请密切关注演讲录像，向 令人难以置信的演讲者阵容 学习，并感谢团队举办这次（免费）展会！

您可以关注 Kris @KrisBuytaert 和 Toshaan @toshywoshy。您还可以查看 Kris 过去的文章 在他的博客上。