为何人人都在云中实施自动化

如果您听我谈论云，几乎可以肯定我最终会说

“云安全始于架构，终于自动化。”

我确实爱重复这句话。这不是一句俏皮话，而是基于近十年来与各种规模的组织在云领域深度合作的经验。我一再看到的一个共性是：组织一旦达到某种规模，就会开始将运营自动化。而且每一年，这条分界线都出现在其云旅程中越来越早的阶段。

我之所以知道这一点，是因为我自己先经历过，随后我看到每一个与我合作过、交谈过，或只是粗略了解过的组织，都走上了同样的道路。

我们都是从在控制台中手动管理一切开始的。

这并不奇怪，因为我们正是在那里注册并开始使用云的。那是最适合学习的地方，大多数控制台都提供向导、说明及其他提示，帮助我们入门。但随着我们构建更复杂的环境，或构建多份简单环境的副本，复杂度不断上升，这种方式很快就无法扩展。为重复性任务在基于网页的用户界面上不断点击并不高效，而且会变得越来越耗时、越来越令人沮丧。这不仅仅是因为云服务商的用户界面糟糕（说实话，其中一些确实相当糟糕）；仔细想想，我们实际上是在试图通过单一的网页界面管理一个数据中心的方方面面。 这是 不是 可能是 实现的。

因此，下一个自然而然的步骤……

就是转向使用命令行界面，但这同样面临复杂性问题。维持一个数据中心的运转，仅初始预配就涉及大量环节，更不用说持续运营了。虽然经常使用的命令很容易记住，但没有人能真正把这种规模下的一切都装在脑子里。而且，归根结底仍然是为相同的任务一遍又一遍地输入相同的命令。

而这一切还只是假设由一个人管理一个账户；然而即便在一家小型初创公司，您也需要跨多个账户管理重复性任务。

与此同时……

开发团队已经在直接使用 API，把云的各个组成部分集成到应用程序中。起初可能只是管理若干 S3 存储桶这么简单，但很快就会扩展到管理从全球规模数据库到机器学习引擎的一切。这正是您将 PaaS 集成到应用程序中、并从云中获取部分最核心价值的方式。

开发团队也很快开始使用 Terraform 和 CloudFormation 之类的工具，以代码方式定义其基础设施。这样他们就能构建开发/测试/生产环境，并保持一切一致。

用不了多久（好吧，有时要花上几年），安全和运营团队也会开始自行利用自动化，通常集中在三个主要方面。

1. 使用基础设施即代码（IaC）构建新环境并与部署流水线集成。IaC 使我们能够构建一致、可重复的环境，并预配基线安全与运营要求。开发人员也用它来定义开发/测试/生产环境。各方都受益，我合作过的每一家公司最终都很快用上了它。
2. 用于评估和监控的自动化。 核心难题在于保持对分散云资源的可见性，即便它们都在同一个账户中。控制台能展示很多信息，但自动化让您能够展示对您而言重要的内容。相较于传统基础设施，这其实是一个巨大的优势——在传统环境中，我们仅仅为了追踪数据中心里的服务器就要花费荒谬的巨额资金，而在云中这只是一次 API 调用而已。
3. 用于运营的自动化。一旦您开始发现偏离基准的情况，就会想着手修复。此外，还有大量工作流天然适合自动化。虽然在大多数传统基础设施中，这种程度的自动化即便可行也成本过高，但在云中它只是日常工作的自然延伸。

云的关键优势之一是隔离……

将环境隔离开来，只保留其所需的资源，使开发人员能够快速推进而不会相互干扰。但这很快就会带来对可重复流程和管理的需求，而 API 就摆在那里，自动化便顺理成章。

孩子会先爬、再走、然后跑，即便是在没有外界刺激的隔离舱里长大也是如此（我们保证没有真的试过……真的）。这是一种自然的进程。云自动化也是一样——它无非是在云中大规模运营任何事物的内在要求，每个人最终都会走到这一步。关键在于以有效的方式走到这一步。