情報処理システムの高信頼化対策について - IPAエアバスA320の墜落事故（1988～93年）名古屋空港で中華航空機が着陸に失敗炎上（1994年）

Software Reliability Enhancement Center Copyright © 2015 IPA, All Rights Reserved

情報処理システムの高信頼化対策について

独立行政法人情報処理推進機構（IPA）技術本部ソフトウェア高信頼化センター（SEC）

八嶋俊介

2015年 5月14日(木)

2 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center

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)

コード量（ＬＯＣ）

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

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


<出典> 片岡正次郎，鶴田舞，小路泰広：重要インフラ間の相互依存構造のモデル化と地震被害波及シミュレーション，国総研資料第 510 号，国土技術政策総合研究所（国総研），平成21年2月． http://www.nilim.go.jp/lab/bcg/siryou/tnn/tnn0510.htm

相互依存の事例（災害時）

２．インフラシステム間の相互依存

インフラシステムは相互に依存し，システム間のネットワーク連携による複雑化が一層進展


３．グローバル・リスク

Figure 1.1: The Global Risks Landscape 2014

<出典> Global Risks 2014 Ninth Edition, the World Economic Forum

大 ←

影響度

発生確率 → 大

インフラシステム障害

サイバー攻撃

財政危機

水危機

気候変動

失業・不完全雇用

異常気象

所得格差

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


△Therac-25による放射線過剰被爆事故（1985～87年） △エアバスA320の墜落事故（1988～93年） △名古屋空港で中華航空機が着陸に失敗炎上（1994年） △携帯情報端末の発熱－実はソフトの不具合（2009年） △電子カルテシステムの不具合（2010年） □新幹線運行管理システムの障害（2008年，2011年） □銀行オンラインシステムの障害（2011年） □株式売買システムの障害（2012年） □レンタルサーバーのデータ消失（2012年）

△人身事故

□経済事故

過去の事故事例（ソフトウェア起因）

４．過去の情報処理システムの障害事例

ひとたびシステム障害が発生した場合，社会に及ぼす影響範囲が拡大し，その深刻度も増大


4/7 日本生命査定システム障害 4/22 三井住友銀行ATM障害 4/25 八十二銀行ATM障害 4/30 三菱東京UFJ銀行自動送金サービス障害 6/5 JAL重量バランスシステム障害 6/25 スカパーシステム障害 8/4 世田谷区役所システム障害

報告が公開された場合にも，情報はあまり詳しくなく，参考とはなりにくい．

個人的なルートで情報を入手しても，共通の教訓として役立てられない．

５．昨年度発生した主なインフラシステム障害（報道）


現状（教訓の共有なし）

製品機器/ ITサービス

(Ａ社)

社会


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

原因分析対策検討

対策実施

教訓Ａ


対策実施

教訓Ｂ


対策実施

教訓Ｃ

障害障害障害

重要インフラ等

６．インフラシステムの障害の増加

増加傾向

社会経済活動に悪影響を与えたＩＴ障害の発生件数

（月平均、報道ベース）

出典： SEC Journal 第36号（2014年3月発行）

障害の増加にかかわらず対応は当事者ごとに実施され、類似の障害が発生している

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

20072008200920102011201220132014201520162017201820192020


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

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

高信頼化対策の対象

７．ＩＴ障害を引き起こす脅威（要因）


【処理量の増大に対する対処遅れ】アフラックの障害（2013.4.4）・・・一部の保険料金が4月から上がるのに伴い、3月末に駆込みの契約が増えたために処理量が増大。みずほ銀行の障害（2011.3.15～3.24）・・・東日本大震災義援金の受付けが携帯電話を利用した送金サービスの口座に集中し、夜間バッチの件数が上限を超過、長期間にわたりサービス停止。 NTTドコモの障害（2011.8.16, 12.20）・・・スマートフォンの急激な普及により通信量が増大し、設備の容量を超え、通信しにくい状況が発生、別の障害も誘発。

