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

这里是维基百科的追求9便利的图表：

有趣的是，2007年排名前20的网站中，只有3家网站能够达到神秘的5个九点或99.999％的正常运行时间。他们是雅虎，美国在线和康卡斯特。 在2008年头4个月，一些最受欢迎的社交networking甚至没有接近。

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

要求他们定义100％以及如何衡量在什么时间段内。 他们可能意味着接近100％，他们可以负担得起。 给他们成本。

详细说明。 多年来，我一直在与客户进行讨论，所谓的荒谬要求。 在所有情况下，他们实际上只是使用不够精确的语言。

他们通常以绝对的方式来构架事物 – 比如100％，但实际上在深入调查时，他们足够合理地进行成本/风险缓解数据所需的成本/效益分析。 问他们如何衡量可用性是一个至关重要的问题。 如果他们不知道这一点，那么你必须向他们build议，这需要首先定义。

如果在下列情况下网站出现故障，我会要求客户定义在业务影响/成本方面会发生什么情况：

• 在他们最繁忙的时间工作x小时
• 在他们最不忙的时间，在X小时

而且他们将如何衡量这一点。

通过这种方式，您可以与他们合作来确定“100％”的正确等级。 我怀疑，通过询问这些问题，他们将能够更好地确定其他需求的优先事项。 例如，他们可能想要支付一定的SLA级别，并妥协其他function，以实现这一目标。

你的客户很疯狂 不pipe你花多less钱，100％的正常运行时间是不可能的 。 简单而简单 – 不可能。 看看谷歌，亚马逊等。他们几乎无尽的钱投入他们的基础设施，但他们仍然设法停机。 你需要把这个信息传达给他们，如果他们继续坚持他们提供合理的要求。 如果他们没有意识到一定的停机时间是不可避免的，那么就沟通吧。

这就是说，你似乎拥有扩展/分发应用程序本身的机制。 networking部分将需要冗余上行链路到不同的ISP，获得ASN和IP分配，并在BGP和真正的路由设备中深入研究，以便IP地址空间可以在ISP之间移动（如果需要的话）。

这显然是一个非常简单的答案。 您还没有应用程序需要这种正常运行时间的经验，所以如果您想要接近神秘的100％正常运行时间，那么您确实需要获得专业人员的参与。

那么，这绝对是一个有趣的。 我不确定我是否希望让自己承担100％的正常运行时间，但是如果我不得不这样做，我会觉得这是这样的：

从负载平衡器上的公共IP开始，完全脱离networking，至less构build其中的两个，以便可以故障切换到另一个。 像Heatbeart这样的程序可以帮助自动故障转移。

清漆主要被称为caching解决scheme，但它也有一些非常体面的负载平衡。 也许这将是一个很好的select来处理负载平衡。 它可以设置为1到n个后端，可以任意组合在导向器中进行随机或循环的负载平衡。 清漆可以做得足够聪明，以检查每个后端的健康状况，并将不健康的后端从循环中排除，直到它恢复在线。 后端不必在同一个networking上。

我现在爱上了Amazon EC2中的弹性IP，所以我可能会在不同的地区或者至less在同一地区的不同可用区域build立我的负载平衡器。 如果必须的话，可以手动（禁止）启动一个新的负载平衡器，并将现有的AloggingIP移动到新的方框。

然而，清漆不能终止SSL，所以如果这是一个问题，你可能会想看看像Nginx的东西，而不是。

您可以在您的客户端networking中拥有大部分后端，而在networking外部拥有一个或多个后端。 我相信，但不是100％肯定的是，你可以优先考虑后端，这样你的客户端机器才能获得优先级，直到所有这些机器变得不健康。

如果我有这个任务，那就是我要开始的地方，而且毫无疑问，随着我的进步，

但是，正如@ErikA所述，这是因特网，而且总是会有一些不在你控制范围内的networking部分。 你要确保你的法律只把你和你控制的东西联系起来。

没问题 – 稍微修改合同措辞，但：

…保证100％的正常运行时间（小数点后四位）。

如果Facebook和亚马逊不能做到这一点，那么你不能。 就这么简单。

从黑客新闻添加oconnore的答案

