障害事例から学ぶ高信頼化へのアプローチ -...

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

障害事例から学ぶ高信頼化へのアプローチ

～システムの信頼性を高めるための教訓集のポイントと

教訓をみんなで作って活用するノウハウの紹介～

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

八嶋俊介

2015年10月8日(木)

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

～目次～

１．アプローチの背景

2．教訓集2014の紹介

（教訓ダイジェストを使用）

３．教訓の共有活動のすすめ


IPA，及びSECについて

Ｊ－ＣＳＩＰ（サイバー情報共有）制御機器のＥＤＳＡ認証制度脆弱性対策情報（ＪＶＮ）セキュリティ被害の届出・相談暗号技術

重要インフラ等高信頼化対策ソフトウェア品質説明力強化ソフトウェア・サプライチェーンソフトウェア工学先導研究支援文字情報基盤、共通語彙基盤

情報処理技術者試験（ｉ-パス）未踏IT人材育成セキュリティ・キャンプＩＴ人材白書

(参考：過去の活動) ソフトウェアエンジニアリングの成果

本日の対象

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

SEC（ソフトウェア高信頼化センター）の事業項目


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)

１．ソフトウェアの複雑性が増大している

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

コード量 (× 100万LOC)

システム

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

１０スペースシャトルエンデバー


<出典> 片岡正次郎，鶴田舞，小路泰広：重要インフラ間の相互依存構造のモデル化と地震被害波及シミュレーション，国総研資料第 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

大 ←

影響度

発生確率 → 大

インフラシステム障害

サイバー攻撃

財政危機

水危機

気候変動

失業・不完全雇用

異常気象

所得格差

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

重要インフラのシステム障害は、サイバー攻撃に比べ発生確率は小さいものの、万が一発生したときの影響度はより大きい


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

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

高信頼化対策の対象

４．脅威（要因）の類型と今回のスコープ


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

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

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

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

△人身事故

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

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

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

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

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

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

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

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

□経済事故


4/7 日本生命査定システム障害

4/22 三井住友銀行ATM障害

4/25 八十二銀行ATM障害

4/30 三菱東京UFJ銀行自動送金サービス障害

6/5 JAL重量バランスシステム障害

6/25 スカパーシステム障害

8/4 世田谷区役所システム障害

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

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

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


現状（教訓の共有なし）

製品機器/ ITサービス

(Ａ社)

社会


(Ｂ社)


(Ｃ社)

信頼性

信頼性

信頼性

原因分析対策検討

対策実施

教訓Ａ


対策実施

教訓Ｂ


対策実施

教訓Ｃ

障害障害障害

重要インフラ等

７．インフラシステムの障害の増加とその理由

増加傾向

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

（月平均、報道ベース）

出典： SEC Journal 第40号（2015年3月発行）

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

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

20072008200920102011201220132014201520162017201820192020


【処理量の増大に対する対処遅れ】アフラックの障害（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 第40号（2015年3月発行）

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

20072008200920102011201220132014201520162017201820192020


１０．IPAの製品制御・ITサービスの研究会で教訓集を作成

2015年3月末公開

製品・制御システム分野

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

[教訓数]

28件

[教訓数]

27件

普遍化取りまとめ

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

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

＜重要インフラITサービス高信頼化部会＞情報処理システム高信頼化教訓集

（ITサービス編／製品・制御システム編）

【参画企業等】

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

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

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

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

アイシン精機（株）

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

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

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

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

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

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

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

九州大学、会津大学

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

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

【参画企業等】

（株）三菱東京UFJ銀行

日本生命保険相互会社

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

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

東京電力（株）

東日本旅客鉄道（株）

KDDI（株）

（株）フジテレビジョン

（株）クロスウェーブ

（株）オリジネィション

日本大学

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

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

製品・制御システム編

2015年8月末時点




（教訓ダイジェストより）


ITサービス編

製品・制御システム編

2014年度版

サービスやシステムの

信頼性を高めるための

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

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

教訓集ダイジェスト

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

サービス・システム高信頼化への対策

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

対象分野の例

私たちIPAは、国民生活や社会・経済基盤を支える情報処理システムの信頼性向上を目標とし、以下の活動を行っています。・システムの障害事例情報の分析や対策手法を整理・体系化して、これから導かれた「教訓」を作成する・「教訓」を業界・分野を越えて幅広く共有し、類似障害の再発防止や影響範囲縮小につなげる「仕組み」を構築する・「教訓」を分野横断で共有するため、障害情報や教訓の共通様式と公開に際しての機密保持などの「ルール」を取りまとめる・類似障害の再発防止に向け、システム開発や運用・管理の継続的なプロセス評価・改善手法を取りまとめる今回はこれに際してとりまとめた「教訓集」をご紹介します。