【二重化システムでの待機系切替え失敗】日本生命（2014.4.7）・・・ディスク障害が発生した後、バックアップシステムへの切替えに失敗し、「査定システム」が停止。個人保険に係る保険金・給付金の支払い事務に遅延。 KDDI（2013.4.16）・・・メール送受信サービス障害の解消後、新システムへの切替え中にエラーが発生、現行システムに切り戻し中に過負荷となり、サービス停止。東京証券取引所(2012.2, 2012.8) 富士通データセンター(2012.6) 住信SBIネット銀行（2011.9）気象業務支援センター(2009.3) NTT東日本(2008.11) JR東日本(2008.9)

８．類似のシステム障害の多発


９．障害事例からの教訓の共有と効果

減少させる

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

社会

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


(Ａ社)


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

事例を原因分析・対策検討し一般化・抽象化・普遍化した教訓を体系的に整理する

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

重要インフラ等

社会経済活動に悪影響を与えたＩＴ障害の発生件数

（月平均、報道ベース）

出典： SEC Journal 第36号（2014年3月発行）

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

20072008200920102011201220132014201520162017201820192020


１０．リスクへの対応

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

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

ソフトウェアは相対的に劣化する

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

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

利用者増，技術進展，他

網羅的な事前抽出が困難

経験に学ぶ

冗長構成，など

教訓の活用

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

リスク要因


１１．事例分析、教訓の共有活動（実績）

2015年3月末公開

製品・制御システム分野

ITサービス分野

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

[教訓数]

28件

[教訓数]

27件

普遍化取りまとめ

収集した情報を分析し対策を検討

＜製品・制御システム高信頼化部会＞

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

＞

情報処理システム高信頼化教訓集（ITサービス編／製品・制御システム編）

【参画企業等】

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

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

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

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

アイシン精機（株）

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

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

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

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

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

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

パイオニアシステムテクノロジー（株）

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

九州大学、岡山県立大学

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

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

【参画企業等】

（株）三菱東京UFJ銀行

日本生命保険相互会社

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

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

東京電力（株）

東日本旅客鉄道（株）

KDDI（株）

（株）情報システム総研

（株）オリジネィション

日本大学

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

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

製品・制御システム編

ITサービス編


１２．事例分析・教訓化の特徴

① 共有グループ（部会）活動では、一定の守秘ルールのもとに実際の現場における事例を収集。複数事例のシステム障害対策の比較や分析など掘り下げた議論・検討を実施。

② これまで約１０年間にわたり産学官の連携のもとに蓄積されたソフトウェア・エンジニアリングの幅広い知見を基礎として、普遍性、一般性のある教訓、未然防止策を導出。

③ 各分野の有識者や専門家のご参加のもと、多様化、複雑化する事象を分析・検討。成果は、産業分野を超えて活用可能な教訓としてとりまとめ、セミナー等を通じて、普及・活用を促進。


重要インフラ分野で要求される信頼度を満たすための教訓を以下の2種類に分類し、特定した。１）ガバナンス／マネジメント領域の教訓

No. 教訓ＩＤ教訓概要

1 Ｇ１システム開発を情シス部門だけの仕事にせず、各事業部門が自分のこととして捉える「態勢」をつくることが大切

2 Ｇ２発注者は要件定義に責任を持ってシステム構築にかかわるべし

3 Ｇ３運用部門は上流工程（企画・要件定義）から開発部門と連携して進めるべし

4 Ｇ４運用者は少しでも気になった事象は放置せず共有し、とことん追求すべし

5 Ｇ５サービスの拡大期には業務の処理量について特に入念な予測を実施すべし

6 Ｇ６作業ミスとルール逸脱は、個人の問題でなく、組織の問題！

7 Ｇ７クラウド事業者と利用者が連携した統制がとれたトラブル対応体制を整備すべし

8 Ｇ８共同利用システムでは、非常時対応を含めて利用者間の情報共有を図ること

9 Ｇ９システム利用不可時の手作業による代替業務マニュアルを作成し定期的な訓練を行うべし

１３．教訓一覧（ITサービス）(1/2)


２）技術領域の教訓

No. 教訓ＩＤ教訓概要

10 Ｔ１サービスの継続を優先するシステムにおいては、疑わしき構成要素を積極的にシステムから切り離せ（“フェールソフト”の考え方）

