27天备战春晚红包项目，字节跳动背后这朵“云”很关键

12月2日，火山引擎的全系云产品正式亮相。

依托于字节跳动云原生理念和实践，火山引擎推出了78项云产品服务，涵盖云基础、视频及内容分发、数据中台、开发中台、人工智能等5大类。

过去9年，字节跳动持续建设IT基础能力。如今，我们已经实现每天新增1500个AB实验和2万次线上变更，3周完成设计和上线新APP，27天备战春晚红包项目。

在这些敏捷迭代和创新背后，“云”都发挥了关键作用。那么，过去9年里，字节跳动是如何建设云的？字节跳动副总裁、火山引擎业务负责人杨震原和大家聊了聊我们的云实践。以下为演讲全文：

早上好，欢迎大家来到火山引擎云产品发布会。特别感谢大家一直以来对火山引擎的支持。

今天火山引擎云产品发布会的主题是“新云，共未来”，不管是新朋友还是老朋友，大家都知道我们要发布云产品。火山引擎是字节跳动技术能力的输出。火山引擎的云产品，也是基于字节跳动的理念和实践来建设的。今天我要跟大家分享的，就是字节跳动在发展的历程中是怎么建设云的。

IT基础建设的目标：敏捷

要讲这个话题就要回到很多年前。当时我们公司还很小，主要有一个核心产品今日头条。按照公司一直以来的做事风格，我们在讨论IT基础建设时，首先就在讨论，我们的目标是什么。直到现在我还记得很清楚，我们定下来的核心目标就是敏捷，就是要快。

当时，今日头条是一个全新的移动互联网产品，我们有着去建设全球最大内容分发平台的愿景。我们每天都会有很多想法、很多讨论，包括内容体裁、创作工具、产品交互、推荐算法等等，每天都在变。如果这些想法能更快实验、更快发布，就会给公司带来很强的竞争力。如果有想法但不能快速上线，就会给公司发展造成很大的风险。

我们实现了敏捷的目标，产品增长很快，大家觉得建设敏捷的IT基础效果很好。这个理念一直延续到现在。

但是，只关注敏捷是不行的，因为还有很多问题。我们需要考虑到稳定性、综合成本，不能说做得非常快，但成本很高；还要考虑到运维的复杂度等等。实现敏捷目标的同时，不能让稳定性等问题成为短板。

在介绍我们怎么做云之前，首先分享一些案例。外界有些人说字节跳动好像是一家APP工厂，虽然并不准确，但我们做产品确实是非常快的。有些新的产品从开始有想法，我们决定要做，只用三周时间就能发布上线，这个基础就是围绕着敏捷目标建设的云。

再分享一个案例。去年距离除夕只有27天的时候，我们的产品技术团队收到了参加央视春晚红包互动的通知。这个活动很复杂，有很多环节。大家也知道，春晚是一个突发用户量非常大的事情，只有27天的时间，要做方案的设计、资源的准备、产品开发上线，最后我们顺利完成了这个工作。而在以前，这类活动一般都会有3个月的准备时间，而且都是互联网大厂在有很多资源准备的情况下完成的。

再列一些数据。第一个是数据中心的天级部署。这是什么概念？当我们交付了一个新的数据中心，我们的物理服务器上架联网之后，部署业务以及切流，只要一两天就可以完成。这也是因为我们自建数据中心以及在全球范围内用了很多云的供应商，不断迁移，锻炼出了这一套能力。

第二个数据，我们每天线上变更是两万次。云的能力，让业务有非常灵活调整的空间。

第三个数据是我们每天新增大约1500个A/B测试，说明我们有很多想法的时候可以快速验证，就会产生进化。我再举个例子，假设有两家公司，他们的方向一致，战略水平也差不多，如果一家公司每个星期能做10个A/B测试，验证10个想法，另一家公司每个星期只验证1个想法，可以想象经过半年之后，两家公司会拉开多大的差距。所以说当方向、战略差不多的情况下，敏捷就是决定竞争力的关键因素。

如何做到敏捷开发？

首先是对业务有宏观设计，对整体架构做合理分层。因为不可能所有地方都敏捷，一些更偏应用、更频繁改动的部分需要敏捷，一些基础的模块需要更稳定、更高性能。我们要对业务有宏观的设计，这样可以把不同子系统放到对应的位置上去。如果胡子眉毛一把抓，什么地方都想快，这是错误的，而且也是很难实现的。

有了宏观的设计，接下来说具体的实现方法：第一是微服务化，拆更小的服务单元，从开发上就可以有利于快速地变更，这些服务单元能够在很多业务系统中灵活组合以及多人并行开发。微服务是提高开发效率非常重要的一点。

第二个是容器化，这个概念我相信在座各位都比较了解。容器对于运维体系来讲有点像集装箱对于货运，可以解决环境部署的问题、隔离的问题、资源分配的问题。容器本身的开销可控，未来还有进一步提高灵活性的空间，以及重组的空间。

