我在一家财富 500 强公司工作，该公司难以准确衡量高可用性应用程序的性能和可用性（即，在 5 秒页面到页面导航的情况下提高 99.5% 的应用程序）。我们将计划内和计划外停机时间都考虑在内，以确定此可用性数量。但是，我们最近在组合中添加了一个 CDN，这使我们的指标有点复杂。CDN 现在处理我们大约 75% 的流量，同时将剩余的流量发送到我们自己的服务器。
我们试图衡量我们所谓的“真正的用户体验”（即，我们的测试脚本模拟典型的用户点击应用程序。）这些监控脚本位于我们的网络之外，这意味着我们访问了大约 75% 的 CDN时间。
管理层已决定我们采用最坏的情况来衡量可用性。因此，如果我们的源服务器出现问题，但 CDN 提供的内容还不错，我们仍然会影响可用性。反过来也是如此。我的想法是，只要“用户体验”成功，我们就不应该无谓地惩罚自己。毕竟，CDN 可以提高性能和可用性！
我只是想知道是否有人知道其他财富 500 强公司如何计算他们的可用性数字？例如，我查看 apple.com 的一个店面，该店面使用的 CDN 似乎永远不会关闭（除非即将发布重大产品公告。）拥有一些确凿的事实数据会很棒，因为我不知道不要相信我们需要在这些指标上不必要地伤害自己。我们正在根据这些数字做出业务决策。
然而，我可以说，鉴于这些指标对管理层是可见的，问题得到解决并很快得到解决（阅读：我们很快就消除了繁文缛节。）不幸的是，作为一名开发人员，我不希望管理层认为由于某些外部因素（即 CDN）正在影响数字，因此应用程序处于上升或下降状态。
想法？
（我错误地将这个问题发布在 StackOverflow 上，对于交叉帖子，我深表歉意）
在摘要中，我会说你应该明确定义什么是“可用”与“不可用”，并根据它来衡量自己。例如，您可以为站点设置一个客户端性能 SLA，该站点的“折叠”时间为 1 秒，完全呈现页面的时间为 3 秒。当您不满足性能 SLA 时，您应该将其视为该时间段的可用性故障。是否访问 CDN 无关紧要——用户体验才是最重要的。
但是，由于您仅每 5 分钟进行一次测量，因此分别测量 CDN 与主站点的点击似乎是合理的，并计算出 75% 的可用性来自 CDN，25% 来自主站点。这里的困难在于 75% 只是一个平均值。为了在给定的时间段内准确地分配责任，您需要知道一个或另一个站点何时实际上不面向客户，例如，在计划的更改期间或在检测到问题时的手动操作之后。您还需要考虑当主站点或 CDN 之一关闭时会发生什么。客户是否获得了 HTTP 500，或者他们只是透明地故障转移到工作站点？很大程度上取决于您的负载平衡解决方案。您描述的“最坏情况”指标似乎过于简单。问你自己， ”
至于CDN宕机时是否应该“责备”：绝对。如果您 75% 的点击进入 CDN，那么您 75% 的客户体验取决于它们。您有责任为您的客户提供良好的体验，因此如果 CDN 出现问题，您需要使用您的工程资源来证明这一点并与提供商联系。
要考虑的另一件事是当主站点长时间不可用时会发生什么。正如您所描述的，听起来 CDN 是主站点上内容的静态副本。如果主站点长时间关闭，CDN 可能会开始变得陈旧。因此，也许您的 SLA 的一部分应该是新鲜度：“折叠”1 秒，完全呈现页面 3 秒，内容不超过 15 分钟。
我同意 user44700，最好将服务器的可用性测试与 CDN 分开，并独立跟踪两者。您真正的可用性将是 Server Avail * CDN Avail，因为如果其中任何一个出现故障 - 您正在考虑您的页面/站点已关闭。这也将使您与任何监控供应商一起花费更少。
我不会去创建一个浏览器测试并查看哪些项目失败了，虽然它可以工作，并且像 Catchpoint 这样的一些公司有“内容可用性”的概念——这可能不是你想要的这种情况。例如，您的网页调用了 CDN 以获取提供 404 的文件，大多数监控解决方案都会告诉您这是一个失败 - 但真的是 CDN 失败了吗？那个文件甚至重要吗？也许有人只是忘记删除一些没有用户注意到的遗物参考。
您可以阅读这篇博文了解更多想法： http: //blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/
SLA 报告应准确反映现实。如果您从用户的角度衡量可用性，并且只有进行衡量的服务器遇到问题，那么在您的 SLA 中报告该问题将不会反映用户体验。
我可以理解希望将源信息保持在高标准，即使不准确，也可能总是报告它，但会附上说明原因的说明。
如果您不能达成一致，也许有一种技术解决方案可以使测量服务器不那么容易出错。
如果信息被报告为中断，而事实并非如此，那么报告提供了什么价值？
在我的环境中，我们从多个来源进行报告。一种外部监控方法，用于从外部角度报告可用性以及报告我们的内部中断记录系统，该系统是人工输入的，并考虑了最准确反映情况的多个因素。
Gomez 和 Keynote 是企业认可的解决方案，用于收集您提到的指标类型。Gomez 还提供一项服务，通过获取 google-analytics-esque javascript 文件来监控您的最终用户 UX。
Pingdom 不错：http ://www.pingdom.com/
我们是财富 500 强企业，拥有支持 CDN 的网站，我们使用了几样东西。如果要检测不同的事物，您已正确确定需要测量不同的事物。我不清楚您具体想要什么 - 帮助您确定应用程序何时实际关闭的可用性数字，或者让您摆脱管理的数字。反正...
要摆脱“CDN”，您可以使用另一个 Keynote/Gomez 监视器并将其指向您的应用程序，而不是使用备用 DNS 名称或诸如此类的 CDN。但由于它仍然具有静态资产，因此它对性能比可用性更有用。并且它将互联网中断、代理中断等保持在循环中，这适用于某些目的而不适用于其他目的。
真实用户监控。有基于网络的（Coradiant、Tealeaf）和基于标签的（Jiffy、Gomez）。我们使用 Coradiant 作为网络嗅探器，它决定了托管在我们数据中心的资产的真实用户可见性能——换句话说，是实际应用程序，而不是 CDN 上的所有静态垃圾。然后，我们编写报告来确定应用程序错误率和性能，并使用 Apdex (apdex.org) 作为派生指标。在某些情况下，您不能使用基于网络的（流量过多，或者您的资产没有托管在您可以在网络上获取的位置），并且基于标签的可靠性并不高。具有实际查看最终用户响应时间和错误的巨大好处 - 很容易设置一个在真实用户所做的所有情况下都不会出错的合成监视器。
本地综合监测。Nagios/zabbix/sitescope/其他一百个。在本地将监视器指向您的应用程序（不要通过 CDN）。对于可操作的（如发送页面唤醒某人）可用性监控，这是黄金标准。不考虑网络的东西。
日志监控。从某种意义上说，这是贫民窟真正的用户监控。但是如果你真的只是想看看什么时候出错，它非常方便。具有真实用户监控的“不，这就是发生的事情”的好处。通常只有可用性，除非您在 Web 层记录所花费的时间，在这种情况下，它会显示您的服务器端花费了多长时间 - 对面向用户的 SLA 没有帮助，但对于“我们需要处理哪些代码”非常有帮助。” 使用 splunk。
这不是非此即彼，我们使用所有这些，因为您确实想要“最终用户故事”以及“我们需要依靠什么程序员”。
BrowserMob很棒