2016 IPA Software Reliability Enhancement Center 2 ~ 目次 ~ アプローチの背景 教訓集 2015 の紹介 ( 教訓ダイジェスト 追加した教訓サンプル ) 教訓の共有活動のすすめ

ET/IoT2016 ブースプレゼン

2016年11月16日,18日

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

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

三縄 俊信

システム障害事例の分析と教訓の共有

（ITサービス編）

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

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 million

Windows Vista : 50 million

Windows 7: 40 million

Windows 8: 50-60million

Windows 10： 80 million

コード量

(million)

システム

40

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

10

スペースシャトル

100

CAR software

2000

Google

Software Reliability Enhancement Center

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

0

10

20

30

40

50

2009 2010 2011 2012 2013 2014 2015 2016

近似線

多大な影響を与えたITサービス障害の

発生件数（報道ベース）の推移

・△△でリコール、国内で数十万台

…理由は、

制御プログラム

に不具合が発見された

ためという。

・○○システムで障害か、終日つながりに

くく

…原因は、法律改正直前の駆け込み需要と期末の

締め処理とが重なり、想定外の

大量入力

にシステ

ムの性能が耐えられなかった模様。

・□□システムで障害、午前中のサービス

停止

…原因は、システムは本番装置の故障により予備

装置に自動的に切り替わるようになっていたが、

その

切替えが失敗

したためという。

社会に大きな影響を与えたシ

ステム障害の発生件数

2009年以降で増加傾向

新聞やテレビなどのメディアでは，

幾度となく以下のようなニュースが

世間を賑わせている：

類似障害の発生

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

件

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

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

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

ソフトウェアは

相対的に

劣化する

（ｼｽﾃﾑ）

使われる環境の変化

 ビジネス方針，ニーズ

 組織・人（慣れによる過信・

油断，交代による技術/ノ

ウハウ継承無し）

 利用者増，新技術，他

網

羅

的

な

事

前

抽

出

が

困

難

失敗に学ぶ

冗長構成，など

教訓の活用

障害事例に基づく

教訓・対策の共有

リスク要因

Software Reliability Enhancement Center

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

<現状の問題は何か？>



類似した問題/失敗

が、重要インフラの異なる業界で、たびたび発

生する



異なるITサービス/製品と装置の各々の失敗ケースが、

会社全体で共有されていない

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

失敗事例

を収集して分析する

↓

根本原因

を抽出して

教訓にする

（組織化、体系化、蓄積）

↓

社会で共有し

（異なる業界間において）

、類似の失敗を防止

して最小

化する

" 失 敗 か ら 学 ぶ “

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

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

現状（教訓の共有なし）

製品機器/

ITサービス

(Ａ社)

社会

社会

より高い安全・安心な

製品機器/ITサービスの提供

製品機器/

ITサービス

(Ｂ社)

製品機器/

ITサービス

(Ｃ社)

信

頼

性

信

頼

性

信

頼

性

原因分析

対策検討

対

策

実

施

教

訓

Ａ

原因分析

対策検討

対

策

実

施

教

訓

Ｂ

原因分析

対策検討

対

策

実

施

教

訓

Ｃ

製品機器/

ITサービス

(Ａ社)

製品機器/

ITサービス

(Ｂ社)

製品機器/

ITサービス

(Ｃ社)

信

頼

性

信

頼

性

信

頼

性

原因分析・対策検討

一般化・抽象化・普遍化

体系的整理

教

訓

Ａ

教

訓

Ｂ

教

_訓

Ｃ

対策実施

対策実施

対策実施

障害

障害

障害

障害

障害

障害

重要インフラ等

_{重要インフラ等}

専門家，有識者のご協力を得て

IPA/SECや業界団体等が担う共有活動

教訓

教訓

教訓

機密保持等

のルール

類似障害の発生

Software Reliability Enhancement Center

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

<出典>

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システム障害

Software Reliability Enhancement Center

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

１

29

300

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

1件の重大な事故

29件の軽微な事故

300件の

ヒヤリ・ハット

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

ハーバート・ウィリアム・ハインリッヒ

（1929年、米国 損害保険会社 技術部長 労働災害5,000件超を統計学的に調査）

労働災害

における経験則の一つ。

（インシデント）

（アクシデント）

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

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月公開）から毎年追加し公開

