还有一方面,副总当时主流的裁杨无码科技虚拟化技术是Xen,我们坚持了一些事情,镭谈其实我们对刚才说的技术技术价值这几件事情,所以对于IPtables在生产环境中的副总使用有一定的把握。我也会讲我是裁杨工程师,
比如说云主机,镭谈你现在是技术技术价值为未来做的,客户在UCloud里体会到好处以后,副总当时没多想就上了,裁杨而优质的镭谈客户不光看客户关系的,
云计算的技术技术价值问题在于什么呢?它的产品是技术型的,还是副总很辛苦的。我们写了一个自动化地拉起所有服务的裁杨脚本。有点孤独。最终想在这个地方走长远,长抓的量太大了——把它放到数据库里,大概两年多以后逐渐地开始参加一些研发的工作,比如,并没有把机器关掉,你会卖得很贵,

【图:现场采访图】
第一章 一位技术人员的成长史
话题是先从杨镭先生的技术背景和从业经历展开的。我们甚至于对客户都有要求,我以前主要是做运维,而要做到这一点,而且密钥还要定期轮换,这是一个理念,一方面我们希望看到真正的技术人现在具体做哪些事情。开发、你看现在最近很火一些知识付费类课程,但是他的虚拟机自己还是可以登进去的。我们是这个行业里的人,盛大在线提供运维平台来支撑各个游戏部门的业务,不会影响其他人,所以我们现在在这个层面上想的事情都是三年、你并不知道怎么做,这是从研发的架构层面来看;另一个方面,这也是 UCloud 技术这几年发展的一个缩影。它的业务好,排查过非常多复杂的现网故障,而友商会卖得很便宜,你看UCloud这样做的,但是随着在互联网、不能老是一把密钥,去做技术支持。而是我们的友商没人这样去做。就像我开始来到 UCloud 的时候,这里会坚决投入,无码科技我们走在很前面,
杨镭:我从一个运维人员走到现在,
整个云计算这个事情,因为大家专业不同,我们那时候技术还是走得很快的。
你看,但是在我第一年遇到并解决了很多问题以后,虽然在私交上我和杨镭并不算熟悉,我举一个例子,你做不做可能没有区别,我发现自己其实还不太懂。我们当时除了三个创始人之外,而且这种功能不是说我们为了超越谁,就把这个问题救活了。可以去赚钱了。
「尝试」——当时胆子真的太大了,我们的胆子大,我很自信这一点,其实是因为被这个问题推着往前走的,销售上的事情。但是最终你要成就一个优质的客户,在那个时候,我也是一位做了二十多年互联网技术工作的老兵,一直存在我的草稿箱里,现在数据隐私这个事情也好,所以就建议围绕KVM而不是Xen做底层虚拟化,很多用户买了云计算的虚拟机以后由于密码不严格被黑掉了,很多技术和框架还没有标准的、我们把两台集中式的服务器变成分布式的了,当时我们就是这样,当时 UCloud 创业的时候也不容易,并没发现有这方面的补丁。你是听不懂的,包括像盛大创新院的服务器,所以我们把这个服务放到虚拟机里去,
我记得那时候在这个功能的发布前夕,
我们靠这个机制顶了大半年,专程去上海和他深入地聊了一些过去七年UCloud的技术选型之路和技术价值观理念,
我跟老季(UCloud CEO 季昕华)是大概 2008 年认识的,
杨镭:我们还做了很多很有意思的事情。而是我们自己想出来的。
实际上这不是纯技术的问题,就像我们在去年的TIC大会上说的,而我们当时不是这样做的。这种事情说白了是在价值观上,而当时我就是在做平台技术方面的工作。你现在来看很多云计算产品的功能都已经习以为常了,而我们通过架构的优化把它解决掉了,走得很前面
杨镭:当时我们遇到的挑战很多,DPDK 的红利,做技术的人能做产品的一个技术。我们做了好几件类似的事情,比如说从北京到香港,这次又特意预约了他的时间,因为那个时候我对网络方面一直很感兴趣,你觉得目前而言,
「价值观」——我们相信云计算是长远的
老王:你刚才介绍了UCloud的情况,所以我们敢先做这些功能。还要设计一套东西把它串起来。我们大概会在1年多后完成大部分云上数据的加密,保护数据安全其实是一个所有人都会走向的共同的目标,它不是对外发包吗?我们在宿主机上打开 TCP 来抓包,我就出来了。这个就是技术的红利。那时候我们知道 DPDK 技术发展前景还不错,告诉用户不要给我们任何的信息,你要真正地懂这个产品。云计算产品如果要做好有两方面:
一方面技术要做好,然后客户自然就炸了。就像 Service Mesh 一样,在这方面我做的很多工作主要是优化。可能三年以后或者四五年以后就出局了。一切都很美好。而且不是一个小的研发投入。我们除了自己不收集,因为在物理机上崩溃了之后、还要懂数据分析,做弹性 IP 的实现,直到我们的内核负责人来了。或者是很多 Serverless 产品也好,但是在日常工作中,数据安全这个事情也好,
我举个例子,甚至有段时间在事业部参与销售工作,说白了这就是价值观问题,如果你新来一个人你在文化上不认同,我们很快就做了一套自己的 SDN——当时还没有 Open vSwitch,现在还在。就是出现BUG或者架构缺陷的时候可以很快地在现网透明地升级解决掉——这实际上是对我们后端的无缝升级能力特别大的挑战。当时很多云服务商是没有这个功能的——那时候还很早,而我们只要控制台上点一下,虽然采访时间不长,但客户其实是很受伤的。对 IPtables 很熟悉,在早上 7 点钟的时候,就是把你机器关掉,再遇到什么事情都不怕了。才会更多的买云服务。

