什么是云上自动化

以下是视频转写全文，供参考：

哈喽大家好，欢迎来到阿里云开放平台自动化专栏 Auto Talk，在这个系列视频中，我们将为大家介绍云基础设施自动化的相关内容，大家可以了解到云上的自动化开发理念、应用场景和如何做好自动化。接下来就让我们踏上自动化之旅，了解一下《什么是云上自动化》。

我是天凯，来自于阿里云开放平台。今天给大家带来的议题是：什么是云上自动化？相信大家在以前做IDC或者进行一些基础的运营管理的过程中，其实对自动化这个概念本身并不陌生。云其实在这个时代为我们的开发者和客户提供了像水、电、煤一样的基础设施。它能够快速地为我们带来云基础设施的支撑和生产。

比如像API、CLI或者SDK。近些年的发展，我们其实也看到一些新的技术和理念。比如像IaC基础设施自动化，IaC里面的典型的产品，比如说像Terraform这种产品。随着我们在云上的资源数量从少变多，我们其实应对的自动化挑战也是从弱变强。我们资源量少的时候，我们可能会通过控制台，通过点点的方式，就可以开通一个ECS，并且管理它。这样的方式大家可能也都体验过，也是非常便捷的。但是随着资源量越来越多，我们达到100台、1000台的时候，这个事情就变得越来越复杂。阿里云应对这个挑战，其实也为我们的客户提供了一系列的集成云的开发工具。

那在定义什么是IaC这个事情上，我想用一句话来进行一个简单的总结。我个人认为其实IaC就是把我们重复反复在做的低效的这个过程，把它变成了一个代码化的逻辑，让机器能够替我们更高效、更标准地去执行这个过程。这个本身就是IaC的手段。其实有很多，不管是你通过CLI、SDK集成，或者说通过ROS编排，亦或者说通过Terraform去进行一些代码化的这种描述性的管理，那都是可以的。我们把我们内部的这些基础设施的业务逻辑通过工具，然后再结合服务生产出云上的资源。这个过程就是IaC。在实际执行过程中，它往往会结合像流程管理，版本管理这样的方式，让它的管理更标准、更高效。这个事情听起来可能还是有点抽象，所以今天我给大家带来一个比较简单的例子。假设我们现在有一个应用要发布上线，您希望把它部署在阿里云上，所以您可能需要一台ECS。为了应对更高峰的一些突增的客户流量、一些压力，您可能借助了ESS弹性伸缩的这种技术手段去管理的ECS。

然后在内部的网络交换上，选择了VPC进行网络的连通。通过SLB发布了一个公网IP这样一套简单的基础设施就布置出来了。通过传统方式管理云，您往往可能会有一个文档来记录您具体在每一台ECS或者每一个步骤上到底做了什么，配置了什么，设置了什么名称和什么参数，以便为您后续的运维动作提供一些参考和沉淀。这件事情其实是有一个很大的挑战的。

因为在我们从开发环境到测试环境，或者说从测试环境到生产环境的整个镜像化的部署过程中，通过文档来保证两个环境相同，这个挑战还是比较大的。主要体现在第一：文档是人写出来的，维护起来其实是比较困难，而且也很难保证它的持续正确。

第二是操作员在按照这个文档进行操作的时候，往往很容易出错。出错之后这些细微的错误其实是很难通过人眼和一次次的检查去识别出来的。这样对于我们在开发的这个版本，部署到生产版本中，是否会带来额外的风险、挑战和不可预知的故障，都是很难说的事情。

