Web应用程序的100％正常运行时间

#1 楼

以下是Wikipedia追求“九”的便捷图表：有趣的是，在排名前20的网站中，只有3个网站能够在9个网站中实现神话般的5个9或99.999％的正常运行时间2007年。他们分别是Yahoo，AOL和Comcast。在2008年前4个月，一些最受欢迎的社交网络甚至还没有达到这个水平。

从图表中可以明显看出，追求100％正常运行时间是多么荒谬的...

#2 楼

要求他们定义100％以及如何在什么时间段内进行测量。它们可能意味着尽可能承受接近100％的费用。给他们成本。

详细说明。这些年来，我一直在与客户讨论可能具有荒谬性的要求。在所有情况下，它们实际上只是使用不够精确的语言。

很多时候，它们以绝对的方式构架事物-例如100％，但实际上，在更深入的调查中，它们足够合理，可以进行成本/收益分析，而成本/收益分析则是降低风险的成本数据。问他们如何衡量可用性是一个关键问题。如果他们不知道，那么您必须向他们建议必须首先定义。

我会请客户定义在业务影响/成本方面会发生什么。如果网站在以下情况下发生故障：


在x个小时的最繁忙时段
在x个小时的最不繁忙时段

以及他们如何衡量。

通过这种方式，您可以与他们一起确定正确的'100％'水平。我怀疑通过问这些问题，他们将能够更好地确定其其他要求的优先级。例如，他们可能想要支付一定级别的SLA并损害其他功能才能实现此目的。

#3 楼

您的客户很疯狂。无论您花多少钱，都不可能实现100％的正常运行时间。简单明了-不可能。看一下Google，Amazon等。他们几乎无休止地投入基础设施，但他们仍然设法停机。您需要将该信息传达给他们，如果他们继续坚持要求他们提出合理的要求。如果他们不认识到一定程度的停机是不可避免的，那么就放弃他们。网络部分将需要涉及到不同ISP的冗余上行链路，获取ASN和IP分配，并深入了解BGP和实际路由设备，以便IP地址空间可以在需要时在ISP之间移动。

很明显，这是一个非常简洁的答案。您没有需要这种正常运行时间的应用程序的经验，因此，如果您想获得接近神话般的100％正常运行时间的信息，则确实需要让专业人员参与。

#4 楼

好吧，那绝对是一个有趣的话题。我不确定我是否想让自己按照合同规定必须100％正常运行，但如果我不得不这样做，我将看起来像这样：

完全从负载均衡器上的公共IP开始并至少建立两个网络，以便其中一个可以故障转移到另一个。像Heatbeart这样的程序可以帮助实现这些程序的自动故障转移。也许那是处理负载平衡的好选择。可以将其设置为具有1到n个后端（可选地按控制器分组），以随机或循环方式负载均衡。可以使Varnish足够聪明，以检查每个后端的运行状况，并将不正常的后端从循环中删除，直到重新联机。后端不必位于同一网络上。

这些天我很喜欢Amazon EC2中的弹性IP，因此我可能会在不同区域或不同的EC2中构建负载均衡器。至少在同一地区的不同可用区中。如果需要的话，您可以选择手动（禁止使用）旋转新的负载平衡器，然后将现有的A记录IP移到新的框中。

清漆无法终止SSL，因此如果这是一个令人担忧的问题，那么您可能想要查看类似Nginx的东西。

您可以将大多数后端都放在客户端网络中，而将一个或多个后端放在他们的网络之外。我相信，但不是100％肯定，您可以为后端分配优先级，以便您的客户端计算机可以优先处理，直到所有这些计算机都变得不正常为止。

如果有的话，我将从这里开始这个任务，毫无疑问地会随着我的发展而不断完善。

但是，正如@ErikA指出的那样，这是Internet，并且总会有部分网络不受您的控制。您需要确保您的法律只将您与您所控制的事物联系起来。

#5 楼

没问题-合同措辞略有修改：


...保证正常运行时间为100％（四舍五入到小数点后零位）。

#6 楼

如果Facebook和Amazon无法做到这一点，那么您就无法做到。就这么简单。

#7 楼

要添加来自Hacker News的oconnore的答案

我不明白问题是什么。客户希望您为灾难做计划，而他们并非以数学为导向，因此要求100％的概率听起来很合理。工程师很容易做到，他想起了prob＆stat 101的第一天，却没有考虑到客户可能不会这样做。他在办公室服务器上的咖啡，磁盘崩溃或ISP崩溃。
此外，您可以完成此操作。使用地理上不同的，独立的自我监控服务器，您基本上不会停机。 3台服务器以独立（1）的速度运行，三台9台可靠性，并具有良好的故障转移模式，因此您的预期停机时间不到每年一秒钟（2）。即使这一切同时发生，您仍处于合理的Web连接SLA范围内，因此停机时间实际上不存在。
客户仍然必须处理世界末日的情况，但是哥斯拉将其排除在外。

