1日の東京証券取引所の障害、バックアップへの切り替え失敗は設定値のミス 55
ストーリー by nagazou
人的ミスだった 部門より
人的ミスだった 部門より
東京証券取引所は5日、1日に発生した取引停止障害の原因が判明したと発表した（JPXからのお知らせ、NHK、ITmedia）。
1日に取引不能に陥った原因は、共有ディスク装置の1台が故障、そのバックアップシステムへの切り替えがうまくいかなかったことが主因であると発表されている。今回の発表では、その切り替えがうまくいかなかった原因について、自動的にバックアップに切り替わるための切替え用設定値に指定されていなかったことが明らかになったとしている。つまり設定上の問題であった模様。なぜそうなったかについてはさらに原因を究明するとしている。
1日に取引不能に陥った原因は、共有ディスク装置の1台が故障、そのバックアップシステムへの切り替えがうまくいかなかったことが主因であると発表されている。今回の発表では、その切り替えがうまくいかなかった原因について、自動的にバックアップに切り替わるための切替え用設定値に指定されていなかったことが明らかになったとしている。つまり設定上の問題であった模様。なぜそうなったかについてはさらに原因を究明するとしている。
原因 (スコア:4, 興味深い)
とのことです。
異常処理のテストをどこまでやるかというのはなかなか難問で、
実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。
Re:原因 (スコア:5, 興味深い)
そう言や、昔、担当した仕事で、テスト中にデータバックアップ用の磁気テープに不良品が混ってる事が発覚。その時、関係者の1人が一言、
「返品するな。データバックアップ失敗のケースの運用テストに使う」
Re:原因 (スコア:2)
富士通に責任はない、と話してたけど、ちょっと風向きが変わるのかな？
重過失ではないにしても、テストが充分ではなかった、となるのもやむなしなような。
Re:原因 (スコア:1)
OSは生きていて、ハートビートは返ってくるので生きていると思ったら、肝心のディスク周りがハングアップっていうことかな？と思っていたら、故障した1号機は自分が故障していて切り替えが必要ってことは自覚（？）していたらしい。
ただ説明図を見ても「切り替え用設定値」ってなんの値だろう？とか「設定された値では切り替えができず」ってどういうことだろう、故障は検知したのに、その設定値によっては故障と見なさないのか？と疑問が湧いてしまい、かえってモヤモヤ…
Re: (スコア:0)
その設定値のオン・オフで実際にバックアップに切り替えるかを
判断するような印象を受けます。
Re: (スコア:0)
デフォルトはどっちだ！？意図的に無効にしたのか、有効にするのを忘れたのか。
デフォルトでメモリ障害だけ切り替わらない設定は変な気がする。
そんな単純な話ではなくて、様々な設定の組み合わせで、結果的にメモリ障害だけ切り替わらなくなってしまっていたとかかな？
Re: (スコア:0)
メモリのSEUによる好ましくないフェイルオーバーを嫌った可能性は?
Re: (スコア:0)
オン・オフだけじゃなくて、0:オフ、1:本番用、2:テストA、3:テストB、…、みたいな
Re: (スコア:0)
故障発見時の動作設定
1.自動
2.担当者の判断が必要(誰でもいいので切り替えOKボタンを押す)
3.責任者の判断が必要(加えて、パスワード入力が必要)
4.社長判断が必要(加えて、稟議書番号入力が必要：決済済みかの判断はネットワークで行う)
デフォルトは4番
Re: (スコア:0)
いや、メモリ故障のアラームパターンを登録してなかったって話だろう
エラーレベルだけで切り替える訳じゃないのは判らんでもない
Re: (スコア:0)
何でもかんでも登録してたら今度は誤検知のリスクが上がるしな
それはそれでわかるんだが (スコア:0)
異常処理のテストをどこまでやるかというのはなかなか難問で、
実際に機器を故障させてテストをするというケースは少ないのではないでしょうか。
1日に3兆円の取引をするシステムなんだからいろんなテストをやっても全然ペイできると思うんだけどな
しかも24時間運用ってわけでもないし
Re:それはそれでわかるんだが (スコア:1)
テスト自体はやることに超したことはないですが、小規模なシステムならともかく
大規模なシステムで網羅的にやるのは不可能に近いような。
特に今回みたくハードウェアに起因するようなものの場合、そもそもそれって
再現させられるの……？って話もありますしね。
なので、障害の早期検知と対応の迅速化とか影響範囲の最小化が方向性としては
とるべき道なのかなとも思いますね。
ただ、今回の件の場合どの時間までに復旧していれば全日取引不能にならなかった
のかわかりませんが……。
Re: (スコア:0)
実機に余裕があればできるけど客先のだけだったらシミュレーションで済ますのかも。
設定値を変更してテストして元に戻すのを忘れたとか…ﾅﾝﾃ
Re:原因 (スコア:3)
異常処理のテストをどこまでやるかというのはなかなか難問で、
そうそう、異常処理（特に原発や自衛隊の演習）のテスト・訓練をやると騒ぎ捲る連中がこの国には多いですから。
原発に関しては「原発は安全です。事故は起きません」って言って建てたヤツが悪いよね
「きわめて低い確率で事故が起きますが、その事故の規模を小さくするために訓練をします」って言えなくなったのは建てたヤツの責任で会って騒ぎまくる連中は悪くないよ
Re: (スコア:0, オフトピック)
だってシステムに異常はありえないのが前提ですから。
可能とか不可能とかじゃなくて「絶対に異常はおきない。100%完全である」のが前提じゃないと認められない。
「異常処理の手順があるということは、異常がある可能性がわかっているということだから、納品前に治せ」ってのがまかり通るんですぜ。
だから嘘でも「異常はおきません」って言うしかない。言わなきゃ永遠に終わらない。
Re: (スコア:0)
富士通はどちらかというと、Xステップのコードだったらx件のバグがあるはずだ。
テストでy件しかバグが見つかっていないということはテストが不十分だということだ。再テストせよ! という会社ですが。
Re: (スコア:0)
だから故意に発見しやすいバグを入れておくそうだ。
故意に総合テストでしか見つからない設定値の入れ替えの混在ってのはやったことがある。
テストは外注だったので正常に行われているか確認する為だったのだが、納品前には忘れていたとか知られちゃいけない事実だ。
Re: (スコア:0)
件数水増しで入れるのはあかんけど、意図的にバグを入れてテストでの検出率から潜在バグ数を推定するってーのは教科書的には定番よ？
どっちの話かによって扱いはまるっと変わる。
# けど忘れてたってことは駄目な方の二乗っぽいな……
RAID装置のコントローラ？それともその上のサーバ？ (スコア:0)
RAID装置上のコントローラに搭載されているメモリとRAID装置コントローラのHA制御部分の問題？
それとも、その上にあるRAID装置が接続されているサーバ OS上で動作させているHA制御部分の問題？
どっち？
（JPXの説明みると前者っぽいけど）
原因追及 (スコア:0)
Q:証券取引が不能に陥った原因はなんですか?
A:共有ディスク装置の1台が故障してバックアップシステムへの切り替えがうまくいかなかったからです
Q:なぜ切り替えがうまくいかなかったのですか?
A:自動的にバックアップに切り替わるための切替え用設定値に指定されていなかったからです
Q:なぜ指定されていなかったのですか ← 今ここ
最終的には「うっかりミスです」とか「すべて私の不徳の致すところです」とか「むしゃくしゃしてやった」とかのレベルまで追及を続けるんだろうか。
Re:原因追及 (スコア:3, 参考になる)
「不徳」はバッドエンド。
正規ルートは
Q: なぜ指定されていなかったのですか
A: この文書の規定に従い、不要と判断しました
Q: なぜその文書の規定では不要だったのですか
A: 業界の常識、ビジネスリスク、経営判断を勘案し職責で不要と決めました。しかし今回必要と分かりました。 ←新しい知見
それで解放される真ルートが
「常識的には不要そうですが、過去の東証の事例からメモリ故障の検討が必要と思われます」「やっておこう」 → インシデント回避 な
なぜなぜは「常識的に想定すべき可能性と諸手続きは全て行ったつもりだったが発生した事案」に対して
「諸手続きは正しく行われたか?」「手続きは全て行ったなら、どういう予見不可能な理由で発生したのか?」という問いに答えるもの
「めんどくせえな、あいつのうっかりミスだよ」「ハイハイ気を付けまーす」「むしゃくしゃして普段ならやらないことをやったんだ」は責任追及じゃない
そのバッドエンドに逃げると何度でも世界大戦は起きるし欠陥車は炎上するしロケットは爆発するしシステム障害は起こる
Re: (スコア:0)
そりゃ追求しないといけないんじゃない？
人的ミスならそれを防ぐ対策をせねばなるまい。
Re:原因追及 (スコア:1)
とはいえ、そっちは、やっちゃいけない系「なぜなぜ」な感じよね
# 自分はあれ苦手なので、うまく捉えられてるかわからないが
M-FalconSky (暑いか寒い)
Re: (スコア:0)
まあ、チェック体制強化するってなるだろうな。
顧客テスト肯定で修正プログラムの適用ミスが発生するたびに手順が増え、書類が増え、人が増え、
それでも適用ミスはゼロにはならなくて、これ以上の対策は無理ですと顧客に頭下げたプロジェクトを思い出すな。
Re: (スコア:0)
分析が不完全、対策が不適切だから手間とミスがダブルで増えるというのはあるあるパターン
Re: (スコア:0)
特定のファームウェアのバージョンだとより酷い問題を引き起こすので、その設定を適用しないとなってたかもしれんし。
分散システムだとよくある。
Re: (スコア:0)
結果的に設定値自動切り替えが行われない設定になっていたというだけで、そもそも「人的ミス」(設定ミス)なのかもまだよくわからないけど、
「うっかりミスです」→うっかりミスしてしまうことになった原因を見つけて是正
「すべて私の不徳の致すところです」→そうなってしまった原因を見つけて是正
「むしゃくしゃしてやった」→ダブルチェックするとか、悪意を持ってやったのならセキュリティの問題でもあるからその辺の是正
となるだけ。
これは組織やプロジェクトの問題だから、一担当者のコメントは参考程度のもの
Re: (スコア:0)
Ｑ：その設定を行った場合のリスクやデメリットは何が考えられますか？
私がＱ側だったらまずこうかなあ。
これさ (スコア:0)
2台ともダメになってたら止めるしかないわけ?
Re:これさ (スコア:2)
証券取引所システムのバックアップが
たった一系統しかないとは思えません。
Re:これさ (スコア:1)
プライマリセンタ2系統とセカンダリセンタ (機能縮小版) 2系統の構成で、プライマリセンタ1系統が故障したがプライマリセンタ2系統に切り替わらず、セカンダリセンタを使用する決定もしなかった。
日本取引所グループのBCP [jpx.co.jp]には、「セカンダリセンタへ切り替える場合、売買・取引の再開は24時間以内を目標とするが、当日中の再開は行わない」と書かれている。
当日中に原因箇所の特定・除去など再起動の目処が立たなかった場合は、翌日はセカンダリセンタで売買・取引を再開するつもりだったと考えられる。
Re: (スコア:0)
セカンダリセンタはコールドスタンバイで立ち上げも少々時間を要するとかも言ってたっけか。
ホットスタンバイな2号機と無停止で交代できた場合は良しとして、
それ以外は再開によるトラブル防止の為に状況分析と再開影響分析が優先されるんだろうね。
今回も1号機直して午後から再開は可能だったけど、
取引の都合上問題が起きそうなので避けた結果の一日停止だし。
障害対応ルールは二次災害予防の観点でかなり慎重のようだ。
Re: (スコア:0)
取引データのバックアップはもっと強力だと思いますが、情報配信システムならこんなものでしょう。平日の9:30-11:30と12:30-15:00が取引時間で、何年かに一度は何かしら取引停止のトラブルがあります。そもそも365日24時間いつでも換金する必要のある資産を株式で保有するのは間違いでしょう。
Re:これさ (スコア:1)
それが気に入らないなら3重にするしかないですね。それでも気に入らないなら4に。それでも…。
RAIDは何台で構成してあれば気が済みますか？っていうのと同じこと。
絶対に止まらないシステムなど存在しない。隕石が落ちてきたら止まるし。
どこで線を引くかの問題で、議論するならその線引きは妥当か、何故妥当と言えるのかという話になる。
でも万人が納得するのはきっと不可能でしょうね。コストが妥当かという問題もあるからね。
Re: (スコア:0)
そうだよ
# だから3台目と4台目と...N台目も買ってください
Re: (スコア:0)
そしてRAIDコントローラーが死亡。
Re: (スコア:0)
待機系の故障に気付かなくて障害が発生した瞬間に詰んでしまうのは稀によくある話。
似たようなのにRAIDの2台目のHDDが壊れてやっと障害に気付いたが時既にお寿司というのがある。
Re: (スコア:0)
1台目の故障に気づいてても、予算無いから交換用HDDの購入はちょっとまってといわれてるうちに、2台目が無事死亡するケースもあるとか...
Re: (スコア:0)
一台目故障から交換再構築完了まで(場合によっては再構築開始前から)負荷が上昇するから、
実は故障率が独立してなくて実際の冗長性は足りてない、とかもまま聞く話。
Re:これさ (スコア:1)
アレイはRAID5+ホットスペア
→1台死亡
→自動リビルド開始
→高負荷で2台目死亡
数回サルベージを経験しましたとも、、、。
Re: (スコア:0)
RAIDって構成しているHDDが、
同じスペック(多くの場合、同じメーカ製の同じ型番)で、
製造時期が近くて(製造スロットも同じだったり、近かったり)、
同じ筐体内で(周囲の温度条件同じ)、
同じアクセス頻度で利用されているんだから、
ひとつ逝ったら、他のも近いうちに逝っちゃうリスクは高いと
思わなくちゃいけないですよね。
Re: (スコア:0)
NetAppやらEMCやらはそこらへんは少しは考えていて、
ファームウェアを独自のものに変更してセクタ数等をアライメントした複数社・製造時期が近くはあるが別ロットのHDD/SSDを1セット内に搭載しています。
なのでHDD/SSDに搭載するファームウェアで共通のやらかしがない限りはある程度ばらけるように調整して出荷しています。
セットで届くのであまり機会がないかもしれませんが、スロットから外してみると面白いですよ。
2シェルフぐらいだとHDDはWD/HGST/Seagateのうち2社になるパターンがやっぱり多いですが、
1ラック以上の場合だと今その会社で取り扱っているストレージでの仕入れ元が揃い踏みすることもあります。
Re: (スコア:0)
スロットから外すのは、納入されて開梱直後の電源を入れる前にして下さい。
運用状態でいきなり外すと、故障と判断されCEが特殊な処理をしないと再使用できません。
そういう装置はLANにつながり、Webインターフェースの管理ソフトが動作してます。
スロットから外さずに、管理ソフト(運用管理担当者に相談して)で確認して下さい。
Re: (スコア:0)
以前、FTサーバで待機系のファイルシステムがReadOnlyになっていることに
半年以上気付かなかったことがあった。
アプリをバージョンアップしようとして初めて気付いたｗ
稼働系が故障しなくてホント助かった…
テストした物が動かなかった時のバグ (スコア:0)
見たくもないけど、稀によく見るのは497日問題踏んだ時とかかな。
今もSNMPでの監視では497日過ぎると監視しなくなったりするし。
Re: (スコア:0)
テストしたときに、１号機から２号機に切り替えて設定が２号機が稼動、１号機がバックアップという感じに切り替わったけど
本番の開始は２号機がバックアップってことで始めただけだったりしてな。
全銘柄を止めた障害は14〜15年くらい前か (スコア:0)
https://ja.wikipedia.org/wiki/%E6%9D%B1%E4%BA%AC%E8%A8%BC%E5%88%B8%E5%... [wikipedia.org]
今回のはシビレたろうな。忘れた頃にやってくる大障害にどうやって対処するか悩む所。
お上の「お認め」がないと実行できないような代物（もしくは設定）がミスる時は、たいがい周りの引継ぎが忘れてるんだろうよ（管轄外だと思って）。
＃そこで信頼ある部下がサポートしてくれるかどうかで、明企業か暗企業で分かれる。
Re: (スコア:0)
「全銘柄停止」と「一部銘柄終日停止」はあったと記憶するけど
「全銘柄」かつ「終日取引停止」ってコンピュータシステム導入以前でもあったのかな？
Re: (スコア:0)
https://ja.wikipedia.org/wiki/%E6%9D%B1%E4%BA%AC%E8%A8%BC%E5%88%B8%E5%... [wikipedia.org]
>1951年（昭和26年）2月15日 - 前日からの吹雪で都心の積雪が30センチメートルを越え