非機能要求グレードの歩き方 Vol.14 バッチ編-C1通常運用

はじめに - Vol.14

本記事では、IPA^[1] が公開する 非機能要求グレード^[2] の
「C.1 通常運用」に含まれるバッチ処理関連の小項目を対象に、
金融 IT 基盤に 30 年以上携わって得た知見をもとに “やらかしがちな” 技術課題と対策を解説します。

筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含め解説します。

シリーズ全体の構成は 👉 非機能要求グレードの歩き方 Index をご覧ください。

---

C.1 通常運用

中項目「C.1 通常運用」では、監視やバックアップなど定常的に行う運用の要件を定義します。
下表は、大項目「C 運用・保守性」-中項目「C.1 通常運用」を抜粋したものです。

表: 「C.1 通常運用」の小項目とメトリクス（折りたたんでいます）

大項目	中項目	小項目	メトリクス(〇: 重要項目)
C 運用・保守性	C.1 通常運用	C.1.1 運用時間	C.1.1.1 ○ 運用時間（通常） C.1.1.2 ○ 運用時間（特定日）
〃	〃	C.1.2 バックアップ	C.1.2.1 　 データ復旧範囲 C.1.2.2 ○ 外部データの利用可否 C.1.2.3 ○ バックアップ利用範囲 C.1.2.4 ○ バックアップ自動化の範囲 C.1.2.5 ○ バックアップ取得間隔 C.1.2.6 ○ バックアップ保存期間 C.1.2.7 　 バックアップ方式
〃	〃	C.1.3 運用監視	C.1.3.1 ○ 監視情報 C.1.3.2 ○ 監視間隔 C.1.3.3 　 システムレベルの監視 C.1.3.4 　 プロセスレベルの監視 C.1.3.5 　 データベースレベルの監視 C.1.3.6 　 ストレージレベルの監視 C.1.3.7 　 サーバ（ノード）レベルの監視 C.1.3.8 　 端末/ネットワーク機器レベルの監視 C.1.3.9 　 ネットワーク・パケットレベルの監視
〃	〃	C.1.4 時刻同期	C.1.4.1 　 時刻同期設定の範囲

