字节跳动是什么，对字节跳动有什么了解（你好，这里是十年前的字节跳动）

关于【字节跳动是什么】，对字节跳动有什么了解，今天小编给您分享一下，如果对您有所帮助别忘了关注本站哦。

• 内容导航：
• 1、字节跳动是什么：你好，这里是十年前的字节跳动
• 2、字节跳动是什么，对字节跳动有什么了解

1、字节跳动是什么：你好，这里是十年前的字节跳动

2012 年底，加入字节跳动的 Samuel 仍在使用非智能手机。他没用过公司早期开发的任何一款 App，却决心辞去大厂工作，加入这家创立于民宅的团队。

原因并不复杂，他认同这家公司的初心：希望把人和信息连接在一起，提高信息分发的效率。

随着产品和用户规模扩大，这份初心承载了更多意义和责任，几经讨论，最终被提炼为字节跳动的使命，“激发创造，丰富生活”。回顾十年间我们所做的很多产品和业务决策，都没有偏离这个航向。

在公司十周年之际，我们找到了一些创立初期的“老照片”，希望可以提供一些线索，试图还原当初我们从哪里出发，以及更重要的是，为什么出发。

｜消除“早知道就好了”的遗憾

2012 年，互联网处于从 PC 端加速转向移动端的阶段。

初创团队看到了移动互联网的趋势，并意识到在移动端获取信息将是一个很大的需求。在这样的场景下，做好信息分发将可能提升社会的效率，创造价值。所以大家常说：“希望可以消除‘早知道就好了’的遗憾。”这也是我们创业的初心。

具体怎么做？团队进行了一次讨论：信息可以抽象出“体裁”和“主题”两大维度，体裁包括图片、长文、短文、视频等，而主题又可以覆盖学习、娱乐、生活等。最后，团队决定以图片作为切入点并上线了第一款App“搞笑囧图”，没想到一个月内注册用户就达到了 100 万。

一鸣写下对信息分发的理解

｜为什么是 ByteDance？

公司的中文名“字节跳动”和英文名 “ByteDance” 几乎是同时有的。

为什么是 ByteDance？团队最初要做信息分发，本质也跟信息流动有关，而信息的最小单位就是字节。起名字时，大家闭上眼睛想，感觉有很多字节在跳动、流动、舞动。当时还有人提议是不是可以叫 ByteJump，汝波当时觉得 ByteJump 不是特别有感觉，在他的提议下，ByteDance 这个名字诞生。

中文名也有很多备选：字节跳动、字节舞动、字节跳跃......虽然“字节舞动”最接近 ByteDance 的直译，但团队觉得“舞动”会让人联想到舞蹈机构，最终选了“字节跳动”。

汝波在锦秋家园的其中一间卧室办公

｜好好吃饭，好好工作

第一间办公室锦秋家园是一间三居室。选择民宅当办公地，主要为了方便大家都住在附近，而且不担心晚上空调被关掉，还能给大家做饭提供三餐。

早上来上班去厨房取早点，厨师会笑咪咪地跟同学们聊这一天的伙食安排，坐在工位上就能够闻到厨房里正在烹饪的菜肴。为什么要配厨师？因为当时招聘亮点之一就是拒绝地沟油、提供健康的一日三餐。

公司早期的大厨

｜空间有形，梦想无限

锦秋家园的办公环境简朴，工程师挤在客厅的几张长桌前办公。不太敢伸腿，否则容易踢到对面的同学。但这小小的空间没有阻碍大家的想象力，每次定产品目标，都会有同学觉得“这是不是太激进了”，但回过头看基本每次都能达成。

今日头条的 DAU 从 100 万到 1000 万，仅用了 1 年多时间。

随着用户规模迅速扩大，团队也数次讨论公司目的和意义。我们打造平台，让用户分享自己的创意和表达，最重要的是，让用户看到更大的世界。

经过多轮思考和讨论，“激发创造，丰富生活”的使命最终成为大家的共识。

大家围在桌子前 coding

｜站在阳台上讨论业务方向

锦秋家园的阳台也承载了不少回忆：大家常常在这里聊骑行，聊最近用户有什么吐槽，或是讨论业务战略方向。

比如是不是要用推荐的方式做信息分发，初创团队也站在这里讨论过。相比传统门户网站依靠人工编辑推荐，有没有更系统性的解决方案？但创业团队的技术条件不好，为什么要做？做了会成功吗？

