最近、HXServersが25230にRCAを投稿しました。RCAは「根本原因分析（Root Cause Analysis）」の略で、障害原因分析（Reasons For Outage）と呼ばれることもあります。

HXServers RCAは素晴らしいものですが、これらのアナウンスは目的を果たさないことが多すぎます。適切に実施すれば、顧客の信頼を高める素晴らしいツールとなり得ますが、不適切に実施すれば、ユーザーの不安を増大させてしまいます。

RCA を台無しにする方法の例をいくつか示します。

• 書くのに時間がかかりすぎます。顧客は数週間ではなく、1～2日以内の回答を求めています。
• 根本原因を明かさないでください。「まだ調査中」と伝えるのは問題ありませんが、その場合はフォローアップを書く必要があります。
• 技術的な詳細に埋もれてしまう。「Gonkulator X-2000のファームウェア2023.1103.102をパッチ1059にアップグレードした際に失敗し、Merkel M-105トランスデューサーに連鎖的な故障が発生しました…」
• 責任を取る代わりに、他人のせいであるかのように振る舞う。

RCA を効果的にするには、次のことを行う必要があります。

何が起こったのか明確に述べてください。 1月13日12時5分に、あれこれと問題が発生しました。アトランタ、ニューブランズウィック、ボイシのデータセンターに影響がありました。ナッシュビルには影響がありませんでした。

あなたはすぐに気づきました。監視はきちんと行われていたか、エンジニアが異常に気づいていたのでしょう。あなたは不意を突かれたわけではなく、怒った顧客が指摘するまで待つ必要もありませんでした。

どのように行動したか。XチームとYチームにすぐに連絡を取り、彼らはすぐに行動を起こしました。対応の緊急性と、問題解決がいかに重要だったかを伝えようとしています。お客様は困っていたので、あなたはできる限り迅速に解決に取り組みました。

問題を解決するために何をしたか。どのような行動をとったか、そしてなぜ時間がかかったのか。その過程でどのような問題に直面したか。常に緊急性を持って行動していたか。

問題が完全に解決されたことをどうやって確認するか。ユーザーに問題がいつでも再発する可能性があると思わせたくありません。問題を理解し、徹底的に解決に取り組んできたかどうかを確認しましょう。

この問題を防ぐために何をしていますか？この問題が二度と発生しないように尽力していますか？監視機能の追加、構成の変更、容量の追加などを行いましたか？

あなたは痛みを認め、謝ります。言い訳をするつもりはありません。自分が足りないと感じていることに気づき、そのことを深く後悔しています。

優先的に、じっくりとお話を伺いたいとお考えですか？もしかしたら、まだお困りのお客様がいらっしゃるかもしれません。もしそうなら、ぜひお力添えください。ご連絡方法はこちらです。

このようなRCAは、お客様に優秀なチームだと感じてもらえるきっかけになります。ITが完璧ではないことは誰もが知っています。Google、Microsoft、その他の巨大IT企業でも、障害やトラブルは発生します。重要なのは、問題が発生することではなく、どのように対応するかです。