すべて開く

第２節 システム統合・更改に伴い発生したシステム障害

1.メモリ領域不足に起因した為替取引不可

＜業態＞
資金清算機関

＜事象１＞

システム更改によるOSの非互換対応17において、テーブル生成プログラムの考慮漏れによるメモリ領域不足に起因して、テーブル更新作業過程でテーブルの内容が一部破損したことにより、移行後初日の営業日にシステムがダウンして移行対象の加盟行との間における為替取引が行えなかった。

＜原因１＞

外部委託先のレビュー体制及び試験内容の確認が不十分であった。

再委託先の人員体制やスキル習熟状況を把握しておらず、システム開発に関する外部委託先全体の業務遂行能力の評価・検証を十分に実施していなかった。

＜対策１＞

外部委託先の開発時の各工程におけるレビュー体制の適切性確認及び試験内容の十分性確認の実施

再委託先を含む外部委託先に対する業務遂行能力の評価・検証の実施

＜事象２＞

障害復旧対応に時間を要し、障害発生日当日にシステムを復旧させることができなかった。 また、代替手段による処理を円滑に行うことができなかった。

＜原因２＞

システムの移行に関して、リスクに応じた移行方法（両センター同時移行）・移行時期（移行対象銀行・移行時期分散、繁忙日・連休明け）の妥当性検証が不十分であった。

障害復旧対応において、復旧に係る暫定対処の適切性の判断や復旧対応に係るタイムマネジメントが不十分であった。

本プロジェクトのリスクを想定した固有のBCPが未整備であった。

BCPの発動基準や代替手段を実施する際の具体的なルール や手順 が未整備であった。

BCPに基づく訓練が不足しており、BCPの実効性（障害復旧対応に係る作業等の所要時間、加盟銀行ごとのBCPに係る習熟度等）の把握・検証を実施しておらず、BCPの実効性を確保していなかった。

大規模障害発生時の対外告知等の対応事項の整備が不十分であった。また、大規模障害時の対応体制等も明確にされていなかった。

平時からの実践的な訓練も不足しており、障害対応力が不十分であった。

＜対策２＞

両センター同時障害発生等のリスクや加盟金融機関の影響を踏まえた適切な移行方法・時期の検討方法に関するマニュアルの整備

障害復旧対応における優先順位の整備、復旧方法の決定に当たっての複数プランの比較検討及び適切なタイムマネジメントの実施方法に関するマニュアルの整備

システム開発案件の特性を踏まえたプロジェクト固有のBCP整備

平時からの備えとしてのBCP・代替手段の運用ルールの整備・強化による実効性の確保

大規模障害発生時の対外告知等の対応事項の明確化及び大規模障害時の対応体制・役割分担の明確化

システム障害対応研修の実施及び今回の障害を踏まえた実践的な訓練の実施

＜事象１、２に係る共通の課題と対策＞

システムに関する専門 性や経験値が十分に蓄積されず、上記障害の対策を検討するためのシステム人材が不足しているため、システム人材の育成・確保を図る。

システム開発・運用に関する検討を実施する委員会等の役割も不明確で、知見も十分に活用されていなかったため、CIO設置による事務局体制の強化、銀行知見活用による各検討体制の強化及び外部目線によるチェック強化を行うことにより、組織全体の体制の強化を図る。

8.システム更改時のプログラム誤りによる取引エラー

＜業態＞
信用金庫・信用組合等

＜事象＞

ATMの他行カード振込取引を行った際、振込金額の支払取引のみが成立し、振込自体がエラーとなる事象が発生した。

＜原因＞

勘定系システム更改の対応において、通帳振込機能の プログラムに誤りがあり、他行カードを利用した振込処理の際、他行宛振込支払応答処理でカードを利用した振込実行処理を実施すべきところ、通帳を利用した振込実行処理を実施し、当該振込実行処理で業務エラーが発生した。

＜対策＞

委託責任者としての各種検証、テスト実施

