因此，这个项目不再是一个纯粹的网络项目，意味着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技术团队自信的底气。