云革命已经持续了足够长的时间了，以至于每一个IT领导者都清楚什么才是最重要的价值主张：云计算可以更容易地共享资源，它能够快速适应不断变化的负载和需求，并通过消除购买、安装和维护自己的硬件机架的需要，来节省时间和金钱。

但它也有缺点，而且也没有被经常提及。也许这是因为把你的烦恼转移到某个隐藏在天空中的香格里拉般的服务器农场的想法总是如此诱人。

不过，将工作负载转移到云上的真正担忧并不是那些常见的弊病。是的，云计算机器也会遇到许多同样的问题，这些问题会使您自己的数据中心中的框架变得混乱。如果Ubuntu 18.04有后门，它就会让黑客进来，不管它是安装在云机器上还是大厅壁橱里的服务器上。所有的计算机都容易受到电源故障、硬盘崩溃、α射线、恶意软件等更糟糕的情况的影响。

然而，更有趣的是云模型所特有的问题。这些问题不会影响您的服务器群中的机器，或者即使它们会产生影响，也不会造成同样规模的灾难。当然，关键是要注意并尽可能在以下这10个特定于云的问题再次困扰您之前解决它们。

成本失控

当云架构师的需求增加时，云可以自动启动新机器来处理负载。但当它真的出现时，在那块幕布后面，仪表将转得越来越快。

这种对负载的弹性响应应该比让机房里的旧服务器不知所措地崩溃要好。比特被传送到了他们应该去的地方，工作也完成了。但是，一个超载的本地服务器只会降低所有人的速度或产生一些404错误，而在云计算中，您的账单可能会突然飙升，在几秒钟内就把一个月的预算全部抹去。

这项挑战已经淹没了许多人。最糟糕的情况可能是开发人员在利用云计算来做副业：一次闪电般的打击，他们就将为一笔巨额的账单而绞尽脑汁。正因为如此，云提供商为此增加了控制，使您能够设置预算和请求支出提醒。但这并没有解决根本的架构问题。一直以来，你的团队都在重新设计你的应用程序，以兑现云的承诺，而看似无限的可伸缩性也意味着可能无限的账单。天下没有免费的午餐。

数据打包

在保护数据时，存储备份会是一个好习惯。但是，如果您的公司的数据是存储在您自己的RAID阵列上，那么这些数据的成本和容量就会得到控制。相反，当您的数据位于云中的某个位置的一个嵌套的存储集合中时，就很难知道是否有关键的日志文件或数据隐藏在其中了。

大多数部署云服务的组织都有保留一切的习惯。为了以防万一，把每一小片数据都放在身边似乎是更容易的，但无数小的零头正在不断累积，没有人愿意做出艰难的决定来删除其中的任何一个。对于储存在云中的数据进行分类以寻找关键的数据位需要大量的劳动。更糟糕的是，数据隐私法规和安全黑客的崛起也意味着，“以防万一”地将每一位客户数据塞进无限的云存储的自由--因为这很容易做到--可能真的会返回来成为你的困扰。

当创建一个新的存储块变得容易的时候，将来也就更容易产生一个需要来进行排序和保护的麻烦。

过度配置

如果一台机器太小，没有足够的内存来运行，你马上就会知道什么时候软件会变得很慢或者立即崩溃。但是如果你有太多的内存，就没有人会抱怨。正因为如此，云计算机器往往会不断升级，而变得非常浪费。有人会在一个重要的周末之后提高内存分配，而没有人会抽出时间再去拧紧螺丝，而现在您可能正在为您再也不会需要的开销在买单。

有些团队会专门安排一个人来观察参数，但这只会扩大团队。花钱买几台配置过剩的机器，还是花钱请一个新的团队成员来争论这些机器，哪个更便宜?

简易的点击启动程序

云提供商的仪表板让开发者和业务用户只需点击几下鼠标就可以启动新电脑，这是非常容易的。而且，每小时只有几分钱，公司肯定负担得起，对吧?我们不妨在一个干净的机器集群上测试代码，您不这么认为吗?