システム更改期間中の緊急時における信用金庫内及び外部委託先を中心とした外部関係機との情報連携強化

9.システム更改時のプログラム誤りによる取引エラー②

＜業態＞
信用金庫・信用組合等

＜事象＞

一部地域のクレジット会社のカードを利用したATM取引がエラーとなる事象が発生した。

＜原因＞

勘定系システム更改にあたり、外部委託先が開発した地域クレジット会社のカード種別を判別する プログラムに不備があった。

外部委託先において、クレジット会社のカードの利用に係るテストの実施対象を全国的なクレジット会社のカードに限定し、地域クレジット会社のカードに対するテストを行わなかったため、本件不備が検知されなかった。

外部委託先から修正プログラムのテスト結果が良好との報告を受け、修正プログラムのリリースを了承し一時復旧したと認識したが、実際はテスト環境で実施していないカード情報の復号処理プログラムに不備が内包されていたため、再度不備が発生した。

＜対策＞

システム更改時における網羅性のあるテストの実施

本番環境とテスト環境の差異の整備

10.システム更改時のプログラム誤りによるキャッシュカード使用不可

＜業態＞
信用金庫・信用組合等

＜事象＞

ATMで生体認証ICキャッシュカードが使用不可となる事象が発生した。

＜原因＞

勘定系システムの更改におけるIC認証に関するプログラム に不備 があった。

生体認証ICキャッシュカード発行開始当初、ICチップ内の一部データ項目が未設定の状態で発行されたものがあり、当該カードも問題なく利用できるよう更改前のシステムのプログラムに改修を加えていたが、更改後のシステムには想定したプログラムが反映できていなかった。

今回不具合が発生する条件のテスト用の生体認証ICキャッシュカードが手元になく確認テストができていなかったため、事前に不具合の検出ができなかった。

＜対策＞

新しいキャッシュカードを発行する際、将来のプログラム改修に備え、テストで使用するキャッシュカード等を 準備及び厳格に保管し、テスト実施を徹底

11.仕様の把握ミスに起因した入金金額相違

＜業態＞
金融商品取引業者等

＜事象＞

営業店でのリアルタイム口座振替指示（取引明細指定）において、振替指示画面上の受渡日の前日基準残高が誤って表示されていたことにより、誤った振替指示が実行された。

＜原因＞

前日基準残高の算出は外部委託先が提供する共同利用型システムの既存仕様にあるロジックを用いて構築したが、旧システムの類似したロジックと利用用途が同様であると思い込んだため、調査・設計の不足があることに気づくことができなかった。

パターンの網羅性を考慮したテストを実施することができなかった。

＜対策＞

新旧システムの仕様に関する差分等の検証態勢の強化

13.プログラム更改時のテスト不足等に起因するオンライン処理の停止

＜業態＞
主要行等

＜事象＞

通帳レス対応に関する営業店オペレーター向けプログラムの改修時の不具合に起因して、オンライン処理で共通的に利用するデータベースの更新等が不可となり、プログラムを切り戻すまでの間、全営業店におけるオンライン処理等が利用不可となった。

＜原因＞

プログラムの品質チェックにおいて、担当者の思い込みや誤りによって再鑑が機能していなかった。

プログラム改修が小規模な予算のプロジェクトであったため、テストによる検証が簡易的に行われていた。

＜対策＞

レガシーシステムの暗黙知を設計書等に明記

最大リスクに応じた深度あるテス トやチェックリストによる確認

14.仕様の把握ミスに起因したスマートフォンアプリケーションのログイン不可

＜業態＞
主要行等

＜事象＞

新勘定系システムに移行後に、旧勘定系システムの仕様を誤認したことに起因して、スマートフォンアプリケーションで約１時間、利用不可となった。

＜原因＞

データベースの設計内容（型指定等）を誤認したまま開発を進めたことで、連携するシステムとの間で不整合が発生した。

