一、高效管理全球云基础设施——利用Terraform的强大功能实现快速部署与灵活调整

甄云科技是由IT咨询公司信息孵化而来，为企业提供卓越的基于云服务的数字化采购平台的服务商，也是国内唯一家荣登榜单用户之声的服务商，陆续服务了全球30多个国内外的知名的中大型企业，我们的客户遍布全球20多个国家和地区。

总结起来三个方面分别是资本亲睐、产品领先、专业可靠，采购速度的核心采购流程形式包含两个闭环的。第一个的话是供应商管理的闭环，从供应商的准入、考核退出，我们做一个全流程的一个闭环管理；另外一个是从寻源到付款流程闭环，产品覆盖了整个企业的全部的品类，从生产性物质、非生产性物质来说，比如一些服务类、工厂类、办公类等等全部品类的覆盖。

对于甄云产品，业务架构就是按照这两个闭环来进行设计的，我们有四大套件供应商管理套件，就是负责来管理供应商这个闭环的，然后另外的巡演协同商城套件的话是负责管理不同品类的一个业务流程的闭环。我们都知道采购不是一个单独的事情，对内和对外的话往往需要打通非常多的一个系统，产品对内能够打通一些核心业务系统，像ER、OA和WMS。对外的话，我们的产品还能够对接各个生态和伙伴赋能，其中包括电商品征信平台以及电子签平台。甄云科技的产品提供了两大门户，采购门户和商城门户，通过其来承载上述的功能。

甄云科技是于2017年成立的，整个业务发展比较迅速的，2018年的时候获得了A轮的1.5亿元的融资，完成了商城产品的一个研发客户规模和团队规模达到300+一个水平，开始逐步的去探索SaaS业务，在2020年的时候我们是获得了B轮的一个3亿元融资，完成了甄云盘古一代产品的一个研发，客户规模是达到了700+，团队规模600+的一个水平，开始逐渐的往SaaS业务转型。

在2021年的时候，获得C轮的一个6.5亿元的一个融资，产品开始往平台化和智能化进行升级，客户规模达到1000+，团队规模700+，也开始逐步的试点以及出海业务，截止到2023年的时候，先后为许多的大型日企提供了私有云服务，并且在日本我们也建设了海外的第一个公有云，同年在日本子公司也成立了，继续深耕海外的市场，十月份有全新一代的数字化采购产品即将发布。

业务如此迅速的发展，其实对我们SIE团队也提出了一些更高的挑战，而挑战主要是在两个方面：业务方面的话，就是在整个发展过程中，云资源规模其实是在不断壮大的，大家也有切身的感受，在一年的时间内，所管理的一个云资源的规模就从最初的十几个发展到几千个的规模，有了几十倍的增长，但是规模在增长同时是对交付所要求的时间及是在不断缩短了，因为场上机会稍纵即逝。

另外就是在整个公有云平台的运营过程中，我们是有一个频繁的一个扩容的一个需求的，韵尾的复杂度，也是在随之节节攀升，此外的话就是公司的一个大队，公司内部也有一个精细化的一个管理的要求，然后可能同时变形，大概有十几个项目在变形，每个迭代也会交付1500多个这样的一个需求，对如此大量的一个云资源进行一个统筹的分配，一些共享类的云资源的一些管理权，归属权的划分的难题逐渐浮出水面。

另一方面的压力来自UA团队，团队内部也有一些管理标准化要求，但是传统的资源供给方式其实是没办法满足业务的需求的，并且传统的资源供给的他整个变更过程是不可记录的，那也就很难做到能够快速回退了，特别是伴随让我们出海的试点和落地我们所面临的跨平台跨区域跨账号统筹多渠道云资源管理的也越发了困难，并且平台和平台之间其实是存在着很大的差异，对于认知成本也也有很大的增加，团队内部的一个维护，还有培训的成本也随之升高，再就是近两年大家也能够切身感受到，所有的企业几乎都在提降本增效吧，我们团队内部的一个成本也需要做一个更为精细化的一个管理，让传统的资源工具方式，也就是缺乏一个统一管理者，没有一个系统化的一个管理体系和财务分担策略。

二、显著提升开发与运维效率——通过IaC方式减少人为错误，加快迭代速度

如何面对这样的问题，我们也算是幸运地发现了IaC这一个理念和Terraform一个工具，在有了一些认识和理解之后，有了一个甄云科技的一个IaC的一个建设构想，就是采用而业界可能常见的一个三层抽象一个示范，第一层的话就是一个最小且可赋有代码抽象，它对应到Terraform中的形象是资源层的抽象，其实Terraform本身做得比较好的，有非常多的云厂商提供了自己的Terraform，其中有大量资源可以供大家去使用。