讨论过后，大家认为推荐系统能够真正解决“个性化”的问题。后来，就有了一鸣自学写出第一版推荐系统的故事。这版系统经历了数轮迭代，在今日头条、抖音等产品的成长中发挥了重要作用，而推荐也成为互联网信息分发的主流模式。

锦秋家园阳台上的景色

｜第一版 A/B 测试系统

创业初期公司知名度低，为招聘增加了不少难度。

但当时我们有一个反常规的“套路”：请这些候选人来公司做分享。这建立了候选人跟团队交流的机会，也能帮助他们更直观感受到这家公司的文化氛围。2012 年底，Samuel 也是通过这样分享的形式被字节吸引。“大家很想把事情做成，”是他跟大家交流后的感受。

几个月后，他在这里开发出公司第一版 A/B 测试系统。时至今日，第一版测试系统已经升级为内部广泛使用的 Libra 平台，支撑产品命名、交互设计和广告优化等方方面面的业务决策，每天同时进行的 A/B 测试达到上万场。

Samuel 在锦秋家园

｜没有总部大楼

2013 年 5 月，字节跳动迎来了第一次搬家，搬入盈都大厦 10 层。

搬家前，公司内部还发起了一次集体决策。700 平米、带落地窗的盈都，给团队的第一感觉是“太奢侈了吧”。大家没想到的是，业务成长速度飞快让几十人的团队迅速扩张到几百人，这 700 平米的办公场地很快不够用了。

2016 年 2 月，我们又从盈都搬到了中航广场。

在《新办公室第一天》的全员信中，一鸣提示大家要警惕“大公司心态”，相比精致的办公环境，我们更应该把注意力放在产品、用户、候选人上。这也是我们虽然有数百个办公室遍布全球，但依然没有总部大楼的原因。

盈都和中航的 Day 1

｜把公司当成一个产品来打造

除了打磨产品服务外部用户，我们一直有一个理念：“把公司当成一个产品来打造。”而公司这个产品最重要的用户就是员工。提供好用的工具，帮助大家更便携地表达和交流，也是打造公司这个产品重要的要素之一。

2013 年，团队内部就提出有没有可能自己做一个即时通讯工具（IM），但自研 IM 工程师至少要一百人，而当时全公司的工程师加起来也只有五十多个。不过，在使用过多款市面上的 IM 后，大家还是觉得不符合预期。

2015 年，公司决定加大对内部工具的投入，因此建立“效率工程”部门，由汝波作为负责人。飞书、People、字节圈等管理工具就是最初由这个团队孵化出来的。

效率工程部门双月会讨论 OKR 系统的 OKR

｜用户边炒菜边配合测试

对于用户体验的重视，是公司延续下来的做事风格：2012 年人员规模还很小的时候，公司就专门招了一位同事做用户反馈，每天发全员邮件同步用户的真实感受。

2013 年国庆假期前，广东地区很多用户反馈头条刷不了，刚准备下班的秋良直接回到工位前开始查问题。团队迅速联系到几个用户，想办法知道用户拿到的数据是怎样的，并做了测试包发给用户。

当时有一位用户一边炒着菜，一边跟他通话帮忙测试。“很多用户是愿意配合的，因为产品能给他带来价值。”这也令秋良倍受触动。

秋良和汝波

｜堵在门口的创作者

在产品孵化阶段，团队就明确了今日头条并不是一个新闻客户端，而是覆盖创作、分发、讨论等各种内容的信息平台。

2014 年 1 月，今日头条的内容创作平台“头条号”上线。次年 9 月，公司举办了第一届头条号创作者大会。因为缺乏经验，前期没有规范的报名和筛选流程，并预估人数租了个场地。结果当天所有人都傻眼了，“没想到来了这么多创作者堵在门口，进不去了”。

也是在那个时刻，大家意识到这个初心已经阶段性地达成——头条号让越来越多人体验到创作的乐趣和价值。回过头看，这也标志着我们从信息分发进入创作，是“激发创造，丰富生活”的重要尝试之一。

｜三次讨论是否要做短视频

2015 年 1 月，日本冲绳团建。结束白天的游玩，晚上一二百号人挤在餐厅里参加年会，这一年的年会主题是“巨变的时代”。目标很远大，但过去每年的目标又恰好都能达成，所以大家都深信不疑。

同样是在冲绳，一鸣和汝波等十几个同事在居酒屋进行了第二次讨论。2014 年讨论过一次，当时大家精力顾不过来，但短视频的机遇已经悄悄涌现，当时很多人会觉得“是不是已经晚了”。