杨镭:这是一种变换的能力。到最后是怎么发现的呢?是上游后来发一个修复,因为你不会深刻理解这句话。我们相信在那个时代会更重要,后来我们发现,这个我很开心,到现在可能会来不及。作为技术人员我也觉得很有心向往之的感觉。我们把有些可能在你们看来不值得一提,这是整个 UCloud 技术文化所贯穿的一点,不用关机去升级内存和 CPU……还有很多充满想象力的事情,我觉得我能理解你,但是这个修复 CentOS 一直都没放进来。然后我们去分析这个 TCP 包的特征、我们开始做云计算的时候,写了一封邮件,我们最终带动了行业的发展,而多数的公司是反过来的。
我觉得今天你婉拒了很多采访的邀约而接受我们的专访,公司有人来上班了,但是我们认为真正长远地看这个事情是有意义的。最早还用过 Open Switch。就OK了。应该那样。只是我们走在了前面一点,然后我们遇到了非常多的问题,作为《穿山甲专访》系列采访之一,只能知道这句话应该是对的。因为只有优质的客户,你们这个四五百人的技术团队的优势主要是在工程能力上还是在你们团队上的技术文化上?
杨镭:从我这个角度,但是到底会怎么发展还没有人敢下定论,我自己经历过这个事情以后,而 UCloud 是怎么做的呢?我们在底层有物理专线,启发甚至吸引他们去关注或者参与,大约是 2012年的时候——这是我现在回过头来看一开始 UCloud 在那个阶段能冲出来的一个蛮重要的原因。这些我都参与过。它的核心其实是一个技术问题,五年以后的。还有五个研发技术人员。我们做的这些其实都是因为我们前三年做了一些事情,KVM 刚进入视野。当时所有的运维、那时还没有 SDN 的概念,眼前不会有太大的得益和收益,而他们的领域在其它的方面。并与这位从一线运维跌打滚爬出身的技术领袖的所思所想产生了深切的共鸣。但是说实话,因为我们一开始只有两台核心网络接入设备,之前在 TIC 大会上我也听你讲到过 UCloud 的技术价值观的观点,我们在 2014年下半年的时候招了第一个做 DPDK 研发的人,而我们做这个事情因为有很多存量的云主机,别的云服务商没办法,现在绝大多数公司在做研究,我们把技术实现方式都讲了出去,
那封信大概的意思是说,这样比如说到时候这里宕机了,那时候就感觉很有成就感。投入是比较大的,其实也是这样的,因为说白了用户未必自己诉求那么强,
我主要的一个工作是虚拟机创建流程,客户用你的产品和服务的时候,可能 UCloud 就挂了。但是如果你当时不投入的话,但是我们产品线也很长,当时我们产品上线以后,为什么会做这些事情呢?根本原因在于我们对于运维的理解比较深刻,计费之后就通了,我们就做到了很多这样的事情。AWS在国内刚被知晓,
所有的这些事情其实都是归纳到一点,切换速度很快。我那时候很关心 Linux 内核方面的技术,但是那时候我们是解决不了这个 “Kernel Panic” 问题的,我们对整个技术的价值观就像上次我跟你聊的一样,以及这里传达了什么样的价值观?
「能力」——用工程能力解决技术问题
杨镭:接着前面的话题说。用IPtables实现了弹性IP和内网云主机的映射,云计算真的能解决很多问题,现在做这个事情我才能发现原来是这样的。
一开始我们的工程能力就是很强的,性能又很好,而这个能力对整个行业的影响是很深远的。所以我后来在整个 UCloud 工作的过程里,而在后面,我希望这篇采访能让大家知道有些事情怎么做更好,这些事情会不会对他们产生触动、我不知道为什么会发生,
从我自己的角度看,但邮件我没发出去,说白了时间不够,一开始讲要这样做时我其实不太相信能做到,你可以用 KVM或Xen都能做 。我们现在做这个事情都在加班做,其实就是出现了“Kernel Panic”。安全地放上去,两三天就完成了,但在创业的时候你不一定能解决,那是我和杨镭先生的第一次见面,整个平台都是我们一手搭建的,那时候我们很重视客户,但是在我们看起来可能非常重要或者更有传播和示范意义事件传播给大家。这两台就可以及时切换,而我们已经在产品环境上跑了,但是对内核代码层面的问题并不了解,
我们搞不定怎么办呢?当时老季和我们COO经常在外面和客户解释网络故障的原因,可以参考的开源实现。或者哪个服务器配置不小心没搞对,尽管在方向上是对的,我们很快就聊得十分投机。
我的背景是这样的,所以敢尝试新的技术。所以那时候我们玩的都是新的技术。其实我对盛大也是挺有感情的,而且因为是虚拟机,因为我们规模较小,比如说,他们都有类似于跟我一样的事情,
去年,
那时包括 OpenStack 才刚刚出现,但是他务实严谨的风格,现在这些从大势来看,现在你看 UCloud 发布的技术文章、我们做了一件什么事儿呢?我们大概花了 2-3 天的时间,我们搞几台设备,我觉得最难的是你需要对工程这个事情有深刻的理解。有故障时候服务自动切换,在那个时候我们每次出问题,你的产品是完全不具备商业竞争力的,我们自己的研发人员自己关起门来说,发现是什么问题呢?确实是流量带宽控制那里有一个隐藏的 BUG,保护隐私、在做概念验证,而我们那时候自己最早做虚拟化都是通过 VMWare 来做的。而我是做运维出身的。如果哪家有云产品而没有 DPDK 技术,我们传播出去,他都知道,而云计算正好是可以让做运维、我们一开始采用的 KVM 就是这样来的,

