アプリケーションのダウンタイム中に通信を管理するにはどうすればよいでしょうか?

アプリケーションのダウンタイム中に通信を管理するにはどうすればよいでしょうか?

最近、ベンダーと自分のアプリケーションの両方で、アプリケーションのダウンタイムを何度も経験しました。これについて考えさせられましたが、グーグルで調べた限りでは、ダウンタイム インシデント中に顧客とのコミュニケーションを管理するための適切または標準的な方法は実際には存在しないようです。

私はこれを様々な方法で処理してきました「私たち以外の全員を責める」へのアプローチ「私たちは失敗してしまい、申し訳ありませんでした」アプローチ。

私の質問は... アプリを台無しにしてダウンタイムを引き起こした場合:

  1. あなたはすぐに過失を認めますか?(法的にはそうすべきですか?)
  2. 何が問題だったかについて、顧客にどの程度の情報を提供しますか? (「問題」と「SQL クエリの 1 つにコード構文エラーがあった」)
  3. フォローアップの予防計画を持って戻ってきますか、それとも「これは解決されました」で終わりますか?
  4. リアルタイムの更新情報を提供していますか? どのくらいの頻度で提供していますか? Twitter 経由ですか、それとも一般向け Web サイト経由ですか?

他に成功したベストプラクティスはありますか?

答え1

私がやっていることは次のとおりです:

  • 明確に述べよ結果(現在および近い将来)起こりうる永続的な結果を強調するまたはその欠如(データ損失、従業員の労働時間の損失)。
  • 口調は中立的にしてください。非難や罪悪感にエネルギーを費やさないでください。理想的には、これは「私はあなたに情報を提供したいのですが、私の注意は他の場所にも必要です」というメッセージを伝えます。
  • 通知は多くの人に転送されるので、CEO が最初の半分の段落の要点を理解していることを確認してください。通常、私は「エグゼクティブ サマリー」を提供します。技術的な詳細は、他の技術者に背景情報を提供できます。
  • さらに質問がある場合の連絡先の詳細(できればダウンタイム中に時間のある人)を提供し、同じ文の中で忍耐を求めます(多くの場合、これでうまくいきます)。
  • 状況が変わったら更新することをお約束します。

良いニュースがある場合、オフィスの閉店時間前(「スタッフ全員が夜通し業務を継続します」 - 必要に応じてタイムゾーンを考慮してください)、およびオフィスの開店時間頃に更新情報を送信します。

問題が解決したら (その単語の定義に関係なく)、次のメールを送信します。

  • 結果のタイミングを含む概要
  • 短期的に実行され、将来に向けて計画されているアクション/変更(「学んだ教訓」)は、次の内容に基づいています。
  • 技術的な根本原因分析

非難、罪悪感、リンチを求める呼びかけは、できれば冷静になる時間を置いた後、別のメールで保管してください。

本当に確実に実行できると確信できる場合を除いて、ダウンタイム中に何かを約束しないでください。どういうわけか、2 つの別々の「悪いニュース」の状況は、長い 1 つの状況よりも悪いのです。

私は、すべてのメッセージに通知がプッシュされる媒体(メール、Twitter など)を使用することを好みます。

答え2

サービス提供者とサービス利用者の両方として私が見つけた最も重要なことは、積極的な責任です。何を言うかではなく、いつ(どれだけ早く)言うかが重要です。

問題が発生して修正された(または作業中)という通知を受ければ、自分で問題を発見し、ベンダーに連絡して何が起こっているのか調べるよりもはるかに良いです。責任のなすり合いもなくなり、トラブルシューティングの時間も大幅に節約できます(問題は私たちにあるのでしょうか、それともベンダーにあるのでしょうか?)。

詳細に関しては、ユーザーが特に詳しい情報を要求しない限り、何が起こったかを簡単にまとめるのが良いと思います。できるだけ多くの詳細を常に求めている人もいますが、ほとんどの人は、(高度な技術を要する場合でも)物事がうまく機能することを望んでいます。

最後に、同じことが二度と起こらないようにどのような対策を講じたかを説明できることは、将来の好意と信頼を得るのに大いに役立ちます。

答え3

特定のアプリの詳細、ライセンス方法、サービスを提供している分野などについてよく知らないと、推測せずに質問に答えることは不可能です。

  1. 自分のミスを認めるのが通常は解決策です。多くの法律、SLA、または綿密な契約が適用される分野の場合は、弁護士に相談してください。
  2. 詳細が多すぎることと、詳細が少なすぎることの境界線は微妙です。一般的には、一般的なユーザーが理解できる程度の詳細が必要です。
  3. 小さなミスですぐに修正できる場合は、そのミスにこだわらないでください。本当に大きな失敗だった場合は、ダメージコントロールを行う必要があります。
  4. 小さなミスの場合は、ダウンしたときと修正されたときに通知します。大きなミスの場合は、解決へのマイルストーンに到達したときに通知します。

私はベンダーがダウンタイムについて多くの情報を提供してくれることを望みます。しかし、多くの企業はそれができないか、弁護士によって封じ込められています。疑問がある場合は、弁護士/保険会社に相談してください。

関連情報