旧仕様を踏襲する設計であったため結合テスト等の工程で試験内容が不足した。

＜対策＞

連携するシステム側の仕様を確認する点を開発ガイドラインに明記

旧仕様を踏襲する設計であっても境界値試験等を実施

17.システム更改時の設計漏れに起因する被仕向送金障害

＜業態＞
地域銀行

＜事象＞

被仕向送金のうち、一部振込に関して、振込資金の入金遅延・仕向銀行への資金の誤返却する障害が発生した。

＜原因＞

受取人口座番号の変更処理プログラムの誤りで、口座番号相違となった。

設計担当者・レビュー担当者双方の被仕向為替における口座番号変換処理仕様に関して理解が不足しており、口座番号の桁数バリエーションまで含めたテストケース設定ができていなかった。

＜対策＞

業務機能・システム処理方式に関する設計ドキュメントの整備

周辺シス テムを意識した勘定系システムの設計レビュー、テスト等の充実

20.プログラムの修正漏れによる振込不可

＜業態＞
信用金庫・信用組合等

＜事象＞

IBやATM等から振込を行う際の取引電文を書き出す為替発信用ファイルに関するプログラムに修正漏れがあり、先日付振込が当初予定の期日に行われない事象が発生した。

＜原因＞

システム開発時における先日付振込を含むテストケースが不足していた。

＜対策＞

IBやATM等を含む対外接続に係る開発において、オンラインで作成されるデータ、センターカットにて作成されるデータ等テストケースを網羅的に洗い出した上でテスト実施

21.IT部門と業務部門の連携不足による祝日設定の誤り

＜業態＞
暗号資産交換業者

＜事象＞

取引システムを更改後、本来取引時間外としている祝日において取引が可能な状態となった。

＜原因＞

取引システムの祝日設定を誤っていた。

取引システムを更改した際、IT部門と業務部門による仕様確認やテストの分担や手順が不明確であった。

＜対策＞

業務に関連するシステムの設定に対する業務部門の確認・指示やIT部門の作業等のプロセス整備

システム更改における業務部門の主体的な関与、IT部門と業務部門との運用に関する役割分担の明確化

第３節 日常の運用・保守等の過程の中で発生したシステム障害

Ⅳ. 取引量増加に伴う容量不足等

2.システムの処理能力不足によるアプリのログイン・決済不可

＜業態＞
資金移動業者等

＜事象＞

キャンペーン等による取引量の増大により、データベースサーバーの処理能力を超えたため、決済アプリのログイン、バーコード等を用いた決済及びチャージができなくなった。

＜原因＞

トラフィック量の増加により、流量制限機能が動作する前にデータベースサーバーの性能限界を超過した。

＜対策＞

データベースサーバーの性能限界に達する前に流量制御機能が働くようトラフィック量定義の見直し

3.ピーク日の処理による法人IBへのログイン困難

＜業態＞
主要行等

＜事象＞

月末ピーク日に処理負荷が高い入出金明細照会を法人IBで集中的に受け付けたことにより、サーバーの処理能力を超えたため、法人IBにログインしにくくなる事象が発生した。また、復旧までに時間（約８時間）を要した。

＜原因＞

メモリの負荷検証が不十分であった。

障害発生時の復旧手順の整備が不十分であった。

＜対策＞

リソース（メモリ、CPU）増強及び処理性能検証の実施

障害発生時の復旧手順の整備

5.カウンター上限値超過によるシステム停止

＜業態＞
主要行等、資金移動業者等

＜事象＞

取引量の増加（キャンペーン等のイベントによる一時的な取引量増加を含む。）に より 、システムで保有する取引件数等のカウンターやメールのファイル格納数等のシステムカウンターが上限値を超過し、システムが停止したため、顧客がサービスを利用できない事象が発生した。また、システム設定値の上限を超過した場合の対応を備えていたが機能しなかった事象も発生した。

＜原因＞

システムで保有する取引件数カウンターやメールのファイル格納数等のシステム設定値の上限の把握や監視ができていない。

