我有一堆随意的抱怨，抱怨这项云业务最近进展到哪里去了。似乎有太多的人认为在别人的硬件上运行虚拟机是做任何事情的唯一方式。这并不能免除你真正擅长这件事，而且常常使事情变得复杂到你永远无法真正发光的地步。
我会直截了当地说：我更喜欢物理硬件。我确切地知道我在处理什么，而且当我试图追踪问题时，没有什么可怕的事情在发生。(这句话的意思是：“我很清楚自己在处理什么，当我试图追踪问题的时候，没有什么可怕的事情在发生。”如果磁盘很慢，我可以找出原因。如果网络不正常，我可以找出原因。没有一个神秘的主机系统生活在别人的世界里，这是我无法企及的。
如果你想要关于生产环境的生活奥秘的令人满意的答案，你需要能够弄清事情的真相。每次您引入一些虚拟化，都会降低找到答案的可能性。当它跨域进入另一家公司或供应商或其他任何地方时，情况会变得更糟。
在这一点上，您只能降低您的标准，并接受更多的不确定性、坏处、停机和其他奇怪的行为。你必须接受这样一个事实，即有些事情可能永远不会真正好转。就在这里，这个因素会赶走一些人。他们要么加入，然后和平解决，要么从一开始就永远不加入。
我应该提到的是，在不存在解决问题的理由的情况下，引入这些解决奇点的方法也为江湖骗子、欺诈和普遍的无能创造了一个很好的机会。为什么？这很容易。每次有不好的事情发生，你就把它归咎于某个已知的麻烦地点。人们喜欢他们的替罪羊。
所有这些虚拟机、云和弹性扩展业务还有另一个有趣的方面：可以创造的令人难以置信的资金沉没。似乎每个人都制定了某种规则，只关注CPU使用率，然后在它超过某个时间点的任何时候都会有帮助地设置更多的实例。
这导致的可怕行为的数量简直令人难以置信。它必须让人看到才能让人相信。我是什么意思？啊，是的，和我一起在记忆的小巷里旅行吧。
我在一个有很多物理机器的地方工作。它还有一整个团队，除了计划和分配容量之外，什么都不做。换言之，该组织确保人们在适当的时候得到机器，而不仅仅是因为他们提出了要求。而且，他们也不是无知的算子手。
团队分配工作背后的真正推动力是我的一个朋友，一个坏家伙工程师。在公司任职的近十年里，仅这一人就可能为公司节省了相当于多座大楼的机器。
这是怎么回事？很简单。每次有团队想要一套全新的硬件时，我的朋友就会出去看看他们是如何使用现有硬件的。这也不仅仅是CPU利用率的问题。我的朋友想知道它是如何使用CPU的。如果它在做愚蠢和低效的事情，当他们运行分析时，它就会被洗掉。他们可以看到这些东西在哪里消磨时间。毕竟，剖析是一件事。
这有一个很好的效果，迫使团队诚实和坦率地描述他们的需求，而不是试图浪费，然后认为更多的硬件可以拯救他们。他们不能随意花公司的钱。我的朋友和她所代表的团队没有把事情搞得一团糟。
不过，其中一些云端网站就没有这样的监管了。他们构建自己的系统只是为了自动扩展，不断扩展，不断扩展。很快，就会有几十个，然后几百个，甚至几千个这样的疯狂的东西。如果他们编写了糟糕的代码，并且他们的足迹每天都在增加，他们甚至没有意识到这一点。可能的情况是，团队本身并不知道他们在使用多少台机器(实际上是虚拟机)，也不知道它的变化速度有多快。
没有等同于我的朋友站在那里告诉他们先优化他们糟糕的代码，然后他们才能获得更多的硬件。供应和部署系统将会泄露这一点，他们确实是这样做的。
通常会发生的情况是，有人会定期运行一份报告，发现一些令人兴奋的事情，比如，哇，服务X现在在1200台机器上运行。怎么会出这事？这很容易。没有人阻止他们在目前的设置中需要1200台机器。人们绞尽脑汁承诺会做得更好，但那些愚蠢的例子仍然坐在那里，整日整夜地烧钱。
在另一个方向也有乐趣。有人可能会设置一条规则，一旦他们的工作低于某个CPU使用率，就缩减他们的工作规模。也许每当利用率低于10%或类似情况时，他们就会告诉缩放器将其降低一个档次。
你认为当它第一次非常安静的时候会发生什么，有一次它降下来了，然后那个实例成功地降到了10%以下？如果你说自动定标器把它降到零，你就对了！是的，没有最小尺寸限制，这就是你得到的。
更令人惊讶的是，显然这可能会发生，但不会立即修复。你会认为它会注意到它需要一些能力来管理事情，然后进入一场拔河比赛，从0到1再到0到1，以此类推，一整晚都是如此。
就我个人而言，我认为，一旦没有更多的实例在运行，任何衡量CPU利用率的东西都可能除以零，并且不能超过该点。不处理这种情况似乎是理所当然的。
然后，可能会发生一种完全不同的巧妙情况。我在别处谈到了这一点，但为了完整起见，我将在这里给出总结。您有一项服务必须正常运行。它就会死。其他所有设备的流量都会下降，因此外面的CPU利用率也会下降。这些其他服务都是按比例缩减的。
在某种程度上，基本服务重新开始工作。车流蜂拥而至，然后..。啊哦！那些其他服务现在太小了，无法处理负载。更糟糕的是，它们以你能想象到的最脆弱的方式编写，所以它们甚至不能忽略额外的流量。他们愚蠢地试图承担每一件即将到来的事情，并没有拒绝他们没有希望处理的东西的想法。
现在它们完全饱和了，什么也做不了，CPU像疯了一样运转。自动伸缩功能会注意到这一点，但让更多实例运行可能需要10-15分钟。这不是开玩笑。我见过这种情况，情况并不乐观。
基本上，你应该能够把相当于火焰喷射器的东西对准你的服务，并让它继续工作。它不必接受额外的请求。它应该只做它无论如何都能做的事情，并视情况忽略或拒绝其余的事情。这样，至少它可以开始吸收一些负荷，而不只是成为问题的一部分。
想想看：如果您的服务的任何一个实例在提供足够的负载时会发生故障和崩溃，那么就会将负载重新平衡到其他实例上。然后，其中一个会沸腾，它会关闭，从而将负载重新平衡到更少的实例上。这种情况会一直持续下去，直到整件事变成一块熔化的熔渣。
你可以告诉你，当你拼凑一些可怕的东西，比如关闭负载均衡器，直到我们可以重新启动服务时，你就处于这样的情况。或者，也许您已经将网络设置为丢弃50%的流量，直到我们赶上为止。如果你曾经不得不这么做，那你就是在运行非常脆弱的东西！同样，如果你曾经担心过同时开始所有事情，否则第一个就会煮熟，然后第二个和第三个就会崩溃，那就让我第一个告诉你：你已经处于不利的境地了。
[旁注：如果这听起来很耳熟，那是因为我在大约15年前有一位客户，他绝对拒绝修复他们糟糕的代码，只想要更好的工具来并行启动和停止他们的东西。站在我这一边的人并不是在寻找参数，所以他们给了他们一个确切的参数。他们很高兴，因为他们不必考虑写出更好的代码。这就是你想从你的东西里得到的吗？]。
有很多方法可以摆脱这种情况。这里只有一个。您可以暂时停止检查侦听套接字的新连接。这意味着您停止调用Accept()。侦听队列将会备份，然后会发生一些有趣的事情。假设Linux，那么在那之后，它可能会停止为连接尝试发出SYN/ACK。您可以使用一些魔术来使其主动RST这些连接，以便客户端快速失败并立即转到其他地方。管他呢。
当事情平静下来后，你可能会再次开始寻找那些新的联系。也许你可以做一些整洁的事情，先处理最新的，因为最老的可能已经用完了大部分的时间，而且无论如何也不会留下来完成工作。这就是我在几个月前的一篇帖子中所说的精挑细选的后进先出(LIFO)。当人们处于一种RPC心态而不是网络心态时，他们往往会想到这类事情。
想要一个真正粗略的节流例子吗？邮件守护程序Sendmail让我们中的一些人的生活变得有趣了很久，它有这样一个东西，它可以监视机器的平均负载。如果它超过了第一个凹槽，它仍然会接受一个连接，但它会用一个错误将它们挥手离开。如果它通过了第二级，它实际上将停止监听网络！这是对的，它实际上会关闭侦听套接字以强制拒绝任何连接尝试。
这比我想要的更像是意识流，但所有这些都需要走出去。可能性是，我会回到这些要点中的一些，并将它们编成他们自己的故事，关于什么应该做，什么不应该做，以及如何判断你的团队或公司已经陷入困境。