InfoQ Geekathon 大模型技术应用创新大赛 了解详情
写点什么

Instagram 的持续部署

  • 2016-05-24
  • 本文字数:3532 字

    阅读完需:约 12 分钟

在 Instagram,我们每天要将后端代码部署 30-50 次(每当工程师将改动提交到主分支以后,就要重新部署)。其中的大部分部署是不需要人为干预的。尽管这种做法看起来很疯狂,尤其是在 Instagram 目前的规模情况下,它却工作的很好。本文就介绍了我们是如何实现该系统并使得它能够很好的工作的。

我们为什么要实现这样的系统

对于我们而言,持续部署有很多好处:

  1. 它使得我们的工程人员可以快速开发。他们可以不受限于每天只能在固定的时间进行固定次数的部署;相反,他们可以在任何有需要的时候部署代码。这就意味着,他们不需要浪费太多时间,而且能够快速的针对变化进行迭代。
  2. 它使得识别错误提交变得更加容易。持续部署使得工程人员不再需要深入分析上千次的提交才能找到一个新错误的根源。相反的,他们只需要分析一次或者最多 2-3 次的提交即可找到错误的原因。当你以后发现一个错误需要去调试时,该方法也会非常有用。指明该问题的量度或数据可被用于识别一个精确的开始时间。而从中,我们就可以找到该时间有哪些提交被部署。
  3. 错误提交可以很快被检测到并进行处理。这就意味着我们不会导致主分支一团混乱,从而导致其他不相关变化的部署时间的巨大延迟。我们总是处于一种可以迅速解决问题的状态。

实现

该实现的成功主要归功于构造的迭代方法。相比于额外的独立构造该系统然后再直接将旧系统全部转换过来的方法,我们采用了迭代策略——针对当前机制进行不断修改,直到他们变成持续部署。

之前的工作机制

在持续部署实现之前,工程师们是依据各自的需要来部署变化的。在代码改动后,如果他们想将其尽快部署,工程师们会运行一次 rollout。否则,他们会等待其他的工程师来运行 rollout。这时候,工程师们需要知道如何进行小规模的测试:他们首先会针对一台机器进行 rollout,登录该机器并检查日志;然后,他们再运行针对整个系统的第二轮 rollout。这个过程被实现为了一个 Fabric 脚本,而且我们拥有一个简单的数据库和 UI——Sauron 来存储 rollout 的日志。

金丝雀版本和测试

第一步就是添加金丝雀——脚本化需要工程师完成的工作。不再针对单个机器运行单独的 rollout,将脚本部署到金丝雀机器,跟踪用户日志,然后决定是否继续进行全面部署。接下来,针对金丝雀机器进行一些基本分析:一个脚本分析每个请求的 HTTP 状态代码,将其分类并使用硬编码的百分比阈值(例如,少于 0.5% 的 5xx,至少 90% 的 2xx)。然后,它只会在超过阈值时向用户发出警告。

我们已经有了一个测试套件,但工程师只在他们的部署机器上运行该套件。代码审查人员不得不相信编码人员的话,认为测试已经通过。而且,我们并不知道提交到主分支后的测试状态。因此,我们安装了 Jenkins 来测试主分支上新的提交,并将结果报告给 Sauron。Sauron 会追踪最近通过测试的提交,并建议在 rollout 时使用该提交(而非最近的提交)。

Facebook 使用 Phabricator 进行代码审查,并使用了能够和 Phabricator 很好集成的持续集成系统——Sandcastle。每当一个 diff 被创建或更新时,我们利用 Sandcastle 来运行测试,并将结果报告给 diff。

自动化

为了能够自动化,我们首先需要完成一些准备工作。我们对 rollout 添加了一些状态(运行中、结束、错误)。如果之前的 rollout 不在“结束”状态的话,脚本会发出警告。我们还在 UI 中添加了一个可以将状态修改为“放弃”的放弃按钮,并使得脚本偶尔去检查状态、做出响应。我们还添加了全部提交跟踪;Sauron 不再仅仅保存最近通过测试的提交,它记录了主分支的每一次提交,并知道每个提交的测试状态。

(点击放大图像)

然后,我们将剩余的、需要由人类来定夺的决定自动化。第一个就是究竟选择哪个提交进行 rollout。初始算法是总是选择一个通过测试的提交并尽可能的少选——绝对不超过 3 个。如果每个提交都通过了测试,它每次只选择一个新的提交,而且没有通过测试的连续提交至多只有两个。第二个决定是 rollout 是否成功。如果超过 1% 的主机无法部署,该 rollout 就被认为失败了。