Software Reliability Enhancement Center

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

IT障害等の事例

事例からの学び

（失敗のカラクリ等の

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

（裏返し）

教訓作成ガイドブック

（教訓を作成する）

抽象

化

教訓活用ガイドブック

（教訓を活用する）

活用

具体化

自社

教訓集

各社／組織で作

成

ＩＰＡ

教訓集

情報処理システム

高信頼化教訓集

IPA/SEC

具体化

ITシステムの

開発・運用の現場

IT障害リスク低減の

具体策等

高信頼化への知恵

（成功のカラクリ等の気付き

を与えるメッセージ）

Software Reliability Enhancement Center

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

2015年度版

サービス

や

システム

の

信頼性

を

高める

ための

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

技 術 本 部

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

教訓集

ダイジェスト

ITサービス

編

組込みシステム

編

お手元の

パンフレットを

御覧ください

Software Reliability Enhancement Center

教訓一覧

T17 定期的な再起動に関する 教訓 長時間連続運転による不安 定動作発生の回避には定期 的な再起動も有効！ （同上） （同上） 負荷分散装置が8か月以上連 続運転状態であり、再起動をし たことがなかった。再起動をし ていれば、バグが顕在化する ことはなかった。 ・毎月の定期保守日に状況を見て 再起動を行うこととした 仮想化、共同利用、システム再起 動 T18 既存システムとのデータ_{連携に関する教訓} 新たなサブシステムと老朽化 した既存システムとを連携す る場合は両者の仕様整合性 を十分確認すべし オンラインサービス の遅延、停止、サー ビス明細の欠落 特別な事象を契機 とする処理集中の ため、夜間バッチが 異常終了 携帯電話に対応した新しいシ ステムと既存システムを接続し た際の全体整合を十分チェック できていなかった ・既存システムの要件定義内容を 再度チェックして連携するシステム 間の整合性を確認。これらをルー ル化してマニュアルに取り込む ・システムが異常終了しても途中か ら再開始可能な仕組みの導入 既存システム、システムの追加、 インタフェース、制限値 T19 ＲＤＢＭＳのクエリ最適化 機能に関する教訓 リレーショナルデータベース （ＲＤＢＭＳ）のクエリ自動最 適化機能の適用は慎重に！ システム応答速度 の低下 ＲＤＢＭＳのＳＱＬ応 答遅延 ＲＤＢＭＳの自動最適化機能に よるフルスキャンの発生 ・インデックスの追加 ・実行計画の固定化の検討 ＲＤＢＭＳ、クエリ自動最適化、実 行計画の固定 T20 パッケージ製品の機能カ_{スタマイズに関する教訓} パッケージ製品の機能カスタ マイズはリスクを認識し特に 必要十分なチェック体制や チェック手順を整備して進め ること コールセンタ業務で 通話着信障害 制御ソフトの無限 ループ発生 パッケージ製品のカスタマイズ による不具合の内包 ・交代系への自動切換もできなく なったため、強制的に手動切替を 行い復旧 ・後日、プログラム修正実施済み パッケージ製品のカスタマイズ、プ ログラムミス、処理の競合 T21 運用保守で起きる作業ミ_{スに関する教訓} 作業ミスを減らすためには、 作業指示者と作業者の連携 で漏れのない対策を！！ 依頼コールの転送ミ スによる現場の混乱 GW増設時のシステ ム設定値の作業ミ ス 作業ミスを起こさせるような状 況、環境があることである。 作業ミスは、個人、環境、ハード ウェア、ソフトウェアの関係性の中 で、対策を考える。ヒューマンファク タの観点からシステムの問題を仕 組みや組織として改善することに 主眼を置く。 ヒューマンファクタ、m-SHELモデ ル、なぜなぜ分析、ヒューマンエ ラー対策 T22 バッファプールの管理に_{関する教訓} 隠れたバッファの存在を把握 し、目的別の閾値設定と超過 アラート監視でオーバフロー を未然に防止すること 予期しない予約シス テムの受付停止 トランザクション集 中に伴うバッファの オーバフロー バッファの滞留状況の監視が されていない 各種バッファの用途に応じた閾値 の設定とアラーム表示機能の追加 バッファプール、閾値設定、アラー ム表示

根本原因

No.

教訓集の目次

（分類）

教訓概要

