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

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

• 情報システムの障害状況（2015年前半）あるいは検死解剖 - 勘と経験と読経

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

• SEC journal：IPA 独立行政法人 情報処理推進機構

photo by Sean_Marshall

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

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

• [1522]auキャリアメールで送受信不可
  • auのメール障害が完全復旧 発生から約3週間 - ITmedia Mobile
  • KDDI田中社長がメール障害について陳謝 - 最大で1000万件に影響 | マイナビニュース
  • 再発防止策は今後検討と8月時点では報じられていたが、その後の情報は発見できず……
• [1523]外為どっとコム取引停止
  • ニュース - 外為どっとコムで約8時間ログインできず、原因はネットワーク障害：ITpro
  • システムレポート2015年│FX│外為│外為どっとコム
  • ネットワーク機器異常＋未処理チェック機能の性能不足とのこと。再発防止のレポートが公表されているのが好印象。
• [1524]佐賀市で携帯納税機能が利用できない
  • 佐賀市「携帯で納税」水の泡 システム構築できず｜佐賀新聞LiVE
  • これをシステム障害といわれるとツライ。発注されていないシステム機能が市民に利用告知されていたというもの。
• [1525]スパコンネットのデータ保存拠点での障害
  • スパコンネットワークで障害、データ15万件が破損 ：日本経済新聞
  • スパコンネットのデータ保存拠点で昨年に発生していた大規模障害、今年3月まで気付かず | スラド ハードウェア
  • スラドが詳しい(というか現場の人がコメントしている模様)。とはいえ原因と再発防止策は読み取れないのが残念。
• [1526]CAFIS障害
  • ニュース - ［続報］CAFIS障害はFEPサーバーのダウンが原因、3割のクレカ決済に影響：ITpro
  • CAFIS障害によるカード決済不可の原因を予想 - 金融ITニュース。時々雑ネタ。
  • ハードウェア故障に加えて、自動切換えが出来なかった事例。ハードが完全故障ではなく不安定化というのがポイントか。
• [1527]厚労省メタボ検診システム役に立たず
  • メタボ健診、効果検証２割のみ データベースに不備 ：日本経済新聞
  • 28億円かけたメタボ検診システム、半角/全角の処理ができず、ほとんど使えてないことが判明 - Togetterまとめ
  • togetterのまとめで「見積りがメタボってる」というのに笑ってしまったのだけど、そもそもこのシステムの更改前から問題があり、28億円かけて更改してもちゃんと対応できなかったという闇の深い問題。
  • これもシステム障害って言われるとツライ印象。
• [1528]ネット銀行システム障害、取引不可
  • ニュース - 住信SBIネット銀がシステム障害、現在は通常通り回復：ITpro
  • ハード障害とのこと。続報見当たらず。
• [1529]地震観測システム、停止
  • 気象庁｜報道発表資料
  • 気象庁｜報道発表資料
  • 電源部動作不良とのことだけど、バックアッププランはなかったのかは気になるところ。
• [1530]個人信用(個信)システムで処理結果不正
  • 【お詫び】個人信用情報機関に提供した奨学金返還に係る情報の内容の一部に誤りがあったことについて - JASSO
  • 奨学金返還者を延滞扱いで登録 日本学生支援機構 ：日本経済新聞
  • 日経コンピュータに詳細記事が掲載されたようだが有料会員にならないと閲覧できない模様。潜在不良。
• [1531][1532]土砂災害・ 防災情報システムが不適切な運営
  • 命守る土砂災害情報システムの欠陥放置 奈良県が認知後２年間 携帯などで閲覧できないのに活用チラシ配布も （1/2ページ） - 産経WEST
  • 【台風１１号】土砂災害情報が最大５時間半も更新されず…奈良県の情報システムでトラブル - 産経WEST
  • こちらも日経コンピュータに詳細記事が掲載されたようだが有料会員にならないと閲覧できない模様。どうやら利用部門が運用保守をしていることが根にある模様。
• [1533][1534][1535]住民票システムで運用ミス多発
  • ニュース - マイナンバーで初のトラブル、取手市が69世帯の住民票に個人番号を誤記載：ITpro
  • マイナンバーを住民票に誤記載、茨城県美浦村でも - ITmedia ニュース
  • ニュース - マイナンバー付き住民票希望者に空白のまま46枚交付、船橋市の自動機に不具合：ITpro
  • 上記以外に「住民から求められていないのに、誤って個人番号（マイナンバー）を記載した住民票を交付」という運用ミスも多発の模様。運用者の問題と言ってしまえばそれまでだけど、UX的な問題点もあったのではないかと邪推。
• [1536]空港内システム停止
  • ニュース - 中部国際空港でシステム障害、サーバールームの空調機故障で国際線10便に最大1時間の遅れ：ITpro
  • サーバールーム空調故障によりネットワーク機器故障とのこと。
• [1537]航空予約システムで正常に予約できず
  • ニュース - 格安航空ピーチのWeb予約に不具合、約900人が支払い後に予約成立せず：ITpro
  • 原因は不明、再発の可能性も・・・と記事にあるけれど、続報は見当たらず。
• [1538]コンビニATM停止
  • 一部コンビニのレジや銀行ＡＴＭで不具合 夜には復旧：朝日新聞デジタル
  • 詳細不明。続報見当たらず。
• [1539]空港内システム停止(2回目)
  • 中部空港でシステム障害 ６日も同じトラブル - 産経ニュース
  • 今度は空調故障ではないとのことだけど、続報は見当たらなかった。
• [1540]ひかり電話の特定ルータで通話先不正
  • ニュース - 10回に3回程度違う番号につながる不具合、NTT東日本「ひかり電話」で：ITpro
  • ソフトウェアの不備っぽいけれど詳細不明
• [1541]緊急速報メール発信できず
  • 緊急メールで設定ミス 福島市 | 河北新報オンラインニュース
  • 設定ミスが原因とのことだが、稼動テストの範囲が不適切だった印象。1年半放置との情報もあるけど前回の訓練では利用しなかったのだろうか
• [1542]おさいふポンタ移行トラブル
  • ニュース - ローソン「おさいふPonta」にシステム障害、ポイント移行できず、4日午後6時に復旧見通し：ITpro
  • 続報発見できず。原因は不明。
• [1543]消防庁司令管制システムが停止
  • ニュース - 東京23区の119番通報が6分間不通、4月に続き日立製システムで障害：ITpro
  • ソフトウェア更新による障害ということだが、詳細は不明。「ソフトウエア更新作業時の障害対策ついて、検討が不十分」というコメントもあるけど、本当にそこが問題なのだろうか？
• [1544]地銀ATM障害
  • 三重銀行：一時取引障害　ＡＴＭやネット　／三重 - 毎日新聞
  • 2015.11.25オンライン障害の発生原因および今後の対応について(PDF)
  • ハードウェア障害、フェールオーバー自動切換え失敗、切替後キャパシティオーバーでダウンとなった模様。詳細が公開されているのは好印象。
• [1545]山手線新型車両が正常運行できず
  • News ＆ Trend - 山手線新型車両E235系で相次いだトラブル、次世代システムのバグが原因：ITpro
  • 東京新聞:山手線トラブル 新型車両 死角は荷重:社会(TOKYO Web)
  • 異常なケース(乗車率180%以上)のテストをシミュレータのみで実施したことにより、想定外事象が検知できなかったとのこと。後知恵では問題があることがわかるけれど、なかなか難しい問題だと思う。

注目事例

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

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

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

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

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