松弛的健康检查一致性
Slack health check consistency
我们是 运行 我们公司的一个 Slack webhook 使用 hooks.slack.com/services/myWebHookId，我们希望知道它是否每 30 秒左右可达。
根据 Slack 健康状态检查，我可以随时去检查 Slack 是否在线使用它的健康页面（当前 https://status.slack.com/api/v2.0.0/current）并了解它的当前健康状况。
我的问题是一致性问题。 Slack 健康页面 status.slack.com 是否有可能以健康状态正确解析，而其中一个 webhook 服务 hooks.slack.com，即我实际使用的服务，会以某种方式被破坏、无法访问或有错误的 DNS 记录？
重点是，Slackurl健康检查，完全不同于web服务url我们实际上是用来发送 Slack 消息。
这个健康检查够好吗？第一个总是代表第二个吗？够靠谱吗？
是否可以改为检查 hooks.slack.com 处的 webhook 服务？
有什么建议或最佳做法吗？
根据官方文档：
https://api.slack.com/docs/slack-status#best-practices
• Use the most recent version of the API endpoint (v2.0.0).
• Call the current endpoint as frequently or infrequently as you need to in order to respond to issues with Slack;
if you need to be notified immediately of an incident, consider polling the current endpoint once a minute.
Polling more frequently than that isn't recommended.
• If you rely on a specific feature of Slack heavily, check the services field of an incident to verify that the feature is working as usual. For example, if your app doesn't use link unfurls, but does rely on messaging, consider filtering for incidents that contain Messaging in the services array, and ignoring alerts that only affect Link Previews.
下面的答案是由 Slack 支持团队发给我的。他们也很友好地允许我在这里粘贴他们的回复：
当我们发现重大问题时，status.slack.com 会手动更新详细信息。因此，可能存在 window，其中状态站点从出现故障时就不会反映 hooks.slack.com 的问题，直到我们在此处发现问题并更新站点。然而，hooks.slack.com 下降将是巨大的，我们会立即看到它的影响。所以我希望在这种情况下 window 非常小。
与整个服务出现问题的可能性相比，特定 webhook 可能存在潜在问题的可能性要大得多。在这种情况下，状态站点将不会更新。如果特定 webhook 存在问题，则在尝试使用 webhook 时应根据错误响应予以注意。在这种情况下，您可以联系我们，我们将努力帮助解决问题。 webhook 通常非常可靠，但如果您确实有顾虑，可以为频道创建第二个 webhook URL，并在您开始在主 webhook 上收到错误时将其用作网络服务的后备。
此外，
没有可用于 webhook 的特定测试方法。但是，您可以发送带有故意不正确负载的消息。这将导致 invalid_payload 错误，并且没有消息实际发布到频道中。确认您在预期时正确收到此错误可以用作测试。此测试可能会遗漏某些场景，因此您仍然希望为实际消息合并适当的错误处理，但这应该是一种相当可靠的方法。
我们是 运行 我们公司的一个 Slack webhook 使用 hooks.slack.com/services/myWebHookId，我们希望知道它是否每 30 秒左右可达。
根据 Slack 健康状态检查，我可以随时去检查 Slack 是否在线使用它的健康页面（当前 https://status.slack.com/api/v2.0.0/current）并了解它的当前健康状况。
我的问题是一致性问题。 Slack 健康页面 status.slack.com 是否有可能以健康状态正确解析，而其中一个 webhook 服务 hooks.slack.com，即我实际使用的服务，会以某种方式被破坏、无法访问或有错误的 DNS 记录？
重点是，Slackurl健康检查，完全不同于web服务url我们实际上是用来发送 Slack 消息。
这个健康检查够好吗？第一个总是代表第二个吗？够靠谱吗？
是否可以改为检查 hooks.slack.com 处的 webhook 服务？
有什么建议或最佳做法吗？
根据官方文档：
https://api.slack.com/docs/slack-status#best-practices
• Use the most recent version of the API endpoint (v2.0.0).
• Call the current endpoint as frequently or infrequently as you need to in order to respond to issues with Slack;
if you need to be notified immediately of an incident, consider polling the current endpoint once a minute.
Polling more frequently than that isn't recommended.
• If you rely on a specific feature of Slack heavily, check the services field of an incident to verify that the feature is working as usual. For example, if your app doesn't use link unfurls, but does rely on messaging, consider filtering for incidents that contain Messaging in the services array, and ignoring alerts that only affect Link Previews.
下面的答案是由 Slack 支持团队发给我的。他们也很友好地允许我在这里粘贴他们的回复：
status.slack.com 会手动更新详细信息。因此，可能存在 window，其中状态站点从出现故障时就不会反映 hooks.slack.com 的问题，直到我们在此处发现问题并更新站点。然而，hooks.slack.com 下降将是巨大的，我们会立即看到它的影响。所以我希望在这种情况下 window 非常小。
与整个服务出现问题的可能性相比，特定 webhook 可能存在潜在问题的可能性要大得多。在这种情况下，状态站点将不会更新。如果特定 webhook 存在问题，则在尝试使用 webhook 时应根据错误响应予以注意。在这种情况下，您可以联系我们，我们将努力帮助解决问题。 webhook 通常非常可靠，但如果您确实有顾虑，可以为频道创建第二个 webhook URL，并在您开始在主 webhook 上收到错误时将其用作网络服务的后备。
此外，
没有可用于 webhook 的特定测试方法。但是，您可以发送带有故意不正确负载的消息。这将导致 invalid_payload 错误，并且没有消息实际发布到频道中。确认您在预期时正确收到此错误可以用作测试。此测试可能会遗漏某些场景，因此您仍然希望为实际消息合并适当的错误处理，但这应该是一种相当可靠的方法。