信頼性に関わる実証的な試みの提言 -...
TRANSCRIPT
東京大学 中尾政之
2009年5月27日
IPAX2009にて
-重要インフラ情報システム信頼性研究会報告書から-
信頼性に関わる実証的な試みの提言
本研究会の狙い
重要インフラシステム障害の頻発
システムに内在する不具合(設計)
システム運用時の環境不適合(運用)
第三者による攻撃(セキュリティ)
重要インフラ情報システムとは?
欠陥の数
開発総費用・購入価格
開発総費用
購入価格
品質尺度
無管理ゾーン 管理ゾーン 特別管理ゾーン 無欠陥目標ゾーン
5~20/500
ユーザー満足度
1/500 1/5000 ほぼ 0
注1 品質尺度:(納入時~安定稼動期迄の欠陥個数)/開発費用(万円)
注2 開発総費用と購入価格のギャップはテスト結果の確認、修正結果の確認のために要するユーザー側の 負荷増加費用をイメージ化したもの。
ユーザー満足度
欠陥の数
開発総費用・購入価格
開発総費用
購入価格
品質尺度
無管理ゾーン 管理ゾーン 特別管理ゾーン 無欠陥目標ゾーン
5~20/500
ユーザー満足度
1/500 1/5000 ほぼ 0
注1 品質尺度:(納入時~安定稼動期迄の欠陥個数)/開発費用(万円)
注2 開発総費用と購入価格のギャップはテスト結果の確認、修正結果の確認のために要するユーザー側の 負荷増加費用をイメージ化したもの。
ユーザー満足度
図3-2 JUASが以前から持っていたプロファイル
直すのに手間がかかる
ちょうどよい
高品質だが高価
出典:『重要インフラ情報システム信頼性研究会報告書』 経済産業省独立行政法人情報処理推進機構 社団法人日本情報システム・ユーザー協会
表3-2 当プロジェクトのプロファイル
重大な影響を社会に与える。
多くの人に迷惑を掛ける、あるいは特定の個人に大きな心理的影響を与える。
軽微。ほとんど無し。社会的影響(注2)
10億円以上。10億円以下。1億円以下。1,000万円以下。障害金額の予測(注1)
死亡事故。重大災害。軽微。ほとんど無し。人命に影響を与える可能性
重要インフラシステム
企業基幹システム
その他のシステム区分
Type ⅣType ⅢType ⅡType Ⅰ要因
出典:『重要インフラ情報システム信頼性研究会報告書』 経済産業省独立行政法人情報処理推進機構 社団法人日本情報システム・ユーザー協会
図3-3 IPAのプロファイル
同じ規模のシステムならたとえばダウン率1/100~1/1000で開発費2~5倍
出典:『重要インフラ情報システム信頼性研究会報告書』 経済産業省独立行政法人情報処理推進機構 社団法人日本情報システム・ユーザー協会
本研究会の手法
共通リファレンスの策定(ベストプラクティスの抽出)
システム障害の回避
共通する障害対策の抽出(失敗のシナリオ分析)
トップダウン
ボトムアップ
ハードウェアの失敗とソフトウェアの失敗の相違点
ハードウェア
ソフトウェア
製品の“賞味期限”が長い→失敗を学ぶとその知識は一生役に立つ
失敗は激減できる。詰め将棋のように理詰めできる
枯れた技術は使えない→次から次へと思わぬ失敗が生まれてくる
失敗はツキモノ、9回裏まで試合はわからないだが一回裏から、要件定義や構造設計を確実にすべき
ハードウェアでは、未知の事故はほとんど起きない
日本のハードウェアの失敗
使用開始の新品では失敗しない→メンテナンス不良が起きる→疲労、摩耗、腐食が失敗三兄弟
欠陥ゼロは無理だから、確率論的に発生する
ハードウェアで確立した手法は適応できるか?
無理、ソフトウェアはそもそも不老不死で劣化しない
失敗は論理ミスから生じる設計者が考え足らずで最悪な条件を見過ごすからイモ設計者も確率的に生まれるか?
「失敗百選」中尾政之著森北出版、2006年3,600円
ハードウェアの失敗を収集しシナリオを抽出した
事件・事故は考えてもみなかった副作用として発生する
エンジニアが感じているリスクの80%は41個のシナリオ
に含まれた
頻繁に起こりそうなリスク
疲労
http://www.nikkei.co.jp/neteye5/mori/20030912n269c000_12.html
http://d.hatena.ne.jp/cobayan/200705
腐食 バランス不良
http://zosen.blog70.fc2.com/file/070825khi_crane-3.jpg
塵あい、動物(ほこりがアークで燃える)http://www.chugoku.meti.go.jp/topics/consumer/h190814tenkenbi.htm
http://www.topics.or.jp/system/newspack/PN20080608/PN2008060801000255.-.-.CI0003.jpg
最近のトピック:
コミュニケーション不足(非正社員に対して)
重要インフラのシステムについてハードウェアとソフトウェアを比較する
ハードウェア 原子力、航空機、自動車、半導体・・・
ソフトウェア 金融、通信、公共、交通・・・
両方とも1000人超の“土方作業”で作る
ハードは10万個の部品でつくるソフトは10億行のプログラムでつくる
ソフトのほうが要求機能が複雑である
日本航空安全啓発センター
20年経って失敗が
勉強できるようになった
日航のジャンボ機の墜落(1985)
シナリオ
(2)疲労破壊
(28)フェイルセーフ不良
(36)コミュニケーション不足
技術的原因
組織的原因
「スーシティの奇跡」
ハードウェアの失敗は
そんなに複雑ではない
システム障害のデータ収集と分析
本研究会ではITProから85例抽出した
ソフトウェアは刑事訴訟が起きないから多くは“薮の中”にある?
原因は何だかよくわからなかった・・・・・・
件数 割合1(%) 割合2(%) 割合3(%)開発 18 21%
再構築 7 8%保守 26 31%運用 34 40% 40%計 85
29%
71%60%
表3-1 フェーズ別障害件数表
うっかりミスが多いように思える
設計が複雑だから再構築や保守で思いがけないミスを生む
出典:『重要インフラ情報システム信頼性研究会報告書』 経済産業省独立行政法人情報処理推進機構 社団法人日本情報システム・ユーザー協会
自動制御ミス
②定期点検中の作業員が 停止命令リミットスイッチに 触れる
③コンピュータが想定外事態でエラー表示 あるいは到着と判断、ワイヤ位置計測、 減速、非常停止が不作動
①運転員がゴンドラ到着前に 運転レバーを逆転操作
図33-1 ロープウェイのゴンドラが壁に衝突
出典:中尾政之著 『失敗百選』 森北出版
図33-3 三菱自動車のリアディファレンシャルギアの破損
0.12秒 6マイクロ秒
誤設定の後に連鎖反応が生じる
DYCに誤信号発信DYCは連続作動
オイル加熱・漏れ発生
クラッチ摩耗・ギア破損
キーを急速回転する
初期設定が中断
強制停止EDU
RAM
LOCK ACC ON START ON
出典:中尾政之著 『失敗百選』 森北出版
図33-4 長野の駒場ダムの異常放流
停止できず
割込操作 スケジュールキャンセル
停止できたが閉まらず
停止でき、閉められたはず
緊急停止
動力電源オフプログラム状態ロック
目標ダム水位9.9m設定
変更取消
計画起動
4時間後に目標ダム水位がプログラム初期値に戻る
4時間後にミスが発生する段取りになっていた
洪水吐ゲートが開く
目標ダム水位初期値
出典:中尾政之著 『失敗百選』 森北出版
図33-5 中華航空エアバスが着陸失敗・炎上
副操縦士が誤ってゴーレバー
推力上昇ゴーラウンドモードオン
オートパイロットオン自動操縦で反発して機首上げ
操縦士に代わるゴーレバー着陸やり直しでゴーラウンドモードオン
推力上昇急上昇
副操縦士は手動操縦で機首下げ
失速警報
墜落
出典:中尾政之著 『失敗百選』 森北出版
待機系不良ミス
図29-1 東証の株式売買システムが稼動せず
常用系ダウン
待機系ダウン
待機系は同じソフトウェアAを使用→ 回復せず
ソフトウェアA
ハードウェアA ハードウェアB
ソフトウェアA
注文
外国1銘柄
取引待ちの無限ループ
値幅制限設定
注文をはじくプログラムにバグ
注文取消し
出典:中尾政之著 『失敗百選』 森北出版
常用電源 予備電源
専用回線中継装置
試験装置
図29-3 NTT専用回線の19000回線ダウン
ヒューズ
試験装置だけ電源から切り放ししたかった。しかしヒューズをぬけば中継装置も動かない。
出典:中尾政之著 『失敗百選』 森北出版
CPU
干渉があるので故障の常用HDDを予備HDDに交換できず
図29-4 福岡銀行で磁気ディスク故障
120個のプロセッサのうち1つだけ故障
常用HDD 予備HDD
出典:中尾政之著 『失敗百選』 森北出版
図29-6 カンザスシティのホテル遊歩道崩壊
4階
2階
遊歩道面
最初の計画
チャンネルをあわせたビーム チャンネルが
めくれてロッドがぬけてしまった
実際の施工
吊り下げ遊歩道32トン
ボルトで止めると書いてあるが、わざわざロッドの途中を太くしてねじを切るとは思えないワッシャを溶接するか、別個に4階を吊るロッドを用意したと思う
ここのワッシャに2階の分の荷重もかかる
出典:中尾政之著 『失敗百選』 森北出版
大和田尚孝著日経BP社、2400円+税
出典:大和田尚孝著 『システムはなぜダウンするのか』 日経BP社
インターネットの競輪車券投票システムのダウン(2008-6-1)
出典:大和田尚孝著 『システムはなぜダウンするのか』 日経BP社
出典:大和田尚孝著 『システムはなぜダウンするのか』 日経BP社
何らかの外乱でトラブルが生じるしかし隠れていたバグが発覚してシステムはダウンする
出典:大和田尚孝著 『システムはなぜダウンするのか』 日経BP社
多少のトラブルでは延焼しないよう設計していたのに性能は劣化し続ける
設計当初で想定していなかったミスを起こす
出典:大和田尚孝著 『システムはなぜダウンするのか』 日経BP社
全面ダウンは、裏にソフトウェアのバグがなければ起きなかった
出典:大和田尚孝著 『システムはなぜダウンするのか』 日経BP社
ハードウェアでも
複雑さが失敗を生む?
タイプ(Ⅰ)
アホか・・・・・・たるんでいる!
安全を考えて用意していたルールを守らない
希硝酸の作り方、中二階の撤廃、ガスマスクの準備
安全装置をせっかく設置していたのに使えない
絶対にうまくいくだろうと思っていたのに、いざというときに働かない
未実現
2008-10-24 東京大学工学部8号館ガス爆発TYPEⅡ
成膜(化学蒸着法 )真空チャンバー
ボラン・ピリジンコンプレックス溶液
温度コントローラ
水
ビニール袋
タイプ(Ⅱ)
もっと考えろ!・・・・・・やる前に仮想演習しろよ!
使っていたら思わぬ干渉が生じていた
ex. 真空装置が高圧保持に干渉した
水の間接加熱がピリジンに干渉した
設計問題である。独立設計が大事。
干渉
タイプ(Ⅲ)
なんでこんなにこんがらがるのか・・・・・・わからん!
ボンベのバルブの形が会社ごとにガスごとにちがう
過去の歴史が積み重なって“産学連関”で事情が複雑になる
あちらをたたくとこちらが壊れる
複雑
干渉だらけだけど設計自体はうまく均衡がとれている
ソフトウェアでは複雑さが原因の失敗が特に多い
今後ともIPAが中心になってシステム障害を分析すべき
データは収集だけではコストパフォーマンスが悪い
きちんとアナリストが時間をかけて分析すべき
共通リファレンスの構築
本研究会では組込みソフトの先行研究から展開した
実行した工数のような“結果”で分析できるのか?
なんだかよくわからない・・・・・・
翔泳社、2008年1,714円+税
プロセス品質評価指標
デザインレビューは全工程の14%
出典:『組み込みソフトウェア開発向け品質作りこみガイド』 翔泳社独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター 編著
プロセス品質評価指標
評価テストは全工程の45%
出典:『組み込みソフトウェア開発向け品質作りこみガイド』 翔泳社独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター 編著
図1-6 共通リファレンスの適用シナリオ
事業/業務の構成要素であるシステム信頼性レベルの分析・把握(システムプロファイルの把握)
故障発生時の人的損害程度,経済損失程度のリスク(被害総額×発生頻度)の分析及び信頼性把握と対処
事業/業務の構成要素であるシステム信頼性レベルの分析・把握(システムプロファイルの把握)
故障発生時の人的損害程度,経済損失程度のリスク(被害総額×発生頻度)の分析及び信頼性把握と対処
信頼性レベルに応じた品質目標の設定・作業/成果物における
品質評価指標・ユーザ・ベンダ合意事項
推移の品質評価指標
信頼性レベルに応じた品質目標の設定・作業/成果物における
品質評価指標・ユーザ・ベンダ合意事項
推移の品質評価指標
技法・手法の評価と改善
・設計手法、設計ツール・テスト手法,テストツール/環境・レビュー、検証、検査・プロジェクトマネジメント など
技法・手法の評価と改善
・設計手法、設計ツール・テスト手法,テストツール/環境・レビュー、検証、検査・プロジェクトマネジメント など
システム/ソフトウエ
ア設計
コード作成/テスト
システム/
ソフトウエア結合
システムソフトウエア適確性確認テス
ト
要件定義
受入テスト
システム開発での作業と成果物
仕様書ソースコード
運用・保守
システム信頼性レベル付
けと事業戦略
システム信頼性レベル付
けと事業戦略
設計書
事業/業務
取得 供給
◆各種ソフトウェア・エンジニアリング-設計手法,レビュー,テスト手法等-プロジェクトマネジメント(リスク評価と見積り,見える化手法)
-定量的マネジメント(科学的・工学的分析)-プロセス共有/改善(組織的能力改善等)
◆人材育成:スキル標準 など
信頼性レベルと品質評価指標(参考値)
信頼性レベルと品質評価指標(参考値)
最適な技法・手法の選択と実践
最適な技法・手法の選択と実践
事業戦略
ステップⅠ
ステップⅡ
ステップⅢ
テスト項目
ステップIIIの具体的指標はこれから・・・・・・
出典:『重要インフラ情報システム信頼性研究会報告書』 経済産業省独立行政法人情報処理推進機構 社団法人日本情報システム・ユーザー協会
図1-5 信頼性向上対策と自己診断スキーム
4
1
4
2
自己診断点数チェック
強化すべき対策の妥当性確認
対策#
プロジェクト開始にあたり、製品の品質に高い目標を持っている
P01に掲げた品質を実現するために必要な工期を見積り、PJ計画に反映している
情報システムを高信頼システムとして開発するに当たりリスク分析が十分に行われリスクを回避するための、或いはリスクが顕在化した場合の対策は明確になっている
P01
P02
P03
P04
○ ○
○
○
○
○
○
○
○
信頼性水準
の推奨対策
(対策はベストプラクティス、ノウハウの集積も併せて実施、対策での評価指標も提示)
要求水準の実施状況の検査
個別説明
個別説明
個別説明
個別説明情報システムの開発コストは、TypeⅣとTypeⅠで約2倍~5倍の差が出るとの報告もある。
⇒Part3(P.50)WG事例報告
100
信頼性要求水準
(システムプロファイル)
強化すべき対策がある領域
自己診断結果(点数)
0 50
TypeⅣ
TypeⅢ
TypeⅡ
TypeⅠ
推奨範囲過大投資
の可能性ありの領域
フェーズ
○
各種リソースの一部に不備が発生した場合の障害対策の基本的な考え方と対策を確立している。(リソースの一部が異常になった場合、トラフィックが当該リソースに集中した場合の対応診断システムの開発など)
○
Ⅰ Ⅱ Ⅲ Ⅳ
実施状況
企画
故障モード定量化
これだけやれば安心というレベルまで対策する
出典:『重要インフラ情報システム信頼性研究会報告書』 経済産業省独立行政法人情報処理推進機構 社団法人日本情報システム・ユーザー協会
セキュリティが原因のシステム障害事例の収集とその対策の分析
10年前に比べれば格段に良くなっているが、犯人も賢くなるのでエンドレスの競争になる
これもなんだかよくわからない・・・・・・
表1-1 情報セキュリティ再発防止策一覧表(抜粋)
企画 L4-P1 外部からの意図した攻撃(DDoS: Distributed Denialof Service攻撃など)に耐えうるインフラ(ネットワークやサーバ等)が検討されている。
L4-U1 関係者の承認を得たソフトウェアのみをインストールできる仕組みが整備されている。
L4-U2 関係者へのセキュリティ教育が行き届いており、セキュリティインシデント規約(関係者連絡先、メディア対応など)に基づく模擬訓練も行われている。
L3-P1 外部からの攻撃を想定したセキュリティポリシーを定めている。
L3-P2 利用者がシステムに対する悪意を持った場合を想定したリスク分析を行っている。
L3-P3 システムの一部が侵入を受けた場合でも、その影響を局所に限定する仕組みが明確になっている。
L3-P4 セキュリティインシデントに対応する体制(CSIRT:Computer Security Incident Response Team)が整備されている。
: : : :
L1-D1 セキュリティに関するソースコードレビューが行われている。
L1-D2 ウェブアプリケーションに対するペネトレーションテスト(クロスサイトスクリプティングやSQLインジェクションなどの脆弱性のテスト)が行われている。
LV1 開発
LV4
運用
LV3 企画
出典:『重要インフラ情報システム信頼性研究会報告書』 経済産業省独立行政法人情報処理推進機構 社団法人日本情報システム・ユーザー協会
信頼性に関わる実証的な試みとして重要インフラ情報システム信頼性研究会を発足させた
やっとスタートしたばかり今までソフトウェアは過去を振り向かなかったから、発足させたことに意義がある
これからは日本独自の障害分析と障害対策の手法を編み出すべきである
まとめ