問題

直接原因

対策

キーワード

教訓一覧

サ ー ビ ス レ ベ ル 管 理 サ ー ビ ス 継 続 ・ 可 用 性 管 理 サ ー ビ ス 報 告 容 量 ・ 能 力 管 理 情 報 セ キ ュ リ テ ィ 管 理 事 業 関 係 管 理 供 給 者 管 理 イ ン シ デ ン ト 管 理 問 題 管 理 構 成 管 理 変 更 管 理 リ リ ー ス 管 理

T16

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

教訓

△

△

●

T17

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

訓

△

●

T18

既存システムとのデータ連携

に関する教訓

●

△

T19

ＲＤＢＭＳのクエリ最適化機

能に関する教訓

●

△

T20

パッケージ製品の機能カスタ

マイズに関する教訓

△

●

T21

運用保守で起きる作業ミスに

関する教訓

△

△

●

T22

バッファプールの管理に関す

る教訓

●

△

△

No.

教訓集の目次（分類）

ＪＩＳ　 Ｑ20000-1：2012より（●主な問題個所、 △関連する問題個所） ５ ． 新 規 ま た は サ ー ビ ス 変 更 の 設 計 及 び 移 行 ６． サービス提供プロセ ス ７． 関係プロセ ス８． 解決プロセ ス ９． 統合的制御プロセ ス

Software Reliability Enhancement Center

【問題】コールセンタにおいて電話コールの一部が着信後に即切断されてしまう事象が発生してい

たがイタズラ電話との認識、また通信回線事業者からコールの接続異常が時々発生してい

るが問題はないかと問合せはあったが他の事業者は正常との回答であったため問題視しな

かった。システム障害と気付くまでに4時間経過していた。

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

だったが漏れた。

エラー電文の蓄積が共通バッファ

オーバフローを招き通話不可。

