エラーが発生したときの動き方

前提

ユーザーに影響があるエラーであれば、その場しのぎの対応でもいいので、何よりもエラーを解消することを第一優先に行動する。
根本的な問題解決や再発防止策の実施などは、その後に行えば良い。

やること

概ね以下のようなことをする気がする(足りないことがあれば教えてください)。

概要	詳細
エラー内容の確認	e.g. エラーメッセージの確認・ユーザーからの報告内容の確認。
ユーザー影響の有無の確認	e.g. 対象の機能を実行して、機能自体が提供できているかどうか確認する。
周知(ユーザー影響があれば)	ユーザー影響がある場合は、取り急ぎ Slack 等で社内関係者に周知する。 詳細な情報は後々でいいので、まずはユーザー影響があることを知らせる。
現象の再現確認	同じ操作で再現するかどうか確認する。
ログなどを元に、エラー内容・エラー発生箇所・原因を明確化	エラー内容を起点にして、有用な情報はなにか、仮説を立てながら、発生日時・内容・スタックトレースなどを集める。 ここでの目的は、エラーの内容の把握(What) -> 発生箇所の把握(Where) -> 原因の把握(Why) のように推移していくので、各目的を意識したうえで仮説を立てて調査をする。 闇雲に情報を集めない。 e.g. Sentry などのエラー追跡ツールの出力内容を確認。
エラー発生時にリリースを行っていれば、まずはその変更内容を疑う	e.g. Sentry の場合は、エラーが発生しだしたときのリリースが何かの情報があるので、そこを見るといい。
修正	そのまま。
修正後、再発しないことの確認	そのまま。
再発防止策の策定	もし運用フローなど自体に問題があったのであれば、再発防止策を策定する。

手順

上記の"やること"は、状況に応じて実行順序は変わるため、その場その場で適切な手順は何か、考えながら作業を進めることになると思う。
ただし、動き方の指針はあると感じており、以下のようであると思う。

1. エラー内容の把握
2. ユーザー影響の有無の確認
3. ユーザー影響があれば周知 -> どのような手を使ってもいいのでエラーを解消 / ユーザー影響がなければ4へ
4. 根本解決
5. 再発防止