プロローグ 2

システム障害事例情報の分析に基づく

教訓・対策を共有する仕組み

～智の共有が安心・安全社会を創る～

ET2014（ブースプレゼンテーション）

2014年11月20日

独立行政法人情報処理推進機構（ＩＰＡ） 技術本部 ソフトウェア高信頼化センター（ＳＥＣ） 山下 博之

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月．P73 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

参考

大

←

影

響

度

発生確率 → 大

重要インフラの ITシステム障害 サイバー攻撃 財政危機 水危機 気候変動 失業・不完全雇用 異常気象 所得格差 生物多様性 損失と 生態系崩壊

 Therac-25による放射線過剰被爆事故（

1985～87年

）

 エアバスA320の墜落事故（

1988～93年

）

 名古屋空港で中華航空機が着陸に失敗炎上（

1994年

）

 携帯情報端末の発熱－実はソフトの不具合（

2009年

）

 電子カルテシステムの不具合（

2010年

）

 新幹線運行管理システムの障害（

2008年

，

2011年

）

 銀行オンラインシステムの障害（

2011年

）

 株式売買システムの障害（

2012年

）

 レンタルサーバーのデータ消失（

2012年

）

 人身事故

 経済事故

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

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

参考

ひとたびシステム障害が発生した場合，

社会に及ぼす影響範囲が拡大し，その深刻度も増大

0 10 20 30 40 50 60 多大な影響を与えたITサービス障害の 発生件数（報道ベース）の推移 件 背景

情報処理システム障害の発生状況

・△△でリコール、国内で数十万台 …理由は、制御プログラムに不具合が発見された ためという。 ・○○システムで障害か、終日つながりにくく …原因は、法律改正直前の駆け込み需要と期末の 締め処理とが重なり、想定外の大量入力にシステ ムの性能が耐えられなかった模様。 ・□□システムで障害、午前中のサービス停止 …原因は、システムは本番装置の故障により予備 装置に自動的に切り替わるようになっていたが、 その切替えが失敗したためという。

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

システム障害の発生件数

2009年以降で増加傾向

新聞やテレビなどのメディアでは， 幾度となく以下のようなニュースが 世間を賑わせている： 類似障害の発生 (出典) SEC Journal 情報システムの障害状況

◆処理量の増大・環境変化に対する対処遅れ 1. みずほ銀行の障害…2011.3.15～3.24 東日本大震災義援金の受付けが携帯電話を利用した送金サービスの口座に集中し，その処 理を行う夜間バッチの件数が上限を超えたことをきっかけに，事後対応のまずさもあり，長期間 にわたりサービス停止の事態に． 2. アフラックの障害…2013.4.4 一部の保険料金が4月から上がるのに伴い，3月末に駆込みの契約が増えたために処理量が 増大し，夜間バッチが想定の時間内に終了しなかった可能性大． 3. NTTドコモの障害…2011.8.16, 2011.12.20 スマートフォンの急激な普及により通信の質が変化すると共に量も増大し，設備の容量を超え たために，通信しにくい状況に．このことが別の障害も誘発． 4. KDDI（ａｕ）の障害…2013.4.16～18 スマートフォンによるメールの送受信等が使用できない状況が断続的に発生したが，利用の急 増に対応するための設備増強の遅れが根本原因と報道されている．(4/18 日経電子版) ◆二重化システムにおける待機系への切替え失敗 日本生命（2014.4.7），JR九州（2013.7.18），KDDI（2013.4.16），東京証券取引所 (2012.2, 2012.8)，富士通データセンター(2012.6)，住信SBIネット銀行（2011.9），気象 業務支援センター(2009.3)，NTT東日本(2008.11)，JR東日本(2008.9) 参考

類似障害の発生状況

背景

情報処理システムの信頼性向上

システムの

構築時

→初期リスク（故障）回避

システムの

運用時

→様々なリスクに対応

ソフトウェア・エンジニアリング技法の活用

はるかに長期間

体系的な取組みが必要

着目点は．．．

初期故障期 偶発故障期（安定期） 摩耗故障期 故 障 率 ＜環境変化＞ 新サービス追加 法制度改正 利用増大(量) 利用形態変化(質)

<故障率曲線の原図> "Bathtub curve" by en:User:Wyatts U.S. Army document. Licensed under Public domain via ウィキメディア・コモンズ -http://commons.wikimedia.org/wiki/File:Bathtub_curve.jpg#mediaviewer/File:Bathtub_curve.jpg

背景

リスクへの対応

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

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

ソフトウェアは相対的に

劣化する

使われる環境の変化

 ビジネス方針，ニーズ

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

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

ウハウ継承無し）

 利用者増，技術進展，他

網 羅 的 な 事 前 抽 出 が 困 難

失敗に学ぶ

冗長構成，など

教訓の活用

障害事例に基づく

教訓・対策の共有

リスク要因

（障害事例）情報の共有

経験を共有し、みんなの力でIT社会の安全・安心を

築くしくみ

 情報処理システム

