2023年第一季度中国卓越技术团队访谈录

目录 封面故事 涉及数万人、历时三年，国内最大规模的云原生实践是如何 打造出来的？i 重磅访谈 从“幕后”走到“台前”，我们在阿里如何建设可观测体系？1 大模型如何实际在行业落地：生成式大模型结合知识 库，打造出7*24小时永远在线的超级员工13 中国的“贝尔实验室”：我们的数据库从自己的第一行代码写 起31 我们不是野心家，走出大厂创业是时代使然46 技术管理漫谈 可悲的现实，大部分技术领导者可能并不称职60 如何为那些在裁员中幸存的人重建技术文化74 架构师角色的演变：从发号施令到与团队合作83 封面故事 涉及数万人、历时三年，国内最大规模的云原生实践是如何打造出来的？ 编辑：Tina 采访嘉宾：邹辉、于广游、王涛 云计算的竞争旷日持久，表面看来格局初定，内里却在酝酿巨变。 具有先发优势的玩家，好不容易取得了看似不可撼动的地位，不曾想到有朝一日会中途被拉到同一起跑线，更换新的“CloudOS”重新出发。这个局面恐怕连Kubernetes早期创始人都会觉得不可思议。他当初只是想改变现状，在亚马逊的主导地位下，让谷歌取得一战之力。 2014年，谷歌开源了Kubernetes，红帽、腾讯、阿里、华为等国内外一众厂商开始力出一处，共同推进Kubernetes的采用。2017年底，就连亚马逊也推出了Kubernetes产品，这也是Kubernetes成为标准化技术的最大信号之一。 这最终改变了整个云计算。 大家都开始基于Kubernetes技术生态去构建公有云产品，基于统一的标准以避免“深度绑定”，但这也让云原生行业严重同质化，因为各个云厂商所提供的功能和服务并没有太大的不同。对一些厂商来说，那些当年引以为豪的自研技术突破，那些树立在公司门口的纪念碑，那些专有性产品优势，都被抹平，这是一件非常残酷的事情。 同时这又是一些公有云厂商重塑格局的机会。锚定Kubernetes进行云原生改造，相当于给公有云更换“技术底座”，并由此构建出一些新的竞争力，从而赢取更多用户。 这场技术改造，难点在哪里？ 对于腾讯来说，这不仅仅是一次技术“改造”，还兼带着腾讯全体系“自研业务上云”的战略任务。 在谷歌GKE之后，腾讯云于2017年推出了TKE。但腾讯云对外服务时，还是会面临客户的质疑：“为什么腾讯自己的业务没有使用腾讯公有云，是不是不敢用？” 腾讯这次“云原生改造+上云”的价值就藏在客户的拷问中。腾讯在这二十年里，发展出了包括社交、音视频、游戏在内的多种业务，每种业务又都拥有海量的用户。 全面上云腾讯不是第一家，但腾讯是拥有最复杂的业务场景的一家，在这个过程中，需要结合业务制定各种各样的技术方案，来满足不同的业务诉求。可以理解为，每个 业务的痛点都有局部最优解，而全面上云，则是在云上寻求通用最优解。如果这些 痛点都能解决，那这样的云服务是足够让大家敬畏的。 要运行这么多业务，云原生底座也不能有短板，必须承载得了微信、QQ、音视频、游戏等自研业务所有需求和核心能力，并最终将这些业务的技术积累和技术优势反向复制到到公有云上，展现给外部用户。 除此之外，云原生改造还对组织能力提出了考验。 在移动互联网时代，腾讯发展出了自己的技术哲学：每个业务都有自己的技术团队， 每个团队都要打胜仗，这就要求“小、快、灵”，要有闭环。在自研业务上云之前，腾讯的每一个业务都有自己完整的技术栈，内部业务在一定程度上形成了“部门墙”效应。并且因为技术栈不同，员工从一个业务转岗到另一个业务，需要重新学习一遍技术，这跟换公司没什么区别。 根据财报数据，腾讯员工已超十万人，其中超过7成是技术人员，这是一次集体向云的迁移，就像一次“搬家”，但又不仅仅是将行李打包那么简单，它是将具有一二十年历史的不同特色的多个“大建筑”，制定“平移”方案迁移到新环境中继续安然运行，难度可谓前所未有的高。考虑到花费的时间、涉及到的人员规模、技术深度，这个项目可能是在世界范围内也很难找到的超级“软件工程”实践。这样的改造，过程中既有高层的推进、动员，也有执行层的博弈、妥协，最终实现了用一个点调动全局，让全公司的技术团队得到了一次很好的穿透对齐，让分散的技术能力得以统一。 有人说，评估腾讯云水平如何，应该参看自研业务上云后的整体水平和运转情况。 去年，腾讯自研业务初步完成了全部的云原生技术改造，腾讯云将所有的底层资源合并到一起进行统一管理和调度，自研业务上云规模突破5000万核，TKE的在离线业务混部能力使服务器资源利用率从30%提升至65%，远远高于改造之前。2020年，线上会议需求爆发，腾讯云组织了几十号人，花了8天紧急扩容100万核，创下了中国云计算史上的一个记录。而全部上云之后，放到现在这个阶段，利用一键扩缩容，腾讯会议再要去扩容100万核，那就是十分钟的事情。 所以，这次云原生改造的好处显而易见：对外，在垂直场景沉淀下来的技术能力，让腾讯云原生获得了差异化的产品能力，能真正解决用户在各种场景下的业务痛点；对内，让腾讯在云端整体的资源利用率有了一个大幅提升，这本身就是巨大的降本增效。 然而，这个过程却是经过了千辛万苦。 “像下一盘棋” 2018年，云原生行业发展趋势初定。 随着云原生技术的兴起，腾讯内部几万研发人员的技术焦虑逐渐加深。早期腾讯积累了大量的技术架构理念，技术人员有非常强烈的自豪感，但是越是成功的组织惯性就越大，腾讯内部很多技术理念和流程还停留在上一个时代。据称，那时候腾讯内部讨论平台“乐问”上充满了技术人员的吐槽和争议。 除了“部门墙”的存在，每个业务部门为了应对突发的流量，在升级服务器资源时会留出资源缓冲区，当所有的缓冲区叠加在一起，就形成了大量的闲置资源浪费。所以，无论是从技术还是资源的角度来看，上云并进行统一的调度在当时已经是不得不做的事情。 2018年底腾讯开了一次高层决策会议，决定将公司内部所有平台合到一起推行K8s，开始进行彻底的技术更新换代。 这个事情一开始由邹辉领导的TKE团队牵头。TKE团队主要由一批资深技术人员构成，成员基本都在30岁以上，资历以10级、11级为主，团队对成员的技术能力和业务理解能力要求很高。 决策已定，但是在执行过程中，尤其是TKE团队，前半年时间并不是真正的去做技术工作，而是跟腾讯内部几个事业群的平台技术团队去聊需求聊具体的改造方案，他 们发现还是存在很大的技术阻力。 腾讯云事业部门在2016年下半年的时候就启动基于K8s的TKE项目，但腾讯内部不同BG存在不同的路线，有的基于Docker，有的基于Mesos。现在要将所有东西都统一到标准的公有云TKE上去，其实内部技术团队难免会心生疑惑：你们是不是要过来抢我们的活？ 为了减轻这些问题带来的阻力，当时腾讯没有采取调整团队人员和效仿建立技术中台的方式，而是制定了开源协同技术战略，把公司内部所有做相似事情的团队整合在一起，采取类似于外部开源运作的方式协同工作。这样既解决了技术浪费的问题，又可以去中心化，保持快速响应，还能更好地满足业务需求。腾讯内部把这种模式称为OTeam。OTeam挂在公司技术委员会下面。由这七八个平台组成的K8sOTeam就是一个典型的例子，它是腾讯首批三个开源协同项目之一。 在解决了技术团队的顾虑之后，腾讯从高层开始推进，说服自研业务团队上云，同时打通职级晋升体系，通过设置公司级的专项大奖、普及云原生知识、改造进度榜单晾晒等，从多个方面入手提高大家积极性，依照三年规划，有步骤地进行云原生改造和上云。 如何用好开源技术？ 其实在上云决策制定之前，腾讯云已经花了两三年时间做了一个TKE“原型”，也踩过了不少坑。 K8s本身只是一个主要做容器编排调度的开源项目，TKE底层是基于标准的K8s，再在上面进行产品化，将K8s和网络能力、存储能力、日志监控等能力对应的网络产品、计算产品、日志产品、监控产品对接整合，给用户提供一个开箱即用的K8s产品，所以TKE对接了腾讯底层的各种IaaS产品能力。 2016年腾讯开始做TKE的时候，国内都还没上K8s服务，业界比较好的产品设计也就是谷歌的GKE，一切都是摸索着来。最开始，TKE团队试图在云上提供一站式的K8s服务，将K8s的概念进行了一些简化，希望通过帮用户降低使用K8s的成本、让用户愿意直接接入K8s，但最终发现这条路线是错的。 他们发现K8s不是直接面向终端用户的，而是面向一个企业内的Infra平台团队的。应该由Infra团队基于K8s构建自己的PaaS平台，提供给公司使用。“它是个Kernel，是云的操作系统的内核、不是PaaS。”于2016年加入TKE团队，一直负责K8s产品化相关工作的于广游表示。“我们没有意识到这样一个核心设计的本质。最开始，我们对它的理解有偏差，所以我们犯了一个错误，走了一些弯路。早期的时候为了面 向业务有一些改动，意识到错误后，在17年底、18年初的时候就纠正了。后来才变成了我们现在TKE的形态，我们也因此做了一次产品改名，从CCS改名为TKE （TencentKubernetesEngine）。” 到了2018年，腾讯启动开源协同之后，因为这七八个不同的容器平台团队，各自都有各自的优势，如果要融成一个标准K8s技术，该怎么做？TKE要么选择都不接收、全部“作废”重来，要么选择将所有的历史包袱都背起来。K8sOTeam在一起讨论之后，选择了后者。 这也是为了上云而做出的妥协。整个公司“像下一盘棋”，下棋是核心矛盾，往K8s里贡献不好维护的代码是当时的次要矛盾。据邹辉和于广游回忆，当时很快每一个团队都用上了K8s，大家也都更加深刻地理解K8s了，理解到往K8s里面去改太多的逻辑，不是最优的方式。有了这个共识之后，K8sOTeam团队在不更改K8s主线代码情况下，差不多用了一年时间，真的就把七八个平台所有的功能、核心技术特长全部融入到了TKE容器平台上。 大家在K8s基础上去添加功能，且无需向用户暴露K8s的基本概念，那么“零K8s基础”的用户也能快速部署应用并管理其监控、日志、服务注册在内的整个生命周期。后来腾讯创建了一套应用模型TencentApplicationDefinition（简称TAD），直接使用应用管理平台，用户不需要去感知K8s细节，极大地降低了容器使用门槛。同时也引入了插件机制，复用了K8s的框架，可以像写K8s插件一样写TKE插件，方便第三方开发。 腾讯云原生底座的“养成”计划 相比公有云外部客户的业务，腾讯自研业务的体量更大，技术积累更深厚，测试标准也更全面和严苛，业务也千差万别。 一开始，K8s很多能力不支持，业务很难平滑切换。在2019年之前，大部分业务还是基于虚拟机的方式去上云，因为自己的IDC物理机切到云上的虚拟机之后，这个过程业务基本上没有感知，整个架构和代码不需要任何的改造。但是业务上虚拟机违背了上云本质诉求，即希望利用云原生的快速弹性伸缩能力，和统一资源池的其他一些能力去提升各个业务团队的研发效能，所以最终TKE团队还是需要帮助业务从虚拟机切到容器化，并提供相应的产品能力。 TKE平台在初期选择的更多还是一些无状态的业务，先让这些无状态的业务能够快速搬到云上完成改造。团队选择了一些平台的核心能力去解决业务痛点，比如说“发布” 的问题。 在公有云场景下大家使用的是K8s基本的发布能力，比如基于滚动的发布。滚动发布过程可控性很差，遇到了问题后回滚，整个发布就会中断。腾讯自研业务需要满足灰度发布的要求，灰度发布对业务来说也是非常关键的一项能力。为了保证服务的质量， 业务团队要求能够非常精准地控制发布频率、节奏和容错，做到发布过程一切尽在掌控之中。针对这样的需求，TKE在自定义工作负载基础之上发布了一套灰度发布策略，业务可以指定要发布的Pod，可以按照一定的百分比进行发布，也可以设置升级失败的比例来实现暂停或回滚。 同时TKE也给业务提供了一些虚拟机提供不了的能力，比如动态路由能力，在容器 销毁时，平台会将对应路由去掉，在容器起