skillup

技術ブログ

アーキテクト設計全般

エラーの告知や収集、通知などについて

投稿日:

障害対応時は基本的にエラーの情報を見て以下のようなことを考えることになりますが、

  • どういうエラーを出すのか
  • どのようにエラーを拾うのか
  • システム管理者にどのように告知するのか

などはいろいろ議論の余地が分かれるところだと思います。

今までいろいろと書いてきましたが、まとめ系の記事として残しておこうと思っております。

どういうエラーを出すのか

エラーコードやExceptionに関する件ですね。

基本的には誰にどんな情報を伝えるのか、ということが目的になるかと思います。

誰に・・API使用者とシステム運用者

どんな情報・・API使用者に対しては端的でわかりやすい情報。システム運用者に対しては障害の詳細な情報です。

  • エラーの内容がコードに対して適当である。
  • 観点としては、その情報をみただけで、どの問題が特定できる(コード値:E0001など)があることが望ましい。問い合わせた時に、これがあるとすぐにわかるため
  • 使用者に必要な情報が完結に提供されている(「在庫が不足しています」など)
  • 逆に詳細すぎるシステムの情報などは当然画面に出さない → この情報はログやエラーリポーティングサービスなどで拾う必要がある

ユーザーに見せるエラーメッセージに関する考察

APIのエラーコードに関して

ちなみに開発時に複数のベンダーが入り乱れる場合があり、詳細な情報をあえて出したほうがよいかも・・・などと思いました。

どのようにエラーを拾うのか

主に障害対応のエラーの抽出ですね。

生ログ、ログサービス(cloud watch)、Sentryみたいなレポーティングサービスなどに分類されるかだと思います。

ログ対策(どのように情報を抽出するか)

どれも経験あるんですが、個人的にはSentryだけだと限界があるので、Sentryをメインにしつつ、cloudwatchみたいなログサービスを併用していくってことになるのがいいんではないかと思います。

エラーでてないんだけど、なんかおかしい・・みたいな挙動をする時がちょくちょくあってそういうときは生ログをどうしても見ていくことにならざるをえないとおもいます。

システム管理者にどのように告知するか

エラーが発生した時ですが、第一段階としてどのエラーを告知するのか、が大事になってきます。

ログレベルの切り分けにもなってくるとおもいますが、

正常系ではないけれど、原因がユーザー自信が自覚できるものなので、告知をしなくてよいものもあると思います。(代表的なものとして画面のバリデーションなど)

完全な異常系・・ようは500などで完全な異常系ですね。単純なExceptionになり、プログラムのエラーなどになります。あるいはおこりえないデータ不備系ですかね。これは最優先で告知する必要があるでしょう。

完全な異常系をどのようにしらせるかですが、

メール、slack、backlog、生ログとしてerrorのものをはく・・・なんでもあるかと思います。

開発側がそれをみることが習慣になっているものですね。今の時代(2023年9月現在)だとslackが多いのかなあ・・と思います。

-アーキテクト設計全般
-,

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

no image

デザインパターンの使い所

昔からデザインパターンは勉強しておりましたが、使い所などで悩むことが多かったです。 現在の現場でいろいろなパターンを見させていただき、なんとなくではありますが使い所がわかったので、まとめてみようと思い …

no image

オブジェクト指向について その3

今回は場合分けによる変更コストとオブジェクト指向のメリットについてです。 例えば給付金が発生して、その金額を死亡時、退職時、通常時で場合分けするとき、if-elseで書けば下記のようになります。 [c …

no image

キャッシュの使い所とメリデメに関して(主に一覧系の処理に関して)

現在のプロジェクトがかなりの規模のECサイトになるため、正確性とパフォーマンスのトレードオフなどが先日議題にあがりました。 完全なトレードオフではないのかもしれませんが、比較的あちらをたてればこちらが …

no image

オブジェクト指向 アプリケーション層に関して

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にアプリケーション層(以下AP層)。MVCモデルでいうところのコントローラーに近い?)の考え方について。 Contents1 …

no image

DIについての再考察

DIに関しては今までも何度か触れましたが、最終的には環境の差異を吸収できるなどが一番のポイントかと。 サンプルソース https://github.com/umanari145/effector 上記 …

アーカイブ