为了解决这个问题，其实在技术领域，现在基本上分为两条思路。第一条思路就是命令式，刚才也提到了，我们像CLI、SDK这种都是命令式的。它有优势也有缺点，优势就是它更原子化一点，它在云服务产生的第一天就伴随它而生。比如说像我们的Open API，像SDK、CLI，你每创建一个ECS对吧，你可能需要调用create-instance，modify-instance去管理，但它的劣势也是说你需要了解每个接口之间的上下游的业务关系。比如说安全组的ID要传入ECS的接口中这样一些复杂的关系，就会让你的业务逻辑写进代码。当你进行一些基础设施更新的时候，其实你的一个前置条件就是要更新你自己的代码。第二个方向，就是声明式，也是最近这些年比较火的，我个人比较喜欢的就是像现在开源社区里面的Terraform。它的理念就更加简单，所见即所得。它优势当然也很明显，就是你在代码中写的声明式的这些属性参数资源，它在与云服务的生产过程中是幂等的。也就是说你不管生产多少次，它的结果都是恒定不变的。这样也为我们管理一套基础设施的代码基线提供了一个先决条件。但同样它也有劣势，因为它忽略了很多细节的步骤，它灵活性显然就不够好，但它的效率会大大提高。

接着刚才那个例子，您的应用需要部署在这个开发测试环境中。借助于代码化的工作，您在DevOps的整个业务流程中变得非常可见、可控、可持续。您的每一次的变更，通过一些GitHub、GitLab基线管理，可以清楚地定义和识别每一个基础设施变更中到底改了什么，添加了什么，以及是否有新的服务和产品在新的基础设施之中应用。这样一来，您的开发测试环境通过这一套描述性的代码，就很容易保持一致。有了这个前提它就可以为客户提供高效、可靠的持续的业务迭代。

还是继续刚才的那个例子，在您的基础设施中，您可能因为业务的迭代需要新加了一个服务叫RDS。同样在新加服务的过程中，首先要保证的就是我的测试、开发、生产环境是镜像式的一致。这样我开发的应用程序部署到这些基础设施上时，才能稳定可执行的。这些事情做完之后，我们就进入到了第二个阶段，也就是并行阶段。在老版本和新版本之间采取了一个并行的方式。这也是我们在基础设施即代码过程中给客户的一些最佳实践。当我们的老版本还在持续运行并为客户提供服务的时候，我们发生变更的新版本需要与它并行一段时间。因为我们所有的基础框架都是基于IaC的，它很容易创建，也很容易被销毁。

所以这也是我们建议客户这样做的一个原因。这边可能有同学会有疑问，问今天我们这样去做会不会带来额外的成本？答案是肯定的，会有额外的成本。但是它对于业务的稳定性和可靠性的保障收益是远远大于这部分的成本的。在我们第二阶段完成之后，验证了我们的新的V2版本的环境和V1版本的环境，都是可持续服务的。这个时候我们就可以通过IaC的destroy这样的方式，把第一个版本完全下掉，并且进入到第三个阶段发布再开发阶段。

我们拿V2版本同样会在我们的开发测试环境中持续迭代。它有可能会有新的云服务，可能会有新的参数变更，但这都没有关系。这套基于基础设施即代码的逻辑已经生产出来了。我们仍然可以回到第一个阶段，然后再进行第二个阶段，从而保障服务的可持续运行。

最后总结一下，我对IaC的一些特征和优势的总结。第一个就是自动化，因为我们通过代码化的方式，所见即所得的方式去描述我们的最终结果。因此，我们可以减少人为误操作和错误的发生的概率。而且对于大量的批量的管理，上千台服务器的效率和可靠性也得到质的提升。第二个就是灵活性，我们不再需要复杂地按照操作手册的方式去点击控制台，一方面是容易出错，另一方面成本比较高，操作步骤也比较冗余和长。这个时候我们通过代码修改一个简单的参数，就可以实现整个业务的线上变更。

第三个就是可复用性。像刚才上面例子，我们提到的，我的测试环境、生产环境怎么样能够让它实现镜像级的一致。通过基础设施即代码这套理念和我的代码以及版本管理，就可以轻松地做到。而且可以做到历史的版本的回滚识别和管理变更。最后一个就是安全性，其实很多同学会觉得安全性往往不是IaC最主要关注的点。但其实IaC在执行我们企业所谓的安全基线和生产基线过程当中，起着无可替代的重要作用。我们的权限策略、基线、网络访问基线都可以通过IaC这套体系去快速的建设，并且持续的运维。