障害対応のリアル:初心者がハマった4つの落とし穴と学び
■この記事で得られること
障害が発生した際、エンジニアとしてどのように行動すべきか悩むことがあるかもしれません。私自身、初めて障害に直面した際に、対応内容を何となく理解していても、実際に行動まで移すことが難しいというギャップを痛感しました。その理由は、きちんと目的とアクションが結びついていなかったからであると反省しています。
この記事では、私が初めての障害対応で得た教訓をもとに、初心者が陥りやすいアンチパターンや抑えるべきポイントを解説します。また、ベテランエンジニアの方々にとっても、初心者の視点を理解する上で参考になる内容を提供します。
■障害の詳細
上記の記事でも紹介した通り、ourlyにおいてはBIツールの作成と運用にエンジニアも関わっています。今回起きた障害はこのBIツールで発生しました。
具体的な障害内容については下記になります。
- 症状: BIツールの一部のデータが欠損し、データが非表示になってしまう。
- 影響範囲: ビジネスサイドのメンバーが最新のデータをもとに意思決定を行えず、意思決定の遅延や誤った判断につながる。
- 初動: メンバーからの報告を受け、障害が発生していることを認知。
- ステークホルダー: ビジネスサイドのメンバー、エンジニアメンバー
以下の解説は上記の障害対応をもとに行います。
■障害対応の基本となる4つのポイント
今回の障害対応で学んだ、障害時に気をつけるべきポイントを4つまとめました。
①~④の優先度で対応するのがオススメです。なぜなら必要なコミュニケーションを抑えた上で具体的な調査や対応に移ることができ、より効率的な動きとなるためです。
対応項目 | 目的 | 具体的なアクション |
---|---|---|
①タイムリーな情報共有 | ステークホルダーの不安を和らげ、全体の進捗を透明化する | 調査や解決にかかる見込み時間と進捗状況を定期的に共有する |
②重要性と緊急性の判断 | 迅速に対応すべきか否かを決定する | ステークホルダーへの影響度を考慮し、緊急性を判断する |
③複数人での調査 | 見落としを防ぎ、多角的な視点で問題を捉える | 二人以上で協力し、問題の全体像をより正確に把握する |
④代替案の検討 | 原因究明が難航した場合でも、影響を軽減する対応策を用意する | 暫定的な解決策を講じ、必要に応じて他のチームメンバーと相談する |
①タイムリーな情報共有
今回の障害対応時には、障害の報告を受けてから「確認します」とだけ連絡をして、そのまま調査に入ってしまいました。上司からは「問題はすぐに解決できそうなものか?もし追加で調査が必要な場合はいつまでに調査結果を報告するのかビジネスサイドに連絡してほしい。」とフィードバックをもらいました。
「△△/◯◯までに調査内容を報告します」
上記のように、期限とアクションをセットにすることで、相手に情報と安心感を与えることができます。
当然ですが進捗共有が多すぎても負担になるため、「相手にとって必要な情報は何か?」を考え適切なバランスをとることが重要です。
②重要性と緊急性の判断
当初、障害の原因をいち早く見つけたいという焦りから、調査を最優先にしていました。その結果、メインで実装する新規実装に遅れが生じてしまったため、優先度をつけてから対応してほしいというフィードバックをもらいました。
起きた障害の影響範囲がどのくらいのものか、いつまでに修正できるといいのか、温度感をステークホルダーに確認して認識をそろえましょう。
今回の事例でいくと、「このデータが見られないことで、業務のどこに問題が生じているのか」「見られなくなっているデータはいつ次に必要になるのか?」を確認することで、適切な対応順序を決めることができます。
③複数人での調査
1人で調査をしている際に、「なぜこれでうまくいかないんだ…」と焦りが募り、ChatGPTにエラーを丸投げするようなことをしていました。生産性が非常に低かった上に、心理的にも不安な状態でした。
障害が発生した時にはこのように冷静さを欠きやすく、原因特定を急ぐあまり、視野が狭まってしまう可能性が高いです。
少なくとも障害の原因が特定できるまでは2人以上で障害対応をしましょう。
また実際の不具合解消に関しては、他の人と進捗を共有しながら対応するようにしましょう。その際の修正内容の意思決定や本番環境に入っての作業などの際には、やはり独断ではなく複数人で対応するようにすることでリスクを軽減できます。
④代替案の検討
障害調査を重ね、優先度が高い問題から修正を試みましたがなかなか解決しませんでした。「いつまでこの修正が続くのか?このままズルズルと続くのは良くないので、期限になっても修正しきれない場合に備えて代替案を提示できるようにしよう」とフィードバックをいただきました。
一時的な措置として、他の手段で一部の要望を満たすことができないのか代替案を並行して考えましょう。今回の障害対応時にも途中から、「BIツール上でしか見れないデータなのか?」、「他の管理ツールや生のCSVファイルでも一時的に代替可能なのか?」を並行して考えながら、調査や対応を行いました。
ただしすぐに代替案を出せない場合もあるので、そこで時間がかかりそうなら、周りに相談をすることも心がけましょう。悩みや問題を自分の中に留めておかないことが重要です。
最後に
障害調査・対応は、ステークホルダーとのコミュニケーションを並行して行うことになるので、難易度の高い業務です。
そのような状況でこそ、「今何が必要なのか?」「この調査や対応は何のためにやっているのか?」という目的意識を持つことが重要になります。本記事が今後の障害対応時の参考になれば幸いです。
Discussion