障害対応時は基本的にエラーの情報を見て以下のようなことを考えることになりますが、
- どういうエラーを出すのか
- どのようにエラーを拾うのか
- システム管理者にどのように告知するのか
などはいろいろ議論の余地が分かれるところだと思います。
今までいろいろと書いてきましたが、まとめ系の記事として残しておこうと思っております。
どういうエラーを出すのか
エラーコードやExceptionに関する件ですね。
基本的には誰にどんな情報を伝えるのか、ということが目的になるかと思います。
誰に・・API使用者とシステム運用者
どんな情報・・API使用者に対しては端的でわかりやすい情報。システム運用者に対しては障害の詳細な情報です。
- エラーの内容がコードに対して適当である。
- 観点としては、その情報をみただけで、どの問題が特定できる(コード値:E0001など)があることが望ましい。問い合わせた時に、これがあるとすぐにわかるため
- 使用者に必要な情報が完結に提供されている(「在庫が不足しています」など)
- 逆に詳細すぎるシステムの情報などは当然画面に出さない → この情報はログやエラーリポーティングサービスなどで拾う必要がある
ちなみに開発時に複数のベンダーが入り乱れる場合があり、詳細な情報をあえて出したほうがよいかも・・・などと思いました。
どのようにエラーを拾うのか
主に障害対応のエラーの抽出ですね。
生ログ、ログサービス(cloud watch)、Sentryみたいなレポーティングサービスなどに分類されるかだと思います。
どれも経験あるんですが、個人的にはSentryだけだと限界があるので、Sentryをメインにしつつ、cloudwatchみたいなログサービスを併用していくってことになるのがいいんではないかと思います。
エラーでてないんだけど、なんかおかしい・・みたいな挙動をする時がちょくちょくあってそういうときは生ログをどうしても見ていくことにならざるをえないとおもいます。
システム管理者にどのように告知するか
エラーが発生した時ですが、第一段階としてどのエラーを告知するのか、が大事になってきます。
ログレベルの切り分けにもなってくるとおもいますが、
正常系ではないけれど、原因がユーザー自信が自覚できるものなので、告知をしなくてよいものもあると思います。(代表的なものとして画面のバリデーションなど)
完全な異常系・・ようは500などで完全な異常系ですね。単純なExceptionになり、プログラムのエラーなどになります。あるいはおこりえないデータ不備系ですかね。これは最優先で告知する必要があるでしょう。
完全な異常系をどのようにしらせるかですが、
メール、slack、backlog、生ログとしてerrorのものをはく・・・なんでもあるかと思います。
開発側がそれをみることが習慣になっているものですね。今の時代(2023年9月現在)だとslackが多いのかなあ・・と思います。