11 Ｔ２蟻の目だけでなく、システム全体を俯瞰する鳥の目で総合的な対策を行うべし

12 Ｔ３現場をよく知り、現場の知識を集約し、現場の動きをシミュレートできるようにすべし

13 Ｔ４システム全体に影響する変化点を明確にし、その管理ルールを策定せよ

14 Ｔ５サービスの視点で、「変更管理」の仕組み作りと「品質管理責任」の明確化を！

15 Ｔ６テスト環境と本番環境の差異を体系的に整理し、障害のリスク対策を練る

16 Ｔ７バックアップ切替えが失敗する場合を考慮すべし

17 Ｔ８仮想サーバになってもリソース管理、性能監視は運用要件の要である 18 Ｔ９検証は万全？それでもシステム障害は起こる。回避策を準備しておくこと

19 Ｔ１０メッシュ構成の範囲は、可用性の確保と、障害の波及リスクのバランスを勘案して決定する

20 Ｔ１１サイレント障害を検知するには、適切なサービス監視が重要

21 Ｔ１２新製品は、旧製品と同一仕様と言われても、必ず差異を確認！

22 Ｔ１３利用者の観点に立った、業務シナリオに則したレビュー、テストが重要

23 Ｔ１４Ｗｅｂページ更新時には、応答速度の変化等、性能面のチェックも忘れずに

24 Ｔ１５緊急時こそ、データの一貫性を確保するよう注意すべし

25 Ｔ１６システム構成機器の修正パッチ情報の収集は頻繁に行い、緊急性に応じて計画的に対応すべし

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

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

１３．教訓一覧（ITサービス）(2/2)


システム要求定義

システム

アーキテクチャ設計

ソフトウェア


ソフトウェア


（変更設計）

実装（コーディング）

レビュー

システムテスト

教育

プロジェクト

マネジメント

運用

No 教訓タイトル

1 複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である ○ ○

2

条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認する

○ ○

3 複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある場合は、条件の抜けがないか確認する。

○ ○

4 変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した上で境界値テストを実施する

○

5 内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること ○ ○ ○ ○ ○

6 フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること ○ ○ ○ ○

7 消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や電源の種類、電池の場合は残量を考慮すること

○

8 想定可能な例外を形式的に漏れなく分析する ○ ○

9 システムを二重化する場合は、同期すべきデータ領域を適切に設定する ○

10 制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する ○ ○ ○ ○

11 プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われているか、あるいはデッドロックが発生していないかどうか注意する

○ ○ ○

12 歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果は異常と判断すべきである

○ ○

13 既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生等と影響を確認する

○ ○ ○ ○ ○

14

・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように注意する・時間帯による負荷変動について考慮する

○ ○ ○ ○

１４．教訓一覧（製品・制御システム）(1/2)


１４．教訓一覧（製品・制御システム）(2/2)

システム要求定義

システム


ソフトウェア


ソフトウェア


（変更設計）

実装（コーディング）

レビュー

システムテスト

教育

プロジェクト

マネジメント

運用

No 教訓タイトル

15 納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リセット、電源断、放置も含め）、への対応を考える

○ ○

16 障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること ○

17 判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する ○

18 ログファイルの断片化に注意する ○

19 人による変更作業ではミスが起きることを前提に、ツール活用などで不具合の作り込みや流出の防止に心がける

○ ○ ○

20 信頼性向上施策を採る場合は、故障発生確率と影響の定量評価を行い、対策は確実に実装する ○ ○ ○ ○

21 高い信頼性対策が求められるシステムでは重大な影響を及ぼす事象の想定と復旧手順を十分に検討する

○ ○

22 処理時間がクリティカルなシステムではツールを活用し、変数やその取りうる状態数とそれぞれの状況における動作処理に最大バラツキを意識し余裕を把握し設計する。

○ ○ ○ ○ ○

23 開発を伴わない保守案件でも，システム構成変更が発生する場合は，手順等作業内容の妥当性を確認できるようなプロセスを経る

○ ○ ○ ○

24 物理量（時間、重量など）を扱う場合は単位、桁数を確認する。 ○ ○ ○

