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

Question

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

我已经看到这种处理方式有很多，从“责怪除我们之外的所有人”到“我们搞砸了，我们很抱歉”的方法。

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

1. 你会立即认错吗？（你应该，合法吗？）
2. 您向客户提供了多少有关出错的信息？（“问题”与“我们的一个 SQL 查询中的代码语法错误”）
3. 你是带着后续的预防计划回来，还是只是把它留在“这已经解决了”？
4. 你们提供实时更新吗？多常？通过 Twitter 或面向公众的网站？

您发现成功的任何其他最佳实践？

Answer 1

这是我所做的：

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

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

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

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

将任何指责、内疚或私刑的电话单独发送到不同的邮件中，最好在一些冷却时间之后。

在停机期间不要承诺任何事情，除非您真的非常确定自己可以交付。不知何故，两个单独的“坏消息”情况比一个长的情况更糟糕。

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