障害の事例情報を収集・分析

 それにより得られた

教訓と対策

を整理・体系化

 教訓と対策を業界を越えて横断的に広く

共有

リスク低減のための体系的な取組み

「他山の石」

「他山の石」の意味

※ ※(出典) 文化庁月報 平成23年10月号(No.517) http://www.bunka.go.jp/publish/bunkachou_geppou/2011_10/series_08/series_08.html

他人の誤った言行やつまらない出来事でも

それを参考にしてよく用いれば，

自分の修養の助けとなる

失敗に学ぶ → 類似障害の発生を防止できる

「対岸の火事」

各社でやるだけでよいのでは？

経験豊富でも，すべてをカバーできますか？

Ａ社のカバーエリア Ｂ社のカバーエリア Ｃ社のカバーエリア

ITサービス機能・システム複雑度 低 高 狭 広 カ バ ー 範 囲 率 1社のみ 社会全体 時代の流れ 高信頼化

みんなの力で全体をカバー

ITサービスの機能やシステムが複雑化す

ると，単一事業者のカバーする知見の範

囲は，相対的に狭くなる．

1事業者に囲われた経験と情報を幅広

く社会全体で共有し、障害対策などに

有効活用できることが重要．

「情けは人のためならず」

「情けは人のためならず」の意味

※1

人に対して情けを掛けておけば，

巡り巡って自分に良い報いが返ってくる

※1 (出典) 文化庁月報 平成24年3月号(No.522) http://www.bunka.go.jp/publish/bunkachou_geppou/2012_03/series_08/series_08.html

“社会間接互恵性”

※2

ある個体が利他行動(他者に親切にする行動)を行った結

果、その個体の評価が高まり、他者に行った利他行動が回

り回って別の他者から返ってくる仕組み

※2 (出典) 大阪大学大学院人間科学研究科の実証実験成果から 2013年8月8日 http://www.osaka-u.ac.jp/ja/news/ResearchRelease/2013/08/20130808_1 「ヒト」は，日常生活で困っている他人を見ると，それが自分の知らない人で あっても助けたい衝動にかられ，多くの場合何らかの親切を行う性質を持つ

・あるITサービス/製品機器は，他のITサー ビス/製品機器に依存することがある． ・ITシステムの中に，製品機器を含むこと がある． エネルギー系 情報処理/制御システム 交通系 情報処理システム データセンター/クラウド 医療機器 _金融系 情報処理システム 制御機器 制御機器 国民生活・社会経済活動 情報通信系 情報処理/制御システム

他サービス/製品機器の障害は，

自サービス/製品機器にも

影響が及び得る

相互に結びつくITサービス/製品機器

相互に依存

障害事例の公開なんて出来ない！

社会（の人々）は思ったより成熟している

社会の在るべき姿

信頼できる企業とは？

“コミュニティ”

オープンソース，ソーシャルネットワーク，など

貢献と尊敬・信頼

アンケート例（1/3）

59.2%

25.0%

3.9%

1.3%

0.0%

0.0%

10.5%

障害事例情報共有の取組みについて、

どのように思われますか？

（回答者76名）

１．社会にとって有用であり、成果は自 社に役立つだろう ２．社会にとって有用であるが、成果は 自社に役立つか不明 ３．社会にとって有用であるが、成果は 自社には役立たない ４．社会にとって有用かどうかは分から ない ５．社会にとって有用とは思われない ６．分からない 無回答 ＜アンケート回答者（計76名）＞ ET2013（2013年11月） ソフトウェアジャパン（2014年2月）

アンケート例（2/3）

28.6%

58.4%

2.6%

0.0%

10.4%

社会として、どうあるべきと思われますか？

（回答者76名）

１．基準を設定し、それ以上の影響があった障害事 例に基づく教訓は、広く社会で共有されるべきであ り、各当事者が対応するのがよい ２．基準以上の障害事例に基づく教訓は、広く社会 で共有されるべきであり、所定のルールの下で、関 連公的機関が取りまとめるのがよい ３．障害事例に基づく教訓は、社会で共有される必 要はない ４．その他 無回答 ＜アンケート回答者（計76名）＞ ET2013（2013年11月） ソフトウェアジャパン（2014年2月）

アンケート例（3/3）

0.0%

82.9%

2.6%

2.6% 11.8%

障害事例情報を公開する企業に対して、どのように思

われますか？（回答者76名）

１．障害を発生させていることから、信 頼できない ２．積極的に情報公開をすることから、 公開しない企業に比べて信頼できる ３．特に何とも思わない ４．その他 無回答 ＜アンケート回答者（計76名）＞ ET2013（2013年11月） ソフトウェアジャパン（2014年2月）

具体的にはどうやればよいの？

本日の主題：

システム障害事例情報の分析に基づく

教訓・対策を共有する仕組み

IPA/SECの取組みの概要を説明

具体的内容は，この後に続く２件の講演で

 事例から学ぶ製品・制御システムの高信頼化へのアプローチ  事例から学ぶITサービスの高信頼化へのアプローチ

