障害事例情報共有の取組みと...

Software Reliability Enhancement CenterCopyright © 2013-2015 IPA, All Rights Reserved

Information-technology Promotion Agency, Japan

Software Reliability Enhancement Center (SEC)

障害事例情報共有の取組みと事例分析により得られた教訓

～情報処理システム高信頼化に向けて～

ITC近畿会セミナー

2015年7月25日

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

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

山下博之

[email protected]

2Copyright © 2013-2015 IPA, All Rights Reserved Software Reliability Enhancement CenterPresentation on 2015-07-25

本講演の趣旨

情報システムの障害は，サイバー攻撃等の情報セキュリティ事案と比べ，一般に，発生頻度は低いものの，ひとたび発生するとその影響範囲は広く，深刻度も高い．世の中を見てみると，障害発生防止のための対策が講じられていても，思わぬ状況や原因により障害は発生している．これを減らすためには，あらかじめすべてのリスク要因を想定することは不可能なため，他所で発生した障害を自システムでは発生しないように対応することが有効であり，そのためには，障害事例情報の共有が必要である．

IPA/SECでは，2013年度から，10程度の分野の事業者のIT部門からお集まり頂く委員会において，一定の守秘義務の下に，各社の障害事例を紹介して頂き，その根本原因と再発防止策等について多方面から議論している．そして，その結果を抽象化・普遍化してまとめ，「教訓集」として公開している．

また，IPA/SECでは，このような取組みがより多くの分野や地域等に拡がることを期待し，そのための啓発・支援活動を進めている．

本講演では，IPA/SECにおけるシステム障害事例情報共有の取組み内容を紹介すると共に，これまでにまとめた障害事例の分析に基づく教訓について説明する．


内容

1.障害事例情報共有の背景

2.これまでの取組みと成果概要

3.障害事例の分析に基づく教訓の説明

4.障害事例情報の活用による信頼性向上

4.1 障害事例から教訓を導く方法

4.2 各組織で教訓を活用する方法

5.まとめ


内容







5.まとめ


ソフトウェアは，それ自身，複雑化・大規模化し，

システム間連携により，複雑化は一層進展

停止・異常動作等のリスクの増大

∵ 市民生活や社会経済活動がＩＴシステムに大きく依存

１．背景

背景

社会リスクに比例して，ビジネス・リスクも増大


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


グローバル・リスク（続）

技術リスクの増大（2014年→2015年）

http://reports.weforum.org/global-risks-2015/ （参考：俯瞰）

経済

地域

社会

技術

環境

技術リスクの増大（過去10年間）

データ例

“重要インフラのITシステム障害“のリスクは，増大傾向


0

10

20

30

40

50

60

2007 2008 2009 2010 2011 2012 2013 2014

多大な影響を与えた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

１．背景

システム運用時に想定されるリスク


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

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

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

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

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

利用者増，技術進展，他

網羅的な事前抽出が困難

失敗に学ぶ

冗長構成，など

教訓の活用

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

リスク要因

１．背景

リスクへの対応


「他山の石」の意味※

※(出典) 文化庁月報平成23年10月号(No.517)

http://www.bunka.go.jp/publish/bunkachou_geppou/2011_10/series_08/series_08.html

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

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

自分の修養の助けとなる

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

「対岸の火事」

参考

「他山の石」


「情けは人のためならず」の意味※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サービス機能・システム複雑度

低高

狭

広

カバー範囲率

1社のみ

社会全体

時代の流れ

高信頼化

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

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

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

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

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

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

参考

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


内容







5.まとめ


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

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

具体的には，

重要インフラ分野*等のシステム障害の事例を分析し，それにより得られた

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

的に広く共有する仕組みの構築を目指す．

* 情報通信，金融，航空，鉄道，電力，ガス，政府・行政サービス，医療，水道，物流，クレジット，石油，化学

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

２．IPA/SECの取組みと成果

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



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

製品機器/ITサービス

(Ａ社)

社会社会

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


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

原因分析対策検討

対策実施

教訓Ａ


対策実施

教訓Ｂ


対策実施

教訓Ｃ


(Ａ社)


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

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

体系的整理

教訓Ａ

教訓Ｂ

教訓Ｃ

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

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

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

