似乎每一家互联网公司都有一种属于自己的气质，我接触过很多知名互联网公司的技术专家，其中有一家公司技术专家给了非常深的印象，那就是 UCloud。在和 UCloud 技术专家的沟通中，我深深感受到这是一支极为自信、动手能力很强的技术团队。

近期，我在UCloud上海办公室采访了 UCloud 虚拟网络负责人徐亮，就如同我采访过的很多一线技术领军人物一样，徐亮给我带来的直接印象就是执着、朴实和认真。

在和他的谈话中，我听到了不少 UCloud 有趣的研发故事，让我对 UCloud 技术团队的动手能力有了更深的认识。尤其是， 当UCloud 所倡行的“客户为先”、“客户的需求就是我们的下一个产品”等理念从一个专注于前沿技术的技术领军人物的谈吐中汩汩冒出时，印象更深刻了。

转化：实验室技术能力 ➡️➡️➡️ 生产能力

我为什么认为 UCloud 的技术团队是一支动手能力极强，这得从他们的 25G 智能网卡项目说起。

众所周知，如何将实验室形成的技术能力转化成生产能力，需要很好的工程能力，25G 智能网卡从实验室到生产环境恰恰体现了这样的工程能力。

“去年我们将 25G 智能网卡产品投入到生产环境，实际上，UCloud 从 2016 年就开始跟踪这项技术。这期间我们测试了很多厂商的智能网卡，有的智能网卡的性能相当不错。但是阻碍我们将其投入生产环境的一个重要原因是，它和公有云所要求的热迁移的能力不兼容。所以，虽然这些智能网卡的性能很好，但是没有办法应用到公有云环境。”徐亮介绍道。

其实，业界一些公有云厂商很早就在借助这些智能网卡做加速，但是在处理热迁移的时候做不到用户的无感迁移，必须要用户手动修改虚机里面网络的配置。这虽然能够达到目的，但是对用户并不友好。对此，UCloud 秉持一向的态度：“我们一定要做到用户没有额外的负担，这样对用户来说才是佳的方案，才是成熟的、用户友好的方案。”

据徐亮回忆，情况在 2017 年底出现了一个转机。彼时，Linux 内核社区开始讨论智能网卡如何能够无感的支持热迁移，UCloud 技术团队时间进行了深入的技术追踪和研究。从社区开始讨论和开发，后到 2018 年 5 月份时该功能趋于稳定，才被接受到 Linux 的内核主线里。

“在发现该功能已经基本成熟后，我们马上就把这个补丁应用回 UCloud 的定制内核当中，跟智能网卡厂商一起研究，很快就在实验室完成了该产品。”徐亮接着谈到，“然后我们就开始在线上做公测。这个时候就非常体现我们的工程能力。”

在徐亮的团队将智能网卡投入生产环境时，虽然也发生了一些问题，但是就算在连固件都升级过两次的情况下、对用户的业务并没有产生太大的影响，我想这就是 UCloud 技术团队的工程能力一个重要体现——“我的固件都升级了，而用户业务不受影响。”

驱动：客户为先 ➡️➡️➡️ 工程能力

在我采访的 UCloud 技术人员中，徐亮并不是个提到“客户为先”、“客户的需求就是我们下一个产品”等理念的，在与 UCloud 技术副总裁杨镭、私有云和容器产品线负责人叶理灯等人的采访沟通中他们都曾提及这一贯彻于 UCloud 所有技术、产品研发中的理念。他们对于“客户为先”以及在产品的研发、技术专研中的践行，让我深信他们从骨子里认可这样一个价值观。可以说，“用户为先”的理念驱动着其工程能力的形成。

谈到他们的经典网络升级至 VPC 2.0 项目，也许你会理解我说的。

以“客户为先”为出发点

据我了解，UCloud 应该是全球一家把经典网络升级到 VPC 2.0 网络的公有云厂商。在我和多位 UCloud 技术人员的接触中，这个项目被多次提及，它的实施可谓是历经周折，遇到的困难很多。

“我们的出发点是‘客户是不是有这个诉求？这件事情对客户来说是不是有好处？’如果是的话，那我们为什么不做呢？“。当问及项目出发点时，徐亮谈到。显然，如果能够透明的将经典网络升级至 VPC 网络，对于用户来说无疑是有诉求和好处，不需要自行迁移或是同时维护两个架构。但，UCloud 一开始低估了这个项目的难度。

