システム障害事例の分析と教訓の共有 - IPA300 1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する 1件の重大な事故

© 2016 IPA Software Reliability Enhancement Center

ET/IoT2016 ブースプレゼン

2016年11月16日,18日

独立行政法人情報処理推進機構（ＩＰＡ）

技術本部ソフトウェア高信頼化センター（ＳＥＣ）

三縄俊信

システム障害事例の分析と教訓の共有（ITサービス編）

～教訓の共有による情報システム類似障害削減の提案～

2© 2016 IPA Software Reliability Enhancement Center

～目次～

アプローチの背景

教訓集2015の紹介

（教訓ダイジェスト、追加した教訓サンプル）

教訓の共有活動のすすめ


１．ソフトウェアの複雑性が増大

Microsoft Windows 成長の足あと

Ｗｉｎ3.1

(1990)

ＷｉｎNT

(1995)

Ｗｉｎ95

(1997)

ＷｉｎNT4.0(1998)

Ｗｉｎ98

(1999)

ＷｉｎNT5.0(2000)

Ｗｉｎ2000

(2001)

ＷｉｎXP

(2002)

0

5

10

15

20

25

30

35

40

45

（ × 100万LOC）

（データ出所EXPLOITING“How to Break Code”by Greg Hoglund/Gary McGraw)

情報処理システムのソフトウェアは，製品・サービスの多様化・高度化に伴う複雑化，大規模化等が進展

Windows XP: 40 millionWindows Vista : 50 millionWindows 7: 40 million Windows 8: 50-60millionWindows 10： 80 million

コード量(million)

システム