取引量等の増加（キャンペーン等のイベントによる一時的な取引量増加を含む）によるシステム設定値の上限の事前検証、見直しができていない。また、システム設定値の上限を超過した場合の対応が正しく動作するかの検証ができていない。

＜対策＞

システムで保有する取引件数カウンターやメールのファイル格納数等のシステム設定値と上限の洗出し

カウンターの監視、取引量等の増加（一時的な取引量増加を含む）によるシステム設定値の上限（システム設定値の上限を超過した場合措置を含む）の事前検証、見直し実施

6.システムの処理能力不足による決済不可

＜業態＞
資金移動業者等

＜事象＞

取引量の増加（キャンペーン等のイベントによる一時的な取引量増加を含む。）によるシステムの負荷予測を行い、システムの処理能力等の事前検証を行っていたが、検証範囲が適切に設定されておらず、決済が不可となる事象が発生した。

＜原因＞

取引量の増加に伴うシステムの負荷予測、システムの処理能力等の事前検証が必要な外部接続先等の範囲の認識が誤っていた。

＜対策＞

システムの負荷予測、システムの処理能力等の事前検証を行う先の選定に関して、決済事業者や販売店（POS会社）の外部接続先を含めた網羅的な検討の実施

7.新規暗号資産販売時の負荷検証不足による処理停止

＜業態＞
暗号資産交換業者

＜事象＞

新規暗号資産販売時において、顧客から大量の発注申込が発生。発注処理遅延からサーバーが一定時間内に応答しないタイムアウトが発生したため、処理が失敗した。

さらに、この処理遅延解消のためにプログラム修正を行ったところ、プログラムミスによって処理誤りが生じ、復旧までに１週間以上を要した。

＜原因＞

想定取引量にもとづく負荷検証が不十分であった。

障害対応として実施した、処理遅延解消のためのプログラム修正の検証が不十分であった。

＜対策＞

想定取引量の適切な見積り並びに想定取引量にもとづく処理時間計測及びシステム負荷の観点での検証態勢の整備

障害対応時におけるプログラム修正に対する検証態勢の整備

第４節 プログラム更新、普段と異なる特殊作業等から発生したシステム障害

Ⅱ. ソフトウェアの不具合

1.設定ミスにより複数回の同一注文が発注可能

＜業態＞
暗号資産交換業者

＜事象＞

当社が提供するスマートフォン向け取引アプリにおいて、注文操作から注文完了画面表示までの間に複数回タップをすると同一内容の注文が重複発注されてしまう障害が発生した。

重複発注を検知する仕組みがなかったため、取引アプリの実装からシステム改修が完了するまでの長期間にわたり発覚が遅れた。

＜原因＞

設計段階では利用者が注文操作を行った後、即座にステータスを「注文中」に変更する仕様としていたところ、実装段階では注文操作を行い注文完了の画面が表示されるまでのステータスを「未注文」として処理をしたため、利用者が同一注文を重複発注できる状態となっていた。

＜対策＞

特異な操作（連続タップや連続スワイプ）に対するテストシナリオの追加

重複発注を検知する仕組みの構築

4.本番環境を想定したテストケースの不足に起因するIBの利用不可

＜業態＞
主要行等

＜事象＞

法人向けIBに関する新規プログラムのリリースに起因して、約３時間、利用不可となる障害が発生した。

＜原因＞

本番ピーク時相当の負荷テストと組み合わせたテストケースの検証を実施していなかった。

＜対策＞

取引が発生しない時間帯でのリリース（対応が難しければ実効性あるテストケースでの検証を実施）

5.新規プログラムの設計不備及びリリース認証不可

＜業態＞
主要行等

＜事象＞

生体認証プログラムの新規リリース後に、誤ったソフトウェア設計に起因して処理が間に合わず大量の認証エラーが発生した。その後システムの切戻しを実施したが、復旧までに時間を要した。

