“众所周知，一等奖是一辆凯迪拉克 Eldorado。有谁想看二等奖？二等奖是一套牛排刀。三等奖是你被解雇了。懂了吗？”就在不久前，一个暴雨的傍晚，接到了 HR 的通知：你被解雇了。接到通知的我对此毫无意外，甚至有点轻松，心想总算可以离开这里了。从 20 多人的团队，发展到一千多人公司，经历了扩张、上市、大裁员、躺平等阶段，再总结回顾一下，继续下一个旅程！
1 工作经历
公司自 2014 年成立，业务类型为音视频传输服务。初始几个人来到了美国硅谷，开启了创业之程。一年后他们回到国内，而我也借此机会于 2015 年加入了团队，开启了这段近 10 年的工作经历。
阶段一：从小工到专家（2014.05 - 2016.05）
初到公司，大概有 20 人左右，基本上都是国内顶流名校（清华、北大、中科大等国内各个名校）的技术大佬，我则是出身普普通通的，没什么优秀的背景和经验。这时几乎每段时间都能从各个大佬身上学到不少东西，所以非常庆幸能够进入到这种团队。
此时，公司还几乎没有什么业务，整体架构也是非常的简单，如图所示：
主要分为三层：
- 边缘接入层，负责用户接入，保持与用户的链接状态，以及音频数据（初始没有视频）的收发。
- 路由转发层，负责转发用户与用户之间数据，最优路径由核心层计算后下发。
- 核心层，由多个服务构成，负责用户登陆权限认证，用户在线状态存储，用户数据传输路径的计算等等功能。
任务：计费设计并开发
第一个接手的任务是，设计并开发计费服务。这个任务看似简单，实际上复杂无比，涉及很多用户状态的异常处理等。任务按功能以及用户规模，分为了几个迭代。
- 迭代一：初次实现非常简单，从已有的用户在线状态服务中订阅数据，计算从用户登陆到退出的时间，存储到数据库中。
- 迭代二：观察数据后发现，经常有很多异常数据，例如有登陆没有退出，用户在线时间被拉的无限长；有退出没登陆，无法计算用户在线时长等等，调查后发现是核心层无法与边缘接入层保证稳定的链接，导致事件的丢失。改进方案是由边缘接入层将数据直接存储到本地，再由数据收集服务收集到计费服务节点上计算，解决了数据丢失导致的异常问题。
- 迭代三：业务需求更新，当增加了视频传输后，需要按照视频不同的级别（分辨率、帧率、码率等）进行不同的计费，而视频的状态是根据网络情况不断进行调整的（网络差时用更低的分辨率等），所以边缘接入层存储的数据变更成为一套更复杂的协议数据，每隔一段时间存储一次，最后再将数据收集到计费服务节点上计算。
后来该服务交给了更专业的大数据团队接手。
任务：边缘接入层服务开发
计费服务的第一个迭代上线后，开始接手边缘接入层服务的开发和维护，主要内容有：
- 协议定义及功能开发，随着音视频功能增多，定义的传输协议中也对应需要更新，所以一方面对音视频相关内容有了一定的学习了解，另一方面需要协调各个团队完成协议的定义以及功能的开发测试等。
- 计费数据输出，内容为计费任务中的迭代二、迭代三中提到的用户事件和计费协议数据输出、收集等。
其他
公司内一直沿用 DevOps 模式，并充分借鉴使用了 Google 的 SRE 模式，所以在此期间学习掌握了 Python，输出了大量测试、监控、运维等脚本。
在初期，还没有使用 Ansible 这种自动化运维工具，所以根据开源项目改写了一个 C++ 版本的 SSH 多端登陆工具 Omnitty 来方便运维等操作。
这两年的时间内，跟着各位技术大佬学习了大量的知识、技能和经验，从一个开发小工，到逐渐开始单独承担某一方面责任，深深的参入到创业的氛围中，个人能力有了大幅的提升。
阶段二：疯狂的“直播”（2016.05 - 2019.12）
时间来到 2015 年，洋葱、映客、花椒等移动直播平台开始爆炸式出现和增长，公司在音视频这方面的业务也做出了相当大的成绩。
在此期间，公司快速完成了直播中“互动连麦”场景的原型，上线后成为各个直播平台火热的玩法，其架构如下：
主播通过实时传输层进行互动连麦，经过转码服务后，输出 RTMP 视频流到 CDN 后进行转发，观众端通过订阅 CDN 的 RTMP/FLV 视频进行观看。这个架构也是目前市面上大多数直播平台所采用的方案。
任务：实时音视频转码服务 1.0（2016.05 - 2017.08）
版本 1.0 的转码服务大概分为几个部分：
- 负载均衡服务（核心）开发，由于转码服务需要对音视频进行解码、混合以及编码，需要耗费大量的 CPU，一台服务器一般只能进行几十个转码任务；另一方面，为了保证低延时，采用边缘计算方式，转码任务分布全世界各地。所以开发负载均衡服务，收集边缘节点的负载信息，合理进行边缘节点转码任务的分配。
- 边缘管理服务（边缘）开发，为了保障各个转码任务之间相互独立、互不影响以及负载信息的上报到负载均衡服务，开发了边缘节点上的转码管理服务。
- 转码服务开发，实现多主播端音视频接收、混合、推流（RTMP）到 CDN 等逻辑，创新使用了 H.264 中 SEI 帧携带视频布局等信息，并根据此信息进行视频的混合。
获得奖项：
- 2016 年度公司重大项目突出个人奖
- 2016 年 InfoQ Arch Summit 架构师大会讲师
任务：实时音视频转码服务 2.0（2017.08 - 2019.08）
经过一年多的业务实践和客户需求的梳理后，为了提高易用性，启动开发了 2.0 版本的转码服务，主要更新有：
- 负载均衡服务（核心）开发，兼容新老版本边缘管理服务，优化负载分配逻辑等。
- 边缘管理服务（边缘）开发，对外增加信令层逻辑，支持客户端对转码服务的控制（启动、停止、更新、状态查询、错误回调等）；对内增加对转码服务的状态管理，降低因转码服务异常导致的故障等。
- 转码服务开发，主要更新有重构实时音视频转码服务，实现客户逻辑自定义，提高易用性，减少因设计问题导致的 Bug 和故障等。
获得奖项：
- 2019 年度公司二级重大项目突出个人奖；
任务：多协议边缘接入层服务（2018.11 - 2019.12）
随着音视频服务规模增长，客户对于多种接入协议的需求也越来越多，由于边缘接入层大部分业务逻辑都是由我开发维护的，对这部分也最了解，所以在其他任务并行进行的同时，又开发了多协议边缘接入层服务。
- 重构 WebRTC 边缘接入服务。对已有的 WebRTC 边缘接入服务进行重构，替换了核心转发模块，大幅度简化了业务逻辑，提高了服务性能等。
- 设计并实现了其他多种标准协议的边缘接入服务，例如 Flv、Dash 等；
获得奖项：
- 2019 年度公司二级重大项目突出个人奖；
其他
除了工作内容之外，还制作了直播问题调查工具 FlvParser 和 Gump 等，也在公司内推广使用了基于 Grafana 和 OpenTSDB、InfluxDB 等的实时监控方案，搭建了基于 Jenkins 的 CI 构建平台等等。
在这段时间内，公司业务得到了大规模的扩张，团队人数也不断增多，个人能力也获得提高的同时，也开始带领团队协同工作，完成更多的目标。
阶段三：云！云！云！（2018.07 - 2022.06）
随着业务规模增长，以及互联网环境的发展，云平台和云原生开始蓬勃发展，开源社区中各种应用、平台、工具日新月异。
为了更好的融合融入到云平台和云原生中，以及解决工作中的业务问题，在这方面也做了不少工作。
任务：通用业务平台（2018.07 - 2020.09）
随着业务场景增多，例如音视频录制、红火一时的远程抓娃娃、支持微信小程序等等，考虑到不能够每出现一个业务就开发一套负载均衡、边缘管理等服务，效率太低。所以在原实时音视频转码服务基础上抽象多种业务场景，打造实时通用微服务平台，提供全球业务负载均衡、调度等能力，大幅度提高微服务开发上线速度，并提供可运维、高并发、高可用保障。
- Kong 网关服务，包括 Kong、Konga 等服务搭建，业务所需的相关插件开发，数据上报 ELK，数据统计、上报、监控等。
- 状态存储服务，为了保证分布式系统的数据一致性，采用 ETCD 作为存储，用户接口经过状态存储服务处理后，再进行下一步的处理。
- 负载均衡服务，支持 CPU、GPU、内存、带宽、并发数等等多种负载因子的配置，支持多种业务形态的负载均衡。
- 边缘管理服务，支持 UDP、TCP、WebSocket、HTTP 等等多协议接入配置，进行灵活的信令层控制。
- 业务服务 sidecar，对协议、配置、数据上报等抽象，支持各类业务对接，降低各个业务对整体系统理解的复杂度，提高业务开发速度。
- 所有服务向云平台方向靠拢，容器化部署，有统一的运维环境（灰度、数据上报、监控、报警等）。
获得奖项：
- 2018 年度公司三级重大项目突出个人奖；
- 2019 年度公司三级重大项目突出个人奖；
任务：OpenAPI 网关（2020.09 - 2021.08）
随着业务增多，网关逐渐起到了关键性的作用，为了保证其高可用、高并发、易用性等，做了部分开发和调整工作。
- 开发业务所需的插件，包括鉴权、业务信息转换等，对内业务开发提高易用性。
- 使用多家云厂商的 DNS 解析器，多区域服务器、数据库等，优化灰度方案，解决了高可用、高并发等问题。
- 全球化部署，多域名解析，开发问题调查工具，数据统计、监控工具等，提高了客户侧的易用性。
- 整理业务以及客户接入最佳实践指南，定义标准接口规范等。
任务：Serverless（2021.05 - 2022.03）
随着云原生的蓬勃发展，公司部分业务逐渐从边缘计算向集群化方向探索，例如说公司搭建了一套 Kubernetes 集群，将部分业务迁移到其中。为了进一步提高通用业务平台的易用性，准备向 Serverless 方向迁移。
- 设计 Serverless 架构，简化内外部交互逻辑。
- 使用 Knative 搭建 Serverless 服务，并开发 Demo 验证。
- 对接公司已有的事件服务系统，通过事件驱动方式，进一步降低业务的耦合。
其他
在 2020 年 6 月份，公司成功上市，给第一段的努力，成功画上了一个圆满的句号。但是，这背后也隐藏着巨大的危机，随着人员大规模的扩张，公司创业的文化越来越稀薄，工作也越来越浮躁。
在 2022 年 3 月份，第一次正式提起了离职申请，原因是感觉工作无目标和方向，自身也得不到成长，内心受到了巨大的煎熬。但是经过了老板的挽留，准备在家休息一段时间调整一下，并想借此机会去外面看看是不是有新的方向。不巧的是，刚休息的第二天，就被“困”在了家里，这一“困”就是三个月的时间，毫无所得。
阶段四：三等奖（2022.07 - 2024.11）
在 2022 年返岗工作的这个时间节点上，正式开启了互联网内的大事件：降本增效（裁员），公司也避免不了的缩减了业务范围，砍掉了很多没有带来实际收入或者短期看不到实际效果的业务，例如说之前提到的 Serverless 等。
而我也终于熬过了三个月的时间，重新回到了工作岗位上，因为之前的工作内容都已经交接完成，所以索性彻底回到了刚开始的地方，重新接起来了边缘接入层服务的开发。
任务：数据上报服务
作为架构师，接手了一个已有的数据上报服务，由于故障频发，需要进行重新设计架构（无开发）。
- 调查故障发生的详细原因，查看已有的逻辑，重新设计架构。
- 跟进进度以及观察上报的数据，确定性能指标符合要求，故障问题解决。
获得奖项：
- 公司团队可用性二等奖；
任务：WebRTC 边缘接入层服务
在 2019 年曾经做过的 WebRTC 边缘接入层服务，经过调整优化后，由另外一个团队开发维护。经过两三年的累积后，又再次成了一团乱麻，所以重新接手了这个服务，继续进行改造优化。
- 合并、删除了大量无用模块，清理代码仓库，重新对接到 CI 系统中，和团队对齐了代码开发、Review、合并等模式。
- 重写 P2P 模块、传输模块、协议解析模块、用户管理模块等等，大幅度降低整个服务中的业务逻辑耦合。
- 性能优化，解决 CPU、内存等问题，性能提高了 3 倍左右。
- Review 新的提交，保证新合入代码质量符合要求。
其他
在 WebRTC 边缘接入层服务重构结束之余，我常常不禁想，经过了这两年的工作，依旧还是没有目标和方向，状态似乎跟以前一样没有丝毫的改变，实在是没有继续勉强下去的必要了，不如凑够十年，就彻底离开这里吧。
结果没想到的是，在这个暴雨的傍晚，接到了 HR 的通知，瞬间感觉心里的重担落下了，浑身轻松，终于可以说出：我可以离开这里了！
2 “喜提”三等奖
最近几年，我时常回忆起当年刚开始创业的时刻，精力十足，创意十足，脑海里满满的都是接下来该做什么。究竟是什么，给这段岁月划上了终止线？刚好时间空了下来，不如先想清楚了再重新出发！仔细回忆和思考了许久，我想出了下面这“三宗罪”。
破烂不堪的文化
“你需要建立机制和文化价值观，使你感觉公司尽可能小。这就是保持创新和快速的方式。” —— 特拉维斯·卡兰尼克（Uber 创始人）
我想把这最大的“罪过”，划给这破烂不堪的“文化”，为什么这么说？文化是什么？我想这里应该是美国文化研究专家 P·巴格比的定义最为贴切：“社会成员的内在和外在的行为规则”，那对公司来说，就是“公司成员的内在和外在的行为规则”。
当公司从 20 多人扩张到 1000 多人时，给人最大的感觉就是同事与同事之间没有了以往的默契，行动不一，而究其原因：没有统一的文化。大家向心力不足，一团散沙，又怎么可能把事情做大做强呢，所以公司文化一定程度上决定了很多事情的成败。
装修风格看公司文化
公司来来回回换了几次办公室，也装修了几次，然而出现在墙上的大标语，也仅有“和而不同，群而不党，周而不比”这一条罢，而公司也真真正正恰好做到了这一条。反倒是后来提到的几条核心文化，做成了宣传板，高高的悬挂在公司前台的上面，不抬头甚至看不见，我至今都不能完整的说出来，实在是可笑又可悲。
我也曾到过其他几家公司，有的把文化作为考试内容，时不时的组织考试；有的将文化做成红色条幅，悬挂在公司的办公桌上方；也有的将其印成形式多样的贴纸，贴在各个会议室的门口。
而公司随着人数增多，不但文化一成不变，甚至没有一个合适的方式来增强大家对文化的认知和理解。
失败的文化管理团队
也许，公司在扩张的时候，想到了这些问题，由几位老员工，成立了虚拟的文化管理团队，每季度/半年/年进行文化考核。然而最大的问题是什么？权责不清！
权利：一个虚拟的团队，最大的问题就是权利如何定义，就如同国家的各个机构，不定义清楚可以行使的权利，那如何执行这个机构的责任？更何况这又是一个虚拟的团队，每个人都在忙着完成自己的工作内容，没有任何人来行使过任何权利。
责任：这个团队可以全都是靠着“自觉”来驱动吗？他们的职责到底是什么？我不清楚他们是不是了解他们的责任。从实际来看，他们并不了解，或者说也许最初是了解的。随着公司规模变大，文化管理团队没有很好的完成自己的职责，甚至后来形同虚设，变成了专职每年年度考核系统的负责团队。
文化上的失败，早在第一次提及离职时，就跟有关同事反馈过，收到的回复总归是我们正在做什么，未来有何规划，可惜的是两年的时间内，我甚至没有感到一丝丝的改变。
研发与管理的断层
接下来的第二大“罪过”，我想应该就是研发与管理的断层。自始以来，20 多人的团队，几乎全部都是研发，甚至包括老板都有时会写代码，随着人员扩张，必不可免的需要出现“管理”岗位，那接下来问题就出现了。
一个研发为主的团队如何被管理？研发要承担管理层工作？
最开始，部分研发的负责人，被拉出来作为管理层，我想，这应该是最佳的路线：需要了解团队的工作，需要和其他团队配合，需要对未来有清晰的计划，需要对当下有合理的判断，需要跟更上一层有承上启下的衔接。
但是，事情往往不是如意的，一方面技术能力强的人，可能管理意识不强，或者其意愿不在管理方面；另一方面扩张速度过快，很多新出现的团队，新来的同事，避免不了出现了一些不恰当的管理层。
公司虽然前期组织过外部培训团队对大家进行培训，但是这种短期一两天的学习，效果真是差强人意，工作真正忙起来，很难把这些管理方法融入进去，对个人来说，也很难有成就感。
我作为研发，也有很长一段时间带团队，每天大量的时间花费在无意义的会议中。体验下来，对于一个研发来说，更能让其真正开心有成就感的，还是写一段代码、解决一个问题。
所以，能到管理层的研发，少之又少，这就导致了下一个问题。
空降领导如何了解公司，如何指挥大方向？
这怕是所有公司都存在的问题，也是最大的断层所在，空降领导不知道研发在做什么，怎么指挥大方向？
曾经，有个高层领导，打电话多次问了我相同的一个技术问题，每次我都细致的回答。以我的判断，这个领导应该没有理解这个技术点，所以每次客户或者其他人问到，他都要让我再给他讲一遍。那这么看来，高层领导很难对当前研发正在做什么有一个详细的认知，这样的领导如何带领整个公司去挑战未来？
这也正好验证了我的想法，果不其然，公司开始兴起了项目管理，并开发了一套项目管理系统，来让领导层知道研发团队在做什么。这样做是成熟公司的标准做法，更适合公司步入正轨，维护已有的项目，慢速逐步迭代更新。但是这一千人左右的公司，真的已经到了成熟公司的阶段了吗？
如此下来，又回到了原来的问题，在互联网快速发展的长河中，领导层如何判断未来方向，作出正确的选择？这也是让人最痛苦的地方，当开发迭代速度降下来，原有的自我计划被延缓或者放弃，领导层没有新的计划，员工们不知道目标是什么，该做什么，日复一日的维护已有的项目，激情冷却，逐渐变成了“摸鱼”、“躺平”的状态。
虚情假意的三不像 OKR
OKR 是一套明确和跟踪目标及其完成情况的管理工具和方法，在 Google 发扬光大，所以互联网公司也大多采用作为其考核工具。与之相对的是大家更熟悉的 KPI，也被很多传统公司所采用。
这两者都是管理工具和方法，而公司采用的是 OKR 这一套，但是实际上的运用效果，我愿称之为第三大“罪过”。
自上而下？自下而上？
大家常常用“驴”的故事，来区分 OKR 和 API：公司的几头驴又偷懒不走了，这个时候就需要 KPI 来充当鞭子，促使他们往前走，使劲走；公司还有几头驴拼命的走，不想落后，但是很多时候走错方向了，这个时候就需要 OKR 来帮助他们走正确的道路，少走曲线。OKR 让驴确定方向， KPI 让驴走的更快。
本质上 OKR 可以让大家做正确的事情，但是实际上，公司把 O（目标）设定为员工或者团队自发性提出。在公司快速发展时，目标和方向是明确的，这时候 O（目标）从员工或者团队设定上，也几乎不会偏离路线。但当公司发展到一定规模时，更多的事情反而是去查漏补缺，例如安全合规、高可用保障等等，这时候把 O（目标）设定为这些日常工作任务上，怕是误入歧途了吧。
这件事情虽然跟有些管理岗位的同事讨论过，但是最终也没有得到一个合理的答复，想想每个年度/季度最重要的 3 件事，排在首位的是故障次数不超过几次，多少也是有点可笑的。
我也常常想，究竟应该把 O（目标）设置为什么？领导层究竟当前想要什么？公司未来目标到底是什么？这目标到底跟我或者团队有什么关系？这些问题始终没有等到一个答案。
随着公司逐渐把 OKR 从每季度一次，变成半年一次，逐渐变成了每年度一次，这似乎告诉了我答案：没有 O（目标）？
计划赶不上变化
公司实行 OKR 以来，另外一个最大的挑战是，计划赶不上变化。当定好目标，要完成某一项工作时，几乎全被打乱，插入了各种各样其他的事情，完全是思想的巨人，行动的矮子，计划内的做不好，临时插入的也差强人意。
从这一点来看，带来最大的影响是考核机制如何执行？现实也是如此，在季度或者年度考核中，几乎没有回看和检查过之前定下的 OKR 目标，反而根据每个人实际的工作内容去做考核，最终评价标准掌握在每个领导手中。
3 未来在哪里？
要想扭转这种局面，肯定是难之又难，但我认为仍应该从以下几方面入手（权当自己想想罢了，也不一定正确）。
重新建立公司文化
越是在困难的时候，越是要“望梅止渴”。多年前提出的公司文化，是指导思想，不能当作公司的行为准则，当下应该重新从每一个员工收集心目中的文化观念，建立起统一的文化理念。
年轻人作为公司的主力，收集他们的文化观念很重要，十年是一个时代的变化，新一代年轻人的许多观念已经与老一代格格不入，时代在发展，文化同样也要更新，这样公司才能重获活力。
海盗与海军
乔布斯曾说过，“做一名海盗，比参加海军更有趣“，海盗们往往有着敏锐的嗅觉，可以快速行动，目标明确，这与初期的创业阶段状态非常相似。公司规模变大后，往往是向海军方向发展，有着明确的管理和统一的行动计划。
而我觉得这两者并不冲突，公司之外应该保留几支海盗队伍，对互联网中的每次浪潮进行突击，这是一个“寻宝”的过程，如果有所突破，应该逐渐交给海军团队去做大做强，将“宝藏”彻底挖走。两者逐渐形成良性循环，公司也会有更大的创新和突破。
4 结束语
最后，写了这么多内容，一方面是想给各位看官介绍一下这番创业的经历，能有所得；另一方面也给这段历程交上一份答卷，画上一个句号。
天晴了，风景依旧绚烂！