这里,当若干个“yes”出现的时候(接受建议的提交、开始金丝雀版本以及全部署),进行一次 rollout。因此,我们允许这些问题可以自动回答,并使得 Jenkins 运行 rollout 脚本。刚开始,工程师会在其桌面电脑中监控 Jenkins 的运行。后来,他们发现自动化完全可以正常进行,便不再监控。

问题

当我们在这个阶段进行持续部署时,过程并不顺利。我们需要解决一些问题。

测试失败

工程师们总会遇到无法通过测试的 diff——它们会引起后续的主分支提交无法通过测试,从而使得它们无法部署。相关工程师就需要注意这种情况、撤销引发问题的提交、等待回卷后提交的代码通过测试,并在自动化流程继续之前手动 rollout 所有积压的提交。这极大的损害了持续部署的主要好处之一——每次 rollout 部署极少的提交。其问题在于测试非常慢,而且不可靠。为了解决该问题,我们进行了各种优化,将测试时间从 12-15 分钟缩减到了 5 分钟,并修复了引起测试框架不可靠的一些问题。

积压

尽管进行了很多改进,我们仍然会遇到很多需要被部署的变化积压在一起的情况。最常见的原因就是金丝雀测试失败(有的是误报,有的是真有问题),当然也有一些其他的原因。当这些问题都被解决以后,自动化的过程就可以继续,每次也只部署一个提交。因此,将积压清除肯定要花费一定的时间,而且会引起新的 diff 的巨大延迟。这时候,工程师会介入,一次部署所有的积压——这大大损害了持续部署的主要好处之一。

为了改善这种局面,我们在提交选择逻辑中实现了积压处理——当积压出现时,系统自动部署多个提交。其算法的基本想法是为每次提交设定一个时间线(30 分钟)。对于队列中的每个提交,它会计算满足时间要求的剩余时间、在剩余时间内能够完成的 rollout 数目以及每个 rollout 需要部署的提交数。它会选择最大的提交 /rollout 值,但上限为 3。这使得我们可以在保证提交的 rollout 时间上限的情况下,完成尽可能多的 rollout。

积压的一个特殊原因是随着框架规模的扩大,rollout 变得越来越慢。我们已经到了一个尴尬的境地——ssh-agent 钳住了整个认证 SSH 连接的核心,而 fab 主进程钳住了管理所有任务的核心。其解决方案是切换到 Facebook 的分布式 SSH 系统。

指导原则

那么,为了实现我们已经完成的系统,我们需要哪些东西呢?以下就是我们能够使得系统很好工作的一些关键原则,供大家参考:

  1. 测试:测试套件需要运行速度快。它需要有合适的覆盖率,但并不需要非常完美。测试需要经常运行:代码审查阶段、landing 前后。
  2. 金丝雀:你需要一个自动化的金丝雀,来防止错误提交部署到整个系统。它不需要十分完美,但即使一个简单的统计和阈值集合也就足够了。
  3. 自动化正常的情况:你不需要自动化每一种情况;只需要自动化已知的、正常的情况。如果出现非正常的情况,将自动化过程停下来加入人工参与。
  4. 使得人们感觉良好:我认为,这类自动化的一个巨大障碍就是人们觉得失去连接和控制的时候。为了解决该问题,系统需要提供它已经完成、正在进行以及将要进行的工作的内容。它还需要好的停止机制。
  5. 预见到错误部署:错误的改变总会出现,但没关系。你只需要迅速发现这种情况,并能够迅速回卷。

以上就是很多其他公司都可以实现的内容。持续部署系统不需要复杂。从专注以上原则的简单东西入手,然后慢慢改善。

未来