非機能要件は、「小項目」ごとに、文章で「レベル」が分かるよう具体的に記述しましょう！
(再掲、大事なことなので繰り返し言います。詳細Vol.1を参照ください）

以降、小項目ごとに解説します。

C.1.1 運用時間 （オンと同様）

メトリクス内容（折りたたんでいます）

小項目	メトリクス(〇: 重要項目)
C.1.1 運用時間 システム運用を行う時間。利用者やシステム管理者に対してサービスを提供するために、システムを稼動させ、オンライン処理やバッチ処理を実行している時間帯のこと。	C.1.1.1 〇 運用時間（通常） C.1.1.2 〇 運用時間（特定日）

項番 メトリクス	レベル0/1/2/3/4/5 備考
C.1.1.1 〇 運用時間（通常）	0: 規定無し 1: 定時内（9時～17時） 2: 夜間のみ停止（9時～21時） 3: 1時間程度の停止有り（9時～翌朝8時） 4: 若干の停止有り（9時～翌朝8時55分） 5: 24時間無停止 【メトリクス】 運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。 【レベル】 （）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。 規定無しは、固定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定している （例: 障害発生に備えた予備システム、開発・検証用システム等）。 定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。 停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指す。 24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。【重複項目】A.1.1.1。運用時間（通常）は、システムの可用性の実現レベルを表す項目でもあるため、重複項目となっている。
C.1.1.2 〇 運用時間（特定日）	0~5: レベルは A.1.1.1 と同 【メトリクス】 特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義している日のことを指す。 特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必要がある （例：「月～金はレベル2だが、土日はレベル0」、 「通常はレベル5だが、毎月1日にリブートをするためその日はレベル3」など）。 また、ユーザの休日だけでなく、ベンダの休日についても特定日として認識し、運用保守体制等を整合すること。 【重複項目】 A.1.1.2。運用時間（特定日）は、システムの可用性の実現レベルを表す項目でもあるため、重複項目となっている。

• 「C.1.1 運用時間」のメトリクスは、「A.1.1 運用スケジュール」と重複しています。
  そのため、片方の小項目には具体的な内容を記述し、もう片方は参照の記述のみにとどめることを推奨します。

C.1.2 バックアップ

小項目	メトリクス(〇: 重要項目)
C.1.2 バックアップ システムが利用するデータのバックアップに関する項目。	C.1.2.1 　 データ復旧範囲 C.1.2.2 〇 外部データの利用可否 C.1.2.3 〇 バックアップ利用範囲 C.1.2.4 〇 バックアップ自動化の範囲 C.1.2.5 〇 バックアップ取得間隔 C.1.2.6 〇 バックアップ保存期間 C.1.2.7 〇 バックアップ方式

メトリクス内容（折りたたんでいます）

項番 メトリクス	備考の【メトリクス】の抜粋、レベル
C.1.2.1 　 データ復旧範囲	データバックアップ以外に、システムバックアップも必要 0: 復旧不要　1: 一部の必要なデータのみ復旧　2: システム内の全データを復旧 　※一部の必要なデータとは、業務継続性の要求を満たすために必要となるデータ
C.1.2.2 〇 外部データの利用可否	外部データとは、当該システムの範囲外に存在するシステムの保有するデータ 0: 全データの復旧に利用できる 1: 一部のデータ復旧に利用できる　　2: 外部データは利用できない
C.1.2.3 〇 バックアップ 利用範囲	マルウェア等によるデータ損失への備えや、監査のためのログの退避など、セキュリティ観点のバックアップも考慮すること。 0: バックアップを取得しない　　1: 障害発生時のデータ損失防止 2: ユーザエラーからの回復　　　3: データの長期保存（アーカイブ）
C.1.2.4 〇 バックアップ 自動化の範囲	0: 全ステップを手動で行う 1: 一部のステップを手動で行う 2: 全ステップを自動で行う
C.1.2.5 〇 バックアップ 取得間隔	0: バックアップを取得しない 1: システム構成の変更時など、任意のタイミング 2: 月次で取得　　3: 週次で取得　　4: 日次で取得　　5: 同期バックアップ
C.1.2.6 〇 バックアップ 保存期間	主に可用性の観点で実施されるバックアップの世代管理とは別に、 ここではデータ保全という観点でバックアップデータの保存期間を検討する。 0: バックアップを保存しない 1: 1年未満　　2: 3年　　3: 5年　　4: 10年以上有限　　5: 永久保存
C.1.2.7 バックアップ 方式	0: バックアップ無し 1: オフラインバックアップ　※システム（あるいはその一部）を停止させて行う 2: オンラインバックアップ　※システムを稼働中の状態で行う方式 3: オフラインバックアップ+オンラインバックアップ

メトリクス内容：全文（長文です）

項番 メトリクス	レベル0/1/2/3/4/5 備考
C.1.2.1 　 データ復旧範囲	0: 復旧不要 1: 一部の必要なデータのみ復旧 2: システム内の全データを復旧 【メトリクス】 システムを障害から復旧するためには、データバックアップ以外に、 OSやアプリケーションの設定ファイル等を保管するシステムバックアップも 必要となることが考えられる。 システムバックアップの取得方法や保管方法についても、同時に検討すべきである。 【レベル1】 一部の必要なデータとは、業務継続性の要求を満たすために必要となるようなデータを想定している。 【重複項目】A.2.6.2。 可用性ではデータをどこまで保全するかという観点で、運用ではデータをどこまで復旧させるかという観点で本項目が必要となり、重複項目としている。
C.1.2.2 〇 外部データの利用可否	0: 全データの復旧に利用できる 1: 一部のデータ復旧に利用できる 2: 外部データは利用できない 【メトリクス】 外部データとは、当該システムの範囲外に存在するシステムの保有するデータを指す（開発対象のシステムと連携する既存システムなど）。 外部データによりシステムのデータが復旧可能な場合、システムにおいてバックアップ設計を行う必要性が減るため、検討の優先度やレベルを下げて考えることができる。
C.1.2.3 〇 バックアップ 利用範囲	0: バックアップを取得しない 1: 障害発生時のデータ損失防止 2: ユーザエラーからの回復 3: データの長期保存（アーカイブ） 【メトリクス】 マルウェア等によるデータ損失への備えや、監査のためのログの退避など、セキュリティ観点のバックアップも考慮すること。 【レベル2】 ユーザエラーからの回復の場合、システムとしては正常に完了してしまった処理を元に戻さなければならないため、複数世代のバックアップの管理や時間指定回復（Point in Time Recovery）等の機能が必要となる場合が考えられる。
C.1.2.4 〇 バックアップ 自動化の範囲	0: 全ステップを手動で行う 1: 一部のステップを手動で行う 2: 全ステップを自動で行う 【メトリクス】 バックアップ運用には、 　・スケジュールに基づくジョブ起動 　・バックアップ対象の選択 　・バックアップ先の選択 　・ファイル転送 などといった作業ステップが存在する。 【運用コストへの影響】 バックアップ運用の自動化を実現するためには、ハードウェア・ソフトウェアに対する投資が必要となり導入コストは増大する。 しかし、運用中におけるバックアップ作業をユーザが実施する必要がなくなるため、その分運用コストは減少すると考えられる。
C.1.2.5 〇 バックアップ 取得間隔	0: バックアップを取得しない 1: システム構成の変更時など、任意のタイミング 2: 月次で取得　　3: 週次で取得　　4: 日次で取得 5: 同期バックアップ
C.1.2.6 〇 バックアップ 保存期間	0: バックアップを保存しない 1: 1年未満　　2: 3年　　3: 5年　　4: 10年以上有限　　5: 永久保存 【メトリクス】 主に可用性の観点で実施されるバックアップの世代管理とは別に、 ここではデータ保全という観点でバックアップデータの保存期間を検討する。
C.1.2.7 バックアップ 方式	0: バックアップ無し 1: オフラインバックアップ 2: オンラインバックアップ 3: オフラインバックアップ+オンラインバックアップ 【レベル】 オフラインバックアップとは、システム（あるいはその一部）を停止させてバックアップを行う方式、 オンラインバックアップとはシステムを停止せず稼働中の状態でバックアップを行う方式を指す。 【重複項目】A.2.6.1。 バックアップ方式は、システムを停止するかどうかの検討が含まれるため、 可用性の観点でも考慮する必要があり、重複項目となっている。

純バッチとオン中バッチは別物

• オンラインと別に、バッチとしてもバックアップ要件を定める必要があります。
  • 純バッチは、最悪でもバッチ処理開始時点の静止点のバックアップから再処理できるため、比較的単純な復旧設計が可能です。
  • 一方、オン中バッチは、バッチ処理の結果やステータスをオンライン用DBに反映することが多く、ファイルとDBの整合性を考慮してバックアップを取得する必要があります。

オンラインと同様の観点

• なお、オンライン編に記載した以下のポイントは、バッチに対しても必要となります。
  • バックアップ取得対象データごとにバックアップ要件を記述
  • スナップショット機能の活用
  • 📌ランサムウェア対策
• また、バックアップ要件をもとに具体的な方式や取得タイミングを設計する際には、
  通常、リストア時間は、バックアップ時間の2倍強となることを踏まえて、
  RTO（目標復旧時間）と整合性のとれた設計を行う必要があります。
• 参考：
  バックアップ媒体として、それまでのテープ装置に代わり、2010年代よりHDDベースのニアラインストレージが普及していましたが、近年以下の特性が再評価されテープ装置復活の兆しがあります
  • シーケンシャルアクセスはHDDより高速（リワインド時間は必要）
  • 保管コストの安さ（電力効率、体積あたり記憶容量、長期保存）
  • ランサムウェア耐性

C.1.3 運用監視

小項目	メトリクス(〇: 重要項目)
C.1.3 運用監視 システム全体、あるいはそれを構成する ハードウェア・ソフトウェア （業務アプリケーションを含む） に対する監視に関する項目。 セキュリティ監視については本項目には 含めない。 「E.7.1 不正監視」で別途検討すること。	C.1.3.1 〇 監視情報 C.1.3.2 〇 監視間隔 C.1.3.3 　 システムレベルの監視 C.1.3.4 　 プロセスレベルの監視 C.1.3.5 　 データベースレベルの監視 C.1.3.6 　 ストレージレベルの監視 C.1.3.7 　 サーバ（ノード）レベルの監視 C.1.3.8 　 端末/ネットワーク機器レベルの監視 C.1.3.9 　 ネットワーク・パケットレベルの監視

メトリクス内容（折りたたんでいます）

項番 メトリクス	備考の【メトリクス】の抜粋、レベル
C.1.3.1 〇 監視情報	監視とは情報収集を行った結果に応じて適切な宛先に発報すること 発報先は「C.4.5.2 監視システムの有無」 本項目は、監視対象としてどのような情報を発信するべきかを決定する 【レベル】 0: 監視を行わない　　　　 1: 死活監視を行う　　　※対象のステータスがオンラインの状態にあるか 2: エラー監視を行う　　※対象が出力するログ等にエラー出力が含まれているか 3: エラー監視（トレース情報を含む）を行う　※トレース情報を含む場合は、どのモジュールでエラーが発生しているのか詳細についても判断することができる 4: リソース監視を行う　※CPUやメモリ、ディスク、ネットワーク帯域といったリソースの使用状況 5: パフォーマンス監視を行う　※業務アプリケーションやディスク I/O、ネットワーク転送等の応答時間やスループット
C.1.3.2 〇 監視間隔	0: 監視を行わない　　　　　　　　1: 不定期監視（手動監視） 2: 定期監視（1日間隔）　　　　　 3: 定期監視（数時間間隔） 4: リアルタイム監視（分間隔）　　5: リアルタイム監視（秒間隔）
以降のレベルは同じ	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、重要度の高いもののみを対象に監視を行うことを想定
C.1.3.3 システム レベルの監視	業務アプリケーションも含め、そのシステムを構成する複数のサーバ等の状態確認結果から、システムとして機能する状態にあるかどうか バックアップの監視やジョブの監視など
C.1.3.4 プロセス レベルの監視	アプリケーションやミドルウェア等のプロセスが正しく機能しているかどうか プロセスの情報（死活、CPU使用率、メモリ使用率など）
C.1.3.5 データベース レベルの監視	DBMSの機能として提供される情報を確認 ログ出力内容やパラメータ値、ステータス情報、領域使用率等
C.1.3.6 ストレージ レベルの監視	ディスクアレイ等の外部記憶装置に関して、状態を確認 ディスク使用率等の他、ファームウェアが出力するログ情報など
C.1.3.7 サーバ（ノード） レベルの監視	対象のサーバがOSレベルで正しく機能しているか ハートビート監視など
C.1.3.8 端末/ネットワーク機器 レベルの監視	クライアント端末やルータ等のネットワーク機器に関して状態を確認 ハートビート監視の他、個別のファームウェア等が出力する情報に基づく監視など
C.1.3.9 ネットワーク・パケット レベルの監視	ネットワーク上を流れるパケットの情報を確認 パケットロスやネットワーク帯域の使用率などの監視など

メトリクス内容：全文（長文です）

項番 メトリクス	レベル0/1/2/3/4/5 備考
C.1.3.1 〇 監視情報	0: 監視を行わない　　　　1: 死活監視を行う 2: エラー監視を行う　　　3: エラー監視（トレース情報を含む）を行う 4: リソース監視を行う　　5: パフォーマンス監視を行う 【メトリクス】 監視とは情報収集を行った結果に応じて適切な宛先に発報することを意味する。 本項目は、監視対象としてどのような情報を発信するべきかを決定することを目的としている。 また、監視情報の発報先については、「C.4.5.2 監視システムの有無」 で確認すること。 【レベル】 死活監視とは、対象のステータスがオンラインの状態にあるかオフラインの状態にあるかを判断する監視のこと。 エラー監視とは、対象が出力するログ等にエラー出力が含まれているかどうかを判断する監視のこと。トレース情報を含む場合は、どのモジュールでエラーが発生しているのか詳細についても判断することができる。 リソース監視とは、対象が出力するログや別途収集するパフォーマンス情報に基づいてCPUやメモリ、ディスク、ネットワーク帯域といったリソースの使用状況を判断する監視のこと。 パフォーマンス監視とは、対象が出力するログや別途収集するパフォーマンス情報に基づいて、業務アプリケーションやディスク I/O、ネットワーク転送等の応答時間やスループットについて判断する監視のこと。 【運用コストへの影響】 エラー監視やリソース監視、パフォーマンス監視を行うことによって、障害原因の追求が容易となったり、障害を未然に防止できるなど、システムの品質を維持するための運用コストが下がる。
C.1.3.2 〇 監視間隔	0: 監視を行わない　　　　　　　　1: 不定期監視（手動監視） 2: 定期監視（1日間隔）　　　　　 3: 定期監視（数時間間隔） 4: リアルタイム監視（分間隔）　　5: リアルタイム監視（秒間隔）
C.1.3.3 システム レベルの監視	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 【メトリクス】システムレベルの監視とは、 業務アプリケーションも含め、そのシステムを構成する複数のサーバ等の状態確認結果から、システムとして機能する状態にあるかどうかを判断するものである。バックアップの監視やジョブの監視などが該当する。 【レベル】監視を行う場合には、システムレベルについての 監視情報と監視間隔を個別に確認する必要がある。 システムが提供するいくつかの機能のうち、 重要度の高い一部の機能のみを対象に監視を行うことを想定している。
C.1.3.4 プロセス レベルの監視	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 【メトリクス】プロセスレベルの監視とは、 アプリケーションやミドルウェア等のプロセスが正しく機能しているかどうかを判断するものである。 主にOSコマンドによるプロセスの情報（死活、CPU使用率、メモリ使用率など） を監視するものを想定している。 【レベル】監視を行う場合は、プロセスレベルについての 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、システム上で稼動する複数のプロセス（アプリケーションおよびミドルウェア）のうち、 重要度の高い一部のプロセスのみを対象に監視を行うことを想定している。
C.1.3.5 データベース レベルの監視	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 【メトリクス】データベースレベルの監視とは、 DBMSの機能として提供される情報を確認し、正しく機能しているかを判断するものである。 ログ出力内容やパラメータ値、ステータス情報、領域使用率等の監視を想定している。 【レベル】監視を行う場合は、データベースレベルについての 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、システム上で稼動する複数のデータベースのうち、 重要度の高い一部のデータベースのみを対象に監視を行うことを想定している。
C.1.3.6 ストレージ レベルの監視	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 【メトリクス】ストレージレベルの監視とは、 ディスクアレイ等の外部記憶装置に関して、状態を確認し、正しく機能しているかを判断するものである。 OSコマンドによって確認できるディスク使用率等の他、ファームウェアが出力するログ情報などの監視を想定している。 【レベル】監視を行う場合は、ストレージレベルについての 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、システムに接続される複数のストレージのうち、 重要度の高い一部のストレージのみを対象に監視を行うことを想定している。
C.1.3.7 サーバ（ノード） レベルの監視	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 【メトリクス】サーバ（ノード）レベルの監視とは、 対象のサーバがOSレベルで正しく機能しているかを判断するものである。ハートビート監視などが該当する。 【レベル】監視を行う場合は、サーバ（ノード）レベルについての 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、システム上に存在する複数のサーバ（ノード）のうち、 重要度の高い一部のサーバのみを対象に監視を行うことを想定している。
C.1.3.8 端末/ネットワーク機器 レベルの監視	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 【メトリクス】端末/ネットワーク機器レベルの監視とは、 クライアント端末やルータ等のネットワーク機器に関して、状態を確認し、正しく機能しているかを判断するものである。 ハートビート監視の他、個別のファームウェア等が出力する情報に基づく監視などを想定している。 【レベル】監視を行う場合は、端末/ネットワーク機器レベルについての 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、システム上に存在する複数の端末/ネットワーク機器のうち、 重要度の高い一部の端末/ネットワーク機器のみを対象に監視を行うことを想定している。
C.1.3.9 ネットワーク・パケット レベルの監視	0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う 【メトリクス】ネットワーク・パケットレベルの監視とは、 ネットワーク上を流れるパケットの情報を確認し、正しく機能しているかを判断するものである。 パケットロスやネットワーク帯域の使用率などの監視などを想定している。 【レベル】監視を行う場合は、ネットワーク・パケットレベルについての 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、システム上の複数のネットワーク経路のうち、 重要度の高い一部のネットワーク経路のみを対象に監視を行うことを想定している。

すぐに結果が見えないことへの備え

• バッチは、処理直後にその妥当性を即時に把握しにくいという特性を持つため、オンラインと異なる固有の運用監視要件が求められます。
  特に、重要業務では、「期待どおり動いたか？」 を能動的に監視することが必要です。

バッチ処理の監視タイミングと確認ポイント

1. 処理開始前：処理要求件数の異常検知
   • 異常に少ない ⇒ 上流処理の不具合など、処理可能なデータが揃っていない可能性
   • 異常に多い 　⇒ バッチ処理完了時限を超え、問題が後続処理に波及する恐れ
2. 処理途中：処理の進捗状況
   • 複雑なジョブネットでは、複数のチェックポイントを設け、
     各通過時刻や処理件数が設計想定内に収まっているか監視
3. 処理終了後：処理結果の妥当性確認
   • 空振りしていないか（例：0件処理）
   • 件数は正常でも内容が業務的に失敗していないか（エラー多発、実行結果不整合(※)など）
     ※ 金融の業務システムでは、人のようにミスなどしないはずのシステムに対しても、バグやオペミスなどの対策として、異なる観点で集計した数字を突合するなど、けん制機能として整合性検証処理をアプリケーションとして作成するのが一般的です。

オンラインと同様の観点

• なお、メトリクスの観点、およびオンライン編に記載した以下のポイントは、バッチに対しても必要となります。
  • 監視要件の記述
  • 📌閾値は予兆検知とセットで2段階
  • 📌リソース監視は1～5秒間隔

C.1.4 時刻同期（特になし）

メトリクス内容（折りたたんでいます）

小項目	メトリクス(〇: 重要項目)
C.1.4 時刻同期 システムを構成する機器の時刻同期に関する項目。	C.1.3.1 　 時刻同期設定の範囲

項番 メトリクス	レベル0/1/2/3/4/5 備考
C.1.4.1 時刻同期設定の範囲	0: 時刻同期を行わない 1: サーバ機器のみ時刻同期を行う 2: サーバおよびクライアント機器について時刻同期を行う 3: ネットワーク機器も含めシステム全体で時刻同期を行う 4: システム全体を外部の標準時間と同期する 【レベル4】 システム全体を外部の標準時間と同期する場合、外部との接続に異常が発生した場合にシステム内の時刻同期をどうするかといった設計を行う必要がある。 【運用コストへの影響】 時刻同期を行うことで、複数のサーバ機器が出力するログの順序保証が得られるため、障害調査や監査等の作業コストを下げられる可能性がある。

バッチとして特筆すべき事項はありません。
Vol.6 オンライン編-C1通常運用 C.1.4 時刻同期を参照ください。

あったら怖い本当の話

※　実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。

😱言われて気づいても炎上後

• キャンペーン期間中、ポイント管理システムは特に異常なく稼働していました。

コールセンタに、ポイントが「付与されていない」「使えない」といった問い合わせが急増。
SNSでも批判が広まり炎上状態に。

敗因

• 該当ポイントの関連処理を調査したところ、1週間前、オペレーションミスにより、複数ある「ポイント付与ファイル反映」バッチのうち一つのジョブを常駐し忘れていました。
  その結果、当該ファイルに計上されているポイントが付与されていませんでした。
• 未処理ファイルのバッチ処理を実行して復旧したものの、既に悪評が炎上しキャンペーンは逆効果となりました。
• 他のジョブはポイントを反映しており、ジョブの起動漏れのためエラーメッセージも出なかったため、能動的にオペミスに気付くことができませんでした。

再発防止

けん制機能として、上流システムが付与した総ポイント数と、反映した総ポイント数を突合していれば、すぐにジョブ起動し忘れに気付けた　という反省を踏まえて、以下の運用改善を実施しました。

1. 業務運用に 「締め」の概念を導入（まずは日単位の日締め）
2. 日締めのタイミングで、接続する各システム間で、総件数と、ポイント数などの総数の情報を交換し、相互に突合し、齟齬があればアラート発報するようにしました。

補足：
日本の銀行は、毎日、締め上げ てます。（いい意味です）
窓口を閉めたあと、店単位-->全店-->全行 へと段階的に、1円のズレもなく勘定があっていることを確認(御明算)する様を締め上げといいます。
A店が単独に御明算でも、B店が御明算にならない原因がA店の締めミスにある可能性があるため、全行の御明算を確認できるまで、全営業店の行員は帰宅できません。
銀行は信用が命なので、銀行業の事務処理やシステムのあらゆるところにけん制機能を組み込んでいます。

まとめ

本記事では、バッチ処理に関わる通常運用は、バッチ処理直後にその妥当性を把握しづらいことを考慮する必要があることを説明しました。

最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。

[募集要領]
https://nttdata-career.jposting.net/u/job.phtml?job_code=1172
[NTTデータ 金融分野の取り組み]
https://www.nttdata.com/jp/ja/industries/finance/

脚注

1. IPA（独立行政法人 情報処理推進機構, Information-technology Promotion Agency, Japan）

2. 非機能要求グレード:
   参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
   活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の　06‗活用シート.xls