40 ISS(国際宇宙ｽﾃｰｼｮﾝ）

10 スペースシャトル

100 CAR software

2000 Google


２.システム障害は増加し類似のものが多い

0

10

20

30

40

50

2009 2010 2011 2012 2013 2014 2015 2016

近似線

多大な影響を与えたITサービス障害の発生件数（報道ベース）の推移

・△△でリコール、国内で数十万台…理由は、制御プログラムに不具合が発見されたためという。

・○○システムで障害か、終日つながりにくく…原因は、法律改正直前の駆け込み需要と期末の締め処理とが重なり、想定外の大量入力にシステムの性能が耐えられなかった模様。

・□□システムで障害、午前中のサービス停止…原因は、システムは本番装置の故障により予備装置に自動的に切り替わるようになっていたが、その切替えが失敗したためという。

社会に大きな影響を与えたシステム障害の発生件数2009年以降で増加傾向新聞やテレビなどのメディアでは，幾度となく以下のようなニュースが世間を賑わせている：

類似障害の発生

(出典) SEC Journal 情報システムの障害状況

件


３．リスクへの対応はハードとソフトで異なる

ハードウェアは劣化する→故障

ソフトウェアは劣化しない

ソフトウェアは相対的に劣化する（ｼｽﾃﾑ）

使われる環境の変化ビジネス方針，ニーズ組織・人（慣れによる過信・

油断，交代による技術/ノウハウ継承無し）

利用者増，新技術，他

網羅的な事前抽出が困難

失敗に学ぶ

冗長構成，など

教訓の活用

障害事例に基づく教訓・対策の共有

リスク要因


４. 問題点とアプローチ方法

<現状の問題は何か？>

類似した問題/失敗が、重要インフラの異なる業界で、たびたび発生する

異なるITサービス/製品と装置の各々の失敗ケースが、会社全体で共有されていない

<では、どうアプローチすればよいか>

失敗事例を収集して分析する

↓

根本原因を抽出して教訓にする（組織化、体系化、蓄積）

↓

社会で共有し（異なる業界間において）、類似の失敗を防止して最小化する

" 失敗から学ぶ “


５．教訓共有の取組みの目指す方向

障害に基づく教訓の共有による信頼性向上のしくみ現状（教訓の共有なし）

製品機器/ITサービス

(Ａ社)

社会社会

より高い安全・安心な製品機器/ITサービスの提供


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

原因分析対策検討

対策実施

教訓Ａ


対策実施

教訓Ｂ


対策実施

教訓Ｃ


(Ａ社)


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

原因分析・対策検討一般化・抽象化・普遍化

体系的整理

教訓Ａ

教訓Ｂ

教訓Ｃ

対策実施対策実施対策実施障害障害障害障害障害障害

重要インフラ等重要インフラ等

専門家，有識者のご協力を得てIPA/SECや業界団体等が担う共有活動

教訓教訓教訓

機密保持等のルール

類似障害の発生


６．脅威（要因）の類型とスコープ

<出典>NISC: 重要インフラの情報セキュリティ対策に係る第２次行動計画

IT障害を引き起こす脅威（要因）としては，意図的要因（情報セキュリティ関連）と非意図的要因（システム障害関連），災害等がある．

高信頼化対策の対象

意図的な要因

(サイバー攻撃等）

(偶発的な要因）

(環境的な要因）

セキュリティ対策の対象


７．重要インフラシステム障害の発生確率と影響度

大

←

影響度

発生確率 → 大

サイバー攻撃

財政危機

水危機

気候変動適応失敗

失業・不完全雇用

異常気象

生物多様性損失と生態系崩壊

<左図の出典>Global Risks 2015 10th Edition,the World Economic Forum

Figure 1.1: The Global Risks Landscape 2015

発生確率

影響度

リスクの低減

受容できないリスク

受容できるリスク

エネルギー価格打撃

伝染病拡散国家間

対立大量破壊兵器

http://reports.weforum.org/global-risks-2015/

“重要インフラのITシステム障害”は“サイバー攻撃”に比べ，発生確率は小さいものの，発生時の影響は大きい

重要インフラのITシステム障害


８. ヒヤリハット（ハインリッヒの法則）

１

29

300

1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する

1件の重大な事故

29件の軽微な事故

300件のヒヤリ・ハット

「ヒヤリハット事例を収集し共有することが重大事故の防止につながる」

ハーバート・ウィリアム・ハインリッヒ（1929年、米国損害保険会社技術部長労働災害5,000件超を統計学的に調査）

労働災害における経験則の一つ。

（インシデント）

（アクシデント）

https://ja.wikipedia.org/wiki/%E5%8A%B4%E5%83%8D%E7%81%BD%E5%AE%B3


９．情報処理システム高信頼化教訓集の公開

2016年3月末公開

組込みシステム分野

国民生活や社会・経済基盤に関わる「障害情報」を収集

[教訓数]

35件

[教訓数]

36件

普遍化取りまとめ収集した情報を分析し

対策を検討

＜製品・制御システム高信頼化部会＞情報処理システム高信頼化教訓集2015

（ITサービス編／組込みシステム編）

【参画企業等】

トヨタ自動車（株）、日産自動車（株）

日本電気（株）、（株）日立製作所

三菱電機（株）、横河電機（株）

富士電機（株）、矢崎総業（株）

アイシン精機（株）

日本電気通信システム（株）

（株）日立産業制御ソリューションズ

三菱電機メカトロニクスソフトウェア（株）

（株）富士通コンピュータテクノロジーズ

オムロンソーシアルソリューションズ（株）

アイシン・コムクルーズ（株）

北陸先端科学技術大学院大学

九州大学、会津大学

（一社）組込みシステム技術協会

（一社）電子情報技術産業協会

【参画企業等】

（株）三菱東京UFJ銀行

日本生命保険相互会社

東京海上日動火災保険（株）

（株）日本取引所グループ

東京電力（株）

東日本旅客鉄道（株）

KDDI（株）

（株）フジテレビジョン

（株）オリジネィション

日本大学

内閣官房情報通信技術総合戦略室

（一社）日本情報システム・ユーザー協会

組込みシステム編

2016年３月時点

2015年度新着７件

2015年度新着９件

新着教訓を随時Web公開

＜特徴＞

①業界・分野を超えて活用可能な普遍化された教訓。

②機密保持ルールの下で詳細情報の提供を受けた深い議論。

③蓄積されたソフトウェア・エンジニアリングに関する知見活用。

http://www.ipa.go.jp/sec/system/lesson.html

＜重要インフラITサービス高信頼化部会＞

2013年度版（2014年5月公開）から毎年追加し公開


10. ガイドブック2編のＷＥＢ公開（2016年2月29日）

IT障害等の事例

事例からの学び（失敗のカラクリ等の

気付きを与えるメッセージ）

（裏返し）

教訓作成ガイドブック

（教訓を作成する）

抽象化

教訓活用ガイドブック

（教訓を活用する）

活用

具体化

自社教訓集

各社／組織で作成

ＩＰＡ教訓集

情報処理システム高信頼化教訓集

IPA/SEC

具体化ITシステムの開発・運用の現場

IT障害リスク低減の具体策等

高信頼化への知恵（成功のカラクリ等の気付き

を与えるメッセージ）


教訓集2014WEBダウンロード時のアンケート(607件）


教訓集2014WEBダウンロードした方への活用アンケート(115件）2016年1月実施


2015年度版サービスやシステムの

信頼性を高めるための

独立行政法人情報処理推進機構（ IPA）

技術本部ソフトウェア高信頼化センター（SEC）

教訓集ダイジェスト

ITサービス編

組込みシステム編

お手元のパンフレットを御覧ください


教訓一覧

T17定期的な再起動に関する教訓

長時間連続運転による不安定動作発生の回避には定期的な再起動も有効！

（同上）（同上）

負荷分散装置が8か月以上連続運転状態であり、再起動をしたことがなかった。再起動をしていれば、バグが顕在化することはなかった。

・毎月の定期保守日に状況を見て再起動を行うこととした

仮想化、共同利用、システム再起動

T18既存システムとのデータ連携に関する教訓

新たなサブシステムと老朽化した既存システムとを連携する場合は両者の仕様整合性を十分確認すべし

オンラインサービスの遅延、停止、サービス明細の欠落

特別な事象を契機とする処理集中のため、夜間バッチが異常終了

携帯電話に対応した新しいシステムと既存システムを接続した際の全体整合を十分チェックできていなかった

・既存システムの要件定義内容を再度チェックして連携するシステム間の整合性を確認。これらをルール化してマニュアルに取り込む・システムが異常終了しても途中から再開始可能な仕組みの導入

既存システム、システムの追加、インタフェース、制限値

T19ＲＤＢＭＳのクエリ最適化機能に関する教訓

リレーショナルデータベース（ＲＤＢＭＳ）のクエリ自動最適化機能の適用は慎重に！

システム応答速度の低下

ＲＤＢＭＳのＳＱＬ応答遅延

ＲＤＢＭＳの自動最適化機能によるフルスキャンの発生

・インデックスの追加・実行計画の固定化の検討

ＲＤＢＭＳ、クエリ自動最適化、実行計画の固定

T20パッケージ製品の機能カスタマイズに関する教訓

パッケージ製品の機能カスタマイズはリスクを認識し特に必要十分なチェック体制やチェック手順を整備して進めること

コールセンタ業務で通話着信障害

制御ソフトの無限ループ発生

パッケージ製品のカスタマイズによる不具合の内包

・交代系への自動切換もできなくなったため、強制的に手動切替を行い復旧・後日、プログラム修正実施済み

パッケージ製品のカスタマイズ、プログラムミス、処理の競合

T21運用保守で起きる作業ミスに関する教訓

作業ミスを減らすためには、作業指示者と作業者の連携で漏れのない対策を！！

依頼コールの転送ミスによる現場の混乱

GW増設時のシステム設定値の作業ミス

作業ミスを起こさせるような状況、環境があることである。

作業ミスは、個人、環境、ハードウェア、ソフトウェアの関係性の中で、対策を考える。ヒューマンファクタの観点からシステムの問題を仕組みや組織として改善することに主眼を置く。

ヒューマンファクタ、m-SHELモデル、なぜなぜ分析、ヒューマンエラー対策

T22バッファプールの管理に関する教訓

隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること

予期しない予約システムの受付停止

トランザクション集中に伴うバッファのオーバフロー

バッファの滞留状況の監視がされていない

各種バッファの用途に応じた閾値の設定とアラーム表示機能の追加

バッファプール、閾値設定、アラーム表示

根本原因No.教訓集の目次（分類）

教訓概要問題直接原因対策キーワード


教訓一覧

サー

ビスレベル管理

サー

ビス継続・

可用性管理

サー

ビス報告

容量・能力管理

情報セキ

ュリテ

ィ管理

事業関係管理

供給者管理

インシデント管理

問題管理

構成管理

変更管理

リリー

ス管理

T16修正パッチの適用に関する教訓

△ △ ●

T17定期的な再起動に関する教訓

△ ●

T18既存システムとのデータ連携に関する教訓

● △

T19ＲＤＢＭＳのクエリ最適化機能に関する教訓

● △

T20パッケージ製品の機能カスタマイズに関する教訓

△ ●

T21運用保守で起きる作業ミスに関する教訓

△ △ ●

T22バッファプールの管理に関する教訓

● △ △

No. 教訓集の目次（分類）

ＪＩＳ　Ｑ20000-1：2012より（●主な問題個所、△関連する問題個所）

５．新規またはサー

ビス

変更の設計及び移行

６．サービス提供プロセス７．関係プロセス８．解決プロセス９．統合的制御プロセス


【問題】コールセンタにおいて電話コールの一部が着信後に即切断されてしまう事象が発生していたがイタズラ電話との認識、また通信回線事業者からコールの接続異常が時々発生しているが問題はないかと問合せはあったが他の事業者は正常との回答であったため問題視しなかった。システム障害と気付くまでに4時間経過していた。

【原因】設定変更のミス。回線収容基板の一部廃止に伴い回線試験用の設定も削除するべきだったが漏れた。

エラー電文の蓄積が共通バッファオーバフローを招き通話不可。

【対策】(復旧措置）交代系への切替えで復旧(作業漏れへの対策）保守運用マニュアルの改善(障害状態検知への対策）バッファ監視機能追加(異常申告への対策）回線事業者連絡会の設置(交代系への切替え判断）原因調査より復旧作業優先

Ｇ10：関係者からの疑義問合せは自社システムに問題が発生して

いることを前提に対処すべし！


【問題】コールセンタにおいて電話コールの一部が着信後に即切断されてしまう事象が発生していたがイタズラ電話との認識、また通信回線事業者からコールの接続異常が時々発生しているが問題はないかと問合せはあったが他の事業者は正常との回答であったため問題視しなかった。システム障害と気付くまでに4時間経過していた。

【原因】設定変更のミス。回線収容基板の一部廃止に伴い回線試験用の設定も削除するべきだったが漏れた。

エラー電文の蓄積が共通バッファオーバフローを招き通話不可。

【対策】(復旧措置）交代系への切替えで復旧(作業漏れへの対策）保守運用マニュアルの改善(障害状態検知への対策）バッファ監視機能追加(異常申告への対策）回線事業者連絡会の設置(交代系への切替え判断）原因調査より復旧作業優先

断続的に発生するオンラインシステムのサイレント障害はセンタ側では気付かないことが多い。

利用者の声は貴重です。

Ｇ10：関係者からの疑義問合せは自社システムに問題が発生して

いることを前提に対処すべし！


Ｇ1４：設計時に定めたキャパシティ管理項目は、環境の変化に

あわせて見直すべし！１分あたりの処理件数の変化１秒あたりの処理件数の変化

Plan(企画・計画）

Action(改善対策）

Do(モニタリング）

Check(分析・評価）

①現行システムに対して

キャパシティ計画の修正、設定した閾値を見直す

②次世代システムに対して

次世代システムのキャパシティ管理要件として、開発時の要件定義に組み込む

【原因】設計時に定めた監視する時間間隔（キャパシティ管理項目）では十分にシステムを監視できていなかった。

【対策】①現行システムに対しては、キャパシティ計画の修正と設定した閾値の見直しを行う。

②次世代システムのキャパシティ管理要件として、開発時の要件定義に組み込む。

【問題】A社のシステムは、以前から一般的な増加とともに、突発的な事象によるデータ量の急増がみられた。このA社のシステムにある日、処理能力を越えた注文が殺到し、サービスの時間が短縮となった。


Ｇ1４：設計時に定めたキャパシティ管理項目は、環境の変化に

あわせて見直すべし！１分あたりの処理件数の変化１秒あたりの処理件数の変化

Plan(企画・計画）

Action(改善対策）

Do(モニタリング）

Check(分析・評価）

①現行システムに対して

キャパシティ計画の修正、設定した閾値を見直す

②次世代システムに対して

次世代システムのキャパシティ管理要件として、開発時の要件定義に組み込む

【原因】設計時に定めた監視する時間間隔（キャパシティ管理項目）では十分にシステムを監視できていなかった。

【対策】①現行システムに対しては、キャパシティ計画の修正と設定した閾値の見直しを行う。

②次世代システムのキャパシティ管理要件として、開発時の要件定義に組み込む。

【問題】A社のシステムは、以前から一般的な増加とともに、突発的な事象によるデータ量の急増がみられた。このA社のシステムにある日、処理能力を越えた注文が殺到し、サービスの時間が短縮となった。

毎分のトランザクション量監視から毎秒に変更し、きめの細かい監視・予測が可能

日々の運用変化への耐性を持つシステムは突発的な変化にも対策・対応が可能


Ｔ22：隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること

【問題】予約受付システムが特定の予約業務の停止から始まり、全予約業務の停止に拡大し、再開まで２時間程度サービス不可となった。

【原因】予約処理Ａサーバの処理がメモリ不足により、スローダウン状態となったため処理待ちバッファに徐々に入力データが滞留し、上限の1,000件を越えた。これにより、予約受付サーバ側の転送バッファに未送信データが滞留して満杯となり、共通バッファから予約処理Ａの入力データが取り出されなくなり、こちらも満杯となり全予約処理の受付が停止した。

【対策】・予約業務Aのスローダウン状態を回復

・滞留データを順次処理し共通バッファを空にする

・予約受付システムを再開

・バッファの洗い出し、閾値設定とアラート監視の改善


Ｔ22：隠れたバッファの存在を把握し、目的別の閾値設定と超過アラート監視でオーバフローを未然に防止すること

【問題】予約受付システムが特定の予約業務の停止から始まり、全予約業務の停止に拡大し、再開まで２時間程度サービス不可となった。

【原因】予約処理Ａサーバの処理がメモリ不足により、スローダウン状態となったため処理待ちバッファに徐々に入力データが滞留し、上限の1,000件を越えた。これにより、予約受付サーバ側の転送バッファに未送信データが滞留して満杯となり、共通バッファから予約処理Ａの入力データが取り出されなくなり、こちらも満杯となり全予約処理の受付が停止した。

【対策】・予約業務Aのスローダウン状態を回復

・滞留データを順次処理し共通バッファを空にする

・予約受付システムを再開

・バッファの洗い出し、閾値設定とアラート監視の改善

各種バッファの存在を認識し、構成情報としてその最大収納件数を認識・管理する。

とくにパッケージ製品を利用する場合は明示されていない内部バッファの存在を把握しておく必要がある。


１１．各産業分野で教訓の共有活動を推進中

電力分野（9団体が参加）

交通分野（航空運航システム

研究会と協業）

電子政府（東京都特別区有志20区参加）

金融分野（生命保険有志15社）

通信分野（日本ケーブル

テレビ連盟約160社）

地域インフラ（北海道インフラ事業者25組織）

ＩＰＡが情報共有体制の支援、事例情報の提供、必要に応じ共有ツールの提供


１２. これまでにスタートした共有体制（IPAツール利用型）

①行政（自治体）分野

東京都の特別区のうち有志区が参加する情報システム担当の情報共有

＜仮想的なオンライン情報共有グループ＞


これまでにスタートした共有体制（メーリングリスト型）

②電力分野

電気事業連合会と協議し、情報共有の取組みに賛同する8組織を中心にメーリングリストを使用した情報共有を行うことで合意（平成27年2月19日）。参加は９組織。

電力ITの情報共有グループに利用登録された方へお送りしております。

┏ 電力IT情報共有グループ ━━━━━━━━━━━━━━━━━━━━━━━━┃ ☆ 第3号 2015.4.9 ☆┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━電力ITの情報共有グループご参加のみなさま

IPA/SEC――――――――――――――――――――――――――――――――――――――INDEX【1】2014年下期の報道されたシステム障害【2】電力分野における過去の類似障害――――――――――――――――――――――――――――――――――――――当メールでは、独立行政法人情報処理推進機構技術本部ソフトウェア高信頼化センターを「IPA/SEC」と表記します。━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━【1】2014年後半に報道されたシステム障害━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━IPA/SECでまとめている、最近報道されたシステム障害(2014年後半（7-12月))が、SECジャーナル40号に掲載されました。「情報システムの障害状況 2014年後半データ」（P.44～P.47）

http://www.ipa.go.jp/sec/secjournal/index.html#section2本文では、2014年7月から12月に報道されたシステム障害一覧を掲載していると共に以下の2点の障害パターンについて解説しています。①処理能力を超える大きなトラフィックが突発的に発生・・・報道 2件②保守作業に伴って発生した事例・・・・・・・・・・・・・報道 3件

※北海道ＩＴ情報共有グループ発足（2016年8月）

インフラ28組織が参加

※生保ＩＴ情報共有グループ発足（2016年2月）生保有志16社が参加

まずは、IPA/SECからシステム障害事例、セキュリティ事故事例に関する情報を電力業界に絡めて編集し、情報提供から実施。共有の意義を醸成してから、各社からの情報発信を期待。

http://www.ipa.go.jp/sec/secjournal/index.html#section2


これまでにスタートした共有体制（個別ツール利用型）

③情報通信分野


1３．IPAからのご提案

みなさまと同じ業界分野でグループを作り、そこで教訓集を作成し、類似障害の撲滅を目指しませんか。

IPA/SECが支援いたします。

IPA/SECでは、定期的に演習セミナーを実施しています。別途、業界向けセミナーも行います。

IPAが公開する新着教訓や、新聞や雑誌等で報道されたシステム障害情報から読み取れる教訓等についてお知らせする、メールマガジン（教訓集活用メルマガ）を発信しています。

配信をご希望の方は是非ご登録を！


ご清聴ありがとうございました

詳細は展示ブースをご覧下さい

Documents

システム障害事例の分析と教訓の共有 - IPA300 1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する 1件の重大な事故