最近，我经历了很多应用程序宕机事件，无论是供应商还是我自己的应用程序。这让我开始思考，我尽可能地在谷歌上搜索，发现在宕机事件期间，并没有一种好的或标准的方法来管理客户沟通。
我已经看到很多处理这个问题的方法“责怪所有人，除了我们自己”方法“我们搞砸了，我们很抱歉”方法。
所以我的问题是......当你搞砸了一个应用程序并导致停机时：
- 你会立即承认错误吗？（从法律上来说你应该这样做吗？）
- 关于哪里出了问题，你会向客户提供多少信息？（“一个问题”与“我们的某个 SQL 查询中的代码语法错误”）
- 您是否带着后续的预防计划回来了，还是只是说“这个问题已经解决了”？
- 你们提供实时更新吗？多久更新一次？通过 Twitter 还是面向公众的网站？
您发现还有其他成功的最佳实践吗？
答案1
这是我的做法：
- 明确说明结果（现在和不久的将来）。强调可能产生的永久后果或缺乏（数据丢失、员工工时损失）。
- 保持语气中立。不要把精力花在责备/内疚上。理想情况下，这传达的信息是“我想给你提供信息，但我的注意力也需要放在其他地方”。
- 您的通知将转发给很多人，请确保您的 CEO 了解前半段的要点。通常我会提供“执行摘要”。技术细节可以为其他技术人员提供背景信息。
- 提供联系方式（最好是在停机时间最紧张的时候有时间的人）以便进一步提问，并在同一句话中询问耐心（这通常很有效）。
- 承诺情况发生变化时更新。
如果有好消息，请在办公室下班前（“所有员工将继续通宵工作” - 必要时考虑时区）以及办公室开门时再次发送更新。
当问题解决后（针对该词的任何定义），发送：
- 包括后果时间的摘要
- 短期内采取的以及未来计划的行动/改变（“经验教训”）；基于：
- 技术根本原因分析
将任何指责、愧疚或私刑的呼吁放在单独的邮件中，最好等一段时间再发送。
不要在停机期间承诺任何事情，除非你真的非常确定自己能够完成。不知何故，两个单独的“坏消息”情况比一个长期的“坏消息”更糟糕。
我更喜欢使用在每条消息上推送通知的媒介（邮件、Twitter 等）。
答案2
我发现，无论是作为服务提供者还是服务使用者，最重要的就是积极主动的责任感。重要的不是你说什么，而是你什么时候（多快）说。
如果您收到问题发生并已修复（或正在处理）的通知，这比自己发现问题并尝试联系供应商以查明到底发生了什么要好得多。这也有助于避免互相指责，并节省大量故障排除时间（是我们的问题还是他们的问题？）。
至于细节，我发现，除非用户明确要求更多信息，否则对发生的事情进行简单的总结就很好了。有些人总是希望获得尽可能多的细节，但大多数人只是希望事情能够顺利进行（即使技术含量很高）。
最后，能够解释你已经采取了哪些措施以避免再次发生这种情况，这对于未来的善意和信任大有帮助。
答案3
如果您对您的特定应用程序、其许可方式、您提供服务的领域等了解不多，就不可能不猜测就回答您的问题。
- 承认自己的错误通常是最佳途径。如果您的行业涉及多项法律、服务水平协议或细致的合同，请咨询您的律师。
- 细节太多和太少之间的界限很微妙。一般来说，细节足够让普通用户感觉他们理解。
- 如果这是一个小错误，而且很快就能改正，那就不要纠结于此。如果这是一个大错误，你就得采取措施来控制损失。
- 对于小错误，在发生故障或修复时通知。对于大错误，在解决方案达到任何里程碑时通知。
我希望我的供应商能够提供更多关于停机时间的信息。但许多企业就是做不到，或者被律师蒙蔽了双眼。如果您有任何疑问，请咨询您的律师/保险公司。