2016 年底，公司第三次讨论觉得还是不能放弃，要大力尝试。不仅要做，还要做两款（抖音和火山），不仅在中国做，还要在全球做。于是，2016 年我们先尝试直播，后来又做短视频。这也成了我们让数亿用户在平台上分享和创造的起点。

冲绳年会

十年过去，少有人能想到那支小小的创业团队能走出这么远。即便很多时候资源和条件还不够完善，但大家有更高的目标，基于使命驱动，愿意投入更多时间精力去做正确的事情、做难的事情。

现在，十几万名优秀的 ByteDancer 共同加入到这份事业中来，打造了更多产品和服务，激发出每个人的潜能，让更多的人和组织享受创造的过程并实现个人价值。放到更大的时间维度去看，这也将是一段精彩、有意义的旅程。

2、字节跳动是什么，对字节跳动有什么了解

埋点数据作为推荐、搜索、产品优化的基石，其数据质量的重要性不言而喻，而要保障埋点数据的质量，埋点验证则首当其冲。工欲善其事必先利其器，要做好埋点验证会面临很多技术挑战：易用性、准确性、实时性、稳定性、扩展性，如何攻克这些挑战呢，其实还是技术，这也是本文的主旨所在。

目前埋点验证已在字节内部得到广泛使用，通过一键扫码开启验证、实时上报验证、自动生成验证报告，解决了埋点数据验证难、埋点质量保障难的问题。

• 埋点生命周期：4 6
• 4 个角色：PM、DA、RD、QA
• 6 个节点：提出需求、设计埋点、开发埋点、测试埋点、上报埋点、分析埋点
• 埋点验证流程：3 3 3
• 3 个角色：DA、RD、QA
• 3 个节点：设计埋点、测试埋点、验收埋点
• 3 个物料：埋点验证方案、埋点验证工具、埋点验证报告

先简单介绍一下产品，以便大家能对平台有整体认识，方便大家更加轻松地理解技术，平台主要包括三部分：埋点验证方案、埋点验证工具、埋点验证报告，三者相辅相成，极大的降低了用户的埋点验证成本。

• 附埋点验证工具图

埋点验证的链路很长，可以简单概括为三个环节：埋点上报、埋点接收、埋点验证，每个环节都有一定的复杂性，此处先介绍整体流程，让大家可以快速对全流程有所认识。其次将主要聚焦于“埋点验证”环节，此环节的重中之重是埋点验证引擎，它包括 4 个部分：规则生成器、规则选择器、埋点验证器和埋点推送器，通过对埋点验证引擎的详解让大家对“埋点如何验证”有更深的理解。

• 埋点上报环节重点是丰富的 SDK(客户端、服务端、JS、Chrome 插件)，要做到简单易用并且保证埋点实时上报。
• 埋点接收环节重点是数据接收服务(客户端-applog、Web 端-mcs、服务端-databus)、数据保存服务(消息队列)，要保证服务稳定并且保证埋点不丢失。
• 埋点验证环节重点是埋点验证引擎，要确保服务高性能并且保证埋点验证结果的准确性。

规则生成器将“埋点验证方案”转换为“验证规则”。埋点验证方案是验证规则的逻辑视图，方便用户操作，降低验证规则的编写和维护成本。通过逻辑视图和物理视图两层逻辑，确保了埋点验证引擎底层不受业务变化的影响。

埋点方案

埋点验证方案支持 2 种：

• 按需求验证：即新建需求计划，针对某次需求验证、
• 按元数据验证：即按元数据验证，元数据是指所有需求的并集

按元数据验证：

• 埋点名称：video_play
• 参数信息
• (名称、类型、是否必填、值校验、是否是场景条件)
• enter_from,string,必传,固定值(login),是
• duration,integer,必传,值无限制,否
• type,integer,必传,枚举(1,2,3),否

埋点数据：

{ "app_id":100, "event":"click", "params":{ "enter_from":"login", "duration":1, "type":3 }}

埋点规则