【対策】(復旧措置）

交代系への切替えで復旧

(作業漏れへの対策）

保守運用マニュアルの改善

(障害状態検知への対策）

バッファ監視機能追加

(異常申告への対策）

回線事業者連絡会の設置

(交代系への切替え判断）

原因調査より復旧作業優先

Ｇ10：

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

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

【問題】コールセンタにおいて電話コールの一部が着信後に即切断されてしまう事象が発生してい

たがイタズラ電話との認識、また通信回線事業者からコールの接続異常が時々発生してい

るが問題はないかと問合せはあったが他の事業者は正常との回答であったため問題視しな

かった。システム障害と気付くまでに4時間経過していた。

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

だったが漏れた。

エラー電文の蓄積が共通バッファ

オーバフローを招き通話不可。

【対策】(復旧措置）

交代系への切替えで復旧

(作業漏れへの対策）

保守運用マニュアルの改善

(障害状態検知への対策）

バッファ監視機能追加

(異常申告への対策）

回線事業者連絡会の設置

(交代系への切替え判断）

原因調査より復旧作業優先

断続的に発生するオンラインシステムのサイレント障害

はセンタ側では気付かないことが多い。

利用者の声は貴重です。

Ｇ10：

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

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

Software Reliability Enhancement Center

Ｇ1４：

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

_{あわせて見直すべし！}

１分あたりの処理件数の変化 １秒あたりの処理件数の変化

Plan

(企画・計画）

Action

(改善対策）

Do

(モニタリング）

Check

(分析・評価）

①現行システムに対して

キャパシティ計画の修正、設定し

た閾値を見直す

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

次世代システムのキャパシティ管

理要件として、開発時の要件定義

に組み込む

【原因】設計時に定めた監視する時間

間隔（キャパシティ管理項目

）では十分にシステムを監視

できていなかった。

【対策】①現行システムに対しては、キ

ャパシティ計画の修正と設定し

た閾値の見直しを行う。

②次世代システムのキャパシテ

ィ管理要件として、開発時の要

件定義に組み込む。

【問題】A社のシステムは、以前から一

般的な増加とともに、突発的な

事象によるデータ量の急増がみ

られた。このA社のシステムにあ

る日、処理能力を越えた注文が

殺到し、サービスの時間が短縮

となった。

Ｇ1４：

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

_{あわせて見直すべし！}

１分あたりの処理件数の変化 １秒あたりの処理件数の変化

Plan

(企画・計画）

Action

(改善対策）

Do

(モニタリング）

Check

(分析・評価）

①現行システムに対して

キャパシティ計画の修正、設定し

た閾値を見直す

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

次世代システムのキャパシティ管

理要件として、開発時の要件定義

に組み込む

【原因】設計時に定めた監視する時間

間隔（キャパシティ管理項目

）では十分にシステムを監視

できていなかった。

【対策】①現行システムに対しては、キ

ャパシティ計画の修正と設定し

た閾値の見直しを行う。

②次世代システムのキャパシテ

ィ管理要件として、開発時の要

件定義に組み込む。

【問題】A社のシステムは、以前から一

般的な増加とともに、突発的な

事象によるデータ量の急増がみ

られた。このA社のシステムにあ

る日、処理能力を越えた注文が

殺到し、サービスの時間が短縮

となった。

毎分のトランザクション量監視から毎秒に変更し、きめの細か

い監視・予測が可能

日々の運用変化への耐性を持つシステムは突発的な変化にも

対策・対応が可能

Software Reliability Enhancement Center

Ｔ22：

隠れたバッファの存在を把握し、目的別の閾値設定と

_{超過アラート監視でオーバフローを未然に防止すること}

【問題】予約受付システムが特定の予約業務の停止から始まり、全予約業務の停止に拡大し

、再開まで２時間程度サービス不可となった。

【原因】 予約処理Ａサーバの処理がメモリ不足により、スローダウン状態となったため

処理待ちバッファに徐々に入力データが滞留し、上限の1,000件を越えた。これ

により、予約受付サーバ側の転送バッファに未送信データが滞留して満杯となり

、共通バッファから予約処理Ａの入力

データが取り出されなくなり、こちら

も満杯となり全予約処理の受付が停

止した。

【対策】・予約業務Aのスローダウン

状態を回復

・滞留データを順次処理し

共通バッファを空にする

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

・バッファの洗い出し、閾値

設定とアラート監視の改善

Ｔ22：

隠れたバッファの存在を把握し、目的別の閾値設定と

_{超過アラート監視でオーバフローを未然に防止すること}

【問題】予約受付システムが特定の予約業務の停止から始まり、全予約業務の停止に拡大し

、再開まで２時間程度サービス不可となった。

【原因】 予約処理Ａサーバの処理がメモリ不足により、スローダウン状態となったため

処理待ちバッファに徐々に入力データが滞留し、上限の1,000件を越えた。これ

により、予約受付サーバ側の転送バッファに未送信データが滞留して満杯となり

、共通バッファから予約処理Ａの入力

データが取り出されなくなり、こちら

も満杯となり全予約処理の受付が停

止した。

【対策】・予約業務Aのスローダウン

状態を回復

・滞留データを順次処理し

共通バッファを空にする

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

・バッファの洗い出し、閾値

設定とアラート監視の改善

各種バッファの存在を認識し、構成情報としてその最大収納件

数を認識・管理する。

とくにパッケージ製品を利用する場合は明示されていない内部

バッファの存在を把握しておく必要がある。

Software Reliability Enhancement Center

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

電力分野

（9団体が参加）

交通分野

（航空運航システム

研究会と協業）

電子政府

（東京都特別区

有志20区参加）

金融分野

（生命保険

有志15社）

通信分野

（日本ケーブル

テレビ連盟

約160社）

地域インフラ

（北海道インフラ

事業者25組織）

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

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

①行政（自治体）分野

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

Software Reliability Enhancement Center

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

②電力分野

電気事業連合会と協議し、情報共有の取組

みに賛同する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から

システム障害事例、セ

キュリティ事故事例に関する情報

を電力業界

に絡めて編集し、情報提供から実施。

共有の意義を醸成してから、各社からの情報

発信を期待。

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

Software Reliability Enhancement Center

1３．IPAからのご提案

みなさまと同じ業界分野でグループを作り、そこで教訓集を作成し、類似障害

の撲滅を目指しませんか。

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

IPA/SECでは、

定期的に

演習セミナー

を実施しています。

別途、

業界向けセミナー

も行います。

IPAが公開する新着教訓や、新聞や雑誌等で報道され

たシステム障害情報から読み取れる教訓等についてお知

らせする、メールマガジン（教訓集活用メルマガ）を発

信しています。

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

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

詳細は展示ブースを