良いアラートメッセージについて考える

はじめに

最近、「システム設計アンチパターン」という書籍を読みました。

https://www.oreilly.co.jp/books/9784873119847/

タイトル通り、アンチパターンが数多く紹介されており、とても勉強になりました。

今回は、書籍の「6章 アラート疲れ」という箇所をもとに、実務でどんなアラートメッセージを出力すれば良いか、について述べていきます。

結論

良いアラートメッセージは、以下のような特徴があります。

• なぜそのアラートがあがったかが明記されている
• 次にどうすればいいかが明記されている

加えて、アラートメッセージは必要なものだけ出力することも大切です。

詳細

なぜ、「なぜそのアラートがあがったか」という情報が必要なのでしょうか？

それは、実際にアラートを見た人が、どこをどう調査すれば良いかという道しるべになるからです。

また、「次にどうすればいいか」を明記することで、アラートを見た人が次のアクションをすぐに実行でき、アプリケーションの障害などを予防できます。

そして、「必要なものだけ出力する」ことを意識しましょう。

みなさまも、不要な情報をだらだらと流すアラートを見たことがあると思います。

そのアラートに対して、どういう対応をしますか？

ミュートしませんか？

人は、不要な情報に長くさらされると、感覚が麻痺してしまいます。

アラートも同様です。

必要な時にだけ出力するからこそ、アラートとして機能するのです。

実例

では、以上を踏まえて、アラートを設計してみます。

今回は、以下の仕様のアラートを出したいとします。

バッチの処理実行時間が15分を超えたらエラーログを出力する

みなさまなら、どのようなメッセージを出力しますか？

まずは悪い例からです。

悪い例

バッチの処理実行時間が15分を超えました

これは、悪いメッセージです。

なぜなら、「15分を超えたからなんなのか？」「なにか対処する必要があるのか？」といった情報が得られないためです。

次に、良い例を見てみましょう。

良い例

バッチの処理実行時間が15分を超えました。
このメッセージを開発チームへと共有してください。

これであれば、見た人は「ああ、開発チームへと共有すれば良いんだな！」とすぐにわかるので、即座に行動へと移ることができます！

終わりに

今回は、「システム設計アンチパターン」の「6章 アラート疲れ」に関連してアラートの設計についてお伝えしました。

私も実務でこの考え方を取り入れてみたところ、「メッセージがわかりやすくて助かる！」という感謝の言葉をいただきました。

他にもDevOpsに関するあれこれが記載されており、おすすめの書籍です！

ぜひお手に取っていただければと思います。

https://www.oreilly.co.jp/books/9784873119847/

それでは。