徐亮说，“为什么这么难？因为一个默认的前提条件出现了变化——我们以前假设用户的 IP 是的，这不光体现在网络产品上，还包括数据库产品、存储产品等，都会假设用户的 IP 是的——在之前的经典网络时，该前提条件似乎是显而易见的。但在我们要升级到 VPC 2.0 时，我们突然发现这个 IP 变得不再，由于不同的租户网络是完全隔离的，IP 完全是可以重复的。”

因此，这个项目不再是一个纯粹的网络项目，意味着 UCloud 平台上的所有产品都需要升级，都要支持这个重要变化，所以在工程上存在非常多的协调工作。这是一件非常、非常难的事，是一个涉及到全公司协调的能力。

“客户为先”驱动产品创新

VPC 2.0 项目过程中，徐亮团队还推出了许多创新产品，如 IPv6 地址转换。

公有云里面会有一些公共服务，比如说，像镜像服务、DNS 服务等，所有的客户都可能会访问这些公共服务，而有些客户的 IP 是彼此重叠的，只是 VPC 不同而已。传统上都是采用 NAT 的方式去做的，因为地址是相同的，肯定需要通过 NAT 翻译成不同的地址，然后再去访问公共服务。

但是，NAT 方式有两个问题，一个是公共服务在获取原地址时变得很复杂，它要用 TOA 或其它手段才能够提取出原地址。另外是这是一个有状态的网关，可扩展性会存在一定的问题，有状态的部分容易成为瓶颈，维护状态代价很大。

UCloud 在这方面做了一个创新——徐亮的团队把用户的地址和用户的 VPC 这两个部分信息组合起来，形成一个 128 位的 IPv6 地址，把用户的 IPv4 的请求无状态地转换成了 IPv6 请求，然后发送给这些公共服务。徐亮说，“我们这个无状态转换的思路，是非常创新的。对用户来说，得到的性能很好，同时不需要为此额外增加成本。”

就这样在“用户为先”的驱动下，UCloud 技术团队一点一点的完成了经典网络到 VPC 网络的升级，历时三年。

“我们的初衷就是从客户为先的角度出发，用我们的技术给客户带去价值，在这个基础上我们就认为这件事情值得就去做。”

自省：关于工程能力的三句话

关于对工程能力的理解，徐亮谈到了几句话： “先于客户发现问题”、 “先扛住再优化”、“这件事情能不能做到24小时止血”、“一周之内能不能拿出一个中期解决方案？”… 让我印象深刻，这也是 UCloud 技术团队的实践路线。

“先于客户发现问题”

据徐亮介绍，其团队做可编程交换机的过程中遇到一个非常隐晦的交换机芯片编译器的 BUG，它会发生哈希冲突，从而导致行为不可预期，但是这个问题在实验室是没办法复现出来。历时一个月时间，UCloud 通过在工程上引入全量测试的环节，提前发现了问题。

这件事情之后，徐亮的团队开发了一个新系统，对所有用户虚机点对点通信的信息进行统计，在做变更时就会针对通信过的场景做全量验证。通过这种方式来发现一些因为软件架构变化导致的问题，能够“先于客户发现问题”，在对客户业务没有产生影响的情况下去解决它。

“先扛住再优化”

发现问题时间不是去分析根本原因是什么，而要考虑怎样降低对客户的影响，这就是 UCloud 团队常说的“先扛住再优化”。比如说，智能网卡出现故障了，不会先修复智能网卡，肯定是先把用户的业务切走，让用户的业务正常，然后再想办法解决智能网卡的问题。

“这件事情能不能做 24 小时止血”

一旦发生故障就会做复盘，这时候UCloud技术团队常说的一句话就是“这件事情能不能做24小时止血”。故障对客户是有影响的，我们要在24小时之内先推出一个方案，这个的方案能够让客户降低损失。不光是出现问题的客户，甚至是其他没有出现问题的客户，我们也要在24小时之内拿出一个方案，让这些问题不会影响到客户。

然后，再问‘一周之内能不能拿出一个中期解决方案？’，后再考虑长期解决方案，长期方案有的时候就真的很长，比如说体系架构设计的不合理、需要进行重构。

结语

在和包括徐亮在内的多位 UCloud 技术领头人在深入沟通后，深切感受到这是一支极为自信、工程能力极强的技术团队，他们敢于尝试新技术，同时其工程能力能在给用户提高价值的同时，保证不出现问题，我相信这是 UCloud 技术团队自信的底气。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。
取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术的作用；穿山甲是珍稀保护动物，宣传公益。