2024年，杭州 · 云栖大会，阿里云网络产品线举办 “简单易用的智能云网络，让客户专注业务创新” 技术分论坛，带来在增强确定性、深度可观测、敏捷全球化和高效自动化等云网络核心能力方向上的产品服务全新升级。阿里云网络产品线 解决方案架构师 陆碧宇带来《Terraform从入门到实践：快速构建你的第一张业务网络》主题分享，阐释阿里云网络长期以来在企业云网络高效自动化上的技术深耕。
本次分享重点围绕阿里云网络在Terraform领域一路走来的心路历程和经验分享，并用4个生动形象的客户案例分别阐述了 “云网络+Terraform” 快速帮助客户从高效部署、敏捷运维、故障切换和业务创新四个维度构建自己的业务网络，从容应对 “AI时代” 复杂多变的市场环境和业务发展要求。
以下是演讲全文（已编辑，约5500字）
在开始之前先分享一下个人的经历，我的职责是产品解决方案架构师，日常主要负责的是海外客户，有接近4-5年的服务海外客户的经验，我看到了先进的海外企业和出海企业不一样的用云视角和姿势，这些给我们带来了很多新的思考，我也希望在今天的分享过程中带给大家。
走出国门，特别是到硅谷，你会发现大量的企业都在不约而同地使用Terraform，这让我想到了孙正义的 “时光机效应” ——它的逻辑是今天在世界的某一个角落发生的事情可能几年后会在世界的另一个角落发生。Terraform所代表的的自动化理念就像“时光机效应”一样，总有一天会走到我们身边。
进入正题，本次分享的内容主要是两部分，第一部分主要是站在云网络产品的视角，和Terraform 、IaC能力、API的历史发展中遇到的一些问题、解决问题的过程以及沉淀的经验。第二部分是基于这些经验，我希望通过几个真实的客户场景，带大家感受下云网络结合自动化、Terraform能力怎么样帮客户解决真正的业务问题。云网络作为IaaS产品的一部分，是润物细无声的，所以我希望用业务的视角去解决业务的问题，从这个角度带大家走进一个新视界。
一、云网络的Terraform之旅
云网络为什么需要自动化？
随着AI时代的到来，对人效的要求越来越高，随之而来是对于自动化的迫切诉求。那么，云网络为什么要自动化呢？原因也差不多，一是效率，二是人才。
效率方面：成本高、质量差、易出错
科技的高速发展正在改变各行各业，市场的节奏变化也比以前快了很多，企业就得具备面对变化的能力，不停地试错、探索新型的市场。举个例子，
今年是茶饮赛道大出海的时代，我们看到蜜雪、瑞幸等各类茶饮企业都在出海。假设你是某茶饮的IT负责人，今年公司给你的要求是在全球范围内开100家门店，覆盖东南亚、欧洲、北美等6个大区，6套系统，但你只有3个人，那就需要考虑部署效率。“企业上云，网络先行”，作为业务上云的第一站，网络需要第一时间考虑6套大规模系统的标准化能力，否则会付出大量额外的成本。同时手搓的方式在你搭建第1套系统时还可以勉强，但如果6套都继续沿用的话，大量的工作会大大加剧出错的概率，所以自动化也是非常重要的能力。
人才方面：人效不足、供应不足、人才匮乏
人才匮乏在网络部分相对来说体现得更明显。网络是一个相对独立且专业的领域，在传统网络里面，思科的认证体系十几年来为行业贡献了大量的人才，但现在上了云，传统网络的基础技能没办法完全匹配云网络的能力，所以专业人才依旧供应不足。还是举几个例子，
一个是某全球知名在线教育企业的IT负责人，他说以前在中国大陆的时候，他们公司才10个人，租个WeWork就行了，IT基础设施一应俱全，他一个人只需要负责所有云上业务的基础设施部署即可。但最近，公司业务飞速发展，涨到了五六十人，WeWork已无法满足，只能搬家了。此时，他不仅要负责云上，还要处理线下五六十个人的IT网络，忙得焦头烂额，已经连续加班一个月了。所以他在招人，招一个既懂云、又懂传统IT网络的人才，但发现招不到。我只能跟他说这很正常，这类全才很少，我们也想招但很难招到满意的，所以这块人才的痛点是通病。
另外有一个日本游戏客户，这个游戏客户的业务以小游戏居多，部分是端游，部分是手游。他遇到的痛点是日本IT人才的流动也非常频繁，一个项目做完，当他离职的时候，会带走大量技术开发的能力，原来需要做历史沉淀的能力沉淀不下来，新人又接不住。客户很痛，所以考虑用Terraform，把多年的游戏开发经验和代码都沉淀下来，作为公司的资产，应对人才的流动。
这个自动化的出发点给我带来了一些新的思考，用IaC的方式可以把一些历史中踩过的坑和解决方案沉淀固化，形成一些可实操的实践库，同时也能面对在AI时代的人才流动问题。所以我们今天的思路就是把我们阿里云网络产品线一些人才的经验和最佳实践沉淀，通过IaC、自动化、Terraform方式输出，持续地服务企业的其他业务。
云网络产品设计：贯彻API First，改变产品设计工作方式
以上是云网络最开始面临的业务挑战。作为一个网络产品，我们比较早的时候就采用API的方式，有对应产品的API能力，但最开始对这部分的能力的重视度不够，我们认为把产品本身的API能力搞定就行，客户就可以自服务了。初期确实是这样，直到后来我们发现问题，当深入不同行业的时候，虽然大家都用同样的API，但大家用云的姿势是不一样的。
比如说云游戏的客户，它的特点是对于单元算力的要求比较低，但对于IP数量的要求非常多。同时它把IP从BGP转化成静态IP，即一个IP变成3个，总数量就跃升至上万个IP。试想一下，把一个EIP在控制台上绑定ECS或者绑定NAT网关需要多久，整体加上Console的操作界面大概要1-2分钟，要重复1万次，该怎么做？大家会用API，但它有限流，一分钟只有50次或60次，业务需要达到150-200才可以。发现问题，就解决问题，我们解决的过程非常痛苦，因为代码已经写死了，产品在迭代的过程中就遇到了这种类型的痛点，这是其中一种案例。
另外一种案例是国际的企业客户，他们的特点是云上的资源不一定特别多， IP可能就几百个，但不同人员对于云上资源的开通、部署的要求是不一样的。因为企业客户更关注的要求是合规、管理、安全，这几个点是企业最高优先级，是红线。这就要求业务团队的人只负责业务，不能创建EIP，这就会对API造成更强的诉求是EIP不仅要做好IP的功能，同时还要做该用户角色的账号能否可以创建EIP。最开始我们做产品的时候get不到这种需求，当我们深入了解客户的场景之后，发现对这类企业来说，这就是一个非常通用的、非常标准的管理类需求。如果一个业务随便能创建EIP出入公网且不加管控的话，如果出现问题，造成的后果是不能接受的。
获取和理解这类需求后，我们要追本溯源，今天我们做API、Terraform、自动化能力，要从产品的Day 0开始做一些设计。所以，我们全面迭代了产品设计的方式，包括功能交付的路径。我们会从客户的场景出发去设计一些对象模型，同时去做一些操作路径来满足客户需求。现在，我们每个产品的API发布之前，都会去做文档审核，甚至是客户POC场景的模拟，确保这个功能能按照客户的场景和要求交付。我们对内部所有云网络产品也提出了新的要求——就是要彻底地贯彻“API first”，因为我们踩过坑，淋过雨，所以希望给我们的客户，给大家打伞。
更加健壮的IaC能力
基于这些产品能力，我们目前的云网络主流产品已经做到100%的Terraform覆盖，全面支持基于Terraform的自动化部署，当然在Terraform背后是更强健的IaC能力、API能力。同时我们也支持CADT、ROS等不同的自动化能力和工具；在此之上，我们还提供了更健壮的IaC能力——比如我们会深入用户的一些业务场景，模拟客户用云的姿势来验证、强化IaC的能力；此外，我们会做一些场景测试，也陆续得到了很多客户的正向反馈，包括很多阿里云内部其它产品的反馈，因为网络是连接所有其他产品的基础，我们要做到并做好连接的功能。而这些正向反馈，也激励着我们持续做好这个事情，让我们更加坚定。
进阶，和客户一起提升自动化可靠性
与此同时，我们会针对一些头部客户的复杂场景与客户共创，从用云的一些姿势和场景做分析，跑一些模拟的配置验证，并将此纳入日常的验证任务中，既保证每个用户的体验，又要扛得住后端API负载和并发。整套流程在不同的大客户场景中体验下来后，能看到累计修复的bug越来越多，系统运行越来越丝滑，这让我们有一定信心去提供更多进阶的能力，比如去支持客户的E2E场景测试。
二、Terraform+云网络：快速构建你的业务网络
这是我们整个产品基于用户需求和场景出发所迭代的一些自动化能力。针对第二部分，我希望通过几个用户的真实案例带大家走进云网络和Terraform、自动化能力碰撞后，怎么在用户的业务场景里发挥效能和价值。我将从四个维度——高效部署、敏捷运维、故障切换、业务创新，通过四个案例带领大家打开脑洞、发挥想象。
高效部署
大家都知道API有些并发能力，我们结合这些并发能力能做到规模化部署。
首先，我们从一个欧洲金融客户的案例出发：
当时客户日常会有很多和交易所互动的需求，并且它在日常跟交易所访问行情、交易订单的过程中发现一个问题， 交易所为了维护稳定性，访问其公网API的每个IP都会有限流，同时它也是该交易所的大客户，所以它就提出了要海量的IP承载行情和交易业务，这个场景需求就是怎样在ECS上快速绑定300个左右的IP来支撑轮询访问，这是一个非常典型的金融场景。客户原来是用控制台的，控制台一个EIP发现、创建、绑定、交付需要1-2分钟，10个需要个10-20分钟，100个、300个5-10个小时根本交不了，要几十台这样的机器，涉及到几千个IP甚至上万个IP，这种场景肯定要用到自动化工具。
我们帮助客户一起深入这个场景去做Terraform脚本的开发、迭代。因为我们有IP Prefix的能力，一个ENI可以支持绑定一个subnet，主要的问题是在整个轮询的过程中怎样实现自动化，能否用一套模板，点一下，泡杯咖啡的功夫就能交付。为了实现这个需求，阿里云网络和客户一起开发了一个Terraform模板，就用公网的这个方案，客户最后比较开心的把这个模板应用到真实的业务环境中。
这是非常典型的高效部署的案例，可以帮助客户实现效率的提升。正是因为把原来控制台的一些功能API化，这样就有确定性的调用时间，就能去实现高效部署，做到20倍的效率提升，而且在这么多资源的管理和部署中不出错。
敏捷运维
第二个是敏捷运维。我以一个游戏客户的案例为例出发：
该公司规模相对较大，有非常多的游戏工作室和开发团队，不同团队对于自动化的要求不一样，有些喜欢用Go，有些喜欢用Terraform。其中一个Terraform团队提出需求，我们深入了解了一下，由于新游出海的时候没有办法判断这款游戏在哪个地域比较火，比如东南亚地区，一款偏二次元的游戏可能在越南不一定火，但在印尼特别火，火了之后就得加机器，否则开服第二天就会出现卡顿情况，如果卡顿时间过长，会极大影响用户在线率，进而导致用户规模急速下降；所以客户要在非常短的时间内做资源扩容。相反，如果某个区域游戏的生命周期已经处于长期稳态，没有开服时那么火，就要考虑资源缩容，所以客户Infra团队就有大量日常运维的工作，要上线机器、调配置、下线机器、调配置，大量的新建和释放动作。我们和客户一起共创，不断迭代使用阿里云Terraform的姿势，逐渐形成了一套多云的Terraform模板，帮助客户大大提升日常运维效率，部署过程中提速16倍，日常运维的过程提升8倍的效率。
今天，我们也把这套模板release到了Terraform官网，以方便更多的客户使用，快速构建混合云的连接。
故障切换
这是一个老生常谈的话题。同样，这里也以一个制造业外企客户的真实案例来讲述故障切换的新思路，今天我们也可以通过自动化的方式来实现故障切换。
制造业往往由全球的ISP线路来打通全球的工厂，云上、云下的IDC、多云的环境。在去年临近春节的时候，该客户的运营商专线断了，短期内无法恢复，该线路的用途是连接设计师团队和位于日本某云上的设计师的系统，以支撑设计师团队的日常工作，例如绘制CAD。
当客户找到我们，求助做一个高效的故障恢复链路时，我们就想到了用自动化。因为外企比较依赖伙伴，IT团队架构强但工程能力弱，而且要紧急恢复，进行客户赋能来不及；因此，我们选择使用自动化方式，尽量屏蔽对于各类资源的调试。我们详细分析了客户的场景和当前云上已有的资源，快速敲定了自动化方案，并同步转化为了 Terraform 脚本，通过云企业网CEN打通了大陆和日本某云的环境，实现故障恢复。
这个case带给我们一些思考，客户也可以用自动化的方式去做一些逃生通道。例如你云上的某个AZ挂了，甚至某个regin出问题，如果日常提前做了一些自动化布局，同样一套代码能快速在另一region拉起，只要把一些必要迁移的资源迁移即可，这是一个非常有意思的思路，是我希望今天带给大家的。
业务创新
AI时代，没有AI怎么讲业务创新呢？我们服务了很多AI企业。在整个过程中，迭代了一套特殊的组网方案。因为GPU资源特别稀缺，虽然各个云厂商都有足够的GPU资源，但分到某一客户可能不够，可能是你要的地域今天不够、下周不够，或者下个月不够，经常会有这种问题的发生。
我们遇到一个AIGC的客户，他目前主要用来做推理，有自己的模型，用了一个市面上知名的基模做了一些AIGC的finetune，他希望日常的业务能做一些推理，但是对于小卡的GPU资源要求比较多。客户日常业务在上海，上海GPU的一些小卡需求的量也不是特别稳定——这和下游客户的需求量有关，今天可能要200张，明天可能要2000 张，后天可能更多。客户希望能在上海获取到更多、更灵活的资源按需使用。由于上海电力紧张，而且GPU紧缺，所以我们构想了一个全新的方案，在乌兰这个相对电力成本较低、卡资源又比较丰富的地方帮客户实现。
数据在上海，算力在乌兰，实现“东数西算”，并基于“东数西算”的Terraform方案进行交付，就可以实现有推理请求处理在乌兰，推理结果再返回到上海OSS。我们也基于客户场景搭了一套环境，并找专门负责AI的同学做了一个大模型的模拟验证，用的是当时比较知名的图生图模型，上海-乌兰整个round-trip的时延大概在40毫秒左右。以一张 10M 图片为例，整个业务包括模型处理、结果返回到呈现的耗时大概在2-3秒，完全满足业务的要求。
整个场景其实是帮大家打开脑洞，网络是一个连接型的产品，它可以帮客户打通不同地方的算力、存力，就像交通基础设施高铁、飞机一样，帮你准确送达；或者像物流，帮客户把一些资源比较充足的地方的服务运送到资源相对资源贫乏的区域，实现类似于东数西算的能力。当网络结合自动化再加AI可以有无限的可能性。这是我希望带给大家的一个案例。
云网络卓越架构白皮书和TF Module正式发布
最后安利一下，阿里云通过多年对客服务的经验积累，逐渐沉淀了一套卓越架构Well-Architected（简称 WA）。WA里包含了详细的架构设计原理、关键点和最佳实践，阿里云网络基于这些框架也完善了云网络的实践总结，将会在11月发布上线云网络卓越架构白皮书。同时，配套的Terraform model 也会逐步上线Terraform官网，敬请期待！