（1）洛杉矶的服务器与波士顿的服务器相当独立，但是的，我知道有一些涉及核战争的交集，中国黑客使电网等。我认为您的客户端不会因此而烦恼。

（2）DNS故障转移可能会增加几秒钟。您仍然处于客户必须每年重试一次请求的情况，这又是在合理的SLA范围内，并且通常不将其与“停机时间”联系在一起。使用故障发生时自动重新路由到可用节点的应用程序，这可能不会引起注意。

#8 楼

您被要求做一些不可能的事情。

在此处查看其他答案，与您的客户坐下来，向他们解释为什么这是不可能的，并评估他们的响应。

如果他们仍然坚持100％的正常运行时间，请礼貌地告知他们认为这是无法完成的，因此拒绝了合同。您将永远无法满足他们的需求，而且如果合同不能完全消除您的利益，就会受到惩罚。

#9 楼

相应地定价，然后在合同中规定，超过SLA的任何停机时间将按其支付的价格退款。

我上一份工作的ISP做到了。我们可以选择正常运行时间为99.9％的“常规” DSL线路，价格为$ 40 / mo，或者T9捆绑三人组的T1s，运行时间为99.99％，价格为$ 1100 / mo。每月有10个小时以上的频繁停电，这使他们的正常运行时间大大低于40美元/月的DSL，但是我们只退还了大约15美元左右，因为这就是每小时*小时的费率。他们像是从交易中得到的强盗。

如果您每月为$ 450,000支付100％正常运行时间的费用，而您只达到99.999％，则需要退还它们$ 324。我愿意打赌，假设完全分布式的colos，多个1层上行链路，fantantant硬件等，基础设施成本达到99.999％左右，每月约为45,000美元。

#10 楼

如果专业人士质疑99.999％的可用性是否可行或在财务上可行，那么99.9999％的可用性就更不可能或不可行。更不用说100％了。

您将无法长时间满足100％可用性的目标。您可能会花上一周或一年的时间，但是随后会发生某些事情，您将承担责任。支出的范围可能从声誉受损（您答应了，您没有兑现）到因合同罚款而破产。

#11 楼

有两种类型的人要求100％的正常运行时间：


完全不了解计算机，计算机系统或Internet的人们。*
一个笨蛋，要么测试您说“不”的能力（Google“橙汁测试”），要么尝试获得某种合同SLA杠杆，以免日后再付钱给您。

我的建议是，多次接纳这两种类型的客户，因此不建议接受该客户。让他们让其他人发疯。

*同一个人可能会毫无疑问地询问光速旅行，恒动，冷聚变等。

#12 楼

我会与客户沟通以确定他们100％正常运行时间的含义。他们可能没有真正看到99％正常运行时间和100％正常运行时间之间的区别。对于大多数人（即不是服务器管理员）来说，这两个数字是相同的。

#13 楼

100％正常运行时间？

您需要的是：

多个（和冗余）DNS服务器，指向世界各地的多个站点，每个ISP都具有正确的SLA。

确保DNS服务器设置正确，并且可以有效识别TTL。

#14 楼

这很简单。 Amazon EC2 SLA明确指出：


“年度正常运行时间百分比”是通过从100％中减去Amazon
EC2处于“区域不可用”状态。


http://aws.amazon.com/ec2-sla/

只需将“正常运行时间”定义为与您可以使用的整个服务包相关实际上可以100％地保持运行状态，您应该不会有任何问题。

此外，值得指出的是，SLA的全部要点是定义您的义务以及如果可以的话会发生什么不见他们。客户是否要求3个9或5个9个或一百万个9个都没关系-问题是他们在何时/是否无法交付时会得到什么。显而易见的答案是为订单项提供100％正常运行时间，价格是您要收取的价格的5倍，如果您错过该目标，他们将获得4倍的退款。您可能会得分！

#15 楼

DNS更改仅在配置为花费时间的情况下才花费时间。您可以将记录上的TTL设置为一秒-唯一的问题是确保及时响应DNS查询，并且DNS服务器可以处理该级别的查询。

这正是GTM在F5大IP中的工作方式-默认情况下，DNS TTL设置为30秒，如果群集的一个成员需要接管，则DNS将被更新，新IP几乎立即被占用。最大中断时间为30秒，但这是边缘情况，平均中断时间为15秒。