我不明白是什么问题。 客户希望你计划灾难，而不是math导向，所以要求100％的概率听起来是合理的。 工程师们很容易做到这一点，他记起了他第一天的问题和统计数据101，却没有考虑到客户可能不会。 当他们这样说的时候，他们并没有考虑核冬天，他们正在考虑Fred将咖啡倒在办公室服务器上，磁盘崩溃或者ISP崩溃。 此外，你可以做到这一点。 凭借地理位置独立，独立的自我监控服务器，您基本上没有停机时间。 3台服务器以独立的（1）3个可靠性运行，并具有良好的故障切换模式，您的预期停机时间每年不到一秒钟（2）。 即使这种情况一次发生，您仍然处于一个合理的networking连接SLA，因此停机时间实际上不存在。 客户仍然需要处理世界末日的情况，但哥斯拉被排除在外，他​​将有一个“永远”的服务。

（1）洛杉矶的一台服务器与波士顿的服务器是相当独立的，但是我知道核战争，中国黑客破坏电网等等有一些交集。我不认为你的客户会感到不安这个。

（2）DNS故障转移可能会添加几秒钟。 您仍然处于客户端每年重试一次请求的情况，这也是在合理的SLA范围内，通常不会被视为“停机时间”。 如果应用程序在失败时自动重新路由到可用节点，这可能不明显。

你被要求做不可能的事情。

回顾这里的其他答案，与你的客户坐下来，解释为什么这是不可能的，并衡量他们的回应。

如果他们仍然坚持100％的正常运行时间，礼貌地通知他们不能做，拒绝合同。 你永远不会满足他们的要求，如果合同不完全吸引，你会受到处罚的罚款。

价格相应的，然后在合同中规定，SLA之后的任何停机时间将按照他们所支付的价格退还。

我上一份工作的ISP做到了。 我们select了正常运行时间为99.9％的“常规”DSL线路，价格为40美元/月，或者T1的99.99％运行时间为1100美元/月。 每月有10多个小时的频繁停机，这使得它们的正常运行时间远低于40美元/月的DSL，但是我们只退还了15美元左右，因为这是每小时*小时的结果。 他们就像交易中的土匪一样。

如果您每月支付45万美元的正常运行时间，而您只能达到99.999％，则需要退还324美元。 我敢打赌，假设完全分布式的colos，多个一级上行链路，fancypants硬件等，基础设施成本达到99.999％在每个月45,000美元附近。

如果专业人员质疑99.999％的可用性是否是一种实际的或财务上可行的可能性 ，那么99.9999％的可用性更不可能实用。 别说100％。

您不会长时间达到100％的可用性目标。 你可能会放弃一周或一年，但是会发生一些事情，你会负责。 排污口的范围可以从损坏的声誉（您承诺，您没有交付）到合同罚款的破产。

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

1. 对计算机，计算机系统或互联网完全不了解的人
2. 那些故意刁钻自己的人，要么testing自己说“不”（谷歌“橙汁testing”）的能力，要么试图获得某种合同SLA的杠杆作用，以便日后退出。

我的build议，多次遭受这两类客户的影响，就是不接受这个客户。 让他们驱使疯狂的其他人。

*这个同样的人可能没有尴尬询问比光速旅行，永恒运动，冷聚变等

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

100％的正常运行时间？

这是你需要的：

多个（＆冗余）DNS服务器，指向全球多个站点，每个ISP都有适当的SLA。

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

这很容易。 亚马逊EC2 SLA明确指出：

“年度正常运行时间百分比”是通过从100％减去亚马逊EC2处于“地区不可用”状态的服务年中的5分钟时间百分比计算的。

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

只要将“正常运行时间”定义为与整个服务捆绑相关，您就可以在100％的时间内保持正常运行，而且应该没有问题。

另外值得指出的是，SLA的全部内容是定义你的义务，以及如果你不能满足他们，会发生什么。 如果客户要求3个9个，9个9个或9个万个，那么这个问题就不重要了，问题是他们在什么时候/如果不能提供什么。 显而易见的答案是以5倍的价格提供100％的正常运行时间的订单项，如果您错过了这个目标，那么他们将获得4倍的退款。 你可能得分！

DNS更改只需要花费时间，如果它们被configuration为需要时间。 您可以将logging中的TTL设置为一秒 – 唯一的问题是确保您及时响应DNS查询，并且DNS服务器可以应对该级别的查询。

这正是GTM在F5 Big IP中的工作原理 – 默认情况下，DNS TTL设置为30秒，如果群集的一个成员需要接pipe，则DNS将被更新，并且几乎立即占用新的IP。 最多30秒的中断，但这是边缘情况下，平均将是15秒。

