LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

監視の画面には何も出ていないのに、利用者から「つながらない」と連絡が来る。容量の残りに誰も気づかないまま、ある日システムが不安定になる——。運用保守の現場では、こうしたことが起こり得ます。運用保守の監視設計とは、システムの何を監視し、異常を知らせる通知を誰が受け、受けた後にどう直すかを、あらかじめ決めておくことを指します。

本記事では、IPA（情報処理推進機構）の「情報処理システム高信頼化教訓集（ITサービス編）」から監視に関わる4つの教訓を取り上げ、運用保守の監視設計に開発要員として専門人材を加えるときに決めることを整理します。扱うのは、運用の責任ごと外部に委託する形ではなく、社内の運用チームに専門人材が参画する形です。運用の責任と最終的な判断は社内に残します。

運用保守の監視設計とは

監視設計で決めるものは、大きく3つです。1つ目は監視の対象で、サーバーが動いているか、資源の残りはどれくらいか、処理にかかる時間は平常どおりか、といった見る観点です。2つ目は通知の受け手で、異常を知らせる通知を誰がどの手段で受け取るかです。3つ目は見直しで、しきい値（通知を出す境目の値）を誰がいつ見直すかです。

手がかりにする教訓集は、社会に影響を与えたシステムの障害事例を分析し、そこから導いた教訓をまとめたものです。IPAによると、この事業は2013〜2019年度に実施され、教訓集は2019年3月15日に公開されました。^*5 各教訓は、問題、原因、対策、効果、教訓の順に書かれています。

使うのは4つの教訓です。G17は装置のアラートに頼らない監視と通知の受け手、T8は資源の監視、T32は処理時間の監視、G12はしきい値の見直しを扱っています。

開発要員に加わってもらう理由

監視の項目を決めるには、システムがどう作られ、どこで詰まりやすいかを知っている必要があります。教訓T8の事例では、運用担当者は従来のIT管理業務の経験は長いものの、仮想サーバーの管理は初めてで、経験と教育の不足から障害を素早く復旧させることができませんでした。^*2 新しい基盤や作り込んだ処理を監視するとき、中身を知る開発要員が加わる意味はここにあります。

ただし、本記事で扱うのは運用の責任ごと委託する形ではありません。社内の運用チームに専門人材が参画し、監視の項目やしきい値の案を出し、通知を受けた後の切り分けを手伝う形です。どの通知を誰が受けるか、業務を止めるかどうか、しきい値をいくつにするかは、社内の担当者が決めます。

開発要員に頼みやすいのは、監視の項目の洗い出し、しきい値の初めの案、平常時の値の調べ、通知を受けた後の手順の下書きです。手順書に書く項目の全体は運用保守の障害対応手順整備にまとめました。

装置のアラートだけに頼らない

教訓G17のA社のBサービスは、本社で作成・編集した情報を、通信回線を通じて全国のグループ企業の関連部署へ配信するシステムです。重要な情報は帯域制御装置で優先して届け、最重要レベルの情報は二重化した装置のうち#1にだけ流れる運用でした。

ある日、装置のソフトウェアのライセンス更新作業の直後に、利用者から通信ができないという連絡が入りました。一部の拠点で最重要レベルの情報が届かなくなっていましたが、装置からアラートは出ておらず、それ以外の情報は正常に配信されていました。そのため運用管理担当者は故障に気づくのが遅れ、約30分にわたって通信の断絶が続きました。^*1

A社が対策の一つとしたのは、装置本体のアラートだけでは検知できない場合に備え、データ流量の下限しきい値監視など、他の機能や周辺の機材を使って代わりのアラートを出す仕組みでした。^*1 「止まった」ではなく「流れる量が減った」を見る考え方です。

開発要員に頼むなら、ここで出てくるのは「この処理が正常なら、何がどれくらい流れているはずか」という問いです。送信の件数、処理したレコードの数、ログの出力量など、平常時の量を知っている人でなければ下限は決められません。応答の遅れが監視に出なかった事例は外部エンジニアのAPIタイムアウト調査で取り上げました。

資源の残りを見る監視

