深度观点：看清云计算的本质，摆脱忧虑得到自由

像我们这样日常工作需要接触云技术的人都生活在泡泡里。我们往往会忘记就算对大部分类似我们这样的人，云也是一种商品，对很多企业来说依然不是最显而易见的选择。

在投身云计算领域并“见到光明”之前，路由器、交换机，以及防火墙就是我全部的日常。我努力学习考取CCIE（Cisco认证的互联网专家），这是一种高大上的顶级Cisco认证，会教你如何顺利掌握并运用Cisco的硬件。

现在我已经从网络世界中抽身，将全部精力投入于云计算，但我发现自己有着忘记这些架构的倾向，这些“传统”的IT资源保护和交付方式其实依然有很大的活力。

云平台和传统IT环境之间鲜明的对比是用户接纳云计算所要面临的最大障碍。更准确来说，这个障碍使得云无法妥善执行自己应该担当的任务。很多与我交流过的IT专家都在问，为云资源创建审批流程的最佳方式是什么。如果能够牢牢记住业务敏捷度（更快速完成任务）以及成本（应该会越来越便宜！）这两个云技术的最主要推动力，我们就会理解，那种需要由人手工进行审批的审批流程，只会导致我们无法实现上述任何一个目标！

在资源供应过程中需要人工参与，这种做法只适合资源仅仅勉强够用的情况。这种想法与云计算自助式服务的本质是背道而驰的。在传统数据中心内，资源可能需要限额供应，因此由人来决定哪里最需要这些资源，这种做法就显得比较合理。但云部署并不会面临这样的问题，资源始终在那里，如果有用户满足所有必要条件，他就应当能立刻获得需要的一切。因此当同事问我实施云资源审批流程的最佳方法时，我的答案始终是：不要审批。

在了解到云平台与传统IT环境截然不同的工作方式后，一起来看看这里面存在的问题和解决方案吧。

自助服务很棒，但也很危险。就职于大型企业的开发者几乎很少需要为公司的财务状况寝食不安，因此周末晚上有几台服务器没有关机看起来也不算什么大不了的事。云平台的一个最终用户可能正忙着完成自己的工作，根本没时间考虑应该使用什么标签或安全组。考虑一下这样一个例子：我们的用户希望供应3台服务器，每台有一个EBS卷，所有服务器绑定至同一个Elastic Load Balancer。那么一共有7个对象需要添加标签，就算只设置1个所有者标签和1个生产状态标签，依然有21个标签等待设置！尤其是对于AWS来说，用户可以在选择了实例类型后立刻“审查并启动”实例，这些因素大幅增加了跳过工作流程中“为实例添加标签”这一环节的可能性。

上文曾经提到，敏捷性也是云技术的一个主要推动力。自助服务的模式可以提供这样的敏捷性，让用户在需要的时间获得需要的资源。

然而自助服务模式在安全、成本，以及云的使用效率方面也为我们制造了不少问题。

上文中提到的问题在Bernard Golden有关该主题的这篇文章中也有体现，这些问题的解决方案正是策略引擎。订购资源的传统工作流会涉及审批，同时需要核实是否具备所申请的这些资源。云的世界中不存在“是否”这个问题。资源始终就在那里。因此这时候问题变成了：要提供给他们吗？

“此人应该得到资源吗？”这个问题比“我们是否具备此人需要的资源？”更容易回答。但无论哪个问题，都需要在无需人工介入的情况下自动做出回答。此时可以通过捆绑至某一用户或环境的一系列规则判断所要执行的各种操作，以及可以消耗的所有资源。考虑到这些情况后，一起来看看不同类型的策略实施。

观察员策略（Observer policy）是指位于工作流程之外，针对使用模式和违背等情况提供信息的策略。观察员可以登录到云平台，检查用户消耗资源的方式是否与财务策略、安全策略等的规定相一致。如果发现存在违背的情况，你将收到通知。观察员是了解云资源使用模式的好方法，不过这种做法往往会产生一些可行性不够高的报告。例如，观察员告诉你说某台服务器的22端口面向互联网开放了，那么接下来要怎么办？为了做出决定，你需要首先了解上下文，这是谁的服务器？直接隔离是否会惹出别的乱子？这类工具通常不会强制实施策略，如果实施，通常是为了对现有问题做出反应。

云平台使用的大部分策略引擎本身是反应式的。此类系统可供你定义一系列规则，例如“不要使用规模大于X的计算机”，并执行某些预设的规则，例如“任何违背该规则的计算机必须缩减规模”。反应策略（Reactive policy）的问题在于，相对于云平台“转瞬即逝”的本质来说，这种策略的执行速度太慢了，并且无法避免误操作所产生的成本。由于反应策略只能在事后实施规则，每次错误的供应都会造成少量财务上的损失。

令人惊讶的是，一些公司选择不使用任何策略引擎，他们会训练人员而非训练系统。这意味着需要创建集中式的维基、入职规划，以及大量培训，向每个人介绍供应云资源时需要使用的工作流程。要使用哪些标签和安全组，如何处理网络的布置等。大部分推行这种做法的公司很快会开始重新反思，因为这种系统根本无法很好地扩展（所以才有了RTFM——Read The Fucking Manual）。

内联策略（In-line policy）引擎通过创建约束，可以防止用户做出错误的选择，只允许使用获得批准并且可用的资源。此类策略引擎是在企业中安全地推行自助服务模式最容易的方法。由于策略执行点位于用户和云平台之间，在供应任何资源前都能以透明的方式实施所需策略。理想情况下，用户只能看到自己有权限使用的选项，策略引擎会确保只有完全符合预算、安全策略，以及管控策略要求的操作能够执行。这种策略实施模式与基于工单（Ticket-Based）的传统系统截然不同，并且是以原生方式为云平台实施策略的唯一方式。如果必须创建工单并记录所供应的资源，这种方式也能自动实现。

毫无疑问，数据中心和相应的管理系统在短时间内依然不会消失，但我们已经步入云的时代。在需要“云方式”的情况下误用不相关的工作流程，这种错误产生的后果是企业无力承担的。重要的是，全新的方式并不会造成太大的挑战。我们将云看做一种大规模的范式转换，很多情况下也确实如此。云技术的采用会对敏捷度产生巨大影响，同时也会让IT资源的消耗过程变得更简单。但从IT管理员的角度来看，管理和策略的实施在云时代应该变得更简单，而不是更难。

大部分企业开始使用云管理平台或其他类似的工具处理多云部署中策略的实施工作。在评估这些工具时不要忘了，策略引擎必须能够感知到每个操作的上下文情境，因此包含内联策略引擎的原生云CMP将会是最有效的选择。

细说云计算

ID：CloudNote

▲长按二维码识别关注

探讨云计算的一切，

有干货，也有闲聊。