在应用程序停机期间如何管理通信？

最近，我在供应商和我自己的应用程序方面都经历了很多应用程序停机的经验。这让我开始思考，尽我所能，谷歌并没有真正的好方法或标准方法来管理停机事件期间的客户沟通。

从“怪我们以外的所有人”到“搞砸了我们感到抱歉”，我已经看到了很多方法。

所以我的问题是...当您搞砸了一个应用程序并导致停机时：

1. 您会立即认错吗？（您合法吗？）
2. 您向客户提供了多少有关发生问题的信息？（“问题”与“我们的一个SQL查询中的代码语法错误”）
3. 您返回预防跟进计划，还是仅将其留在“此问题已解决”？
4. 你们提供实时更新吗？多常？通过Twitter还是面向公众的网站？

您是否已找到其他成功的最佳做法？

这是我的工作：

• 非常清楚地说明后果（现在和将来）。突出显示可能的永久后果或缺乏后果（数据丢失，员工工时损失）。
• 保持语调非常中立。不要将精力花在责备/内gui上。理想情况下，这传达了“我想向您提供信息，但在其他地方也需要我的关注”。
• 您的通知将转发给很多人，请确保您的首席执行官了解上半段的要旨。通常我会提供“执行摘要”。技术细节可以为其他技术人员提供背景信息。
• 提供联系方式（最好是那些在停机时间很忙的人）以进一步询问问题，并在同一句话中耐心等待（这通常很有效）。
• 情况发生变化时，Promise会更新。

在有好消息的情况下，在办公室关闭时间之前发送更新（“所有员工将继续通宵”-如果需要，请考虑时区），然后在办公室开放时间之前发送更新。

解决问题后（对于该单词的任何定义），请发送：

• 摘要，包括后果的时机
• 在短期内采取并为未来计划的行动/变化（“经验教训”）；基于：
• 技术根本原因分析

最好在一些冷却时间过后，再将任何责备，内或私刑的呼吁留在单独的邮件中。

除非您确实非常确定可以交付，否则在停机期间不要做出任何承诺。不知何故，两个单独的“坏消息”情况比长期的情况要糟。

我更喜欢使用一种在每条消息（邮件，Twitter等）上推送通知的媒介

作为服务提供商和服务用户，我发现最重要的事情是主动承担责任。您说的不是您所能说的，而是您说的时间（多久）。

如果您收到问题发生并已解决（或正在解决）的通知，那总比自己发现问题并尝试与供应商联系以了解问题的实质要好得多。它还有助于解决非常规游戏，并节省了大量的故障排除时间（是我们还是他们？）。

就细节而言，除非用户特别要求提供更多信息，否则我认为对所发生的事情进行简单总结是不错的。会有一些人总是想获得尽可能多的细节，但是大多数人只是希望事情能够进行（即使他们具有很高的技术水平）。

最后，能够说明您已采取的步骤，以免再次发生，这对将来的商誉和信任大有帮助。

在不了解您的特定应用程序，如何获得许可，您提供服务的领域等更多信息的情况下；没有猜测就不可能回答您的问题。

1. 通常由自己承担错误。如果您的领域适用许多法律，SLA或细致的合同，请咨询您的律师。
2. 细节之间的界限太细了。一般而言，足够多的细节使普通用户会觉得自己理解。
3. 如果这是一个小错误，并且很快就解决了；不要细说。如果这确实是一个大问题，那么您就需要进行损害控制。
4. 小错误，请在发生故障和修复时通知您。重大错误，请在达到解决方案的里程碑时通知。

我希望供应商提供太多有关停机时间的信息。但是许多企业无法做到，或者被律师束之高阁。如有任何疑问，请咨询您的律师/保险公司。