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