教訓教訓教訓

機密保持等のルール

類似障害の発生

情報セキュリティ

航空原子力金融教訓共有の取組みの目指す方向


・個別企業等へのヒアリング・SEC研究員による事例分析

事例情報・教訓素材



委員会蓄積教訓

教訓の整理体系化方法

教訓の活用・展開方法

（製品・制御システム編）

（ITサービス編）

教訓の一般化・抽象化の処理(A)製品・制御

システム高信頼化部会

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

教訓

各業界の専門家等から成る委員会(２種)を設置（共有グループ）

情報共有のための機密保持等のルールを整備

3種のソースから，障害事例情報・教訓素材を委員会に入力

障害事例に基づく“教訓”集の取りまとめ

情報共有のためのルール整備（機密保持等）

（委員企業等より）

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


ＩＰＡにおける障害事例情報共有活動の試行

グループメンバによる活用

公開


製品・制御システム分野

ITサービス分野

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

[教訓数]

18件

[教訓数]

9件

普遍化取りまとめ

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

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

＜重要インフラITサービス高信頼化部会＞情報処理システム高信頼化教訓集（ITサービス編／製品・制御システム編）

【参画企業等】

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

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

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

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

アイシン精機（株）、

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

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

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

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

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

九州大学、岡山県立大学

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

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

【参画企業等】

（株）三菱東京UFJ銀行

日本生命保険相互会社

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

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

東京電力（株）

東日本旅客鉄道（株）

KDDI（株）

（株）情報システム総研

（株）オリジネィション

日本大学

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

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

製品・制御システム編

ITサービス編

2013年度版：2014年5月13日公開http://www.ipa.go.jp/about/press/20140513.html

2014年度版：2015年3月27日公開

+10件

+18件

2014年度の追加

http://www.ipa.go.jp/sec/reports/20150327_1.html＜特徴＞

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

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

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

…


重要インフラシステム等のソフトウェア障害情報の収集・分析

(2013年度)


活動参加者の声

・自社事例を“教訓”化するための議論の中で，“気づき”を得ることがあった．

・他分野の事例紹介では，鉄道の線路を送電線に置き換えて考えている．

・他分野の事例からも参考になる情報が得られた．

・議論された中の気になった事例に関して，自社のITシステム担当に点検を指示した．

試行結果：共有活動について２．IPA/SECの取組みと成果

活動参加のメリット

・共有グループ内のみに開示される（非公開の）詳細情報が得られる．

・障害原因分析や事例の教訓化を通して，スキルアップにつながる．“分析力”“抽象力”


PART Ⅰ 教訓集（本編）

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

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

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

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

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

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

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

「教訓集」の構成２．IPA/SECの取組みと成果


情報提供者情報管理者

（IPA）共有グループ

（部会）教訓利用者

No. 収集方法

ルールの適用局面（義務を負う者）

情報提供者から預かった障害情報の管理（情報管理者）

共有グループへの情報開示時（情報管理者）

共有グループでの議論時（共有グループメンバ）

教訓の公開時（情報管理者）

1

情報管理者が、個別ヒアリング等により提供された障害情報を取り扱う場合

情報提供者との間で、機密保持のルールを適用

情報提供者との間で、加工情報の共有に係るルールを適用

情報管理者との間で、機密保持のルールを適用

情報提供者との間で、公開のための情報加工のルールを適用

2

共有グループのメンバが、障害情報をグループ内に直接開示した場合

適用なし適用なし共有メンバ間で、機密保持のルールを適用

情報提供者との間で、公開のための情報加工のルールを適用

情報の流れのモデル

(注)ここでは、情報管理者をIPA、共有グループをIPA内に設置された部会として説明する。また、共有グループの運用を情報管理者が行うことを前提としている。情報管理者は共有グループのメンバでもある。これらは、本ルールの適用先に応じ、適切な組織・会議体に置き換えることになる。

情報の流れのモデルと機密保持等のルールの適用局面２．IPA/SECの取組みと成果


活用事例

教訓集・ガバナンス・技術領域

活用ガイド・教訓化方法・分析手法・対策手法

提供支援

教訓と自組織とのコンテキストを比較・照合