第二层的是原子方法的抽象，对应到Terraform是个模块的抽象这层的话，我们认为是目前做得不太好的地方，我们也是用了很多社区的模块，其实是很难跟我们的业务需求相匹配。第三层的就是技术还有流程的一个深度结合，在Terraform就是一个场景的一个抽象这块也是我们未来探索的地方，基于这样的一个构想的，我们也推动新模式的一个变革。

第一个的话就是坚持一个长期的投入，因为入门比较简单，但是想要精深的话还是有一定的曲线的，所以要坚持长期投入对一些高平的高优先级的资源模块业务来进行优先抽象，然后优先投产来逐步提升我们整个的效率，然后做到一些相对规范化的管理之后，通过IaC代理业务进一步落地，就能够减轻跨团队跨部门的一个成本，提高整体的一个生产效率。

有了这样理念以后就能进入Terraform，首先构建技术设施的L1层也就是构建云基础设施代码复用层。在初期建设和保障的思路首先就是模块的最小化，尽量将模块拆分为单一职责，避免扩大，确保每个模块完成特定功能。另外在设计过程中要考虑模块和模块之间的接口是模块，能够方便组合提升复用性和灵活性。另外在实际开发过程中也要尽量保证自己的命名，比如说命名规范提供完备的文档测试用力而来，保证他的功能清晰，能够方便他人的使用。最后尽量模块去编写一定的一个特定单元，来保证他的功能是满足预期的。

那如果有这样的思路其实就够了吗？其实还是不够的，我们来自业务压力仍然是层层加码的，于是才推动了从L1层往L2层抽象一个过渡，同时在这个过程中，我们也针对Terraform本身的劣势也做一些分析，第一点，如果大家仅仅是将我们在控台创建了一个的云资源，平铺到我们的Tyrod代码中，那么实际上这个复杂度并并没有减轻的，重复性的工作，从Console可能延伸到IDE，另外便是Terraform所使用的配置云叫HCL，它本身是介于代码语义和业务语义之间的一个配置云。

对于一些复杂的结构，特别是复杂逻辑，其实是缺乏一些简单的支持，如果大家亲自去写过代码的话便会有这样的亲身感受，它也能够写一些比较复杂的逻辑，但是实践起来是非常复杂，然后另外的话一点就是我们认为Terraform目前的视角是相对比较低的，因为他视角是资源，和实际认为的场景中相面对比说一个组建或甚至一套环境，其实是不匹配的，因为对他的视角是不够高的，那我们就通过L1层往L2层的一个抽象去把它劣势转变转化为优势来实现了真的意义上的基础设置代码，甚至在某种程度上实现了技术设施基地代码（后面这方面会详细讲解），然后进一步的提高了代码整体的一个可复用性，使他能够快速的进行一个环境的部署和重建。

另外就是通过多层的封装实现多余的一个统一框架来屏蔽了不统一厂商之间一个差异性，能够更好的适应公司的一个出海战略。另外我们模块和插件的设计，使他具备非常强大的一个可扩展性，可以按需扩展自己的功能，提升了整体的管理效率和定制化的能力，左边就是原生Terraform的代码，是非常长的，右边上面定制化框架所用到配置云的代码，这两边所创建出来的资源是等价，可以看到整体代码量下降至少50%以上，然后下面的话，通过大规模的模块是代码，更有可读性和可扩展性，这套框架也很好地帮助我们业务的稳健发展，刚刚也提到我们的客户遍布全球20多个国家和地区，我们也累计服务了全球三十多个行业的一个知名大中型企业，获得了1000家客户的选择和认可。

这套框架，有几个点首先是能够更快的资源供给，从资源供给的时间从天极算到了分钟级，另外就是原生的最佳实践，因为在层层代码的分层过程中将很多的最佳实践进行了代码沉淀，向安全极限成本分摊等等特性，以至于可以做到开箱急用。再者就是在对比途中我们选择作为配置语言开发里面无需编写任何一行Terraform代码，而是仅通过编写APSARA配置并可以实现资源创建有更高的一个可读性和可维护性。

三、持业务快速扩展——为公司的全球化战略提供稳固的云基础架构支持

非常感谢阿里，各位同学支持问题解决，我们也支持和及时将问题解决，所以希望能够将来这套框架做得成熟，能够把它开原来回馈社区，能够帮助大家帮助阿里云的伙伴来更好，更快。未来也希望能跟社区进行更共创持续的更新为IaC事业做出更大贡献。对于未来的展想就是会不断地进行更深维度的一个业务抽象去构建管理平台，使得我们的开放不再是一个孤岛的工具，而是能够更好地嵌入到我们的业务流程工具，对业务人员来说会提供一个灵交互与测试是自服务的障碍，一个体验能够更快速的支撑业务的扩张好的。