成功的失败

休斯顿，我们有一个问题！这是一条标志性的台词，提醒无数太空迷和电影迷想起阿波罗13号太空任务的巨大难度，潜在的灾难以及危险状态，这项任务被NASA称为“成功失败”。忽略自己的应用程序可用性警报可能不会在历史上成为决定性的时刻，但也会造成类似的破坏

现在回到1970年：

“对氧气罐进行例行搅拌会点燃其内部损坏的电线绝缘层，从而引起爆炸，从而将两个服务模块（SM）氧气罐的内容物排空。 没有呼吸和发电所需的氧气，SM的推进和生命维持系统将无法运行。 必须关闭命令模块（CM）的系统，以保留其剩余的再入资源，从而迫使机组人员以救生艇的身份转移到月球模块（LM）。 随着月球着陆的取消，任务负责人努力使机组人员还活着。”

氧气罐的爆炸触发了警报，警告，压力和电压下降，通信中断，然后是宇航员与任务控制系统之间现在著名的无线电通信。但是，如果在爆炸之后机组人员什么也没做呢？ 如果他们从未检查过爆炸，从未对警告和量具做出回应，也从未告知任务控制部有问题该怎么办？如果任务控制在控制中心的仪表板上收到通知或提醒后，从未尝试提供任何帮助怎么办？如果团队把头埋在沙子里，或者为了命运和机会而辞职，却从未尝试从遇到的失败中学习，即兴发挥或改善自己，该怎么办？结果将是悲惨的！它可能是一部纪录片，但几乎没有一部具有标志性线条的大片。

在环境中触发警报时该怎么办？

除非您当然在NASA工作，否则太空行走与我们的日常活动相去甚远，但是最近有关Apollo 13的博客确实引发了一个有关可用性的问题。当您的环境中触发警报时，您该怎么办？ 你只是忽略它吗？您是否低估它，等待警报，日志消息或其他指示符消失？您是否与供应商支持联系以了解如何禁用这些警报，警告和消息？还是说：“我们这里有问题，需要解决”？

作为SIOS Technology Corp.客户体验的副总裁，我们在警报和指示器方面都有着丰富的经验。我们与选择忽略警告的客户进行了艰苦的交流，关闭了指示问题的严重警报，这些警告的范围从应用程序阈值到网络不稳定到潜在的数据不一致。我们还看到了一些客户，他们调动了他们的警报，调查了为什么警报响起，发现了根本原因并享受了劳动成果。这种成果通常是提高稳定性，创新和学习或避免灾难的甜蜜收获。

可用性产品触发警报时您可以做的4件事

1.确定可用性警报的类型和严重性。

警报或错误是否表示警告，错误或严重问题？ 帮助您和您的团队了解关键性的一个好地方是查阅可用的文档。 检查产品文档，在线论坛，知识库文章（KBA）以及内部团队数据和流程手册。

2.评估警报的即时性。

对于警告和错误，它们有多大可能发展为严重的问题或事件。对于关键问题和警报，这可能很明显，但是即使对关键事件进行评估，也可以为您的后续步骤提供一些指导；自我更正，问题隔离或立即升级。

3.咨询其他资源。

您还可以访问其他哪些来源来确定警报条件？ 例如，如果警报与存储有关，是否还有其他工具可以揭示存储的运行状况？如果问题是网络警报，是否部署了虚拟机监控程序工具，流量工具，NIC统计信息或其他专用的监视工具来帮助进行分析。

4.联系支持。

换句话说，如果不确定，请通知任务控制。 确定类型，评估即时性并咨询其他资源之后，最好与供应商联系以寻求支持。关于API调用阈值的警告似乎是无害的。 但是，如果一旦达到这样的限制，API调用将失败，则可能导致立即采取措施。 获得专家的授权可能有助于保持内心的平静和避免灾难。

SIOS等经验丰富的供应商可以帮助您快速确定问题的原因并推荐最佳解决方案。

反复忽略可用性环境中的问题可能会导致意外的后果，但同样会带来灾难性的后果。 解决由警报，日志消息，警告指示符或其他已安装和配置的指示符指示的问题，可以在给您的客户，企业，团队和您自己带来“解决问题的机会”之前，将其变为灾难。 同时，增强您的可用性策略和基础架构。您会选择哪一个？

– Cassius Rhue，客户体验副总裁

转载自SIOS