・自社のシステムを点検し適用可能な教訓について確認・対策を実施

⇒未然防止

自組織の運用ルール等の見直し・整備と(若手)教育

・未然防止に向けた運用ルール等見直し・障害事例から学ぶＩＴ人材教育

各産業分野における共有活動と各社の取組み

社間での情報共有

電子掲示板等

SECによる支援①障害事例分析に基づく教訓集の

提供②教訓の活用方法を取りまとめた

ガイド類の提供③各々の業界における教訓づくり

のためのノウハウの提供④各々の業界における共有活動の

支援（電子掲示板等の提供、セミナー講師の派遣など）

教訓の共有

幅広い産業分野における自律的な活動を促進

今後：障害事例情報共有活動の普及促進２．IPA/SECの取組みと成果

安全文化の醸成

適用事例


分野・業界Ａ内の情報共有

分野・業界Ｅ内の情報共有

分野・業界Ｄ内の情報共有

分野・業界Ｂ内の情報共有

分野・業界Ｆ内の情報共有

分野・業界Ｃ内の情報共有

企業a1

企業a2

企業a3

企業a4

企業a5 企業

a6

企業b2

企業b1

・・・

企業d1

分野・業界にまたがる情報共有

企業d2

企業d3

企業e3

企業e2

企業e1

企業c1

企業c2

企業f1

企業f4

企業f3

企業f2

企業f5

・・・

応用分野に関する情報共有

地域団体による情報共有

教訓

・・・企業g1

企業h1

目指す社会に向けて

障害事例情報に基づく教訓共有の仕組みの展開イメージ２．IPA/SECの取組みと成果


内容







5.まとめ


システム要求定義

システム

アーキテクチャ設計

ソフトウェア


ソフトウェア


（変更設計）

実装（コーディング）

レビュー

システムテスト

教育

プロジェクト

マネジメント

運用

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製品のバージョン、動作仕様の相違等の情報が関係者にタイムリーに参照できるようにする ○ ○ ○ ○

３．教訓


１）ガバナンス／マネジメント領域の教訓（黄色は２０１４年度に追加したもの）

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

No. 教訓ＩＤ教訓概要

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

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

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

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

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

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

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

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

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

３．教訓


２）技術領域の教訓（黄色は２０１４年度に追加したもの）

No. 教訓ＩＤ教訓概要

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

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

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

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

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

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

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

17 Ｔ８仮想サーバになってもリソース管理、性能監視は運用要件の要である

18 Ｔ９検証は万全？それでもシステム障害は起こる。回避策を準備しておくこと

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

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

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

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

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

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

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

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

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

３．教訓

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


問題：障害事例の内容

原因：問題を引き起こした要因の分析結果

対策：問題の原因を取り除き再発を防止するための方法

効果：対策の実施により見られた／期待される効果

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

[教訓ＩＤ]教訓概要(タイトル)

類似の障害は起きないか？

あらかじめ実施しておくべき対策はないか？

各教訓の構成

各教訓の説明

３．教訓

別冊_教訓概要-考えよう(投影用).pptx


◆ガバナンス／マネジメント領域

文献 G1 G2 G3 G4 G5 G6 G7 G8 G9

ガバナンス／マネジメント領域

1 ユーザ企業とベンダ企業の連携、合意形成

1 ユーザ企業による要求品質の確保文献1 ○

2 機能要件の合意形成文献2 ○

2 ユーザ企業内の事業部門と情シス部門との連携 ○ ○

3

1 性能要件の合意形成 ○

2 障害時発生時の合意形成 ○

4 クラウドセンターと利用企業の連携、合意形成文献x7 ○ ○

5 障害管理の取組み文献x4 ○ ○ ○ ○

6 プロセス改善文献x1 ○ ○ ○ ○

7 ヒューマンファクターズ ○ ○

共同センター利用におけるユーザ企業の連携、合意形成

教訓番号

障害対策

参照SEC BOOKS等⇒

関連対策を含めて体系的に理解する際に有効

３．教訓

障害対策手法と教訓の対応付け(1/2)


◆技術領域

文献 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16 T17 T18

技術領域

1 トレーサビリティ管理

1製品に関するトレーサビリティ　ISO9001

文献x2 ○