内 容

1. IPA/SECの概要…省略

2. IPA/SECの取組み

「重要インフラ等システム障害対策」など

3. これまでの成果概要

ITサービス高信頼化“教訓集”

システム障害事例の分析に基づく対策・教訓の共有の仕組み

4. 今後の取組み

業界を超えた“教訓”共有の仕組みの展開

5. まとめ

◇重要インフラ分野のシステム障害への対策

経験を共有し、みんなの力でIT社会の安全・安心を築くしくみ

具体的には，

重要インフラ分野

*

_{等のシステム障害の事例を分析し，それにより得られた}

教訓と対策

を整理・体系化した上で，再発防止策を，業界を越えて横断

的に広く

共有

する仕組みの構築を目指す．

* 情報通信，金融，航空，鉄道，電力，ガス，政府・行政サービス，医療，水道，物流，クレジット，石油，化学 http://www.ipa.go.jp/sec/system/index.html ２．IPA/SECの取組み

重要インフラ分野における高信頼化対策（IPA）

２．IPA/SECの取組み 障害に基づく教訓の共有による信頼性向上のしくみ 現状（教訓の共有なし） 製品機器/ ITサービス (Ａ社) 社会 社会 より高い安全・安心な 製品機器/ITサービスの提供 製品機器/ ITサービス (Ｂ社) 製品機器/ ITサービス (Ｃ社) 信 頼 性 信 頼 性 信 頼 性 原因分析 対策検討 対 策 実 施 教 訓 Ａ 原因分析_対策検討 対 策 実 施 教 訓 Ｂ 原因分析_対策検討 対 策 実 施 教 訓 Ｃ 製品機器/ ITサービス (Ａ社) 製品機器/ ITサービス (Ｂ社) 製品機器/ ITサービス (Ｃ社) 信 頼 性 信 頼 性 信 頼 性 原因分析・対策検討 一般化・抽象化・普遍化 体系的整理 教 訓 Ａ教訓 Ｂ教_訓 Ｃ 対策実施 対策実施 対策実施 障害 障害 障害 障害 障害 障害 重要インフラ等 重要インフラ等

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

専門家，有識者のご協力を得て IPA/SECや業界団体等が担う共有活動 教訓 教訓 教訓 機密保持等 のルール 類似障害の発生 情報セキュリティ 航空 原子力 金融

2014年5月13日公開

IPAにおける事例分析，教訓の共有活動 （実績）

＜特徴＞ ①業界・分野を超えて活用可能な普遍化された教訓。 ②機密保持ルールの下で詳細情報の提供を受けた深い議論。 ③蓄積されたソフトウェア・エンジニアリングに関する知見の活用。 http://www.ipa.go.jp/about/press/20140513.html ２．IPA/SECの取組み

３．これまでの成果概要

PART Ⅰ 教訓集（本編）

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

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

付録A

障害情報の取扱いルール

情報処理システム高信頼化教訓集 （ITサービス編）の本体 今回の活動の中で実施した、障 害の分析手法・事例の調査結果 をまとめたもの 障害情報を報告・記録する共通 様式と、それらの収集・公開に 際しての機密保持等のルールを まとめたもの 教訓集中の各教訓を実践するため に必要な手法を整理したもの

「教訓集」の構成

教訓番号 教訓タイトル 1 複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である ○ ○ 2 条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条 件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認す る ○ ○ 3 複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある_{場合は、条件の抜けがないか確認する。} ○ ○ 4 変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した_{上で境界値テストを実施する} ○ 5 内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること ○ ○ ○ ○ ○ 6 フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること ○ ○ ○ ○ 7 消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や_{電源の種類、電池の場合は残量を考慮すること} ○ 8 想定可能な例外を形式的に漏れなく分析する ○ ○ 9 システムを二重化する場合は、同期すべきデータ領域を適切に設定する ○ 10 制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する ○ ○ ○ ○ 11 プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われている_{か、あるいはデッドロックが発生していないかどうか注意する} ○ ○ ○ 12 歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果_{は異常と判断すべきである} ○ ○ 13 既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生_{等と影響を確認する} ○ ○ ○ ○ ○ 14 ・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように 注意する ・時間帯による負荷変動について考慮する ○ ○ ○ ○ 15 納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リ_{セット、電源断、放置も含め）、への対応を考える} ○ ○ 16 障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること ○ 17 判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する ○ 18 ログファイルの断片化に注意する ○ シ ス テ ム テ ス ト 教 育 プ ロ ジ ェ ク ト マ ネ ジ メ ン ト 運 用 シ ス テ ム 要 求 定 義 シ ス テ ム ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 （ 変 更 設 計 ） 実 装 （ コ ー デ ィ ン グ ） レ ビ ュ ー ３．これまでの成果概要 複雑な条件式のロジッ ク変更を行う場合は、デ シジョンテーブル等によ る検証が有効である 歩留りのある製品の良 品／不良品を検査する 装置では、全てが良品 あるいは、不良品との 検査結果は異常と判断 すべきである 消費電力の多い機 能を追加する場合 には、一時的な電 圧降下による影響 （リセット、フリーズ 等）や電源の種類、 電池の場合は残 量を考慮すること