ITサービスを担う情報処理システムにおける、主としてソフトウェアに起因する障害関連情報を収集し、それらの分析や対策手法の整理・体系化を通して得られる教訓をまとめました。教訓は、「ガバナンス・マネジメントに関する教訓」と「技術に関する教訓」の２つに分類しています。

・ガバナンス・マネジメントに関する教訓一覧・技術に関する教訓一覧・教訓の例・教訓集の普及展開（展示会やセミナー）

ITサービス編 P4

サービス・システム高信頼化教訓集

交通機関や電気・水道の制御など、製品に組み込まれた機器の制御を行う「製品・制御システム」（組込みシステム）の障害情報を収集・分析し、そこから得られた経験やノウハウを教訓集にまとめました。各教訓は、類似障害の未然防止を目的に、他製品・他産業領域への活用も可能なものにするため、分析から対策までを含めた未然防止知識の形に整理し、抽出された直接原因や真因は、観点マップとして整理しています。

・教訓一覧・未然防止知識事例・観点マップ

製品・制御システム編 P12

P4

P6

P10

P11

P12

P14

P18

ソフトウェア高信頼化センター（SEC）の取り組み

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

障害事例を分析し、未然防止策を社会で共有する仕組みを作ります。

詳しくは、下記URLをご参照ください。

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

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

下記URLからダウンロードできます。

http://www.ipa.go.jp/sec/reports/20150327_1.html

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

下記URLからダウンロードできます。

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

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

〒113-6591 東京都文京区本駒込2-28-8 文京グリーンコートセンターオフィス16F

[TEL] 03-5978-7543 [E-Mail] [email protected]

[URL] http://www.ipa.go.jp/sec/index.html

INFORMATION


（黄色は２０１４年度に追加したもの）

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

No. 教訓ＩＤ教訓概要

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

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

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

4 Ｇ４少しでも気になった事象は放置せず発信し、とことん追求すべし

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

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

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

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

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


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

システムトラブルの8割は、上流の要件定義局面でのコミュニケーション・ギャップから問題が生じていることが判明 →システム開発におけるビジネスサイドの役割と責任を明確化し、コミュニケーションの質を高める態勢「アプリケーション・オーナー制度」

アプリケーション・オーナー制度：責任と役割分担（東京海上日動火災株式会社の例）

•システム開発は、情シス部門に任せきりにすべき仕事ではなく、自分の考えた商品や施策を具体化するために行う自分自身の仕事であるという「オーナーシップ」の考え方を持たせる。

•事業部門に、要件の詳細が固まるまで、情シス部門と対話を繰り返す責任を持たせ、要件定義の最終責任を負わせる。

•事業部門に、要件定義どおりにシステムが出来たかどうか受入れテストを実施する責任を負わせる。

教訓の概要（Ｇ１）


教訓の概要（Ｇ４）

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

【問題】運用者及び保守者が夜間作業中の異常を誤認してオンラインサービスの開始が遅れ、数時間停止

【原因】運用担当者が察知した異常を、保守担当者が異常なしと誤認．運用部門責任者も十分に確認せず、報告そのままに問題なしと判断し、ＣＩＯへの報告を怠る．

運用担当者は確かな異常状況に気づいていたが、運用マニュアル通りに作業し、気づきを運用部門の責任者等に伝えなかった．

【対策】①「運用担当者が現場での異常を察知したときには、状況判断できる運用部門の社員にその情報を連絡して協議する態勢を作る」ことを運用マニュアルに明記．

②障害対応体制面での改善・強化：・事象として障害と断定できない場合でも障害の可能性がある場合は早期に上位役職者へ報告するルールの追加作成

・状況判断できる運用部門社員の24時間常駐

③確認手順及び項目の明確な定義

④教育・訓練

２０１４年度に追加した教訓

運用子会社保守ベンダ運用部門

CIO

障害連絡

調査対応結果報告

報告

① 障害診断ツールの診断レポートの内容を電話と電子メールで保守ベンダに報告

② 診断レポートを誤認し，切替えが成功していると回答

③ 業務への影響はないと判断し，障害対応を完了

④ 業務システムの異常が判明後，ＣＩＯに連絡


（黄色は２０１４年度に追加したもの）

技術領域の教訓

No. 教訓ＩＤ教訓概要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

現在時刻

予測ダイヤ

①抑止入力

修正箇所

②ダイヤ修正発生

④予測ダイヤの表示ができなくなった

実績ダイヤ