教訓T8のA社のシステム部門は、プライベートクラウドの運用をしていました。共有ストレージの論理ボリューム#1の空きが突然なくなり、そこを使う仮想サーバーグループの全サーバーの動作が不安定になりました。不要なサーバーを削除して一時的に戻ったものの、削除したサーバーのスナップショットが大量に出力され、再び空きが足りなくなりました。正常に向かったのは障害の発生から6時間後で、削除したサーバー上の3業務は24時間にわたり正常に稼働できませんでした。^*2

直接の原因は移行作業での割り当ての誤りでしたが、教訓集は、運用担当者がリソース監視をきちんと行っていなかった点も挙げています。根本原因は、仮想化に移っても運用の要であるリソース管理や性能監視が重要だと理解していなかったことだとしています。

A社は緊急の対策として、スナップショットの世代数を7世代から3世代に減らし、論理ボリュームのしきい値と監視の方法も見直しました。再発防止としては、移行のときに業務部門から要件を聞き、同じ要件のサーバーをまとめたグループの単位で資源と性能を見積もる手順を作っています。^*2

監視設計に引き寄せると、容量の監視は「今どれだけ使っているか」だけでなく、「何が増えると減るか」まで押さえる必要があります。スナップショットやログのように、作業や障害の対応そのもので増えるものもあり、それを挙げやすいのは作りを知る開発要員です。

処理にかかる時間の変化を見る

教訓T32は、物流センターの制御システムの事例です。同期して動く多数のPLC（自動機械の制御に使う装置）で構成され、新型と旧型が混在していました。ネットワークの障害から復旧した後、運転を再開するための「再稼働初期設定」機能を実行したところ、旧型の制御装置がハングアップし、制御システムの復旧が大幅に遅れました。

原因は、旧型の装置で、1サイクル当たり0.5秒の周期処理が時間内に終わらず、後続の処理が次々と滞留したことでした。この機能は障害時にだけ使うもので、長年実行されていませんでした。その間に機器が増え、流れるデータも増えていましたが、その変化に気づかないまま、障害マニュアルには使うツールとして載っていました。^*3

A社は対策として、周期処理の周期時間を管理し、それを超える場合がないかを適宜監視する管理ルールを定めました。前の処理が終わらないまま時間を過ぎたら、処理をせずに終了して結果を監視に知らせる仕組みも検討しています。教訓集は、周期時間は制限値と同様に変化を見逃さない管理方法が必要だとしています。^*3

事例は制御システムですが、夜間のバッチや定期的に動く連携の処理にも同じ見方が使えます（この記事の考え方）。毎回の所要時間を記録し、決めた時間に近づいたら知らせる形です。めったに使わない障害時の手順ほど、データが増えた今の環境で動くかを開発要員に確かめてもらう価値があります。

通知を誰が受けるか

教訓G17に戻ると、対応が遅れた原因は監視の仕組みだけではありませんでした。最初に障害に気づいたのはシステムを使う業務担当者でしたが、その時点では業務担当者から運用管理担当者への連絡ルートが確立しておらず、初動の遅れの一因になりました。

A社は、重要なサービスについて、迅速に運用管理担当者へ連絡が入るよう、通常とは別の連絡系統を設けました。すべての保守作業の項目（約100件）を抜き出し、影響するサービスの重要度に応じて連絡の要・不要を分類して関連部署と共有し、重要なサービスへの作業は、実績があっても関連部署へ連絡するルールにしています。教訓集は、アラートの通知がメールで届く流れだった点について、電話による緊急連絡の手段と体制を加えておくべきだったとも書いています。^*1

受け手は、サービスの重要度ごとに通知の宛先と手段、届いたことの確かめ方を表にしておくと迷いません。下の表は事例をもとに役割を分けたものです。

開発要員を通知の受け手に入れるかどうかは、契約と提供範囲で確かめる事柄です。夜間や休日に連絡を受けるか、どの時間帯に応じるかは、前提として置かずに先に確認します。障害に気づいた直後の連絡の流れは開発要員の初動で扱っています。

しきい値を決めて見直す

教訓G12は、キャパシティ管理についてのある企業の取り組みを紹介しています。A社のシステムでは、ある日、処理能力を超えた注文が殺到し、サービスの時間が短縮されました。

対策の中心は役割の分担です。システムごとに責任を持つ業務部門を決め、業務部門がオーナーとして業務量とキャパシティの管理に責任を持ち、システム部門と連携します。そのうえで、システムごとに管理項目とそれぞれのしきい値を設定し、拡張の方法や限界を明らかにし、月次のPDCAサイクルでキャパシティの月次報告を両部門が確かめる形にしました。