#16 楼

您知道这是不可能的。

毫无疑问，客户的注意力集中在看到“ 100％”上，因此，除了[不是您自己的错的所有合理原因]之外，您所能做的就是保证100％。

#17 楼

尽管我怀疑100％是否可行，但您可能需要考虑使用Azure（或具有类似SLA的产品）。发生了什么：

您的服务器是虚拟机。如果一台服务器上出现硬件问题，则您的虚拟机将移至新计算机。负载均衡器负责重定向，因此客户不应看到任何停机时间（尽管我不确定您的会话状态将如何受到影响）。精神错乱的99.999和100个边界之间的差。

您必须完全控制以下因素。
-人为因素，包括内部和外部的，恶意的和阳imp的。这样的一个例子是有人将某些东西推入生产代码中，从而使服务器瘫痪。更糟的是，破坏活动如何？
-业务问题。如果您的提供商失去了业务或忘记支付电费，或者只是在没有充分警告的情况下决定停止支持您的基础设施，该怎么办？
-自然。如果不相关的龙卷风同时打击了足够多的数据中心以淹没备份容量怎么办？
-完全没有错误的环境。您确定没有第三方或核心系统控制未出现的极端情况，但将来仍会出现吗？
-即使您完全控制了上述因素，您确定监视此程序的软件/人员在检查系统是否正常运行时不会给您带来假阴性吗？

#18 楼

坦白地说，就黑客攻击而言，至少在没有动摇的情况下100％完全是疯了。最好的选择是做Google和Amazon的事情，因为您有一个按地理区域分布的托管解决方案，您可以在多个地理位置的多个服务器之间复制站点和数据库。这将确保它不会发生任何重大灾难，例如将互联网骨干网切断到某个区域（确实会不时发生）或近乎世界末日的灾难。

我只想在其中添加一个条款此类情况（DDOS，Internet骨干网切割，世界末日的恐怖袭击或大战等）。本质上，云设置不仅将在每个位置提供冗余，而且还将提供流量的可伸缩性和地理分布，以及在发生故障的地理区域周围重定向的能力。尽管我的理解是，地理分布的成本更高。

#19 楼

我只是想在“理论上可以做到”的聚会上再加一个声音。

无论他们付给我多少钱，我都不会签有这样的合同一个研究问题，它有一些相当有趣的解决方案。我不太熟悉网络来概述步骤，但是我想将与网络相关的配置+电气/硬件布线故障转移+软件故障转移的组合在某些配置或其他工作中可能会真正实现。 br />
在任何配置中，总有某个地方存在单点故障，但是如果您努力工作，则可以将这一点推为可以“修复”的状态（即，根dns掉线了） ，但值仍会缓存在其他位置，因此您有时间修复它。）再次，并不是说它是可行的。我只是不喜欢一个答案不能解决这个事实不是“出门在外”-如果他们考虑透彻，那就不是他们真正想要的东西。

#20 楼

重新考虑测量可用性的方法，然后与客户一起设定有意义的目标。

如果您经营的是大型网站，则正常运行时间根本没有用。如果您在客户最需要查询（流量高峰）的情况下放弃查询10分钟，那么与周日凌晨3点长达一个小时的停机相比，这可能对企业造成更大的破坏。公司使用以下指标来评估可用性或可靠性：


成功回答的查询的百分比，没有服务器端错误（HTTP 500s）。
查询的百分比在特定目标延迟以下得到回答的问题。
被丢弃的查询应计入您的统计信息（请参阅下文）。

不应该使用示例探针来评估可用性，这是外部实体，例如pingdom和pingability能够报告。不要仅仅依靠它。如果您想做对，则每个查询都应计数。通过查看实际获得的成功来衡量可用性。

最有效的方法是从负载均衡器收集日志或统计信息，并根据上述指标计算可用性。

删除查询的百分比也应计入您的统计信息。可以将其与服务器端错误归为同一类。如果网络或DNS或负载平衡器之类的其他基础结构存在问题，则可以使用简单的数学方法来估算丢失的查询数量。如果您希望在一周中的这一天进行X次查询，但获得X-1000，则可能会丢弃1000条查询。将您的流量绘制成每分钟（或每秒）图表的查询次数。如果出现间隙，则删除查询。使用基本几何来测量这些间隙的面积，从而为您提供删除查询的总数。

与您的客户讨论此方法并解释其好处。通过测量其当前可用性来设置基准。他们将清楚地知道100％是不可能的目标。