是不是有这些技术之后就很美好了？我想说的是，从实践来看，问题才刚刚开始。

比如说运维、质量和发布体系的问题。有了大量的微服务，一旦有一个服务出问题，会导致故障的影响面不可控，排查很麻烦。做过运维的同学会了解，有可能会产生服务雪崩。另外，当我们想扩容的时候，怎么样在一条服务链路的依赖体系下比较自动地扩容，还有灰度发布问题，还有很多其他的问题。如果这些问题处理不好，你会发现你的发布是变快了，但维护代价也在成倍增加，渐渐地就敏捷不起来了。

所以我们做了大量投入，建设完善的DevOps体系，包括持续集成的流程、平台、线下测试环境、灰度发布、全面的监控系统、容灾系统、故障半径分析与治理、自动缩扩容等。直到今天我们还一直在做，就是让开发人员更关注业务本身，其他麻烦事儿让平台解决。

第二个是存储的易用性问题。微服务化之后，存储成为限制敏捷开发的一个关键因素。

存储是一个技术很复杂的领域，专业性很强，目前还没有一种可以应用于各个领域的存储技术，我们需要建立一套产品矩阵来满足需求。通过存储计算分离、架构改进、容器化部署、自动运维工具等等，来达成更优的存储方案。

第三是性能优化。前面做了这么多敏捷、自动帮助开发者降低成本的事情，都是有代价的，性能损失就是其中之一。如果不去改进，从系统延迟和综合成本两方面，都会遇到挑战。我们做了大量的性能优化工作。

经过多年的技术实践，我们的在线微服务数量超过10万，这是指微服务的类型，确实是很大的一个数字，我自己都觉得可能有点太大了；我们容器实例部署的规模大概是1000万的量级，应该是国内容器规模最大的企业之一，目前我还没听到过其他企业公布过更大的数字。我们在微服务和容器的使用上是非常极致的。

云原生理念的实践

我刚才讲的字节跳动建设云的实践，和云原生概念是非常契合的。

云原生这个概念，也火了很多年了。它的本质是什么？我自己感觉，云原生就是软件研发体系向前发展的一个过程。

大家想下，计算机刚刚被发明的时候，人们写机器代码太麻烦了，程序员都怕麻烦，于是有了高级编程语言，编译器；人们自己定义各种数据存储格式，读写存储非常麻烦，还容易出错，于是有了数据库；人们已经写了软件，想用的时候，还得买机器，租机房，部署网络，太麻烦了，于是有了云计算。

那么，现在还有哪些事情太麻烦？还有很多，我上面提到了一些问题，其实现在也还有很大的进步空间。

所以，我觉得云原生，就是考虑云上的软件开发、维护全流程，去改进各个子系统，目标就是让开发人员更聚焦在业务本身，让云平台去解决其他的“麻烦事儿”。

基于敏捷开发的理念，字节跳动不断改进系统，就是希望让开发人员更聚焦在业务上。这让我更加相信云原生这个理念，因为这个理念是有实践基础的。

高密度计算、数仓与底层硬件探索

接下来再分享下我们在云实践过程中的三点经验。

第一点是高密度计算。业务系统有很多类型，有些系统用非常敏捷的方式是好的。另外有些系统比如推荐、搜索、广告、视频理解，这些系统的计算密度很高，服务粒度要稍微大一点。当我们在这些系统上做敏捷的时候，可能要选择用插件化的方式去加速它的开发和迭代，这是一类高密度计算的问题。

第二点，数仓的问题。字节跳动的核心技术理念是数据驱动和敏捷开发，我们需要全面的数据平台。我在2014年初刚入职的时候，发现公司已经有一个小时级可以看到结果的A/B测试平台，之后我们也一直都在践行数据驱动理念，让新的产品发布、新的功能可以很方便地做A/B测试。所以我们在敏捷开发的同时，需要保证数据平台有很高的数据准确性、一致性、稳定性。

这里列一些规模和效率的数据。现在我们数据仓库本身，不算视频和机器学习的数据，总量已经到了9500PB的规模，每天新增40PB左右，指标数超过27000个。在这样的一个体量之下，我们依然能够很快地去做新产品的数据支持。一个全新的产品线，大概需要两周时间就可以完成所有核心数据的分析，包括数据报表建设等工作。

第三点，底层硬件的技术探索，这肯定是基础的事情，我们也有很多的投入，比如自研服务器、DPU、AI芯片、数据中心技术等等。这里不展开介绍，未来可以和大家做更多展示。

以上就是我对字节跳动建设IT基础的一些思考。这些技术、这些实践全部都会在火山引擎云产品中开放给我们的客户，希望能够帮助更多的企业，这样也会产生更大的社会价值和商业价值。

这就是我今天的分享，谢谢大家！

编辑 宋钰婷 校对 卢茜

（王治强 HF013）