検索
連載

キーワードは「モニタリング漏れ」「オオカミ少年」 リリース後の運用課題をリクルートはどう解決したかリクルート事例に見るエンジニアとしての価値の高め方(5)(2/2 ページ)

リクルートでの新規プロダクト開発事例からエンジニアとしての価値の高め方を探る本連載。5回目となる今回は「モニタリング」にフォーカスし、機能追加や他サービスとの連携で見つかったモニタリングの課題とその改善策について解説する。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

課題2.エラー通知の「オオカミ少年」化と対応の属人化

 エンハンスフェーズにおけるモニタリングにおいて、もう1つ大きな課題となったのが「エラー通知」です。

エラー通知のオオカミ少年化

 前述したように、エラーや障害が発生した場合にはSlackや電話で担当者に通知が飛ぶような仕組みになっています。それはいいのですが、リリース後のエンハンスフェーズに入ると、特に対応しなくてもいい、もしくは課題として認識しているので毎回通知する必要ないといった「優先度の低いエラー通知」が増えたのです。数多くの通知が届き、本来確認すべきエラーログが埋もれてしまうといったことが頻発しました。さらに、いわゆる「オオカミ少年の話」のように、メンバーの危機感が薄れ見逃してはならないエラーを見過ごしてしまうような状況に陥っていました。

エラー対応の属人化

 もう1つの問題はエラー対応の属人化です。エラーに対応するためには、システムの構成や機能の仕様などの情報を把握していなければなりませんが、時間の経過とともにその量は増えます。特にエンハンスフェーズに入った後はさまざまな機能が追加されるため、リリース当初の機能だけでなく、追加された機能も含めた全体像を把握する必要があります。

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る