2文書およびデータに関するトレーサビリティ

文献3 ○ ○ ○

2 「見える化」手法

1 暗黙知の整備・有効活用文献4 ○

2 俯瞰図文献4 ○

3 要求獲得手法文献5 ○ ○

4 変更管理

1 共通フレーム2013 文献6 ○ ○ ○ ○ ○

2JIS Q20000-1サービスマネジメント

文献7 ○ ○ ○ ○ ○

5 フェールソフト ○

6 テスト技法

1 テスト環境のリスク管理 ○ ○

2 シミュレーション手法 ○

3 テスト網羅性の高度化技法文献x3 ○ ○

7 可用性管理

1 システムの冗長化設計 ○ ○ ○ ○ ○ ○

2 シングルポイントの洗出し ○ ○

3障害運用マニュアルの整備と訓練

○ ○ ○

4可用性の注意点：フルメッシュ構成

○

8 非機能要求グレード文献8 ○ ○ ○ ○ ○

9 仮想化技術文献x5 ○

10 レビュー手法文献x6 ○ ○

11 サイレント障害対策 ○

12 パッチ管理文献x8 ○ ○

13 高回復力システム基盤導入文献x9 ○ ○

教訓番号

障害対策手法と参考文献

３．教訓

障害対策手法と教訓の対応付け(2/2)


内容







5.まとめ


障害事例の分析に基づく高信頼化活動の俯瞰

障害

発生

原因

解析

応急

対策原因

分析

再発防止

策（教訓）

社内

展開

普段の活動

（当事者）

（他者）

情報

解析

自社

確認(対策)

障害

発生・・・情報

開示

原因

分析

再発防止

策（教訓）共有

情報開示情報開示

（参加者）

情報

解析

自社

確認(対策)適時の

アクション

“教訓”集公開

対応教訓化

(臨時)点検

(定期)点検

（各者）

各社内

各社内

共有グループ

・開示は必須ではない・開示時期は概ね遅い・開示内容が詳細でない


他所でのシステム障害発生時の一般的対応

点検や対応の範囲や観点…自システムのライフサイクルにおける段階により異なる開発前：類似障害が発生しないような方式の採用・対策の実施を，プロセスを含む開発計画に盛り込む

運用中：類似障害の発生するリスク要因の有無確認，発生時の影響の見積り

• 障害の原因により，点検や対応の重点，実施部門が異なる• 障害の発生したシステムの応用分野により，自システムと同じ分野であればより慎重になる等，点検や対応への“心構え”が異なる？

臨時点検（他所）障害発生・

情報入手自システムの関連性判断

（臨時）点検

※詳細情報の入手の都度，必要に応じ，追加点検

４．障害事例活用


社内の開発・運用標準に規定された，自システムのライフサイクルにおける特定の段階で，自システムのリスク評価（例：チェックリスト）

個々の教訓に関する確認の観点自システムで類似の障害は起きないか？類似障害の発生防止のため、あらかじめ実施しておくべき対

策はないか？万一類似障害が発生した場合の影響は、どの程度か？類似障害発生時に影響範囲を小さくする対策はあるか？

定期点検


教訓の一般的活用方法

教訓：障害発生から一定の時間が経過．内容は整理されている．


事例と根本原因対策

対策対策対策

普遍化

有識者・専門家による機論

Ａ分野Ｃ分野Ｂ分野Ａ分野

高

低

抽象レベル共有

各分野で展開

コンテキストコンテキストコンテキスト

コンテキスト

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

一般化・抽象化された教訓

共通コンテキスト

★：本質

★

★

★ ★ ★

“想像力”が重要

暗黙知

形式知

社会智


教訓の作成と活用の流れ

“分析力”“抽象力”が重要


サブベンダ

アウトソーサ

元請けベンダ

システム子会社

システム開発担当

部門長

関連会社

システム推進担当

業務推進担当

部門長

担当役員

社長

部署等／役割（ロール）

サブベンダ

アウトソーサ

元請けベンダ

ベンダ

システム子会社

システム開発担当

部門長

情報システム

部門

関連会社

システム推進担当

業務推進担当

部門長

業務部門

担当役員

社長

経営層

部署等／役割（ロール）

社内教育