25 顧客が要求していることの目的と背景に遡って、その意図を確認することが、要求仕様のあいまいさ排除に役立つ

○ ○

26 遠隔地等物理的に離れた装置をネットワーク接続して稼働させるシステムでは、故障などの状態検知やメンテナンスも容易ではないため、システム的視点での状態把握を行う。

○ ○ ○

27 マルチベンダーシステムでは仕様に外れた想定外事象が発生することを前提とした自己防衛策を採る。

○ ○ ○

28 データベース等COTS製品のバージョン、動作仕様の相違等の情報が関係者にタイムリーに参照できるようにする

○ ○ ○ ○


１５．「教訓集」の構成

PART Ⅰ 教訓集（本編）

PART Ⅱ 障害対策手法・事例集

PART Ⅲ 障害分析手法・事例集

付録A 障害情報の取扱いルール

情報処理システム高信頼化教訓集（ITサービス編）の本体

今回の活動の中で実施した、障害の分析手法・事例の調査結果をまとめたもの

障害情報を報告・記録する共通様式と、それらの収集・公開に際しての機密保持等のルールをまとめたもの

教訓集中の各教訓を実践するために必要な手法を整理したもの


１６．類似障害へ適用できる教訓（例）

【二重化システムでの待機系切替え失敗】を予防したい・・・

[教訓Ｔ７]バックアップ切替えが失敗する場合を考慮すべし、の対策を実施する

KDDI（2013.4.16）・・・メール送受信サービス障害の解消後、新システムへの切替え中にエラーが発生、現行システムに切り戻し中に過負荷となり、サービス停止。

JR九州（2013.7.18）・・・列車進路制御装置の外部記憶装置の交換により情報のやり取りに不具合が発生し、システム全体にトラブルが波及。

対策１１＞本番稼働に近いテスト環境を用意し、OS、ミドルウェアのバージョンアップ時の動作確認と性能（負荷）確認が行えるようなツールを作成する。対策１２＞冗長化を実施する場合、すべての機器（単体機器、または密結合の機器）が冗長化されていることを常に点検する。

対策７＞バックアップ切替え後、縮退運転の場合でのピーク時性能は、日常の監視の中で想定し、必要に応じてシステムを見直す。対策８＞本番稼働に近いテスト環境を用意し、性能（負荷）確認が行えるようなツールを作成する。対策９＞切替え、縮退運転の性能要件（ピーク時）は、設計時に明確にする。


１７．教訓共有のメリット ◆“教訓”集の活用によるメリット

①さまざまな分野での経験から得られた教訓（開示レベル：公開用）の中から自社に適

用可能なものを見つけ、活用することができる。

◆情報共有の仕組みへの参加によるメリット

①情報共有のグループ（教訓化過程）への参加により、公開教訓より深い情報（開示レ

ベル：グループ内限り）が得られる。

②自社の事例情報に対する有識者や他分野の専門家等からの意見や、教訓化（抽象

化）の議論を通した気づきが得られる。

③（分野間の共有により）他分野の方々とも交流が深まる。


１８．各産業分野における教訓の共有活動

各産業分野における教訓の共有活動の例（１）障害事例から得られた教訓の共有活動の実施

①ＷＧなど共有の場における意見交換 ②電子掲示板・メーリングリスト等を活用した適時の情報共有

（２）関心テーマに関する勉強会やセミナーの開催（３）業界内での教訓の活用 ①未然防止に向けた自組織の運用ルール等の見直し ②障害事例から学ぶＩＴ人材教育（４）業界内での検討により得られた新たな教訓の提供


グループウェア機能（主なもの）サーバデータ

Knowledge Suite（グループウェア）

インターネット

掲示板（トピック）

ファイル共有

IPA/SEC 各企業様

担当研究員運営事務局 A社ご担当様 B社ご担当様

※管理する単位は検討する。お互いに非公開な情報を保有することが可能。

注）Knowledge Suite（SaaS事業者のグループウェア：IPAがユーザとして契約している）

１９．ネットワークを利用した情報共有


トピック機能

IPA/SECからの情報提供

障害事例