你知道这是不可能的

毫无疑问，客户的重点是看到“100％”，所以你可以做的最好的是承诺100％，除了[所有合理的原因，不是你的错]。

虽然我怀疑100％是可能的，但你可能会考虑将Azure（或类似SLA的东西）视为可能性。 怎么回事：

你的服务器是虚拟机。 如果在一台服务器上有硬件问题，你的虚拟机将被移动到新的机器上。 负载平衡器负责redirect，因此客户不应该看到任何停机时间（尽pipe我不确定会话状态如何受到影响）。

也就是说，即使是这样的失败，99.999和100之间的差异也会导致精神错乱。

您必须完全控制以下因素。
– 内心和外在的人性因素，无论是恶意还是无能。 这方面的一个例子就是有人将某些东西推到生产代码中，导致服务器closures。 更糟的是，破坏行为呢？
– 业务问题。 如果您的提供商不再支付电费或忘记支付电费，或者只是决定在没有充分警告的情况下停止支持您的基础设施？
– 自然。 如果不相关的龙卷风同时击中了足够的数据中心来压倒备份容量呢？
– 一个完全无bug的环境。 你确定没有一个第三方或核心系统控制的边缘案例没有performance出来，但今后仍然可以这样做吗？
– 即使您完全控制了上述因素，您是否确定在检查您的系统是否正常运行时，软件/人员监控不会给您带来误报？

诚实地1​​00％完全疯狂，至less在黑客攻击方面动摇。 您最好的select是做Google和Amazon的工作，您拥有一个地理分布式托pipe解决scheme，您可以将您的站点和数据库复制到多个地理位置的多个服务器上。 这将保证它不会发生重大灾难，例如互联网主干被切割到一个区域（这种情况不时发生）或几乎是世界末日。

我会为这种情况（DDOS，互联网主干切割，世界末日恐怖袭击或大规模战争等）提供一个条款。

除此之外，还要关注Amazon S3或Rackspace云服务。 从本质上来说，云设置将不仅仅提供每个位置的冗余，还包括stream量的可扩展性和地理分布，以及在失败的地理区域周围redirect的能力。 虽然我的理解是，地理分配花费更多的钱。

我只是想增加另一个声音，“它可以 （理论上）完成”党。

无论付给我多less钱，我都不会承担这个合同，但作为一个研究问题，它有一些相当有趣的解决办法。 我并不熟悉networking来概述步骤，但我想象一下networking相关configuration+电气/硬件布线故障切换+软件故障切换的组合，可能在某些configuration或其他工作中实际上将其closures。

在任何configuration中，几乎总是有一个单一的故障点，但是如果你努力工作的话，你可以将这个故障点推到“现场”（即root dns停机，但是这些值仍然被caching其他地方，所以你有时间来解决它）。

再次，不要说这是可行的..我只是不喜欢一个单一的答案如何解决这个事实，它不是“出路” – 这只是他们真正想要的东西，如果他们想通了。

重新考虑衡量可用性的方法，然后与您的客户合作，设定有意义的目标 。

如果您正在运行大型网站，则正常运行时间根本无用。 如果客户最需要10分钟的查询时间（stream量高峰），则可能对业务造成更大的损害，而在星期天凌晨3点，则会长达一小时的停机时间。

有时，大型networking公司使用以下指标衡量可用性或可靠性：

1. 成功回答的查询的百分比，没有服务器端错误 （HTTP 500s）。
2. 在特定目标延迟以下回答的查询的百分比。
3. 下降的查询应该计入您的统计（见下文）。

可用性不应该使用样本探针来衡量，这是外部实体（如pingdom和pingability）能够报告的内容。 不要单靠这个。 如果你想做的正确， 每一个查询应该算 。 通过观察你的实际成就来衡量你的可用性。

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

丢弃的查询的百分比也应计入您的统计。 它可以作为服务器端错误在同一个桶中。 如果networking或其他基础设施（如DNS或负载平衡器）出现问题，则可以使用简单的math运算来估计丢失的查询数量。 如果您希望一周中的某一天有X个查询，但是您有X-1000，则可能会丢失1000个查询。 绘制您的stream量到每分钟（或第二）图查询。 如果出现间隙，则丢弃查询。 使用基本几何来测量这些间隙的面积，从而为您提供丢失查询的总数。

