AS400 / IBM iの運用改善では、「障害が起きたか」だけでなく、「どれだけ早く気づき、どれだけ早く切り分け、再発を減らせたか」を見ることが大切です。障害検知のKPIを決めておくと、保守会議や改善要望の優先順位を決めやすくなります。
AS400は安定しているからこそ、障害が少ない時期に検知と初動を整えるべきです。夜間バッチ、MSGW、QSYSOPR、帳票、外部連携、バックアップを定量的に見ておくと、属人化した運用から抜け出しやすくなります。
見るべきKPI
| KPI | 意味 | 改善の方向 |
|---|---|---|
| 検知時間 | 異常発生から気づくまでの時間 | MSGW・バッチ監視を強化する |
| 通知時間 | 担当者へ連絡されるまでの時間 | メール通知や連絡ルールを整える |
| 一次切り分け時間 | 原因候補を絞るまでの時間 | ジョブログ、メッセージID、手順書を整備する |
| 復旧時間 | 業務再開までの時間 | 再実行、切戻し、復元手順を決める |
| 再発件数 | 同じ原因の障害が繰り返される件数 | 恒久対応とテスト観点を強化する |
| 手作業対応件数 | 人の判断や補正が必要だった件数 | 自動化・資料化・教育の対象にする |
KPIを保守会議で使う
KPIは、責任追及のためではなく改善のために使います。検知が遅いなら監視、切り分けが遅いなら手順書、復旧が遅いなら再実行や復元、再発が多いなら恒久対応を見直します。
- 今月のMSGW件数
- 夜間バッチ遅延件数
- 本番アベンド件数
- 平均検知時間と最大検知時間
- 再発障害と未完了の対策
- AIやテンプレートで短縮できた調査時間
月次の確認は AS400保守会議の月次アジェンダ、日次監視は AS400日次運用監視チェックリストも参考にしてください。
再発防止に必要な記録
- 障害発生日と検知時刻
- メッセージIDとジョブログ
- 業務影響と対象部門
- 一次対応と復旧手順
- 原因と恒久対応
- 次回同じ障害が起きた時の確認手順
障害報告書の形に残す場合は AS400障害報告書テンプレート、MSGW・夜間バッチ検知は AS400 MSGW・夜間バッチ停止を早期検知する設計も確認してください。
まとめ
AS400障害検知のKPIは、検知時間、通知時間、一次切り分け時間、復旧時間、再発件数、手作業対応件数を見ると整理しやすくなります。数字で見ることで、監視、手順書、教育、AI活用の改善対象がはっきりします。
障害検知KPIは件数より時間を見る
AS400運用で見るべきKPIは、障害件数だけではありません。検知までの時間、担当者へ届くまでの時間、初動判断までの時間、復旧までの時間、再発防止が完了するまでの時間を見ると、監視や保守体制の弱点が見えます。
夜間バッチやMSGWは、朝まで気づけないことが一番危険です。自前通知、監視サービス、月次会議、Codexによるジョブログ整理を組み合わせて、調査時間を減らしながら復旧判断を早くすることが重要です。
KPIは数字を増やすより、気づくタイミングを見る
AS400の障害検知では、件数だけを追うと現場改善につながりにくいです。大事なのは、異常に気づいた時刻、業務影響を判断した時刻、復旧した時刻、再発防止を決めた時刻です。夜間バッチや締め処理では、検知が30分遅れるだけで朝の業務に影響します。
- 発生から検知までの時間
- 検知から一次判断までの時間
- 一次判断から復旧までの時間
- 同じ種類の障害が再発した回数
- 属人対応になった件数
KPIの開始・終了時点をそろえる例
同じMTTRでも、検知から復旧までを測る人と、対応開始からジョブ再開までを測る人が混在すると比較できません。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 検知時間 | 最初の異常発生から監視通知まで | 通知遅延と監視漏れを評価する |
| 着手時間 | 通知から担当者が確認を開始するまで | 当番・連絡経路の遅れを評価する |
| 復旧時間 | 確認開始から業務再開と照合完了まで | ジョブ終了だけでなく業務側の復旧を含める |
同一障害から大量のメッセージが出た場合は、通知件数ではなく一つのインシデントとして数える基準を決めます。KPIは担当者を責める数字ではなく、監視と手順を改善するために使います。