しきい値の決め方として、教訓集は突発的な増加に備え、過去の実績で最も多かった量の2倍のキャパシティを確保する、といったルールを例に挙げています。^*4 数字はA社の例で、どのシステムにも当てはまるわけではありません。大事なのは、根拠となる実績と、誰が決めたかを残しておくことです。

開発要員には、過去の実績の集計や、項目ごとの値の推移の整理を頼めます。しきい値をいくつにするか、増強に踏み切るかは、業務の見通しを持つ社内の部門が決めます。教訓集も、システムをシステム側の目だけで見て運用してはいけないとしています。

専門人材に参画を頼む前の確認

監視設計に開発要員として専門人材に加わってもらうなら、頼む範囲を先に書き出します。たとえば、監視の項目とその理由の一覧、項目ごとのしきい値の案と根拠、平常時の値の記録、通知を受けた後の切り分けの手順の4つを成果物にする形です。運用の作業そのものを引き受けてもらうわけではないことも、最初に共有しておきます。

あわせて、本番の環境でどこまで見てよいか、監視の設定を変えてよいかを決めます。案は開発要員が出し、設定の変更は社内の担当者が行う形にしておくと、記録が社内に残ります。運用保守の分担を会社の規模からどう考えるかは運用保守の開発要員の社内・外部分担で扱いました。

ここまで書き出せれば、監視する基盤や処理の中身を知っていることなど、求める経験もはっきりします。

まとめ：運用保守の監視設計で決めておく4つのこと

運用保守の監視設計に開発要員を加えるとき、決めておきたいことは4つです。第一に、止まったかどうかだけでなく、流れる量の減り方、資源の残り、処理にかかる時間の伸びを監視の対象に入れること。第二に、サービスの重要度ごとに通知の宛先と手段を決め、利用部門から運用担当者へ伝わる道筋を作ること。第三に、管理項目としきい値を決め、実績を定期的に確かめ、機器やデータが増えたときに見直すこと。第四に、開発要員に頼む範囲を監視の項目やしきい値の案と切り分けの手順にとどめ、しきい値の決定と業務を止める判断は社内に残すことです。監視の中身を知る人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」2.17 重要サービスの運用に関する教訓（G17）（PDF）（https://www.ipa.go.jp/archive/files/000062029.pdf）。出典：問題（Bサービスの構成と障害の経緯・約30分の通信断絶）、原因（対応が遅れた原因①〜④）、対策（代替アラート・別の連絡系統・保守作業約100件の分類・作業連絡のルール化）、教訓を参照（確認日2026年10月5日）（2026年10月確認）
2. *2　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.8 仮想化時の運用管理に関する教訓（T8）（PDF）（https://www.ipa.go.jp/archive/files/000049544.pdf）。出典：問題（論理ボリュームの容量不足と6時間・24時間の影響）、原因（リソース監視の不足と根本原因）、対策（スナップショット世代数7→3ほか・再発防止のプロセス）を参照（確認日2026年10月5日）（2026年10月確認）
3. *3　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.32 周期起動を持つシステムに関する教訓（T32）（PDF）（https://www.ipa.go.jp/archive/files/000072041.pdf）。出典：問題（再稼働初期設定機能の実行とハングアップ）、原因（1サイクル0.5秒の周期処理の滞留・根本原因）、対策⑴周期時間管理、教訓を参照（確認日2026年10月5日）（2026年10月確認）
4. *4　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」2.12 キャパシティ管理のマネジメントに関する教訓（その1）（G12）（PDF）（https://www.ipa.go.jp/archive/files/000051349.pdf）。出典：問題、原因、対策①〜④（業務部門のオーナー化・実績の2倍を確保するルール例・管理項目としきい値・月次のPDCA）、教訓を参照（確認日2026年10月5日）（2026年10月確認）
5. *5　参考：IPA「情報処理システム高信頼化教訓のリンク集（ITサービス編）」（アーカイブ）（https://www.ipa.go.jp/archive/digital/iot-en-ci/system/lesson.html）。出典：事業の実施期間（2013〜2019年度）、教訓集（ITサービス編）の公開日（2019年3月15日）、教訓一覧を参照（確認日2026年10月5日）（2026年10月確認）

Tweet