现在系统运行正常,但我们仍然需要解决一些挑战以及进行一些改善:

  • 保持系统快速:Instagram 正在快速发展,而提交的速度也会持续增加。我们需要保持 rollout 的快速,以使得每个 rollout 的提交数目可以保持在 3 个以内。一个可能就是将 rollout 划分成多个阶段,并用流水线来实现。
  • 添加金丝雀:随着提交速度的增加,金丝雀失效和积压会越来越影响开发人员。我们希望能够阻止错误提交影响到主分支,从而影响部署。因此,我们正在将金丝雀实现为 Landcastle 的一部分。在测试通过以后,Landcastle 会利用生产环境流量来测试改动。如果改动未通过金丝雀阈值,Landcastle 会放弃金丝雀部署。
  • 更多的数据:未来,我们希望改进金丝雀的检测能力。因此,我们正在规划收集和检查更多的统计数据,比如每个视图的函数响应代码。我们也正在尝试从一堆控制机器中收集统计数据,并将其与金丝雀统计数据进行比对(而非现在的所采用的,与静态阈值进行比对)。
  • 改进探测:如果能够减少没有被金丝雀发现的错误提交的影响,那就最好了。之前,我们总是先在一台机器上进行测试,然后再将其部署到整个系统。未来,我么可以添加更多的中间阶段(一个集群或一个区域),然后在这些阶段检查相关的量度。

感谢谢丽对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

活动推荐:

2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。

2016-05-24 17:142194
用户头像

发布了 268 篇内容, 共 114.8 次阅读, 收获喜欢 24 次。

关注

评论

发布
暂无评论
发现更多内容

VUE 项目本地没有问题,部署到服务器上提示错误

HoneyMoose

[Go WebSocket] 多房间的聊天室(一)思考篇

HullQin

Go golang 后端 websocket 9月月更

nft系统开发

开源直播系统源码

区块链 NFT 数字藏品 数字藏品软件开发

Qt|自定义Widget实现互斥效果问题

中国好公民st

qt QWidget 9月月更

JavaWeb -JavaBean MVC Filter 监听器 过滤器

喜羊羊

9月月更

C++学习------cmath头文件的源码学习01

桑榆

c++ 源码阅读 9月月更

每日一R「23」回顾基本概念

Samson

学习笔记 ​Rust 9月月更

融云 x KUPU:印尼蓝领用工的「直聘」样板

融云 RongCloud

互联网

【JavaWeb】Servlet系列——HttpServletRequest接口详解

胖虎不秃头

Web java; 9月月更

【JavaWeb】Servlet系列——使用纯Servlet做一个单表的CRUD操作

胖虎不秃头

Web java; 9月月更

Linux系统安装Redis

Centos 7 redis 底层原理 9月月更

有效预警6要素:亿级调用量的阿里云弹性计算SRE实践

阿里云弹性计算

监控 预警 SRE实践

网络IO是如何一步一步走向零拷贝的

C++后台开发

cpu 零拷贝 C++后台开发 网络io C++开发

计网复习二,网络应用

前端小刘不怕牛牛

计算机网络 HTTP 9月月更

【C语言深度剖析】详解strlen与sizeof的区别及用法

Albert Edison

C语言 sizeof 9月月更 strlen

讲究卡路里多少的美食出圈了!维小饭被评为“2022中国轻食十大品牌”

联营汇聚

javaweb-JSP

喜羊羊

9月月更

线上直播预告:数据库人才培养创新与变革

阿里云数据库开源

数据库

Elasticsearch6.1.2源码下载和编译构建

程序员欣宸

elasticsearch 9月月更

2022-09-08:以下go语言代码输出什么?A:5 66;B:5 88;C:7 88;D:以上都不对。 package main func main() { var x = []int{4:

福大大架构师每日一题

golang 福大大 选择题

Zilliz 论文入选数据库顶会 VLDB'22

Geek_2d6073

SpringBoot源码 | prepareContext方法解析

六月的雨在InfoQ

springboot 源码阅读 9月月更 prepareContext

Zilliz 论文入选数据库顶会 VLDB'22

Zilliz

数据库 分布式 云原生 VLDB'22

数据治理(十一):数据安全管理Ranger初步认识

Lansonli

数据治理 9月月更

leetcode 437. Path Sum III 路径总和 III(中等)

okokabcd

LeetCode 数据结构与算法

mysql基本类型

急需上岸的小谢

9月月更

转转商业化OCPC产品的护航之旅

转转技术团队

人工智能 计算广告 PID OCPC

SD-WAN应用选路方案

阿泽🧸

SD-WAN 9月月更

Java终极学习路线-共计9大模块/6大框架/13个中间件

小明Java问道之路

Java 架构 JVM 中间件 9月月更

ChaosBlade Java 场景性能优化,那些你不知道的事

Java快了!

java;

计算机网络——分层结构

StackOverflow

编程 计算机网络 9月月更

  • 扫码添加小助手
    领取最新资料包
Instagram的持续部署_语言 & 开发_张天雷_InfoQ精选文章