③修正箇所が上限値を超過

現在時刻

表示項目数がシステムの上限値を超えたため、全画面表示が消え，オペレータが混乱

↳システム構築当初から決まっていた上限値について、外部仕様変更に伴う見直しを未実施

原因の本質は、全体に影響する変化点（この場合、予測時間、列車運転本数）が不明確

【原因１】予測時間を4H⇒24Hに変更した際、そのような要件変更があったにもかかわらず、「修正箇所数」の上限値の増加などシステム全体の機能要件変更を未実施

【原因２】列車の本数が年々増加しており、本来ならば（運転本数の増加の都度）上限値を超えた際のシステムの挙動を見直す必要があったにもかかわらず、未実施

【対策】制御系システムの変化点の管理ルールを明確にし、そのルールを守る仕組みを構築

・システムが監視・制御する対象と仕様の変化点を網羅

・変化点管理のルールとそれを守る仕組みを構築

・変化点管理で使用する管理指標を関係部門で共有し、「変化点の見落とし」を防止

教訓の概要（Ｔ４）


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

冗長構成を取っているにも関わらず、バックアップ切替えが失敗しシステム障害となるケースが多い。下図に示されるさまざまな失敗原因にあらかじめ配慮してシステムの開発・運用を行うことにより、過去に発生した障害と類似の障害の発生を防ぐことができる。

稼働系待機系/分散稼働

現用

予備

電源装置(現用)

電源装置(予備)

ネットワーク

(5)手動切替え失敗（操作ミス）

(7) 待機系システムの障害（稼働系と同一原因）

(9) 切替え失敗（保守作業ミス）

(11)電源装置の自動切替えに失敗

ネットワーク

データデータ

(10) ネットワークの自動切替えに失敗

ハードウェア

アプリケーションOS等

ハードウェア

アプリケーションOS等

(8) 切替え後動作不安定（データ不正）

(4)切替え失敗（切替えソフトウェア不具合）