＜原因＞

新規プログラム開発時に行った負荷テストが、そもそもシステム要件に合致していなかった。

システムの安全性に配慮したリリース手順ではなかった。

＜対策＞

開発委託先の負荷テストの検証結果を確認するプロセスの追加

システムリリース時における手順の品質向上

6.システム更改（機能追加）時の、仕様の理解不足等によるプログラムミス

＜業態＞
信用金庫・信用組合等

＜事象＞

共同センター（個人向けIB) において、機能追加による更新時に設計書の記載が不正確であったことにより、プログラムミスによるエラーが発生し、約 10 金庫の個人向けIBにおいて、ログインできない事象が発生した。

共同センター 法人向けIB) において、機能追加による更新時に仕様変更を把握していなかったことにより、データベースのレコード作成に誤りがあり、約90金庫の法人向けIBにおいて、取引画面が操作できない事象が発生した。

＜原因＞

機能追加による更新時に、設計書の記載が不正確であった。

更改時の仕様変更を把握していなかった。

＜対策＞

設計書の再点検

データ構成を変更する際に既存データが変更後の仕様に合致しているかの全件チェックを実施することをルール化

機能追加・変更があった設定の再検証

レコード作成要領の整備

システム更改時の仕様変更について、理解度向上のための講習会を実施

7.システム開発におけるレビュー不足によるサービス提供不可

＜業態＞
信用金庫・信用組合等

＜事象＞

勘定系システムの通信状況を監視するプログラムの不備により、当該システムが停止し、窓口での現金受払、ATM、IB等の取引が不可となる事象が発生した。また、システムを運用する外部委託先から金融機関への報告に時間を要した。

＜原因＞

プログラムの不備により、ホストコンピュータのリソースが枯渇し、システムが正常に稼働しなくなった。

プログラムの初期導入時、検証者によるレビューが有効に機能しなかった。

夜間・早朝に障害が発生した際の連絡手段に不備があり、また、定義されたCPが不徹底であった。

＜対策＞

ホストコンピュータのリソース監視強化、本番リリース時のチェックリストの見直し、本事象と同様の不備有無の点検

大規模障害発生時の連絡体制の再検証、大規模障害の訓練の定期的な実施

9.ログ出力仕様の誤りによる取引開始遅延

＜業態＞
金融商品取引業者（ネット証券会社）

＜事象＞

データベースサーバーが高負荷の状態で実行された定期バックアップ処理に時間を要し、FX取引サービスの開始が遅延。また、復旧作業を行った影響により、取引報告書閲覧開始が遅延。

＜原因＞

障害発生の数日前にリリースした改修プログラムにおいて、本来はログ出力が 不要 にもかかわらず、一部のログを高頻度に出力する不具合が内在していた。

ログ出力がないとの思い込みによりテストでのログ出力確認を実施せず、また、テストでは本番よりも負荷の少ないテストデータ使用したことにより不具合の発見に至らなかった。

＜対策＞

設計時にログ出力頻度やリソースへの影響について確認することを開発時のチェックシートへ明記

サイクルテスト実施時に不要なログ出力のないこと、予期せぬ性能劣化のないことを確認することを開発時のチェックシートへ明記

10.外部委託先が招いた設計不備、自社によるテスト不足による送金不可

＜業態＞
資金移動業者等

＜事象＞

性能改善のためリリースした修正プログラムに設計不備があり、送金先へ接続できず、送金不可となる事象が発生した。

＜原因＞

外部委託先において設計書等の成果物の整備が不十分で知識が属人化しており、また、担当者の異動時の引継ぎが不十分であったため、リリース前に設計不備に気付けなかった。

当社による受入テストにおいてもテスト項目が不十分であり、設計不備を検知できなかった。

＜対策＞

知識の属人化防止のための成果物の確実な作成、担当者の異動に備えた体制の整備

システム変更箇所を考慮した十分なテスト計画を作成の上、受入テストを実施