与客户讨论这种方法，并解释其好处。 通过测量其当前可用性来设置基线 。 对他们来说很清楚，100％是不可能的目标。

然后，您可以根据基线的改进来签署合同。 比如说，如果他们目前正在经历95％的可用性，那么可以承诺通过达到98.5％来改善10倍的情况。

注意：这种测量可用性的方法有缺点。 首先，收集日志，自己处理和生成报告可能并不重要，除非您使用现有的工具来完成。 其次， 应用程序错误可能会伤害您的可用性。 如果应用程序质量较差，则会导致更多的错误。 解决scheme是只考虑由负载均衡器创build的500个而不是来自应用程序的500个。

事情可能会因此而变得复杂一些，但仅仅只是测量服务器正常运行时间而已。

虽然有些人在这里指出，100％是疯狂的或不可能的 ，但他们却错过了真实的一点。 他们认为，其原因是，即使是最好的公司/服务也无法实现。

那么比这更简单。 这在math上是不可能的 。

一切都有可能。 在您存储服务器的所有位置可能会同时发生地震，从而摧毁所有服务器。 可以肯定的是，这个概率很小，但不是0.所有的互联网提供商都可能面临同时发生的恐怖/networking攻击。 再次，不是很可能，但也不是零。 无论你提供什么，你都可以得到一个非零概率的情景，从而降低整个服务。 因此，你的正常运行时间也不能100％。

去拿一本关于制造质量控制的书，使用统计抽样。 本书中的一般性讨论，任何经理在大学综合统计课程中都会涉及到的概念，决定了从一千元到一千元到十万分之一十亿分之一的数字呈指数级上升。 从本质上讲，100％正常运行时间的能力将花费几乎无限的资金，就像将物体推向光速所需的燃料量。

从性能工程的angular度来看，我会拒绝这个既不可测也不合理的要求，即这个expression更多的是一种渴望而不是真正的要求。 由于任何应用程序之外的应用程序依赖关系存在于networking，名称parsing，路由，从底层架构组件或开发工具中传播的缺陷中，实际上不可能有任何人保证100％的正常运行时间。

我不认为客户实际上是要求100％的正常运行时间，甚至是99.999％的正常运行时间。 如果你看看他们正在描述的内容，他们正在谈论的是如果meteor拿走他们的现场数据中心，那么他们正在谈论他们离开的地方。

如果这个要求是外部的，人们甚至没有注意到，那该有多严重呢？ 将一个Ajax请求重试，并显示一个微调30秒的最终用户是可以接受的？

这些是客户关心的事情。 如果客户实际上正在考虑精确的SLA，那么他们就足够了解它，将其expression为99.99或99.999。

我的2美分。 我负责一个非常受欢迎的财富5公司的网站，他将为超级碗拿出广告。 我不得不面对巨大的stream量高峰，而我解决这个问题的方式就是使用像Akamai这样的服务。 我不为Akamai工作，但我发现他们的服务非常好。 他们有自己的，更聪明的DNS系统，知道一个特定的节点/主机要么负载很重，要么closures，可以相应地路由stream量。

关于他们的服务的整洁的事情是，我没有必要做任何非常复杂的事情，以便将我自己的数据中心中的服务器上的内容复制到他们的数据中心。 另外，我从与他们的合作中知道，他们大量使用Apache HTTP服务器。

虽然不是100％的正常运行时间，但您可以考虑将这些内容分散到世界各地。 就我所了解的情况而言，如果我在密歇根州，Akamai也有能力将本地化的stream量意义化，我从密歇根/芝加哥的服务器获得内容，如果我在加利福尼亚，我应该从加利福尼亚州的服务器获取内容。

而不是异地故障转移，只需从两个位置同时运行应用程序，内部和外部。 并同步两个数据库…然后，如果内部closures，内部人员仍然可以工作，外部人员仍然可以使用该应用程序。 内部恢复联机时，请同步更改。 您可以有一个域名的两个DNS条目，甚至有一个循环的networking路由器。

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

但是，即使拥有Google的全部资源和世界上最先进的平台， App Engine SLA正常运行时间保证仅为“任何日历月的99.95％”。

简单而直接：任播

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

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

但是请记住，100％的正常运行时间是不可能的，从99.999％到99.9999％的成本要大得多。