(1）稼動系システムの障害未検知

(2)待機系システムの障害（構成不備）

(3)待機系システムの障害（アプリケーション不備）

(6)切替え後動作不安定（性能不足）

教訓の概要（Ｔ７）


教訓の概要（Ｔ１２）

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

【問題】2重化された制御系システムにおいて、部品交換の保守作業時にシステム全体の動作が停止し、短時間で復旧できずに、サービス利用者が終日影響を受けた。

【原因】システムのディスク装置が、数年前に，当初構築時のHDDからSSDに交換されていた。部品交換作業でA系を切り離した時にB系OSから両系のディスク装置にリセット要求が発せられるが、SSDのリセット要求処理時間は、HDDのそれよりかなり長く，OSのタイマ監視においてタイムアウトが発生した。その後のリカバリ処理もうまくいかなかった。

【対策】・仕様上の互換性を過信せず、差異分析を必ず実施

・ベンダとユーザの双方が相手の役割分担を支援し合う（ユーザ側でハザード分析を行う）

２０１４年度に追加した教訓

SSDへの交換時に、HDDと完全に互換性があると誤認し、検証・テストが不十分であった。


１１．教訓を類似障害へ適用すると

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

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

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

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

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

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


１２．今回の教訓化の３つの特長

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

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

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


１３．教訓共有でこんなメリットがある ◆“教訓”集の活用によるメリット

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

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

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

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

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

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

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

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


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

共有活動の例

展開

（１）障害事例から得られた教訓の共有活動の実施 ①ＷＧなど共有の場における意見交換 ②電子掲示板・メーリングリスト等を活用した適時の情報共有

（２）関心テーマに関する勉強会やセミナーの開催

（３）業界内での教訓の活用 ①未然防止に向けた自組織の運用ルール等の見直し ②障害事例から学ぶＩＴ人材教育

（４）業界内での検討により得られた新たな教訓の提供

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

１５．ＷＧなど共有の場における意見交換

①情報通信分野 ITA（情報サービス団体（加盟18社））との協業で、「障害再発防止策研究会」が平成26年に発足し、システム障害情報の教訓化の仕組みを団体内に構築し活動開始。IPAのITサービス高信頼化部会においてITAが活動状況の報告を実施。活動の成果はITAのWebサイト上で「ITA情報処理システム障害事例集」として公開されIPAのウェブサイトからURLリンクによる連携を実施（平成27年1月28日）。ITAの研究会は平成27年も「システム高信頼化研究会」と改称して活動を継続。

事例№ 発生フェーズ原因フェーズ123456 運用・保守設計7 製造計画8 運用・保守設計9 設計設計10 設計設計11 結合・システムテスト要件定義12 製造契約13 設計計画、要件定義14 導入・納品計画15 運用・保守結合・システムテスト16 運用・保守運用・保守17 運用・保守結合・システムテスト、運用保守18 結合・システムテスト要件定義、設計19 運用・保守設計20 運用・保守要件定義

ポカヨケ　－ミスを誘発しない手順を、担当者の経験を考慮して文書化する

オペミス撲滅　－　詳細な手順・チェックリスト、ペア作業密なコミュニケーション　－　顧客満足度の高いシステム構築への鍵

業務精通者のレビューは必須と心得よシステム運用設計は現実の業務量を想定してシミュレーションすること

自分で考える－　顧客やプライムSIerの言うことを鵜呑みしないスコープ増大　－現場当事者では気づかない場合あり。上層部の監視も重要

チェックリスト　－　過去に痛い目にあった経験を共有する手段

遅れ始めたプロジェクトに人を投入しても遅れを拡大させるだけ

品質作りこみのために、暗黙知や職人芸は期待しない

レビューに勝る品質向上策なし

過剰な品質管理は品質劣化を招くユーザ検証時の仕様変更は当たり前

過信は怪我の元　①　－　手順書に見えない部分あり過信は怪我の元　②　－　連携先の怪我も事前手当過信は怪我の元　③　－　記憶は不確か明記は絶対過信は怪我の元　④　－　自己満足に陥らない。周囲の意見を大切に

同じ構文でも環境が変われば結果は異なる機能変更は過去データへの影響を配慮せよ設計はシンプルに！

タイトル


１６．電子掲示板を活用した情報共有

②行政（自治体）分野東京都特別区電子計算主管課長会にて障害情報の共有の意義が理解され、情報共有を行うことが決議（平成26年11月6日）。会議にて、本取組みに対する必要性・重要性について、「システムの障害は小さなものならば日々発生している」、「委託管理の視点から、情報共有には意味がある。業者が既知の問題を捉えているかというチェックを行うことができる」、「短時間でもシステムが止まれば区民を待たせることになる。他区の事例や情報を共有し、リスクを回避する必要がある」などの意見。

＜仮想的なオンライン情報共有グループ＞世田谷区で試行運用中新聞報道より

障害情報

各区が共有

「教訓」生かし

リスク回避

（区電算課長会）

２０１４年１１月１８日（都政新報社）


１７．メーリングリストを活用した情報共有

③電力分野

電気事業連合会と協議し、情報共有の取組みに賛同する８組織を中心にメーリングリストを使用した情報共有を行うことで合意（平成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件

まずは、IPA/SECからの障害共有情報を電力業界に絡めて編集し、情報提供から実施。共有の意義を醸成してから、各社からの情報発信を期待。

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

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

18．IPAからのご提案

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

◆メリット・他社での障害を自社で発生させないことができる。・教訓化することで、システムの保守・運用のノウハウの継承に役立つ。・人材育成に役立つ。

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

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


【ご参考】SECセミナーのお知らせ

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

【SECセミナー】事例から学ぶITサービスの高信頼化へのアプローチ～障害事例の分析から導かれた情報処理システム高信頼化教訓集～

このセミナーでは、最初に講義編で教訓集について解説し、続く演習編では、受講者の皆さまに事例を基に教訓作りを体験していただきます。参加いただくことにより、障害に対する取組みの「気付き」を学ぶことができます。さらに、効果的に障害対策を実行できる方法を身につけることができます。

日程： 2015年12月4日(金) 時間： 13:30～17:00 場所： IPA会議室(東京都文京区)

※詳細・申し込み方法等は決まり次第、以下のサイトにてお知らせいたします。


（問合せ）

ソフトウェア高信頼化センター（SEC) システムＧ

[email protected]


39

「ｉパス」は、ITを利活用するすべての社会人・学生が備えておくべき

ITに関する基礎的な知識が証明できる国家試験です。

ITパスポート公式キャラクター

上峰亜衣（うえみねあい）

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


40

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

サポート終了後は修正プログラムが提供されなくなり、脆弱性を悪用した攻撃が成功する可能性が高まります。

周辺ソフトウェアもサポートが順次終了していくため、あわせて対策が必要です。

サポートが継続しているOSへの移行検討とOS移行に伴う周辺ソフトウェアの

影響調査や改修等について迅速な対応をお願いします。

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

IPA win2003 検索詳しくは

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

脆弱性が

未解決なサーバ脆弱性を

悪用した攻撃

ホームページの改ざん

重要な情報の漏えい

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

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

データ消去

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


41

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

Transcript of 障害事例から学ぶ高信頼化へのアプローチ -...