似乎每一家互联网公司都有一种属于自己的气质，我接触过很多知名互联网公司的技术专家，其中有一家公司技术专家给了非常深的印象，那就是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所有技术、产品研发中的理念。他们对于“客户为先”以及在产品的研发、技术专研中的践行，让我深信他们从骨子里认可这样一个价值观。可以说，“用户为先”的理念驱动着其工程能力的形成。
谈到他们的经典网络升级至VPC2.0项目，也许你会理解我说的。
以“客户为先”为出发点
据我了解，UCloud应该是全球唯一一家把经典网络升级到VPC 2.0网络的公有云厂商。在我和多位UCloud 技术人员的接触中，这个项目被多次提及，它的实施可谓是历经周折，遇到的困难很多。
“我们的出发点是‘客户是不是有这个诉求？这件事情对客户来说是不是有好处？’如果是的话，那我们为什么不做呢？“。当问及项目出发点时，徐亮谈到。显然，如果能够透明的将经典网络升级至VPC网络，对于用户来说无疑是有诉求和好处，不需要自行迁移或是同时维护两个架构。但，UCloud一开始低估了这个项目的难度。
徐亮说，“为什么这么难？因为一个默认的前提条件出现了变化——我们以前假设用户的IP是唯一的，这不光体现在网络产品上，还包括数据库产品、存储产品等，都会假设用户的IP是唯一的——在之前的经典网络时，该前提条件似乎是显而易见的。但在我们要升级到VPC 2.0时，我们突然发现这个IP变得不再唯一，由于不同的租户网络是完全隔离的，IP完全是可以重复的。”
因此，这个项目不再是一个纯粹的网络项目，意味着UCloud平台上的所有产品都需要升级，都要支持这个重要变化，所以在工程上存在非常多的协调工作。这是一件非常、非常难的事，是一个涉及到全公司协调的能力。
“客户为先”驱动产品创新
VPC2.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技术团队自信的底气。
