ETWest2016
2016年7月7日
独立行政法人情報処理推進機構（ＩＰＡ）
技術本部 ソフトウェア高信頼化センター（ＳＥＣ）
三縄 俊信
障害事例の分析により得られた教訓の共有
（ITサービス編）
～教訓を活用して情報システムの類似障害を削減～
配布用～目次～
Ⅰ．アプローチの背景
Ⅱ．教訓集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２.システム障害は増加し類似のものが多い
0 5 10 15 20 25 30 35 40 45 50 2009 2010 2011 2012 2013 2014 2015 多大な影響を与えたITサービス障害の 発生件数（報道ベース）の推移 件 ・△△でリコール、国内で数十万台 …理由は、制御プログラムに不具合が発見されたためという。 ・○○システムで障害か、終日つながりにくく …原因は、法律改正直前の駆け込み需要と期末の締め処理とが 重なり、想定外の大量入力にシステムの性能が耐えられなかっ た模様。 ・□□システムで障害、午前中のサービス停止 …原因は、システムは本番装置の故障により予備装置に自動的 に切り替わるようになっていたが、その切替えが失敗したため という。社会に大きな影響を与えたシステム
障害の発生件数
2009年以降で増加傾向
新聞やテレビなどのメディアでは， 幾度となく以下のようなニュースが世間を賑 わせている： 類似障害の発生 (出典) SEC Journal 情報システムの障害状況３．リスクへの対応はハードとソフトで異なる
ハードウェアは劣化する→故障
ソフトウェアは劣化しない
ソフトウェアは
相対的に
劣化する
（ｼｽﾃﾑ）
使われる環境の変化
ビジネス方針，ニーズ
組織・人（慣れによる過信・
油断，交代による技術/ノウ
ハウ継承無し）
利用者増，技術進展，他
網
羅
的
な
事
前
抽
出
が
困
難
失敗に学ぶ
冗長構成，など
教訓の活用
障害事例に基づく
教訓・対策の共有
リスク要因
４. 問題点とアプローチ方法
<現状の問題は何か？>
類似した問題/失敗
が、重要インフラの異なる業界で、たびたび発生する
異なるITサービス/製品と装置の各々の失敗ケースが、
会社全体で共有されていない
<では、どうアプローチすればよいか>
失敗事例
を収集して分析する
↓
根本原因
を抽出して
教訓にする
（組織化、体系化、蓄積）
↓
社会で共有し
（異なる業界間において）
、類似の失敗を防止
して最小化する
" 失 敗 か ら 学 ぶ “
５．教訓を共有すると
障害に基づく教訓の共有による信頼性向上のしくみ 現状（教訓の共有なし） 製品機器/ ITサービス (Ａ社) 社 会 製品機器/ ITサービス (Ｂ社) 製品機器/ ITサービス (Ｃ社) 信 頼 性 信 頼 性 信 頼 性 原因分析 対策検討 対 策 実 施 教 訓 Ａ 原因分析対策検討 対 策 実 施 教 訓 Ｂ 原因分析対策検討 対 策 実 施 教 訓 Ｃ 製品機器/ ITサービス (Ａ社) 製品機器/ ITサービス (Ｂ社) 製品機器/ ITサービス (Ｃ社) 信 頼 性 信 頼 性 信 頼 性 原因分析・対策検討 一般化・抽象化・普遍化 体系的整理 教 訓 Ａ教訓 Ｂ教訓 Ｃ 対策実施 対策実施 対策実施 障害 重要インフラ等専門家，有識者のご協力を得て
IPA/SECや業界団体等が担う共有活動
教訓 機密保持等 のルール 類似障害の発生 社 会 重要インフラ等より高い安全・安心な
製品機器/ITサービスの提供
障害 障害 障害 障害 障害 教訓 教訓６．４つの脅威と今回のスコープ
<出典> 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 システム障害８．教訓集の公開
組込みシステム分野 国民生活や社会・経済基盤に関わる 「障害情報」を収集 [教訓数] 35件 [教訓数] 36件 普遍化 取りまとめ 収集した情報を分析し 対策を検討 情報処理システム高信頼化教訓集2015 （ITサービス編／組込みシステム編） 【参画企業等】 トヨタ自動車（株）、日産自動車（株） 日本電気（株）、 （株）日立製作所 三菱電機（株）、横河電機（株） 富士電機（株）、矢崎総業（株） アイシン精機（株） 日本電気通信システム（株） （株）日立産業制御ソリューションズ 三菱電機メカトロニクスソフトウェア（株） （株）富士通コンピュータテクノロジーズ オムロンソーシアルソリューションズ（株） アイシン・コムクルーズ（株） 北陸先端科学技術大学院大学 九州大学、会津大学 （一社）組込みシステム技術協会 （一社）電子情報技術産業協会 【参画企業等】 （株）三菱東京UFJ銀行 日本生命保険相互会社 東京海上日動火災保険（株） （株）日本取引所グループ 東京電力（株） 東日本旅客鉄道（株） KDDI（株） （株）フジテレビジョン （株）オリジネィション 日本大学 内閣官房情報通信技術総合戦略室 （一社）日本情報システム・ユーザー協会 組込みシステム編 2016年３月時点 2015年度 新着７件 2015年度 新着９件 2015年12月から新着教訓を随時Web公開2013年度版（2014年5月公開）から毎年追加し公開
＜特徴＞ ①業界・分野を超えて活用可能な普遍化された教訓。 ②機密保持ルールの下で詳細情報の提供を受けた深い議論。 ③蓄積されたソフトウェア・エンジニアリングに関する知見活用。 http://www.ipa.go.jp/sec/system/lesson.html ＜重要インフラITサービス高信頼化部会＞ ＜製品・制御システム高信頼化部会＞ 2016年3月末公開９．教訓集2014活用アンケート
(WEBダウンロードした方に実施 回答115件 ： 2016年1月）
21% 40% 33% 6% 活用している組織や範囲 組織全体 一部の組織 個人 その他 87% 1% 12% 教訓集の有効性 役に立つ 役に立たない よく分からない 1% 83% 13% 3% システム障害情報を公開する 企業をどう思うか 障害を発生させていること から、信頼できない 積極的に情報公開をする ことから、公開しない企業 に比べて信頼できる 特に意識したことはない その他 45% 55% 活用している割合 はい いいえ 0 5 10 15 20 25 30 回 答 数 活用の目的１０．教訓集2015の紹介
2015年度版
サービスやシステムの
信頼性を高めるための
独立行政法人情報処理推進機構（IPA） 技術本部 ソフトウェア高信頼化センター（SEC）教訓集
ダイジェスト
ITサービス 編
組込みシステム 編
お手元のパンフレットを御覧ください
教訓一覧
T17 定期的な再起動に関する教 訓 長時間連続運転による不安 定動作発生の回避には定期 的な再起動も有効！ 基幹業務システムの１日 停止 負荷分散装置の障害発 生 負荷分散装置が8か月以上連 続運転状態であり、再起動をし たことがなかった。再起動をし ていれば、バグが顕在化する ことはなかった。 ・毎月の定期保守日に状況を見て 再起動を行うこととした 仮想化、共同利用、システム再起 動 T18 既存システムとのデータ連携 に関する教訓 新たなサブシステムと老朽化 した既存システムとを連携す る場合は両者の仕様整合性 を十分確認すべし オンラインサービスの遅 延、停止、サービス明細 の欠落 特別な事象を契機とする 処理集中のため、夜間 バッチが異常終了 携帯電話に対応した新しいシ ステムと既存システムを接続し た際の全体整合を十分チェック できていなかった ・既存システムの要件定義内容を 再度チェックして連携するシステム 間の整合性を確認。これらをルー ル化してマニュアルに取り込む ・システムが異常終了しても途中か ら再開始可能な仕組みの導入 既存システム、システムの追加、 インタフェース、制限値 T19 ＲＤＢＭＳのクエリ最適化機 能に関する教訓 リレーショナルデータベース （ＲＤＢＭＳ）のクエリ自動最 適化機能の適用は慎重に！ システム応答速度の低 下 ＲＤＢＭＳのＳＱＬ応答遅 延 ＲＤＢＭＳの自動最適化機能に よるフルスキャンの発生 ・インデックスの追加 ・実行計画の固定化の検討 ＲＤＢＭＳ、クエリ自動最適化、実 行計画の固定 T20 パッケージ製品の機能カスタ マイズに関する教訓 パッケージ製品の機能カスタ マイズはリスクを認識し特に 必要十分なチェック体制や チェック手順を整備して進め ること コールセンタ業務で通話 着信障害 制御ソフトの無限ループ 発生 パッケージ製品のカスタマイズ による不具合の内包 ・交代系への自動切換もできなく なったため、強制的に手動切替を 行い復旧 ・後日、プログラム修正実施済み パッケージ製品のカスタマイズ、プ ログラムミス、処理の競合 T21 運用保守で起きる作業ミスに 関する教訓 作業ミスを減らすためには、 作業指示者と作業者の連携 で漏れのない対策を！！ 依頼コールの転送ミスに よる現場の混乱 GW増設時のシステム設 定値の作業ミス 作業ミスを起こさせるような状 況、環境があることである。 作業ミスは、個人、環境、ハード ウェア、ソフトウェアの関係性の中 で、対策を考える。ヒューマンファク タの観点からシステムの問題を仕 組みや組織として改善することに 主眼を置く。 ヒューマンファクタ、m-SHELモデ ル、なぜなぜ分析、ヒューマンエ ラー対策 T22 バッファプールの管理に関す る教訓 隠れたバッファの存在を把握 し、目的別の閾値設定と超過 アラート監視でオーバフロー を未然に防止すること 予期しない予約システム の受付停止 トランザクション集中に 伴うバッファのオーバフ ロー バッファの滞留状況の監視が されていない 各種バッファの用途に応じた閾値 の設定とアラーム表示機能の追加 バッファプール、閾値設定、アラー ム表示 対策 キーワード 根本原因 No. 教訓集の目次（分類） 教訓概要 問題 直接原因教訓一覧
サ ー ビ ス レ ベ ル 管 理 サ ー ビ ス 継 続 ・ 可 用 性 管 理 サ ー ビ ス 報 告 容 量 ・ 能 力 管 理 情 報 セ キ ュ リ テ ィ 管 理 事 業 関 係 管 理 供 給 者 管 理 イ ン シ デ ン ト 管 理 問 題 管 理 構 成 管 理 変 更 管 理 リ リ ー ス 管 理 T1 6 修正パッチの適用に関する 教訓 △ △ ● T1 7 定期的な再起動に関する教 訓 △ ● T1 8 既存システムとのデータ連携 に関する教訓 ● △ T1 9 ＲＤＢＭＳのクエリ最適化機 能に関する教訓 ● △ T2 0 パッケージ製品の機能カスタ マイズに関する教訓 △ ● T2 1 運用保守で起きる作業ミスに 関する教訓 △ △ ● T2 2 バッファプールの管理に関す る教訓 ● △ △ No. 教訓集の目次（ 分類） Ｊ ＩＳ Ｑ 20000-1：2012よ り （●主な問題個所、 △関連する 問題個所） ５ ． 新 規 ま た は サ ー ビ ス 変 更 の 設 計 及 び 移 行 ６． サービ ス提供プロ セ ス ７． 関係プロ セ ス８． 解決プロ セ ス ９． 統合的制御プロ セ スＧ10：
関係者からの疑義問合せは自社システムに問題が発生して
いることを前提に対処すべし！
【問題】コールセンタにおいて電話コールの一部が着信後に即切断されてしまう事象が発生していたがイタズラ 電話との認識、また通信回線事業者からコールの接続異常が時々発生しているが問題はないかと問合せ はあったが他の事業者は正常との回答であったため問題視しなかった。システム障害と気付くまでに4 時間経過していた。 【原因】設定変更のミス。回線収容基板の一部廃止に伴い回線試験用の設定も削除するべきだったが漏れた。 エラー電文の蓄積が共通バッファ オーバフローを招き通話不可。 【対策】(復旧措置） 交代系への切替えで復旧 (作業漏れへの対策） 保守運用マニュアルの改善 (障害状態検知への対策） バッファ監視機能追加 (異常申告への対策） 回線事業者連絡会の設置 (交代系への切替え判断） 原因調査より復旧作業優先Ｇ1４：
設計時に定めたキャパシティ管理項目は、環境の変化に
あわせて見直すべし！
１分あたりの処理件数の変化 １秒あたりの処理件数の変化 Plan (企画・計画） Action (改善対策） Do (モニタリング） Check (分析・評価） ①現行システムに対して キャパシティ計画の修正、設定し た閾値を見直す ②次世代システムに対して 次世代システムのキャパシティ管 理要件として、開発時の要件定義 に組み込む 【原因】設計時に定めた監視する時間間隔（キャパ シティ管理項目）では十分にシステムを監視 できていなかった。 【対策】①現行システムに対しては、キャパシティ計画の 修正と設定した閾値の見直しを行う。 ②次世代システムのキャパシティ管理要件として、 開発時の要件定義に組み込む。 【問題】A社のシステムは、以前から一般的な増加と ともに、突発的な事象によるデータ量の急増 がみられた。このA社のシステムにある日、 処理能力を越えた注文が殺到し、サービスの 時間が短縮となった。Ｔ19
：
リレーショナルデータベース（ＲＤＢＭＳ）の
クエリ自動最適化機能の適用は慎重に！
【問題】ある朝、オンラインシステムのタイムアウトが多発し運用監視コンソール端 末にトランザクション異常終了のメッセージが大量に出力された。 【原因】広範囲にわたる検索条件入力が投入された(①)ため、ＤＢサーバで稼働 するRDBMSの最適化機能により全件フルスキャンを行うSQL実行計画 が適用されSQL処理が長時間実行された(②)。 APサーバのSQL監視タイマのタイム アウト（3分）となりアプリケー ションが異常終了した(③)。 以降のトランザクションも同じSQL 実行計画が適用され続けたため。 【対策】・RDBMSの再起動で回復 ・フルスキャンが発生しにく いようインデックスキーを複 数追加したＴ19
：
リレーショナルデータベース（ＲＤＢＭＳ）の
クエリ自動最適化機能の適用は慎重に！
【問題】ある朝、オンラインシステムのタイムアウトが多発し運用監視コンソール端 末にトランザクション異常終了のメッセージが大量に出力された。 【原因】広範囲にわたる検索条件入力が投入された(①)ため、ＤＢサーバで稼働 するRDBMSの最適化機能により全件フルスキャンを行うSQL実行計画 が適用されSQL処理が長時間実行された(②)。 APサーバのSQL監視タイマのタイム アウト（3分）となりアプリケー ションが異常終了した(③)。 以降のトランザクションも同じSQL 実行計画が適用され続けたため。 【対策】・RDBMSの再起動で回復 ・フルスキャンが発生しにく いようインデックスキーを複 数追加したSQL実行計画の変更による性能劣化発生への対策
案
対策内容
メリット
デメリット
備考
１
インデックスを追加 クエリ最適化機能は活用 できる 更新負荷の増大による性 能劣化の恐れあり データ量の変動が 予測される場合２
SQL実行計画の固定化（利用 比率の高いSQLのみ） 案3に比べて効率的 利用比率が均等だと効 果は小さい システム全体に影 響させたくない場 合３
全てのSQL実行計画を固定 化 SQL実行計画の自動切 替は発生しなくなり極端 な劣化は発生しない。 データ量の変化に追随し ないため高速処理は望め ない。 極端に遅くなるの を防止したい場合Ｔ21：
作業ミスを減らすためには、
作業指示者と作業者の連携で漏れのない対策を！
【問題】A社は、4回に1回の割合でB社への集荷依頼をC社集荷本部に転送していた。 現場は混乱し、集荷作業漏れが多発し、顧客からの苦情が殺到していた。 【原因】障害の直接原因は、作業者の些細な誤りであったが、根本的には、誤りを見逃しやすい作業環境と最 後の砦となるべき作業指示者の確認不足によるものであった。 【対策】・作業者の観点から、個人、 環境、ハードウェア、ソフト ウェアの視点で、作業ミスの 原因、対策を考える。 ・作業指示者の観点から、作 業指示者は、システムの問題 を仕組みや組織として改善す ることに主眼を置く。11．類似のシステム障害を教訓活用で減らす
【二重化システムでの待機系切替 え失敗】を予防したい・・・ [教訓 Ｔ７]バックアップ切替えが 失敗する場合を考慮すべし、の対策を実施する KDDI（2013.4.16）・・・メール送受信 サービス障害の解消後、新システ ムへの切替え中にエラーが発生、 現行システムに切り戻し中に過負 荷となり、サービス停止。 JR九州（2013.7.18）・・・列車進路 制御装置の外部記憶装置の交換 により情報のやり取りに不具合が 発生し、システム全体にトラブルが 波及。 対策１１＞本番稼働に近いテスト環境を用意し、OS、 ミドルウェアのバージョンアップ時の動作確認と性能 （負荷）確認が行えるようなツールを作成する。 対策１２＞冗長化を実施する場合、すべての機器（単体機器、または 密結合の機器）が冗長化されていることを常に点検する。 対策７＞バックアップ切替え後、縮退運転の場合での ピーク時性能は、日常の監視の中で想定し、 必要に応じてシステムを見直す。 対策８＞本番稼働に近いテスト環境を用意し、性能（負荷） 確認が行えるようなツールを作成する。 対策９＞切替え、縮退運転の性能要件（ピーク時）は、 設計時に明確にする。１２．教訓を共有するメリット
◆
“教訓”集
の活用によるメリット
①さまざまな分野での経験から得られた教訓（開示レベル：公開用）
の中から
自社に適用可能
なものを見つけ、
活用
することができる。
◆
情報共有の仕組み
への参加によるメリット
①情報共有のグループ（教訓化過程）への参加により、
公開教訓より
深い情報
（開示レベル：グループ内限り）が得られる。
②自社の事例情報に対する有識者や他分野の専門家等からの意見
や、教訓化（抽象化）の
議論を通した気づき
が得られる。
③（分野間の共有により）他分野の方々とも
交流
が深まる。
１３．教訓の共有活動の展開
共有活動の例
展
開
（１）障害事例から得られた教訓の共有活動の実施
①
ＷＧ
など共有の場における意見交換
②
電子掲示板・メーリングリスト
等を活用した適時の情報共有
（２）関心テーマに関する
勉強会
や
セミナー
の開催
（３）業界内での
教訓の活用
①未然防止に向けた自組織の
運用ルール等の見直し
②障害事例から学ぶ
ＩＴ人材教育
（４）業界内での検討により得られた
新たな教訓の提供
１４. 教訓共有の事例（行政・自治体分野）
東京都の特別区のうち有志区が参加する情報システム担当者間の共有が開始
障害事例を掲示板に登録・議論（まずやってみよう！）
システムの障害は小さなものならば日々発生している 委託管理の視点から、情報共有には意味がある。 業者が既知の問題を捉えているかというチェックを行える 短時間でもシステムが止まれば区民を待たせることになる。他区の事例や情報を共有し、リスクを回避する必要がある ＜仮想的なオンライン情報共有グループ＞ 試行運用中 ★平成27年度末に各区が参加する事例勉強会を開催（グループ 討議型式） 登録されたシステム障害事例について、グループ毎にディスカッション実 施 ・問題の整理・認識 ・なぜなぜ分析による根本原因の分析 ・改善策の導出 ・全員で発表 ⇒事例登録区にとって気付かない改善事項 他の区では本事例の対応策を振り返る材料1５. 教訓を活用するガイドブック2編を公開
IT障害等の事例 事例からの学び （失敗のカラクリ等の 気付きを与えるメッセージ） 高信頼化への知恵 （成功のカラクリ等の気付き を与えるメッセージ） （裏返し）教訓作成ガイドブック
（教訓を作成する） 抽象化教訓活用ガイドブック
（教訓を活用する） フィード バック 具体化 自社 教訓集 各社／組織で作成 ＩＰＡ 教訓集情報処理システム
高信頼化教訓集
IPA/SEC 具体化 ITシステムの 開発・運用の現場 IT障害リスク低減の 具体策等1６．ご提案
みなさまと同じ業界分野でグループを作り、そこで教訓集を作成し、類似障害
の撲滅を目指しませんか。
◆メリット
・他社での障害を自社で発生させないことができる。
・教訓化することで、システムの保守・運用のノウハウの継承に役立つ。
・人材育成に役立つ。
IPA/SECが、ご支援いたします。
IPA/SECは、
教訓の演習（SECセミナー)
を実施しています。
また、
各種業界や企業グループへ出向いて
個別にセミナー
も行っています。
ご清聴ありがとうございました
詳細は展示ブースを
新試験はじまる！
情報セキュリティマネジメント試験
◆28年度秋期試験実施時期◆
・実施日
2016年10月16日（日）
・申込受付 2016年
7月11日（月）から
・個人情報を扱う全ての方
・業務部門・管理部門で
情報管理を担当する全ての方
◆受験をお勧めする方◆
初回応募者 約2万3千人！！情報セキュリティの基礎知識から管理能力まで、
組織の情報セキュリティ確保に貢献し、脅威から
継続的に組織を守るための基本的スキルを認定する試験
「ｉパス」は、ITを利活用する
すべての社会人・学生
が備えておくべき
ITに関する基礎的な知識が証明できる国家試験です。
ITパスポート公式キャラクター 上峰亜衣（うえみねあい）