＜出典（縦軸）＞ SEC BOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」，p.37 の 3.2（１）項、p.41 の 4.1

組織・体制の

整備調達時の指示事項

ﾚﾋﾞｭｰ・試験項目

調達時の確認事項

運用手順の

整備

開発手順の

整備

教訓の最終的な適用先の例

トラブル発生時の

原因推定

類似事例

組織に“安全文化”を醸成


教訓の恒久的な反映



開発標準への反映事例

社内で策定している「レビュー実施基準」の中で，

『レビューの振り返り』プロセスを規定している．

そのプロセスでは，

発生したトラブル事例を分析し，

『レビューの観点リスト』に盛り込む

ことを行っている．

＜あるベンダの例＞


内容







5.まとめ


障害内容

・(根本)原因・再発防止策

教訓(形式知)

教訓(社会智)

分析

普遍化

一般化・抽象化

「なぜなぜ分析」中心

(暗黙知)

４.１教訓化

障害事例の教訓化過程のモデル

教訓

コンテキスト

★本質対策


一般化 Generalization□広辞苑第五版：特殊的なものを捨て共通のものを残すことによって一般的なもの

（概念・法則）を作ること。普遍化。概括。□三省堂大辞林：あるグループの一部の事物について成り立っていることから，その

グループ全体について成り立つように論をおしすすめること。普遍化。

抽象（化） Abstraction□広辞苑第五版：事物または表象の或る側面・性質を抽(ぬ)き離して把握する心的

作用。．．．一般概念は多数の事物・表象間の共通の側面・性質を抽象して構成される。

□三省堂大辞林：事物や表象を，ある性質・共通性・本質に着目し，それを抽（ひ）き出して把握すること。

普遍化 Universalization□広辞苑第五版：「一般化」に同じ。□三省堂大辞林：個別的・特殊なものを捨て，共通なものをとり出すことによって概念

や法則などを引き出すこと。

→多くの応用分野に適用可能なようにすること

→具体的なモノ・コトから共通の性質を表すモノ・コトに表現し直すこと下位概念から上位概念に表現し直すこと

現状では，必ずしも十分に切り分けられてはいないが，．．．

４.１教訓化

一般化・抽象化・普遍化の意味


【教訓タイトル】＜抽象的な表現の例＞システムの部分変更（に伴う新旧混在）時に（非変更部分との）整合性を確認する．

＜具体的な表現の例＞変化に対応して（プログラム／システム定義データ中の）定数をチェックする．

【問題（障害事例）】20xx年m月dd日，ある鉄道会社にて，列車運行を管理するシステムのうち，

ダイヤに基づき各駅の信号機を自動制御する「自動進路制御装置(PRC)」の保守時に異常が発生．その後バックアップ系統への切替えに失敗し、装置が停止．管轄する3路線の鉄道が2時間以上運行できなくなり，385本が運休，約11.1万人に影響．

教訓化事例の説明

４.１教訓化

事例を用いた説明

補足

C:/yamah/他機関/JUAS/別冊_障害事例から教訓を導く例_20150407.pptx#1. 障害事例から教訓を導く例

別冊_障害事例から教訓を導く例_20150407.pptx


内容







5.まとめ


４.２教訓活用

教訓の活用過程のモデル

教訓

コンテキスト

★本質対策

自システム/組織

コンテキスト

施策

整合？適用

Yes

具体化

比較

★

• 開発開始時• 開発中の節目（レビュー時等）• 運用開始時• 運用中の節目（定期点検時等）• トラブル発生時• 開発/運用標準・規定類• 組織・体制

システマティックな取組み


防護壁

事故危険因子

（さまざまな）穴

<参考例> http://rikanet2.jst.go.jp/contents/cp0300/manual/extra/ex_29.html

安全文化：スイスチーズモデル(1/2)

•プロダクト面（空間）

•プロセス面（時間）

参考


システム障害不具合/ミス

の要因

設計運用試験

プロセス／アクティビティ

教訓

穴をふさぐ

多様な観点広範囲の事例

安全文化：スイスチーズモデル(2/2)参考


信頼性向上対策（全体）

教訓（再発防止策）

障害事例に基づく対策は部分的→体系的な対策も重要