教訓一覧（製品・制御システム）

３．これまでの成果概要 組織連携 発注者責任 要求 設計 製造 試験 運用 1 Ｇ１ システム開発を情シス部門だけの仕事にせず、 各事業部門が自分のこととして捉える「態勢」をつくることが大切 ○ 2 Ｇ２ 発注者は要件定義に責任を持ってシステム構築にかかわるべし ○ 3 Ｔ１ サービスの継続を優先するシステムにおいては、 疑わしき構成要素を積極的にシステムから切り離せ （“フェールソフト”の考え方） ○ 4 Ｔ２ 蟻の目だけでなく、 システム全体を俯瞰する鳥の目で総合的な対策を行うべし！ ○ ○ 5 Ｔ３ 現場をよく知り、現場の知識を集約し、 現場の動きをシミュレートできるようにすべし！ ○ ○ ○ 6 Ｔ４ システム全体に影響する変化点を明確にし、 その管理ルールを策定せよ！ ○ 7 Ｔ５ サービスの視点で、 「変更管理」の仕組み作りと「品質管理責任」の明確化を！ ○ 8 Ｔ６ テスト環境と本番環境の差異を体系的に整理し、 障害のリスク対策を練るべし ○ ○ ○ 9 Ｔ７ バックアップ切替えが失敗する場合を考慮すべし ○ ○ ○ ○ 技術 No ガバナン ス／マネ ジメント 技術 領域 ＩＤ 教訓概要 ガバナンス/マネジメント

教訓一覧（ITサービス）

各教訓の説明

・自社事例を“教訓”化するための議論の中で，

“気づき”

を得ることが

あった．

・他分野の事例紹介では，

鉄道の線路を送電線に置き換えて

考えてい

る．

・他分野の事例の中に参考になるところがあった．

・他分野の事例ではあるが，今回の障害に関連する情報として，（特に

外国製の）パッケージ利用における留意点を知りたい．

・クラウドの活用が拡がりつつある中で，まだあまり事例が多くない障害

情報の共有ができればありがたい．

・今回の自身の障害の教訓としては，システム停止時の手動での業務

のやり方を決めて，普段から訓練しておく必要がある，ということ．

３．これまでの成果概要

共有活動への参加者の声，参加予定者からの期待等

４．今後の取組み

整理・体系化：分析と議論を通して分かったこと（例）

1. 多忙時や例外対応時に起こしやすい「ルール逸脱」

システム運用の厳格なルールが定められているにもかかわら

ず，多忙のために，あるいは，例外的事象発生時の対応のため

に，そのルールで規定されていない簡易な方法（例：ローレベ

ルの強力コマンドの使用）で操作することにより，重大事故を

引き起こし易い．ベテラン技術者でも起こし得る．

過信して，油断して，「叱られたくない」ために，等々．

2. システム停止中の「人手」による業務手順の規定要（IT-BCP）

迅速な顧客対応が必要な業務等については，システム停止時

には，可能な範囲で，人手等で対応する計画（IT-BCP）をあら

かじめ策定し，訓練しておくことが重要．

参考

人間系の要因分析(1/2)

＜出典＞

太田氏（株式会社ジャステック） の調査検討資料

参考

人間系の要因分析(2/2)

＜出典＞

太田氏（株式会社ジャステック） の調査検討資料

事例と 根本原因 対策 対策 対策 対策 普遍化 有識者・専門家 による機論 Ａ分野 Ａ分野 Ｂ分野 Ｃ分野 高 低 抽 象 レ ベ ル

共有

各分野で展開 コンテキスト コンテキスト コンテキスト コンテキスト 各組織での活用時，システマティックな取組み： 教訓と共に提供されるコンテキストと 自身のコンテキストとを比較・照合し， 適用可能な教訓について，具体的対策を検討

一般化・抽象化

された教訓

共通コンテキスト

★：本質

★ ★ ★ ★ ★ ４．今後の取組み

教訓の共有

（社会で）

と活用

（各組織で）

“想像力”

が重要

* FP発生不具合密度：ファンクションポイント（機能規模）当たりに発生する不具合（バグ）の数

品質保証体制の専門スタッフ

がいるプロジェクトの方が，

そうでないプロジェクトに比べ，プロダクトの信頼性が高い

4.8 12.2

約2.5倍

N=63 (37+26) 出典：「ソフトウェア開発データ白書2014-2015」(IPA/SEC) 低 ← 信 頼 性 → 高 優れた品質保証体制の組織 参考

優れた品質保証体制の組織のプロダクトは信頼性が高い

システマティック

な取組みの効果

統計データ例

【教訓タイトル】 ＜抽象的な表現の例＞ システムの部分変更（に伴う新旧混在）時に（非変更部分との）整合性を確認する． ＜具体的な表現の例＞ 変化に対応して（プログラム／システム定義データ中の）定数をチェックする．

