详解：全球最大正版流媒体音乐服务平台Spotify是如何管理服务器的 _机器

翻译：孙薇
责编：钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件，另有「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信申请入群，备注姓名+公司+职位。
简介
是全球最大的正版流媒体音乐服务平台，我们拥有大约1.2万台服务器，每当用户登录，浏览个性化推荐列表，并播放某个媒体的时候，就有其中的一些与之互动。

文章插图
出于历史原因，并未使用AWS之类的公共云服务，而是选择了在私有物理服务器机组上运行核心架构。我们的服务器机组已经达到了硬件配置最小化，这些服务器分别位于全世界的四个数据中心。在基于容器的持续集成和持续部署方面（CI/CD），我们大量运用了模型，每台服务器一般都有单独的用途，也就是说大多机器都只运行一个微服务单例。
在，我们认为每个团队都有“运营责任”：即微服务的构建者也负责它的部署与相应服务器的管理。也许大家会以为，让数以百计的工程师管理数千台服务器，还要保证可靠性，情况一定会非常复杂。
在本文中，我们将会详细描述的服务器管理架构进化史，并在技术实现上、这些实现对生产率的影响、对工程师情绪的影响方面讲述一些细节。
2012年以及之前——前序
那时还只是一家小公司，想要有一只传统、集中化的运营团队还是可以实现的。虽然这只团队一直不停地忙于“救火”事宜，同时要完成所有的运营任务，然而他们很聪明，知道不能一直只靠手动来管理日益增长的服务器群。
在，首批用于服务器管理的工具之一就是著名的：负责追踪细节，比如服务器的硬件规格、所处位置、主机名、网络接口以及硬件的唯一名称，每台服务器都有一个“状态”，比如“使用中”、“已坏”或“安装中” 。最初，我们只有一个简单的SQL数据库和一系列脚本，并通过全自动的安装程序（FAI）来完成服务器的安装，管理一般是通过可提供串行控制台访问与电源控制的moob来执行。我们所使用的DNS zone数据，大多是由人工精选出来的，并且需要手动推送才能生效。一旦基本操作系统安装完毕，所有服务器都会由（现在仍是）来管理。
之后该堆栈有很多部分都被替换掉了，FAI先是换成了和-，后来又换成了我们自己开发的Duck 。尽管在配置过程中有很多步骤都是自动执行的，但很容易出错，仍旧需要人类的监督。想要对20台新服务器进行配置，都可能会成为不可预知且非常耗时的工作。工程师们在JIRA上创建资源请求，等待我们来分配，而满足这个请求可能需要几周乃至数月的时间。
2013年末——架构与运营部落
一直很偏爱敏捷团队（按照的说法就是小组）。在2013年末，运营团队被并入了新成立的架构与运营（IO）团队，在运营中针对特定的问题再组建新的小组，而我们的小组全权负责配置和管理的服务器。
一开始，我们预想的是完全自助式的机器管理服务，但由于小组工作非常繁忙：我们应接不暇地处理请求新机器、机器录入（在中记录新的服务器）等事务。于是我们决定从小处开始，先将一些最小可行产品（MVPs）拼凑起来，让最主要的痛点自动化，以便腾出时间做些更重要的事。
我们的努力集中在下面这三个方面：
DNS推送
DNS推送是我们最早获得成功的项目之一。起初，运营团队必须手动编辑DNS zone文件，提交版本控制，再在DNS 上运行脚本，以编译部署新的DNS zone数据。我们逐渐将这个过程自动化：首先我们构建了一个工具，从自动生成大部分的DNS zone数据；然后再添加集成测试与代码机制，从而保证所更改内容的质量。不久之后，我们解决了难题，让推送自动化——我们创建了Cron任务，来自动触发上述过程。最终，类似为新的子域自动创建DNS zone之类的工作总算能够自动搞定了。