４.２教訓活用

体系的な対策に向けて

ガイド類

教訓に関連するガイド類を参照し，そのカテゴリ全体の信頼性向上方法を理解する

既存のガイド類に不十分なところがあれば，その精緻化を図る

開発／運用等の標準・規定類，組織・体制等

反映


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

品質保証体制の専門スタッフがいるプロジェクトの方が，そうでないプロジェクトに比べ，プロダクトの信頼性が高い

4.8

12.2

約2.5倍

N=63 (37+26)

出典：「ソフトウェア開発データ白書2014-2015」(IPA/SEC)

低

←

信頼性

→

高

優れた品質保証体制の組織

システマティックな取組みの効果

統計データ例

データ例

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


教訓活用事例の説明

４.２教訓活用

事例を用いた説明

【教訓タイトル】＜抽象的な表現の例＞システムの部分変更（に伴う新旧混在）時に（非変更部分との）整合性を確認する．

＜具体的な表現の例＞変化に対応して（プログラム／システム定義データ中の）定数をチェックする．

…

補足

C:/yamah/他機関/JUAS/別冊_各組織で教訓を活用する例_20150407.pptx#1. 各組織で教訓を活用する例

別冊_各組織で教訓を活用する例_20150407.pptx


内容







5.まとめ


暗黙知

形式知

社会智

５．まとめ（に代えて）

みなさまへの期待

イノベーション

1．各社内での取組み

障害事例情報を収集・蓄積する．

再発防止策をまとめ，共有する．

2．グループ企業や業界における取組み

社内での取組みを関係者へ拡げる．

3．社会レベルでの取組み

社内やグループ内の知見を社会全体のために役立てる．

他所からの知見を，自身のために活用する．


0.0%

82.9%

2.6%

2.6% 11.8%

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

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

１．障害を発生させていることから、信

頼できない

２．積極的に情報公開をすることから、

公開しない企業に比べて信頼できる

３．特に何とも思わない

４．その他

無回答＜アンケート回答者（計76名）＞ET2013（2013年11月）ソフトウェアジャパン（2014年2月）

参考

アンケート例


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

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


以降，参考


参考

ＩＴリスクが風評に及ぼす影響(1/2)

※ (出典)フォールアウト～予期せぬ影響～，フォーブス・インサイト, 2014年．

図1 重度の中断は企業評価とブランド価値に最大のリスクを与える

3 つのレベル「( 軽度」、「中度」、「重度」) の中断のそれぞれの総コストについて、回答者は、100 ポイントを 6 つのコスト・カテゴリーに配分するように依頼されました。

グラフ出典: ITリスクと企業評価の経済的影響: 企業にとっての事業継続およびITセキュリティーの真の意味 (2013年9月)


※ (出典)フォールアウト～予期せぬ影響～，フォーブス・インサイト, 2014年．

参考

ＩＴリスクが風評に及ぼす影響(2/2)

図3 過去2年間に一般的な脅威によって企業評価とブランド価値の損害を被った企業の割合

グラフ出典: ITリスクと企業評価の経済的影響: 企業にとっての事業継続およびITセキュリティーの真の意味 (2013年9月)

図2 6つの一般的な脅威によってもたらされた過去2年間の中断の平均数

「ミスを犯すたった 1 人の人間に対して、システム全体がいかに脆弱であるか」


Therac-25による放射線過剰被爆事故（1985～87年）

エアバスA320の墜落事故（1988～93年）

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

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

電子カルテシステムの不具合（2010年）

新幹線運行管理システムの障害（2008年，2011年）

銀行オンラインシステムの障害（2011年）

株式売買システムの障害（2012年）

レンタルサーバーのデータ消失（2012年）

人身事故

経済事故

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

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

データ例

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


人の性：「自分だけは大丈夫」と思う

… 正常化の偏見※

※ (出典)人はなぜ「自分は大丈夫」と思うのか，防災研究家の片田群馬大学教授に聞く，ITpro 2007/04/11http://itpro.nikkeibp.co.jp/article/Interview/20070409/267753/

→ 確かに大丈夫，という確認が必要

参考

「正常化の偏見」


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

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

重要インフラ間の相互依存

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

データ例