参考：教訓の一例(1/5)

★：本質

【説明】 交換（部分変更）する構成要素（ソフトウェアを含む）は，交換前のものと互換 性があるという仕様になっていても，機能やインタフェースが一部異なっている かもしれない．特に，新機能が追加されていることがよくある．異なる技術が用 いられている場合には，設計思想そのものが異なっていることもある．また，機 能は同じでも，性能等の非機能特性が異なるケースは多い． したがって，交換する構成要素と，システムの他の部分（交換しない部分）とが 整合するかについて，様々な視点から確認する必要がある． 特に，性能差がある場合，タイマ監視等を行う処理においては，監視タイマ値の 妥当性を入念にチェックし，チューニングをやり直す必要がある．特に，新しい 構成要素の特性が性能に影響する場合を見逃してはならない． 共通コンテキスト

参考：教訓の一例(2/5)

【問題（障害事例）】 ◆概要 2013年7月18日，ある鉄道会社にて，列車運行を管理するシステムのうち， ダイヤに基づき各駅の信号機を自動制御する「自動列車進路制御装置(PRC)」の 保守時に異常が発生．その後バックアップ系統への切替えに失敗し、装置が停止． 管轄する3路線の鉄道が2時間以上運行できなくなり，385本が運休，約11.1万 人に影響． ◆状況 午前4時，装置の部品（今回の要因となった部品とは別のもの）の交換作業を 始めると，アラームが鳴動． 復旧のため，機器内に２つある処理系統のうち上記部品交換を行ったのとは別 の系統（バックアップ系統）を起動させようとしたものの，起動せず． 交換対象の部品を戻して再起動する等を試みたが，装置は復旧せず． ５時半頃に予備の装置を使ってシステム全体の復旧に取り掛かり，６時54分 に復旧．７時半頃から順次運転を再開． (個別)コンテキスト <参考> 新聞等の報道記事

【（直接の）原因】 自動列車進路制御装置(PRC)のディスクとして，もとはHDDが使用されていた が，2010年からSSDに交換されていた．（交換当時は，現用・待機両系停止の 状態で装置を起動する試験のみを実施し，潜在リスクを発見できず．） その後，PRC内部のある故障部品を交換する必要が生じ，現用系のみを停止し て実施することとした．工場での事前確認では，同じ装置がなかったため，HDD 搭載装置での試験を行い，SDD搭載装置ではできなかった．このような状況で， 現場で実際の交換作業において，PRCの現用系停止状態で待機系を起動させた． 装置の仕様上，初期起動時に，CPU上のOSがディスクにリセット要求を行い， その完了をタイマ監視（タイマ値=200ms）で待つ．HDDの場合には1msで完 了するが，今回の装置に搭載されていたSSDでは300msが必要であった． したがって，タイムアウトを検出したOSはディスクの異常と判断して停止要求 を行い，SSDはそれを不正コマンドとして受け付けず，外部からのコマンドを拒 否するモードに移行． 【今回の対処】 OSの監視タイマ値を200msから360msに変更． <参考>(1) 日経エレクトロニクス，2013.8.9. (2) 日経コンピュータ，2013.9.10.

参考：教訓の一例(3/5)

(個別)コンテキスト

【教訓活用時のコンテキスト】 (1) 比較的大規模なシステムにおいて，システムの構築あるいは更改を段階的に 行う場合，版や性能等の異なる構成要素が混在することになるケース (2) 比較的長期間使用しているシステムにおいて，あるいは技術進展の激しい分 野において，一部の部品を当時の最新の（or 通常出回っている）ものと交換 するケース

参考：教訓の一例(4/5)

【対策（例）】 ◆コンポーネント・レベル ・ミスを起こさない：特にメンテナンス時における，ハード担当と制御ソフト担 当とのコミュニケーションの徹底（気づかせるための会議，文書の工夫等） ・ミスを逃さない ：試験時の思い込み（“互換性”への過信）排除（第三者の関 与等）．標準規格の規定事項/規定外事項の明確化 ◆システム・レベル ・ミスを起こさない：変化点を捉えた，俯瞰的かつ系統的な設計レビュー ・ミスを逃さない ：試験時における，本番環境との相違点に関するリスク評価 共通コンテキスト

【教訓の活用（例） 】 (1) 比較的大規模なシステムにおいて，システムの構築あるいは更改を段階的に 行う場合，版や性能等の異なる構成要素が混在することになるケース 多数のサーバと端末装置から成るシステムにおいて，当初は全体を一括で構 築したものの，端末の更改を，毎年一部ずつ順に行うような場合，新規端末の性 能が当初端末より高い場合には，サーバとの通信における応答待ちタイマ値等を チューニングし直す必要があるかどうか，検討する． (2) 比較的長期間使用しているシステムにおいて，あるいは技術進展の激しい分 野において，一部の部品を当時の最新の（or 通常出回っている）ものと交換 するケース 装置内のメモリを増量のために大容量チップに交換する際，大容量のために 前のものよりアクセス時間が若干長い仕様となっている場合，CPUやDMAデバイ スとの整合性を確認する．

