概要
自分は今まで事業会社スタートアップのエンジニアとして働くことが多かったので、その経験の中で得たアラート対応の心得を書きます。 サービス提供をする事業会社のエンジニアとして、システムを開発するだけでなく、普段のシステム運用を通してユーザーが常にシステムを安定的に使えるようにすることは重要なことです。システムが安定的に動いていないことを示すのがアラートです。アラートへの対応を素早く的確に行うことで、提供できるサービスの品質をよくすることができます。
アラートチャネル編
- 即時対応が不要なものはアラートにあげない。
- アラートチャネルに送られるメッセージはすべて通知されることが推奨される
上げるべきでないアラートが上がってしまうと、即時反応するコストが上がってしまいます。その場合は、上がるべきじゃなかったアラートを減らせるように設計しましょう。
アラートが上がったら編
- アラートに上がるものは即時に反応する
- アラートが上がるということはユーザーがサービス利用できていないということ。
- 確認を始めたらまわりに確認を進めていることがわかるように「確認します」というリアクションをメッセージでもスタンプでもいいからする。
アラートは多くの場合、複数人が同時に対処を進めることになります。そのときに、まわりの状況が伝わらないと、効率の良い解消には向かいません。全員が自律的に対処を進め解消に動けるように情報を共有しましょう。
状況調査編
- 確認の進捗は逐一上げる。
- 確認すべきことが一つだけとは限らない。情報が共有されれば、それを踏まえて他の人が別の観点で調査できる。
- 判断だけじゃなくて、事実を上げる。
- 事実と意見は明確に分ける。
- わからないならわからないということも上げる。とにかく状況を共有する。
- まず顧客影響を考える
- お客さんが何ができなくなっているのか。
調査内容が残ることで、次に対応する人の参考になったり、なにか調査内容に間違いがあってもその内容を検証できます。
対応内容判断編
- もし対応すべき内容の判断がつかなくても、その時点で分かる情報と根拠から決定する。
- 必ずしも、100%の自信を持って判断できることばかりではない。
- そういった場合は「検証可能な状態で判断をする」ことで、もし判断が間違っていても次に活かせるようにする。
- 何を根拠にどういう判断をしたのかを具体的に残す。
- 情報が足りなくて判断が難しい場合は、ログを残すなどのチケットを作成することで状況を改善し、次のアラート発生時には対応可能な状態を目指す。
対応編
- 調査内容から完全に正解がわかる場合は、そのまま対処を進める。
- 応急対応ですぐに対応が必要なものはすぐに行う。
- 恒久対応で時間がかかるものは、チケットに起票し、スプリントなどの開発サイクルのなかで対応する。
まとめ
- 即時対応すること。アラートが数分以上放置される状況は何かが異常です。なぜ放置されるのかを分析してすぐに問題を解消しましょう。
- 「間違ってるかもしれないから何もしない」「わからないから何もしない」というのはエンジニアの責務放棄です。あなたがわかるかどうかが大事なのではなく、サービスを少しでも早く復旧させることが重要なのです。何もわからない状況・一部しかわからない状況でもできることはあります。