・あるITサービス/製品機器は，他のITサービス/製品機器に依存することがある．

・ITシステムの中に，製品機器を含むことがある．

エネルギー系情報処理/制御システム

交通系情報処理システム

データセンター/クラウド

医療機器金融系情報処理システム

制御機器制御機器

国民生活・社会経済活動

情報通信系情報処理/制御システム

他サービス/製品機器の障害は，自サービス/製品機器にも影響が及び得る

相互に依存

参考

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


メインフレーム → 分散（Ｃ／Ｓ）システム → クラウドコンピューティング

自分は先輩と同じような間違いを犯していないか？

後輩は自分と同じような間違いを犯しはしないか？

→ 他所のシステム障害にも目を向ける

参考

もう一つの効果（目的）：経験の継承


社会智とイノベーション

暗黙知形式知（知識）

形式知（智恵）

個有

共有

組織

社会

現状

現状

現状

個人が目指すところ

企業が目指すところ

人類が目指すところ

当面のマイルストーン

見える化分析・体系的整理

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

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

ソーシャル・イノベーション

オープン・イノベーション

参考


情報処理システム高信頼化教訓集（製品・制御システム編）－2013年度版－

情報処理システム高信頼化教訓集（ITサービス編）－2013年度版－

http://www.ipa.go.jp/sec/reports/20140513_2.html

http://www.ipa.go.jp/sec/reports/20140513.html

プレス発表重要インフラを支えるシステムの障害情報や対策を分析した2種類の教訓集を公開http://www.ipa.go.jp/about/press/20140513.html

情報処理システム高信頼化教訓集（製品・制御システム編）－2014年度版－

情報処理システム高信頼化教訓集（ITサービス編）－2014年度版－



＜2013年度＞

＜2014年度＞


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


例：製品・制御システム編の教訓例（１）

※以下、直接の対策と恒久対策に続く

４．“教訓”の内容


参考

出典： NISC ,「サイバーセキュリティ2013」（案）について,平成25年6月27日,P4

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

http://www.nisc.go.jp/conference/seisaku/dai36/pdf/36shiryou0101.pdf


重要インフラの情報セキュリティ対策に係る第３次行動計画の概要

参考

出典： NISC ,重要インフラの情報セキュリティ対策に係る第３次行動計画の概要,平成26年10月10日,P2

http://www.nisc.go.jp/conference/seisaku/ciip/dai38/pdf/38sankousiryou02.pdf


2013年度実施件数

参考：セキュリティ

サイバーセキュリティ情報共有活動［J-CSIP］


参考：航空

2014年度から国土交通省航空局の「航空安全プログラム」が開始されたことに伴い始まった安全情報の報告制度

法令等で定められた事故やインシデント等に関する義務的な報告制度だけでは捉えきれない多くの情報を収集し、航空の安全向上のために活用

航空活動に直接携わっておられる方々（個人またはその所属する事業者等の組織）から，自ら経験または視認した航空の安全上の支障を及ぼす可能性があったと思われる事象（いわゆるヒヤリハット）についての報告を収集し，業務実施者間で情報を共有するとともに，それらの情報を分析して必要と思われる改善を提案することにより，航空の安全向上に寄与

出典：航空安全情報自発報告制度（VOICES) についてhttp://www.jihatsu.jp/index.html

報告者保護の観点から，航空安全当局（国土交通省航空局）や報告者の所属する組織以外の第三者機関が運営を行う．

航空安全当局は，報告者の個人，会社名等が特定される情報の提供を制度運営者に対し求めない，本制度に提供された情報を行政処分等の不利益処分の根拠として使用しない．

そのヒヤリ！さっきのハット！を役立てます！

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


参考：航空

出典：航空安全情報自発報告制度（VOICES) についてhttp://www.jihatsu.jp/FAQ/index.html#pageLink02

公益財団法人航空輸送技術研究センター（ATEC）が運営

報告の受付け分析担当者によるヒアリング情報の秘匿化分析作業とフィードバック

VOICESポータルサイトにて周知，等

航空安全情報自発報告サイト

https://asicss.cab.mlit.go.jp/voluntary/

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


参考：原子力

