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

勘と経験と読経

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

情報システムの障害状況ウォッチ(2015年後半)、ポストモーテム

Project Management

SEC Journal44号で2015年前半の情報システム障害状況まとめが公開されたので読んでみる記事。
前回記事はこちら。

SEC Journal最新号の入手はこちらから。

http://www.flickr.com/photos/7119320@N05/22856576053
photo by Sean_Marshall

情報システムの障害状況ウォッチ(2015年後半)

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をニュース記事などとザックリ照らし合わせてみた。全般的にトラブル発生時の速報はあれど、原因や再発防止などが公開されていることはあまりないのが残念なところ。また、日経コンピュータさんがいろいろ取材されて深掘りされているようなのだけど、記事がほとんど公開されていないのはちょっと残念。ビジネス的な判断なのだと思うのだけど、公益性も鑑みてトラブル事例は公開していくことを検討して欲しいと思う。

注目事例

SEC Journal44号の紹介記事の中でも取り上げられているけれど、「長期間の不具合放置」関連の事例が目立っている(1524,1526,1530,1541など)。SEC jounal44号の記事では

以上の5件はいずれも、一見正常に運転されているにもかかわらず、実は重大な問題を抱えたまま運用されていた事例である。不具合によってシステムがダウンするなどの現象が発生すれば、誤りは直ちに検知されるが、この種の事故は開発段階での綿密なテスト計画の策定とその着実な実施という基本的な対策でしか回避の方法はない。
(SEC Journal44号 連載 情報システムの障害状況 2015 年後半データ より)

と書かれているのだけれども、ちょっと違う印象を持った。リスク管理の問題ではないだろうか。

  • 最終テストとして、何を確認して、何を確認していないのか明確にする
    • 例えば[1541]の緊急通報メール発信トラブルについては、システムと通信事業者間の疎通確認はやったけれども、通信事業者から利用者までのメール発信の疎通は(おそらく)実施していない。本番環境でのテストは実施しないという判断はあり得るが、テストしていないという事実をきちんと関係者間で共有していたのかというと、おそらくしていないのではないかと思う。
    • [1527]メタボ検診システムについても、実データでのテストは実施していないということを明確にしておくべきだったのではないかと。これもセキュリティ等の観点で、実データを利用しない判断があったとしてもこれは問題ない。しかし、何を「やっていないか」を明確にすべきだろう。
  • 実機で確認できていないことは、どんな代替手段でリスク軽減(検証)したのかをはっきりとさせる
    • 実機確認できないものについても、テスト環境で検証するか、それも困難であれば綿密な机上確認するなどによってリスクは軽減できるはずであり、それを検討すべきと考えている。
  • 残余リスクについて、そのリスクが消滅するまで継続監視する
    • システムの構造上、なかなか本番稼動しない機能はあると思う(1年に1回しか動かない、とか災害時にしか動かないとか)。とはいえ、本番稼動実績のない機能はリスクが残っている。こういったリスクは解消するまで(初回稼動が終わるまで)トレースしていかないと、思わぬところで足をすくわれる事になるのでは無いかと思っている。

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則