読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

IPA「情報システム高信頼化教訓集(ITサービス編)」を読む

Project Management

IPAが2014年の5月に出した「情報システム高信頼化教訓集(ITサービス編)」を読んだ。けっこうイイ事が書かれている気がするのだけれども、読むべき人に届いているのかはちょっと疑問がある。みんな読んだ?

http://www.flickr.com/photos/28111950@N00/11156856823
photo by dfirecop

情報システム高信頼化教訓集とは

  • 情報システムは社会基盤の重要インフラに浸透している
  • トラブったら大変なことになる
  • しかし、トラブルの原因や防止策が業界内で共有できていないやんけ!

そこでIPA/SECでは、重要インフラに関わるシステムにおける類似障害の発生防止と影響範囲の縮小を目指し、金融・通信などのサービスを行う「ITサービスシステム」および、組込み機器の制御などを行う「製品・制御システム」の2つのシステム領域からこれまでの障害情報とその対策をそれぞれ普遍化し、「教訓」として取りまとめ、「情報処理システム高信頼化教訓集(ITサービス編/製品・制御システム編)」の2種類の教訓集を公開しました。

ちなみに今回読んだのは「ITサービス編」のみ。

割と普通のことが書いてあるけれども、内容はナマナマしい

というわけで「情報システム高信頼化教訓集(ITサービス編)」の中身の話になるのだけれども、本編であろうPart1は、基本的には9つの教訓を軸に事例などが整理されている体裁となっている。9つの教訓の内訳はこんな感じ。

  • ガバナンス/マネジメント
    • システム開発を情シス部門だけの仕事にせず、各事業部門が自分のこととして捉える「態勢」をつくることが大切
    • 発注者は要件定義に責任を持ってシステム構築にかかわるべし
  • 技術
    • サービスの継続を優先するシステムにおいては、疑わしき構成要素を積極的にシステムから切り離せ(“フェールソフト”の考え方)
    • 蟻の目だけでなく、システム全体を俯瞰する鳥の目で総合的な対策を行うべし!
    • 現場をよく知り、現場の知識を集約し、現場の動きをシミュレートできるようにすべし!
    • システム全体に影響する変化点を明確にし、その管理ルールを策定せよ!
    • サービスの視点で、「変更管理」の仕組み作りと「品質管理責任」の明確化を!
    • テスト環境と本番環境の差異を体系的に整理し、障害のリスク対策を練る
    • バックアップ切替えが失敗する場合を考慮すべし

並べてみるとあたりまえのことだけれども、あたりまえだからこそ難しいとも言える。教訓集ではそれぞれの教訓にやたらとナマナマしい事例が載っているのが特徴である。
上流工程系は「ユーザーのオーナーシップの持ち方」に関する事例や、「発注者責任の明確化」など。各企業の説明・対策資料がわりとそのまま掲載されているのが興味深い。

自分がやらかした時にも活用できそう。

単純に読み物としても興味深いけれども、むしろ自分が何らかのトラブルに関わったときに改めて参照するのが良さそうな印象。資料の付録に各種の分析手法などの記載もついている。単純にテクニックが参考となりそう(正直、なぜなぜ分析以外で知っているのはHAZOPくらいだった)。

  • なぜなぜ分析
  • ImSAFER
  • RCA
  • 総合的インシデント分析
  • HAZOP
  • FTA(フォールトツリー解析)
  • FMEA(故障モード影響解析)
  • STAMP
  • STPA(STAMP based Process Analysis)
  • CAST(Causal Analysis using STAMP)

原因分析には様々な方法があり、各社で工夫した適用が見られるが、全般に、ITサービスでは、発生後の「なぜなぜ分析」の使用が多く、障害の事前予測系の分析は弱いように思われる。
(中略)
STAMP(STPA、CAST)は上記の分析手法の長所と適用範囲の問題点を解決する手法である。従来は、製品制御系主体だった手法を、対象をソフトウェアやインタフェースを含めたシステムに拡張し、IT サービスにも使えるようにしたものである。原因分析手法も適用する対象の技術の発達にあわせて開発/改良されてきている。 このような手法を現場で積極的に活用し、まずは小規模でよいので適用/評価していくべきである。

やらかしたときに、やってみようかと思う。