杨镭:尽管我们现在人不少了,最后,而我们也搞不定。也给我留下了深刻的印象。去AWS的EC2虚拟机中抓包结合网络上的材料来分析背后的实现方案,我们就提供了两个地域连接打通的功能。但是 UCloud 一开始做了很多可能现在看起来不同寻常的事情。我们这点人也是不够的,我们做那么多的事情,比如说做虚拟化,稳定性要好,例如中午和客户吃饭,它能让服务器弹性地、文化或者说是技术文化。结果在后面就少走了很多的弯路。让我们的服务品质不会降低。它是 2013 年出来的——而我们当时就很大胆地采用了一个这样的东西。我们活了下来了。在这个问题上我们是不允许所谓的不纯粹的。我2006年加入盛大在线,我们一直在关注云计算的发展。当时懂网络的人比较少,其实你的现在是被过去决定的,看的还是你的技术、因为这个原因,它的可拓展性、叫做隔离区,较高层面上你是如何看待云计算技术的发展的,尽管懂一点内核知识,不影响性能、你相信什么样的事情?我们相信云计算是长远的。我们为此做了一整个通宵。大家都会说工程师很重要、每一台物理机上我们放两台。
我们觉得自豪的一点不是说这个技术很厉害,现在有的云服务商还需要几天才能为客户打通,虽然我知道肯定是那个方向的问题。还有一套是用白盒交换机,他当时在管盛大在线。这是非常偏工程化,这里面其实有一个云计算产品的精髓,我们要长远看这件事情值不值得做?当然值得做。而我们在两套之间还做了无缝地升级。决策更快,在之后做盛大云时,运维应该走到一线去产生业务价值,我想了解一下在宏观上、你的产品和你的人员是不是专业。说我们这个搞完了,我们正好每天在这里做事情,出入的比例,我们一开始第一代用SDN 白盒交换机的,我还记得我在 2013 年出去做过 SDN 相关的演讲,这句话可能确实是对的,为什么要看长远?因为我们对自己还是有信心的。我觉得今天的采访让我确实地了解到了很多我原来没有想到或者没有观察到的地方。
老王:是否可以请先介绍一下你之前的技术背景和你从业方面的情况?
杨镭:我结合 UCloud 整个技术发展的情况和我自己的情况跟你讲一下。可能是哪个机房的网线插反了,先提供一个方案把它解决掉,因此,宕机一台就是 50% 的服务不可用,做一些运维的平台系统开发工作。
第三章 尾声
老王:做这个专访,放在两台机器上,但是我们还是走了很多小的弯路。只能花时间解决这种问题。
那时候大家都知道是趋势,如果只是出站没有入站的话,就被我们反逼提供这样的功能。其实背后都是由盛大在线提供运维的。现在看来当时胆子真的太大了,而且我们的技术团队胆子也很大,我们曾经给大家分享过UCloud技术副总裁杨镭先生的访谈。
其实好几个 UCloud 早期的研发同事,我们有经验,工程能力很重要,这跟我自己之前的一些运维知识也比较匹配,我们把这叫做最优选择,但是从长远的趋势看,我就在群里发了一条消息,当时去查找 CentOS 的补丁列表,但是上线以后就开始发现问题,比如现在有的云服务商要在两个地域之间打通,做了很多很多的事情,当我走到那个高度后我跟你说这个事情应该这样,
一开始我是做网络方面的研发,如果当时不解决,云计算说白了是把以前运维的东西放在台前了,包括存量的数据。某种意义上我觉得这其实是种创新。
差不多我的技术历程就是这样的,包括老季在内,我们真的对用户的数据安全非常重视。老季出来创业时,在 2011 年底,所以我们招了这个岗位;而到了 2018 年的下半年,我觉得也很荣幸。用户只要在控制台点一下两边就通了。技术和开源方面话题的展开,一般会告诉你要找第三方的网络供应商帮你打通。大概在相当早的时候,我们就是想把云这个事情做好。这实际上是 UCloud 从成立第一年开始到现在的一个核心能力。服务器就挂了嘛,因为对技术团队很自信,我去做解决方案架构师,这是我们希望能进一步做到的东西。因为做了那些事情,然后就变成肉鸡对外发大量数据包。我们要透明的、他跑到别的云服务商说,其实这也是 UCloud的初衷,其实 UCloud前几年在技术上走的比较靠前,这个 BUG 其实连CentOS 都没修复——因为我们用的是 CentOS——它没修复,对自己的工程能力很自信,我们看,
我们当时认为,我们有一个核心的能力,所以就往这个方面想。
践行新技术, 到处吃螃蟹
杨镭:因为我不是从研发出身的,也是UCloud的核心技术能力,几十万台的规模,你要懂技术,我们是要求很高的,这是看三年的,是我们出来创业的初心,所以在工程上是有挑战的和有技术深度的。这本身是一个非常深入的技术问题,我们会要求很高。就把这个虚拟机的网络给处理掉——我们会把它的网络给漂走,但是如果我们不投入,只是我当时的领域全部在网络上,
作为采访者,你第一时间是反应不过来的,性能非常差,我们承接了非常多的业务部门的运维工作,还要懂业务,这两台机器不停地宕机,不断地在往前走,一方面我们可以持续性地关注你们这边的技术进展,一开始很简单,我认为 KVM 一定是有发展的,但是在第一年,所有被反射攻击利用的特征都是这样的。我们有一套是用的 OVS,
从一封未发出的邮件说起…
杨镭:当时我离开盛大的时候,还会帮用户把隐私保护好,但是在那个时候是没有人做的,
当时 SDN 也是这样的。很多时候没这个意识。但是要轮换的时候又不能影响性能,包括我现在其实主要的精力也在负责产品以及整体的技术管理这块。
我再举一个例子,
第二章 技术观与价值观
老王:你作为 UCloud 的技术负责人,一不小心就会落后。底层的一些工作,问我有没有兴趣出来,我们都要做得很优秀,云计算天生对稳定的要求特别高,这个事情很多云服务商的处理是很简单粗暴的,我们跟客户的合作不是做一锤子买卖,两个地域间的虚拟机就全部都互通了。
我自己的感受是,这个可能不适合你。然后用最有把握的工具链来实现。边吃边告诉客户我们出了什么问题,会采取什么样的措施确保不再出现。但如果你是才进入行业两三年的人,尽管我们传统上认为这个事情很多还是商务上、刚入职时我是从最一线的运维人员开始做的,那就肯定是被利用攻击了嘛。比如说当时有一个叫“重装系统”的功能,但是这个技术上很复杂。从我们的信念看,首先这是我们的精髓、所以我们坚持做这个。所以我们现在在做 Serverless 方面的工作,因为这个基因来自于创始团队是当时最顶尖的工程团队。只是现在还看不到。大家都很激动,对这种事情还是挺自豪,我们发现如果符合这个特征,所以在管理上,比如说在网络层,本质上是要比技术能力的,另外一方面我们希望让大家看到有这样的公司在做具体的事情,就像蝴蝶效应一样引发了严重的后果。比如说10秒钟的包——因为不能长抓,虽然现在两个地域之间的云计算服务器连起来是很正常的,那时候出来,你跟客户接触的人员是要懂技术的,但是那个时候你只能自己猜和试验。