運用中のエラーをすべて開発へ渡さなかった――保守運用で直す問題と維持開発へ依頼する問題の分け方
システム運用中にエラーを検知しても、すべてを開発チームへ調査依頼していたわけではありません。
私が携わったプロジェクトでは、まず保守運用側が監視ログを確認していました。ログの内容から原因と対応方法を判断できる場合は、保守運用側で対応しました。一方、機能内部の処理エラーなど、ログだけでは判断できない問題は、サーバーから取得したログやデータを添えて維持開発側へ調査を依頼していました。
例えば、CPU負荷などの環境要因によるエラーで、バッチの起動スケジュールを変更することで対応できる場合があります。その場合は、保守運用側で仕様書を変更し、本番環境へリリースしていました。
前回は、本番移行後に月次の重要バッチまでログを重点監視し、監視時間超過と処理失敗を分けて判断した経験を紹介しました。
今回は、運用中に検知したエラーについて、保守運用側で対応する問題と、維持開発側へ調査を依頼する問題をどのように分けていたのかを紹介します。
エラーをすべて維持開発へ渡していたわけではない
監視ログにエラーが出るたびに、すべてを維持開発側へ渡していたわけではありません。
保守運用側で確認できる情報から原因と対応方法を判断できる場合は、そのまま保守運用側で対応していました。
ここでいう維持開発側とは、運用開始後も、機能内部の調査やプログラム改修などを担当するチームです。
保守運用と維持開発の担当範囲を分けることは必要ですが、エラーの種類を確認する前から、機械的に担当を決めていたわけではありません。まず保守運用側でログを確認し、その結果に応じて対応先を判断していました。
最初に保守運用側で監視ログを確認した
エラーを検知したときは、保守運用側で監視ログの内容を確認していました。
ログだけで原因と対応方法を判断できるエラーであれば、保守運用側で対応します。
一方、ログだけでは機能内部で何が起きたのか分からない場合や、プログラムの処理を調査する必要がある場合は、維持開発側へ依頼します。
このように、担当部署へ振り分ける前に、保守運用側が一次確認を行っていました。
※監視ログを起点に、保守運用側で対応できる問題と、ログやデータを添えて維持開発側へ依頼する問題に分ける流れを示すイメージです。
環境要因は保守運用側で対応した
保守運用側で対応できる例として、CPU負荷などの環境要因によるエラーがありました。
複数のバッチが同じ時間帯に動くことで負荷が高くなっている場合など、バッチの起動スケジュールを変更することで対応できることがあります。
そのような場合は、保守運用側でバッチの起動スケジュールを見直していました。
必要な変更について仕様書を修正し、本番環境へリリースするところまで保守運用側で対応していました。
ただし、CPU負荷による問題なら、どの案件でも起動スケジュールの変更だけで解決できるという意味ではありません。ここで扱っているのは、保守運用側で原因と変更内容を判断できた事例です。
機能の処理エラーは維持開発側へ依頼した
機能内部の処理エラーが発生した場合は、維持開発側へ調査を依頼していました。
この場合も、エラーが出たという連絡だけを送るのではありません。
保守運用側で監視ログを確認し、サーバーから調査に必要なログやデータを取得していました。それらを維持開発側へ渡し、機能内部で何が起きたのかを調査してもらいます。
保守運用側で分かる範囲を先に確認し、調査材料を揃えてから依頼することで、維持開発側が調査を始められる状態にしていました。
障害票を起票して調査履歴を残した
維持開発側へ問い合わせる場合は、障害票を起票していました。
障害票は、RedmineなどのWebアプリケーションでチケットとして管理していました。
チケットには、エラーの発生と調査依頼を記録し、その後の調査や対応の履歴を残します。
口頭やメールだけで調査を依頼すると、その場では早く伝えられても、後から経緯を確認しにくくなります。通常の調査依頼はチケットとして残すことで、保守運用側と維持開発側の間で対応状況を共有していました。
緊急時はチケットに加えて一斉メールを送った
緊急度が高い問題では、障害票を起票するだけではありませんでした。
上位の管理職などへ一斉メールを送り、緊急対応が必要なことを知らせていました。
ここでも、メールだけに切り替えて履歴を残さない運用にはしていません。障害票で調査と対応の履歴を残しながら、一斉メールで緊急性を共有していました。
チケットは調査履歴と対応状況を管理するために使い、メールは緊急度の高い問題を関係者へ速やかに知らせるために使っていました。
※通常時は障害票で履歴を残し、緊急時は障害票に加えて管理職などへ一斉メールを送る使い分けを示すイメージです。
担当を分けても調査情報を分断しなかった
保守運用側と維持開発側には、それぞれ異なる役割があります。
保守運用側は、監視ログを確認し、自分たちで対応できる問題か、機能内部の調査が必要な問題かを一次判断します。
維持開発側へ依頼する場合は、サーバーから取得したログやデータを渡し、障害票で調査履歴を残します。緊急時には、一斉メールで管理職などにも状況を知らせます。
担当を分けることは、情報を分断することではありません。誰が調査する場合でも、エラーの内容、調査材料、対応履歴をつなげておく必要がありました。
まとめ
運用中にエラーを検知しても、すべてを維持開発側へ渡していたわけではありません。
保守運用側で監視ログを確認し、ログから原因と対応方法を判断できる場合は、保守運用側で対応していました。CPU負荷などの環境要因に対して、バッチの起動スケジュールを変更できる場合は、仕様書の変更と本番リリースまで行っていました。
機能内部の処理エラーなど、ログだけでは判断できない問題は、サーバーから取得したログやデータを添えて維持開発側へ調査を依頼していました。
調査依頼はRedmineなどで障害票を起票し、履歴を残しました。緊急度が高い場合は、それに加えて上位の管理職などへ一斉メールを送りました。
保守運用と維持開発の役割を分けるときは、エラーの発生だけで担当を決めるのではなく、まず確認できる情報から切り分けることが必要でした。また、担当が変わっても、調査材料と対応履歴が途切れないようにしていました。
次の記事：