然后，您可以根据基准上的改进签订合同。说，如果他们当前正在经历95％的可用性，则可以保证将情况提高到98.5％，从而将这种情况提高十倍。

注意：这种测量可用性的方法有缺点。首先，除非您使用现有工具来完成日志收集，处理和生成报告，否则可能并不容易。其次，应用程序错误可能会损害您的可用性。如果应用程序质量低劣，它将产生更多错误。解决方案是仅考虑由负载平衡器创建的500，而不考虑来自应用程序的500。

这种方式可能会使事情变得有些复杂，但这仅是衡量服务器正常运行时间的第一步。

#21 楼

尽管有人在这里指出，100％疯狂或不可能，但他们却以某种方式错过了真正的意义。他们认为，这样做的原因是即使最好的公司/服务也无法实现这一目标。

，这要简单得多。从数学上讲这是不可能的。

一切都有可能。您存储服务器的所有位置可能同时发生地震，从而破坏了所有服务器。可以接受的是，这是一个非常小的概率，但它不是0。您所有的互联网提供商都可能同时面临恐怖分子/网络攻击。同样，可能性不大，但也不是零。无论您提供什么，都可以得到非零概率的情况，这会使整个服务瘫痪。因此，您的正常运行时间也无法达到100％。

#22 楼

阅读有关使用统计抽样的制造质量控制的书。本书中的一般性讨论（在大学的一般统计学课程中，任何管理者都会接触到的概念）规定了从花费从千分之一到百万分之一到百万分之一到十亿分之一的指数增长。从本质上讲，达到100％正常运行时间的能力将花费几乎无限量的资金，就像将物体推向光速所需要的燃料量一样。

从性能工程的角度来看，我会拒绝这种要求既不可检验又不合理，因为这种表达更多的是渴望，而不是真正的要求。由于存在任何应用程序依赖关系，而这些依赖关系在任何用于网络，名称解析，路由，底层体系结构组件或开发工具传播的应用程序之外的应用程序中，任何人都无法保证100％的正常运行时间，这实际上是不可能的。

#23 楼

我认为客户实际上并不是要求100％的正常运行时间，甚至不是99.999％的正常运行时间。如果您查看他们的描述，那么他们正在谈论的是流星从其现场数据中心中取出时从中断的地方接站。那有多激烈？发出Ajax请求并向最终用户显示30秒的微调器是否可以接受？

客户关心的就是这些。如果客户实际上是在考虑精确的SLA，那么他们将足以将其表示为99.99或99.999。

#24 楼

我的2美分。我负责一家财富5强公司的非常受欢迎的网站，该网站将为超级碗广告。我不得不应对巨大的流量高峰，而解决问题的方法是使用Akamai之类的服务。我不在Akamai工作，但我发现他们的服务非常好。他们拥有自己的更智能的DNS系统，该系统知道特定的节点/主机处于高负载状态或处于关闭状态，并且可以相应地路由流量。

关于他们的服务的整洁之处在于我没有为了将我自己的数据中心中的服务器上的内容复制到其数据中心，实际上必须做任何非常复杂的事情。此外，从与他们的合作中我了解到，它们大量使用了Apache HTTP服务器。

虽然不是100％的正常运行时间，但是您可以考虑使用这种方法在全球范围内分发内容。据我了解，Akamai还具有对流量进行本地化的功能，这意味着如果我在密歇根州，我从密歇根州/芝加哥的服务器中获得了内容，而如果我在加利福尼亚州，则据说是从加利福尼亚州的服务器中获得了内容。 />

#25 楼

无需异地故障转移，只需从内部和外部两个位置同时运行应用程序即可。并同步两个数据库...然后，如果内部发生故障，内部人员将仍然能够工作，而外部人员仍将能够使用该应用程序。内部重新联机后，请同步更改。您可以为一个域名有两个DNS条目，甚至可以是具有轮询机制的网络路由器。

#26 楼

对于外部托管的网站，最接近您100％正常运行时间的是将您的网站托管在Google的App Engine上，并使用其高复制数据存储（HRD），该存储可自动在至少三个数据中心之间实时复制数据。同样，App Engine前端服务器会自动为您缩放/复制。

但是，即使拥有Google的所有资源和世界上最复杂的平台，App Engine SLA正常运行时间的保证也只是“在每个日历月中有99.95％的时间。”

#27 楼

简单直接：Anycast

http://en.wikipedia.org/wiki/Anycast

这就是cloudflare，google和其他任何大公司用来做冗余的事情，低延迟，跨大陆故障转移/平衡。

但也要记住，不可能有100％的正常运行时间，而且从99.999％到99.9999％的成本要大得多。 br />