原子力施設情報公開ライブラリーを意味する英語の名称NUClear Information Archives の頭文字をとった略称で、国内原子力発電所や原子燃料サイクル施設の運転に関する情報を広く共有化するためのサイトです。http://www.nucia.jp/index.html

原子力施設情報公開ライブラリー［NUCIA］ (1/2)


参考：原子力

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

原子力施設情報公開ライブラリー［NUCIA］(2/2)


参考：金融

出典：一般社団法人金融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のみ，システム障害情報も共有．

金融ISAC (1/1)


2015.3.20 IPA

５．まとめ（に代えて）

セミナーの模様


制御盤

自動進路制御装置(PRC)*

CTC中央装置

運行表示盤

CTC駅装置

連動装置

信号機転轍機軌道回路

……

<Ａ駅> <Ｂ駅> <Ｃ駅>

運行情報

進路設定要求

(手動の場合)

(自動の場合)

指令室

各駅

中央機器室

(事前設定)

CTC: Centralized Traffic Control(列車集中制御装置)

PRC: Programmed Route Control

* 系統（○○本線等）ごとに設置

教訓分析例

障害事例Ａ(2/6) 列車運行制御システムの概要


保守作業中PRC異常停止(切替えも失敗)

始発に間に合わず列車運休多数

大勢に影響

ディスク装置へのリセット要求コマンド・タイムアウト

HDDからSSDに交換されていた

事前に分からなかった

直前の作業確認時は本番環境と

異なるHDD搭載機

今回のケースは試験シナリオ/

項目に含まれず

機能互換思い込み(担当間のコミュニケーション不足)

運行部門に保守作業未通知

ユーザにSSDへの交換未通知

たまたまあった訓練用PRCで

再開

片系停止時に両系のディスクを初期化する仕組み

アーキテクチャ

運用

設計

試験

ユーザ側からの確認/指示無し

SSDのリセット処理時間は300ms

(HDDは1ms)

障害発生

リスクの認識なし

保守作業のリハーサルOKとのメーカ報告

教訓分析例

障害事例Ａ(6/6) 障害事例の分析例


PRC内のディスク装置の交換

情報処理システム内の構成要素の交換

抽象化

リセット要求コマンドの処理時間が異なる

非機能関連のインタフェースが異なる

抽象化

本質システムの一部構成要素の交換

非交換部分とのインタフェースの整合

リスク評価に基づく事前対応

事前の列車運行部門との共有

抽象化事前の関係部門との共有

教訓分析例

抽象化と本質


教訓分析例

構築当初のシステム構成要素の一部を交換

整合性の確認要

教訓の一例(2/3)


【教訓の活用例（1）】

比較的大規模なシステムにおいて，システムの構築あるいは更改を段階的に行う場合，版や性能等の異なる構成要素が混在することになるケース

多数のサーバと端末装置から成るシステムにおいて，当初は全体を一括で構築したものの，その後の端末の更改を，毎年一部ずつ順に行うような場合，新規端末の性能が当初端末より高い場合には，サーバとの通信における応答待ちタイマ値等をチューニングし直す必要があるかどうか，検討．

(個別)コンテキスト

教訓活用例



中央センタ・システム

Ａ

Ｂ

拠点サーバ各支店端末群

第一期更改高

性能化

教訓活用例

大規模システムの段階的更改


【教訓の活用例（3）】

システムの定期メンテナンスにおいて，一部のハードウェアコンポーネントあるいはソフトウェアモジュールをその時の最新のものと交換するケース

交換予定の最新のハードウェアコンポーネントあるいはソフトウェアモジュールでは，従来機能に加えて，機能拡張が行われていることがある．その場合，何らかの条件で，それら新規ハードウェアコンポーネントあるいはソフトウェアモジュールから，従来インタフェースにはなかったエラーメッセージが上位ドライバモジュールに報告されると，上位ドライバモジュールが異常停止するかもしれない．そのような可能性について，確認．

(個別)コンテキスト

教訓活用例



下位モジュール

上位モジュール

…

デバイス群

入替え

下位モジュール

上位モジュール

…

デバイス群

障害解析支援機能強化版

エラーメッセージ新規追加あり

教訓活用例

機能拡張されたモジュールとの交換

障害事例情報共有の取組みと...

Documents