{ "app_id":100, "event_name":"video_play", "logical_filter":{ "enter_from":"login" }, "meta":{ "required_field":[ "duration", "enter_from", "type" ], "scene":{ "condition":"enter_from=login", "name":"登录页" }, "validate_field":[ "duration", "enter_from", "type" ] }, "physical_validation":"{"$schema":"https://json-schema.org/draft/2019-09/schema","type":"object","properties":{"params":{"type":"object","properties":{"duration":{"type":"integer"},"enter_from":{"type":"string","enum":["login"]},"type":{"type":"integer","enum":[1,2,3]}},"required":["duration","enter_from","type"]}},"required":["params"]}", "source":"schema_scene"}

埋点规则字段说明

• app_id：应用 id
• event_name：埋点名称
• logical_filter：用于“规则选择器”
• physical_validation：用于“埋点验证器”
• source：区分规则来源：按需求验证、按元数据验证

规则选择器将依据“埋点”中的关键信息，从“验证规则池”中选择出对应的“埋点验证规则”。

• 选择逻辑：具体数据参考“规则生成器”
• 根据“埋点数据”中 app_id 和 event 从“验证规则池”中筛选出“匹配的规则”
• 将“埋点数据”的 parms 字段和“匹配的规则”的 login_filter 规字段进行匹配，选择出最终的“埋点验证规则”

埋点验证器将依据“基础验证规则”以及“规则选择器”产出的“埋点验证规则”，对“埋点数据”进行验证并产出“验证结果”。

• 基础验证规则：埋点是否登记；埋点是否禁用；是否是 debug 埋点；
• 埋点验证规则：参数是否丢失；参数类型是否正确；参数取值是否符合预期:枚举、范围、正则；
• 埋点验证结果：验证结果提供双语格式，用户可自行选择中文或者英文；

埋点推送器将“埋点验证结果”推送到前端，推送的过程存在数据交互频繁、数据体积大、数据传输稳定性的要求，这里我们自建 Push 服务进行数据传输，保证数据实时可达。

• 易用性：快速接入埋点验证，快速开始埋点验证
• 准确性：埋点验证结果准确、用户可信
• 实时性：埋点数据实时可见
• 稳定性：埋点数据可靠不丢失
• 扩展性：快速接入新的埋点数据格式

快速接入埋点验证，快速开始埋点验证

• 快速接入埋点验证
• SDK 提供“埋点验证开关”，客户端集成 SDK 的时候，可根据不同环境来配置是否开启“埋点验证开关”
• SDK 层判断如果开启“埋点验证开关”，埋点数据会双发，此过程对业务是透明的
• 双发的原因或者为什么不从“线上埋点通道”取数？这里主要考虑两个原因：
• “线上埋点通道”数据量太大
• SDK 层线上上报逻辑是采用微批的形式，默认 1 分钟从客户端上报一次，而埋点验证要求实时性，所以采用单独的通道

端

SDK

如何开启埋点验证开关

客户端

Android SDK IOS SDK

Android、IOS 提供 API，开关默认是关闭的，业务侧集成的时候可选择在“域内测试包”打开此开关

服务端

Go SDK Java SDK Python SDK

服务端会自行判断是否是非线上环境，如果是非线上环境，会默认开启“埋点验证开关”

web 端

JS SDK 浏览器插件

1. JS SDK 采用和客户端 SDK 一样的逻辑 2. 为了使用方便，我们也提供了浏览器插件，用户只需打开此插件即可，无需关注“埋点验证开关”

• 快速开始埋点验证
• 连接流程
• 建立 WS 连接：服务端和验证平台建立长连接，用于通信
• ws_id：验证平台根据 ws_id 生成二维码
• 扫码：客户端扫描二维码
• 获取并打开验证开关：客户端获取设备信息并且打开埋点验证开关
• 上报 device_id：客户端将长连接信息和设备信息上报至服务端
• 下发 device_id：服务端将设备信息推送到验证平台
• 开始验证：埋点验证平台进入验证阶段
• 上报埋点：客户端开始上报埋点
• 推送埋点：服务端将埋点推送到验证平台
• 下发原理
• 客户端上报的埋点数据中含有设备信息
• 用户通过扫码在验证平台回填设备信息
• 服务端接收到埋点数据后，将埋点数据中的设备信息和验证平台的设备信息进行匹配，如果匹配则将埋点数据进行下发

埋点验证结果准确、用户可信

埋点验证引擎必须保证埋点验证结果的准确性，才能降低验证成本。针对埋点数据本身的格式验证，我们采用了 JsonSchema 作为验证手段，以支持完善的验证规则、可信的验证结果。上文中的“规则生成器”、“规则选择器”、“埋点验证器”也都在一定程度上保证了埋点验证结果的准确性。

event:video_play

• 埋点名称：video_play
• 参数信息
• (名称、类型、是否必填、值校验、是否是场景条件)
• enter_from,string,必传,固定值(login),是
• duration,integer,必传,值无限制,否
• type,integer,必传,枚举(1,2,3),否

jsonSchema

{ "$schema":"https://json-schema.org/draft/2019-09/schema", "type":"object", "properties":{ "params":{ "type":"object", "properties":{ "duration":{ "type":"integer" }, "enter_from":{ "type":"string", "enum":[ "login" ] }, "type":{ "type":"integer", "enum":[ 1, 2, 3 ] } }, "required":[ "duration", "enter_from", "type" ] } }, "required":[ "params" ]}

event:video_play

{ "app_id":100, "event":"click", "params":{ "enter_from":"login", "duration":1, "type":3 }}

event:video_play

• 测试地址：https://www.jsonschemavalidator.net/

埋点数据实时可见

埋点验证场景下，服务端和验证平台需要频繁地进行数据交互，所以我们自建了 Push 服务(基于 WebSocket 的封装)，能够保证数据的实时畅通性

1. 基于 WebSocket 实现一套通用长连接通讯协议，能实现同一个客户端上的不同业务共享同一个长连接通道，并实现可靠的心跳机制。
2. 客户端和服务端基于通用长连接通讯协议实现一个稳定可靠的全双工通道。
3. 客户端实现一个通用的 SDK，服务端实现一个通用接入层。
4. 客户端 SDK，服务端接入层，都要很方便后续 service 接入。
5. Push 服务定期做打点监控，同时开放 http 的 Admin 接口，方便系统的监控和查看服务状态

1. 连接稳定性：Push 服务分为两个组件 Push 和 Backone，实现了业务和推送解耦。push 面向客户端连接，设计尽可能简单，需保持大量客户端活跃连接，避免了业务服务更新时不影响客户端连接
2. 服务隔离性：不同的业务服务接入 push 服务，会根据接入信息做集群隔离，避免业务之间互相影响
3. 横向扩展性：当业务服务不断增多时，只需对 push 服务做横向扩容即可支持

埋点数据可靠不丢失

1. 定义：服务级别协议 (service-level agreement，即 SLA) 是服务提供方与客户之间的正式承诺，用来量化服务水平(质量、可用性、责任)
2. 埋点验证服务：服务的特征是实时，所以衡量埋点验证不可用的手段是“数据延迟”，即埋点从“上报”->“验证平台”的 p99 超过 3s 即视为不可用，日常 p99 在 1s

可用性

双月故障时间

年故障时间

99.9%

86.4m

8.64 h

• 为了保证“SLA”，我们做了一系列的保护措施
• 日志转换器：客户端、服务端、web 端上报的是原始日志格式，需要转换为埋点验证日志格式后进行验证

措施

说明

监控

为了保证线上服务的稳定性，对线上流量进行监控，支持按 app 粒度进行查看 app 粒度的 QPS，以便发生报警的时候，可以快速定位到具体是哪个 app 的流量异常

报警

对线上流量进行报警，报警策略的设置如下：- 当前 QPS 达到最大 qps 的 50%的时候，报警级别为 warning，提示需要注意- 当前 QPS 达到最大 qps 的 70%的时候，报警级别为 critical，提示必须处理

限流

当发生报警的时候，通过监控定位出具体 app，做如下处理：1. 针对此 app 数据进行限流，确保其他 app 不会受到影响 2. 联系 app 业务方，确认此 app 流量是否为异常流量 3. 如果是异常流量，对异常流量进行处理，处理后撤销限流 4. 如果是正常流量，那么埋点验证服务进行处理

降级

实时验证流程是当前的主要业务，当发现流量突增，限流无法解决的情况下，对自动化验证流程进行降级，确保主要业务的稳定性

快速接入新的埋点数据格式

• 提供可插拔的“日志转换器插件”，服务高内聚，可支持各种日志格式快速接入、验证

埋点验证是保障埋点质量的有效方式，此方式属于事前验证，适用于埋点频繁变化的业务场景，需要一定程度的人工介入，能够解决基本的埋点质量问题。但是对于核心埋点场景来说，这种方式的验证成本较高，需要重复的人力投入，为了解决核心埋点验证成本高的问题，我们正在探索落地其他方式：

本文关键词：海南字节跳动是什么，字节跳动是什么性质的企业，字节跳动是什么东西，字节跳动是什么意思，字节跳动是什么时候成立的。这就是关于《字节跳动是什么，对字节跳动有什么了解（你好，这里是十年前的字节跳动）》的所有内容，希望对您能有所帮助！