参考：教訓の一例(5/5)

(個別)コンテキスト

４．今後の取組み

障害事例情報に基づく教訓共有の仕組みの展開イメージ

分野・業界Ａ内 の情報共有 分野・業界Ｅ内 の情報共有 分野・業界Ｄ内 の情報共有 分野・業界Ｂ内 の情報共有 分野・業界Ｆ内 の情報共有 分野・業界Ｃ内 の情報共有 企業 a1 企業 a2 企業 a3 企業 a4 企業 a5 企業 a6 企業 b2 企業 b1

・・・

企業 d1 分野・業界にまた がる情報共有 企業 d2 企業 d3 企業_e3 企業 e2 企業 e1 企業 c1 企業 c2 企業 f1 企業 f4 企業 f3 企業 f2 企業 f5

・・・

応用分野に関す る情報共有 地域団体による 情報共有

教訓

・・・

企業 g1 企業 h1

目指す社会

に向けて

５．まとめ

お願い

具体的内容は，

この後に続く２件の講演で

 事例から学ぶ製品・制御システムの高信頼化 へのアプローチ  事例から学ぶITサービスの高信頼化へのアプ ローチ

失敗に学ぶ，システムの信頼性向上のために，

経験の共有にご理解とご協力をお願いします

http://www.ipa.go.jp/sec/index.html

ご清聴，ありがとう

ございました

アンケートへのご協力を

よろしくお願いいたします．

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

Windows Server 2003のサポートが、2015年7月15日に終了します。

サポート終了後は修正プログラムが提供されなくなり、脆弱性を悪用した攻撃が成功す る可能性が高まります。 サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの 影響調査や改修等について計画的に迅速な対応をお願いします。 会社の事業に悪影響を及ぼす被害を受ける可能性があります

IPA win2003

検索 詳しくは ■WindowsXPを利用されている方は、サポートが継続しているOSへの移行検討をお願いします 脆弱性が 未解決なサーバ 脆弱性を 悪用した攻撃 ホームページの改ざん 重要な情報の漏えい 他のシステムへの攻撃に悪用 業務システム・サービスの停止・破壊 データ消去 IPA XP移行 検索

国家試験

ｉパス

検 索

iパスは、IT化された社会で働く

すべての社会人が備えておくべき

ITに関する基礎知識を証明する国

家試験

です。

公式キャラクター 上峰 亜衣 日本の元気 をiパスで！

Check！ Catch！

Search！

社会智（１／４）

『津波てんでんこ』

東北地方を中心に語られる防災教訓の一つ

「津波が来たら、各自てんでんばらばらに高台へと逃げろ」

昔から津波の多かった三陸沿岸地域で語り継がれてきた内容（体験

に基づくもの）

この教訓の精神に基づいて、日頃の備えや訓練を行っておくことによ

り、津波の被害から免れることができる

東日本大震災における「釜石の奇跡」と呼ばれる事例で実証済

社会智（２／４）

医療・医学における知見例

出典：乳がんと喫煙――「いつやめるか？」「今でしょ！」と言いたくなるデータ (朝日新聞，2014.1.14)

数多くの協力者からの収集データの分析によりまとめられたもの

非喫煙者 禁煙者 喫煙継続者 (＊＊) 喫煙指数 20未満 喫煙指数 20～34.9 喫煙指数 35以上 乳がん再発 1 0.98 (*) 1.22 1.37 1.41 乳がん死亡 1 0.99 (*) 1.14 (*) 1.54 1.61 総死亡 1 0.97 (*) 1.26 1.68 2.17 (非喫煙者のリスクを１とする) (*) 誤差範囲に留まる結果 (**) 喫煙継続者の喫煙指数の平均は３９ 生涯を通した喫煙量と乳がんとの関係

社会智（３／４）

＜ポイント＞

暗黙知の形式知化

社会智

智の運用

情報の(セミ)オープン化

経験をデータに基づいて見える化，整理・体系化

社会にとって役立つ知見

知見に基づき行動する，知見を継承するための，不断の努力

智の共有による，社会（自身もその一員）への恩恵

多様な意見に基づく，ブレークスルー/イノベーションの創出

社会智（４／４）

暗黙知

形式知

（知識）

形式知

（智恵）

個有

共有

組織

社会

現状

現状

現状

個人が 目指すところ 企業が 目指すところ 人類が 目指すところ 当面の マイルストーン

見える化

分析・体系的整理

＜参考文献＞ 山下: 社会の“インテリジェンス”活用推進に向けた考察, SEC journal, No.23.

知とその共有に関する進化

データに基づく管理の分類