保持云计算的低成本是一项艰巨的挑战。每个人都明白购买硬件的麻烦。采购订单，预算会议，运输延误。但就像免费的食物或糖果在几秒钟内就会消失一样，几次快速的点击同样也能让你每月的云账单增加一倍或两倍。

消失的负载

轻负载和休眠机器会让云计算公司陷入困境。但他们可以将未使用的周期分发给共享相同硬件的其他实例。毕竟，如果它们可以让另一个客户满意，为什么要让它们闲置呢?

但当这些沉睡的机器醒来时，它们会想要回归自己的硬件份额，而其他机器则可能会开始错过免费的计算机周期。昨天运行得很快的代码开始运行得很慢。当然，虽然昨天的高速只是一个秘密的礼物，但也要试着告诉用户他的工作是进展顺利的。

超支

每个云协议中最容易被忽视的部分之一是数据移动的成本。我们常常把注意力集中在了计算机上，而忘记了比特的流动。

在大多数情况下，我们是可以忽略的。一般情况下，平均实例不会超过数据移动的阈值，因此许多开发人员甚至不考虑为查询提供答案的成本。这一切都很好，直到你的网站像病毒一样传播开来的时候，而一个月后惊喜就会出现在你的账单上。如果您在系统架构方面做得很好，那么缓存将承担巨大的负载，并且机器也不会陷入困境。然而，云提供商依旧将计算从其系统中流出的字节数，并相应地计费。

这是一种难以预料的打击。聪明的开发人员可能会试图通过运行许多本地测试机器人来测试负载，这些机器人会不停地ping机器。这可以测试他们的代码质量，但却不会标记出可能输出的高额成本。

模糊的位置

一些公司在大厅里建立了自己的数据中心。其他人甚至买下了整栋楼。在这两种情况下，每个人都知道他们服务器的物理位置。然而，云计算机器被租借出去时，除了可能找到机器所在的国家或州之外，不会有太多的细节。只要网络连接速度快，程序员可能并不在乎，但众所周知，多年来律师们一直就在争论应该由哪个政治实体来控制。我认识的一家公司在一个没有销售税的州建了一个数据中心，就是为了避免这个问题。

很容易丢失数据和应用程序在云中的位置。但大多数人对此并不关心，云提供商也经常出于安全原因故意含糊其辞。但是如果你的团队中有人关心法律问题，他们就会希望能够确保你在正确的政治控制下启动你的实例。

最终的控制

如果你有你服务器室的钥匙或者colo机架的钥匙，机器就是你的了。你控制着一切。然而，云中的实例属于其他人，他们会自己决定托管在他们身上的东西会发生什么变化。当然，当一切进展顺利时，他们通常会顺从你，但问题会出现在压力足够大的情况下，比如自然灾害或战斗发生的时候。如果一些政府调查人员想要传唤你的数据，他们甚至可能都不会告诉你的律师。

不公平的服务条款

服务条款是由云计算公司写的，除非你开了一张大支票，否则你就无法进行谈判。像所有的术语作者一样，起草术语的人首先想到的是他们自己。

考虑AWS服务条款的这一部分：“31.3. 您的邮件域和最终用户的帐户可能会被目标电子邮件服务器和我们无法控制的其他原因被阻止、延迟发送。无论你的电子邮件是被阻止、延迟还是屏蔽，你的支付义务都将继续。”

当然，这和大厅里的电子邮件服务器上的问题没什么不同。即使不起作用，你还是要付钱。但是，如果是一项服务的账单被冻结了，那就有点让人惊讶了。

意外之外的清理

所有的云服务都会清理掉那些布满灰尘、发霉的项目，然后把它们扔掉。他们必须这样做，因为人们总是在试验云实例，然后忘记了他们的试验或他们所在的地方。然而，问题是云提供商会按照他们的时间表而不是你的时间表进行清理。

例如，AWS承诺会删除在过去三个月内未调用的所有Lambda函数。如果你的团队构建了AWS Lambda函数，然后不管出于什么原因把它们放在了次要位置，你就必须记住这个最后期限，并留意任何警告您有人将要进行清理的电子邮件。