技術相談

障害事例の報告を行う。

ITに関する技術相談を行う。

教訓活用の相談を行う。

教訓集の発行やIPA/SECの成果物、IPAの成果物などの情報を提供。

教訓活用

２０．情報共有のメニュー


２１．教訓を活用する手順

現状のＩＴシステム

改善後のＩＴシステ

ム

教訓の適用プロセス

教訓適用手順・事例

教訓適用

教訓の適用の見極め

設計実装

効果測定/評価活用する教訓Ｇ１事業部門が責任をもってＧ２発注者の責任Ｔ６テスト環境と本番環境の差異整理Ｔ７バックアップの失敗・・・

教訓集

※教訓活用の分担・適用や効果測定/評価は各メンバが実施する・IPA/SECからは過去の適用事例に基づく助言などを行う


２２．教訓集はこんな使い方もできます

１．ITの経験者から若手へのノウハウ移転(若手の人材育成) 以下のように教育の中で活用する。まず教訓を読み、ケーススタディでワークショップを行って、感想を述べあう。これにより、世代を超えてＩＴの疑似体験によるノウハウ共有が図れる。

３．暗黙知を形式知にする活動の推進まずは、教訓集の教訓を説明して展開する。次に自分の教訓を持参して説明しさらに教訓が拡大し、参加者の輪も広がっていく。このサイクルで、自動的／自律的にＩＴ教訓の輪が展開されていく。

２．同業他社とのノウハウ交流に活用同業他社の連絡会などで、教訓集を使い情報交換を行う。これを参考に、現在かかえている問題や対策の知恵を出し合うことで、情報交換の輪がひろがる。


Windows Server 2003のサポートが、2015年7月15日に終了します。サポート終了後は修正プログラムが提供されなくなり、脆弱性を悪用した攻撃が成功する可能性が高まります。

サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの影響調査や改修等について計画的に迅速な対応をお願いします。

会社の事業に悪影響を及ぼす被害を受ける可能性があります

IPA win2003 検索詳しくは

またWindowsXPを利用されている方はサポートが継続しているOSへの移行検討をお願いします

脆弱性が未解決なサーバ

脆弱性を悪用した攻撃

ホームページの改ざん

重要な情報の漏えい

他のシステムへの攻撃に悪用

業務システム・サービスの停止・破壊

データ消去

Windows Server 2003のサポート終了に伴う注意喚起


「ｉパス」は、ITを利活用するすべての社会人・学生が備えておくべき ITに関する基礎的な知識が証明できる国家試験です。

ITパスポート公式キャラクター上峰亜衣（うえみねあい）

【プロフィール：マンガ】 https://www3.jitec.ipa.go.jp/JitesCbt/html/uemine/profile.html


IPA ソフトウェア高信頼化センター(SEC) Software Reliability Enhancement Center , Information-technology Promotion Agency , Japan

で、 IPA/SECの事業内容やセミナー動画をCheck！

●SEC事業紹介 http://www.ipa.go.jp/sec/about/index.html

●SECセミナーオンデマンド http://sec.ipa.go.jp/seminar/ondemand/

Twitterで、 IPA/SECの最新情報をCatch！

https://twitter.com/IPA_SEC

アカウント名：＠IPA_SEC

SWE iPediaで、 IPA/SECの事業成果をSearch！

探したい情報を

分類やキーワードで検索！

http://sec.ipa.go.jp/sweipedia/

IPA/SECウェブサイトで利用者登録！ IPA/SECウェブサイトから利用者登録（無料）をすると、メルマガ・DMの購読や、セミナーの参加申込み、ツールの利用などができます。是非、ご登録ください！

https://sec.ipa.go.jp/entry/index.html

↓詳しくは、SECウェブサイトをClick！

ソフトウェア高信頼化センター検索

Documents

情報処理システムの高信頼化対策について - IPAエアバスA320の墜落事故（1988～93年） 名古屋空港で中華航空機が着陸に失敗炎上（1994年）

情報処理システムの高信頼化対策について - IPAエアバスA320の墜落事故（1988～93年）名古屋空港で中華航空機が着陸に失敗炎上（1994年）