データ 手法 見える化ツール 主な活用方法 定 性 作業日報等 ビッグデータ解析 (分析) なし 因果関係確認等 失敗事例 (分析) チェックリスト （例:信頼性自己診断ツール） 教訓集 妥当性確認(問題 点抽出) 再発防止策 障害事例 (分析) 定 量 開発データ インプロセス計測 定量的プロジェクト管 理ツール 異常の予兆検知 (*) _{比較による計画策} 定・妥当性確認 ベンチマーキング (分析) データ白書 運用データ ビッグデータ解析 (分析) なし 障害予兆検知等 データマイニング 活用（確認・対策等)のための 知見の抽出 (*) 定量的品質予測，等 (1) 情報システムの障害状況の整理 (2) 障害情報の収集・分析に基づく教訓の共有 (3) 信頼性自己診断ツール (4) 定量的プロジェクト管理ツール(EPM-X) (5) ソフトウェア開発データ白書 (2)(3) (1)(2) (4) (5) ソフトウェア リポジトリ

Ｊ－ＣＳＩＰ（サイバー情報共有） 制御機器のＥＤＳＡ認証制度 脆弱性対策情報（ＪＶＮ） セキュリティ被害の届出・相談 暗号技術 重要インフラ等高信頼化対策 ソフトウェア品質説明力強化 ソフトウェア・サプライチェーン ソフトウェア工学先導研究支援 文字情報基盤、共通語彙基盤 情報処理技術者試験（ｉ-パス） 未踏IT人材育成 セキュリティ・キャンプ ＩＴ人材白書 (参考：過去の活動) ソフトウェアエンジニアリングの成果

本日の

対象

IPA: 信頼性，セキュリティ，人材育成の一体的取組み

SEC（ソフトウェア高信頼化 センター）の事業項目 １．IPA/SECの概要

IPA，及びSECについて

１．IPA/SECの概要 大学 研究機関・ 研究団体

連携の場

・ ベスト・プラクティスの収集・普及 ・ 開発手法・技術の開発と実証実験 ベンダ企業 ユーザ企業 業界団体 学会 SEC 産業界

重点：生産性・信頼性向上から

安全・安心

へ

対象：企業・業界レベルから

国民レベル

へ

・ 現場課題に基づく共同研究，など 開発競争力強化 から高信頼化へ

H24年度まで：ソフトウェア・エンジニアリング

H25年度から：情報処理システム・ソフトウェア障害の対策，教訓共有等

IPA/SECの活動

１．IPA/SECの概要 ＜H24年度までの主な成果＞ ◇エンタプライズ系 • 経営者が参画する要求品質の確保 ～超上流から攻めるITの勘どころ～ • ITプロジェクトの「見える化」 • ソフトウェア開発データ白書 • ソフトウェア開発見積りガイドブックシリーズ • 共通フレーム • 機能要件の合意形成ガイド • 非機能要求グレード • プロセス改善手法（SPEAK-IPA，SPINA3_CH） • アジャイル開発関連報告書 • GQM+Strategies • 高回復力システム基盤導入ガイド • 高信頼化ソフトウェア開発手法ガイドブック • 重要インフラ情報システム信頼性研究会関連報告書 など ◇組込み系 • 高品質な組込みソフトウェア開発（ESxRシリーズ） • 組込みスキル標準（ETSSシリーズ） など

ソフトウェア・エンジニアリング関連の成果

問題：障害事例の内容

原因：問題を引き起こした要因の

分析結果

対策：問題の原因を取り除き再発

を防止するための方法

効果：対策の実施により見られた

／期待される効果

教訓：得られた教訓の内容説明・

補足

[教訓ＩＤ]

教訓概要(タイトル)

類似の障害は

起きないか？

あらかじめ実施

しておくべき対策

はないか？

H25年度の「教訓集」概要

各教訓の構成

http://www.ipa.go.jp/about/press/20140513.html

文献１、文献２ 文献３ 文献４ 文献５ 文献6、文献7 文献８ Ｇ１ ○ Ｇ２ ○ Ｔ１ ○ Ｔ２ ○ Ｔ３ ○ ○ Ｔ４ ○ ○ Ｔ５ ○ ○ ○ Ｔ６ ○ Ｔ７ ○ ○ 障害対策手法と参考文献 ⑧ 可用性管理 ・システムの冗長 　化設計 ・シングルポイント 　の洗出し ・障害運用マニュ 　アルの整備と 　訓練 ガバナンス /マネジメン ト領域 技術領域 ① 超上流工程での要求 品質管理 ・ユーザ企業内の事業 　部門と情シス部門との 　連携 ・ユーザ企業とベンダ 　企業の連携、 　合意形成 ② トレーサビ リティ管理 ③ 「見える化」 　手法 ・暗黙知の 　整備・有 　効活用 ・俯瞰図 ④ 要求獲得 手法 領域 ⑤ 変更管理 ⑥ フェール ソフト ⑦ 網羅的テスト技法 ・テスト環境の 　リスク管理 ・シミュレーション 　手法 ⑨ 非機能要 求グレード 対策事例 に対応す る教訓ID 参照SEC BOOKS等⇒

障害対策手法・事例の分類

H25年度の「教訓集」概要 関連対策を含めて体系的 に理解する際に有効

情報提供者 情報管理者 （IPA） 共有グループ （部会） 教訓利用者 No. 収集方法 ルールの適用局面（義務を負う者） 情報提供者か ら預かった障 害情報の管理 （情報管理者） 共有グループへ の情報開示時 （情報管理者） 共有グループ での議論時 （共有グループ メンバ） 教訓の公開時 （情報管理者） 1 情報管理者が、個別ヒア リング等により提供された 障害情報を取り扱う場合 情報提供者と の間で、機密 保持のルール を適用 情報提供者と の間で、加工情 報の共有に係 るルールを適用 情報管理者と の間で、機密 保持のルール を適用 情報提供者と の間で、公開 のための情報 加工のルール を適用 2 共有グループのメンバが、 障害情報をグループ内に 直接開示した場合 適用なし 適用なし 共有メンバ間 で、機密保持 のルールを適 用 情報提供者と の間で、公開 のための情報 加工のルール を適用 情報の流れのモデル (注)ここでは、情報管理者をIPA、共有グループをIPA内に設置された部会として説明する。 また、共有グループの運用を情報管理者が行うことを前提としている。 情報管理者は共有グループのメンバでもある。 これらは、本ルールの適用先に応じ、適切な組織・会議体に置き換えることになる。 H25年度の「教訓集」概要

情報の流れのモデルと機密保持等のルールの適用局面

「サイバーセキュリティ戦略」

参考

重要インフラの情報セキュリティ対策に係る

第３次行動計画の概要

参考

2013年度 実施件数

参考：セキュリティ

参考：航空

航空安全情報自発報告制度 [ VOICES ](1/2)

2014年度から国土交通省航空局の「航空安全プロ グラム」が開始されたことに伴い始まった安全情 報の報告制度 法令等で定められた事故やインシデント等に関す る義務的な報告制度だけでは捉えきれない多くの 情報を収集し、航空の安全向上のために活用 航空活動に直接携わっておられる方々（個人また はその所属する事業者等の組織）から，自ら経験 または視認した航空の安全上の支障を及ぼす可能 性があったと思われる事象（いわゆるヒヤリハッ ト）についての報告を収集し，業務実施者間で情 報を共有するとともに，それらの情報を分析して 必要と思われる改善を提案することにより，航空 の安全向上に寄与 出典： 航空安全情報自発報告制度（VOICES) について http://www.jihatsu.jp/index.html 報告者保護の観点から，航空安全当局（国土交通省航空局）や報告者の所属する組織以外 の第三者機関が運営を行う． 航空安全当局は，報告者の個人，会社名等が特定される情報の提供を制度運営者に対し求 めない，本制度に提供された情報を行政処分等の不利益処分の根拠として使用しない．

その

ヒヤリ！

さっきの

ハット！

を

役立てます！

参考：航空

航空安全情報自発報告制度 [ VOICES ](2/2)

出典：航空安全情報自発報告制度（VOICES) について http://www.jihatsu.jp/FAQ/index.html#pageLink02 公益財団法人 航空輸送技術研究センター（ATEC）が運営 報告の受付け 分析担当者によるヒアリング 情報の秘匿化 分析作業とフィードバック VOICESポータルサイト にて周知，等 航空安全情報自発報告サイト https://asicss.cab.mlit.go.jp/voluntary/

参考：原子力

原子力施設情報公開ライブラリーを意味する英語の名称

NUClear Information Archives の頭文字をとった略

称で、国内原子力発電所や原子燃料サイクル施設の運 転に関する情報を広く共有化するためのサイトです。

http://www.nucia.jp/index.html

参考：原子力

トラブル情報等 「トラブル情報」 「保全品質情報」

参考：金融 出典： 一般社団法人 金融ISACの設立について http://www.f-isac.jp/new4.html

金融機関間のサイバーセキュリティに関する情報を共有するための組織

（2014年8月1日設立）

高度化するサイバー攻撃に対抗するため、フィッシング被害、不正送金被害、 APT攻撃、DDoS攻撃、脆弱性・ゼロディの脅威等のサイバーセキュリティに関 する情報を、会員である金融機関で共有し連携して対策に当たる。

すでに米国には同様の組織があり（FS-ISAC：Financial Services Information Sharing and Analysis Center）、4,600社を超える金融機関が会員となって活 動しているが、金融ISACはFS-ISACとも連携し、情報共有を促進。また、国内 の組織とも積極的に連携していく予定。 http://www.f-isac.jp/index.html 参考： 米国のセキュリティ情報共有組織（ISAC）の状況と運用実態に関する調査 平成22年3月 株式会社 三菱総合研究所 http://www.nisc.go.jp/inquiry/pdf/fy21-isac.pdf

IT-ISAC, Chemical ISAC, Communication ISAC, ES-ISAC(エネルギー), FS-ISAC(政府施設), MS-ISAC等がある．ES-ISACのみ，システム障害情報も共有．