URL

「記者の眼 - 判明、ANAシステム障害の真相:ITpro」のグラフ

記者の眼 - 判明、ANAシステム障害の真相:ITprohttp://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/041100532/
月のグラフ

コメント

(2018/09/21 16:28:01 更新)
  • ServiceguardのIPモニター設定してたら回避できた、かもね。(しらんけど https://t.co/ouKY6z1FCA / メイン用途がL2SWとしてだと、やっぱIC用セグのVLAN I/FにはIPアドレス振ってなかったんだろうなあ。必要ないと思っちゃうだろうし:hdkINO332016-04-19 15:36:17
  • snmptrap出なかったから検知できなかったのか。。半死の状態だと確かに出なそうではある。死活監視も二重とかになってくるんだろう、、辛い時代である:hackapellmanda2016-04-15 09:36:37
  • ツイート 搭乗手続きなどでごった返す全日本空輸のカウンター(3月22日午前11時40分ころ、新千歳空港) [画像のクリックで拡大表示]  大型のシステム障害の詳細が見えてきた。全日本空輸(ANA)が2016年3月22日に起 Tags: via:fake-jizo2016-04-14 22:55:45
  • みてれぅ: "記者の眼 - 判明、ANAシステム障害の真相:ITpro":dai_air2016-04-14 15:07:38
  • 続報:legoboku2016-04-14 07:08:47
  • 国内線旅客システムの大規模障害の詳細。:adsty2016-04-13 23:39:25
  • 544:garage-kid2016-04-13 21:13:30
  • 世界初のバグって、単に故障じゃないの。たまたま一部パケットをロストするような状態になったっていう。:murasuke2016-04-13 20:52:20
  • 「故障シグナル」はSNMPだったのか。ネットワーク機器の監視にネットワークを使うと本当にダメな時にうまく行かない気がするのだが、ちゃんとやるとするとどうやるのだろう。:rryu2016-04-13 20:36:15
  • HP-UX 11i B.11…まだ現役なんだ。そしてProCurveではないんだ。 サービスガードも登場。「 死活監視機能自体がSPOF(Single Point of Failure:単一障害点)になる」:hogetahogeko2016-04-13 19:51:49
  • 色々問題点も浮かぶだろうが、「この情報公開にGOを出した」という一点だけで、俺はANAを再度信頼出来る。:copymattt2016-04-13 16:26:37
  • 「世界初の事象であり、機器固有の問題である可能性が高いという報告を受けている」[ANA]:HHR2016-04-13 13:31:46
  • "後にシステムログを調べるとDBサーバーの最初の3台はデータ同期がタイムアウトしたとしてRACが停止させ、最後の1台はHP Serviceguradが停止"止めたログは調べないとわからないのね。:hiroomi2016-04-13 12:54:41
  • 可用性の高さや復旧の早さ、不具合診断の速さは評価できるけど、スイッチの死亡判定がSNMP Trapだけだったってのはお粗末すぎる...:hidetoz2016-04-13 11:38:49
  • 本当に外部監視系なかったんだろうか:naga_sawa2016-04-13 10:37:23
  • これ、サーバに比べてネットワーク構成が貧弱すぎやしないか…?負荷きつそう…。:atauky2016-04-13 08:59:50
  • サーバ系のスーパーリッチな構成に比べ、ネットワークがえらい節約モードなのが気になる。特にSNMP Trapでスタンバイ側起こすという悠長な設計はやや疑問。なんにせよこういう情報を出して頂けるのは大変ありがたい。:tetsutalow2016-04-13 08:20:08
  • 障害の情報Update。身近なテーマ。死亡通知というよりは能動的な生死監視。:lackofxx2016-04-13 06:10:54
  • うーむ:daybeforeyesterday2016-04-13 04:28:52
  • 『Catalyst 2960に加え、Catalyst 3750とCatalyst 4948EでDBサーバーの台数を増やしながら性能テストした結果、Catalyst 2960はDBサーバーが3台以上になるとインターコネクトで使うUDPパケットの処理能力が極端に低下』どこ持ちなのかね:wushi2016-04-13 00:40:26
  • このレベル/レイヤーのインフラわかるエンジニアはこの先育つのだろうか。ニッチになって超人が高給取るのかな:Dy662016-04-12 23:08:17
  • バグとか障害って大抵、突き詰めてミクロな観点で見ると「なんだこんなくだらないところでー」ってなるのが多いだろうし、今回の場合はNW監視が甘かったってのが結果論なのかなぁ。失敗を公開するのは良いね:totttte2016-04-12 23:06:14
  • 検証環境に持っていっても死にかけ継続するのはバグ? (パケロスか?)素人でもツッコミ入れたくなる故障通知はSIの指示を愚直に実装したからか? おんなじ方式でCiscoがバグだけ対処したのなら再発必至だと思うなぁ。:terlen02016-04-12 23:01:39
  • 2016/04/12:ilya2016-04-12 22:42:23
  • 同業他社のシステムでアプライアンスの運用設計したことあるが、「ハードウェアの故障検知が製品提供のSNMP trapのみ」って、この規模の高信頼要件に対してちょっとお粗末すぎる印象。アクティブ監視してあげないと。:namisk2016-04-12 22:34:02
  • もうな、エンジニア視点では障害はしょうがないんだよ。複雑になり過ぎて無理なんよ。:heihatirou-edajima2016-04-12 22:21:23
  • 故障シグナルはTrapだったのか…。Trap頼りの検知漏れも、スイッチの半死状態も、ある程度のエンジニアなら経験していると思う。そもそもサーバとDBに対する投資額と、スイッチとその監視に対する投資額が見合ってない:yunohito2016-04-12 21:31:47
  • RAIDにせよこういうのにせよハードウェアが担保してくれるからなんもせんでも冗長構成可用性maxってのは大体嘘と思うで。:xxxxxeeeee2016-04-12 21:24:51
  • こんなに立派なノードなら10GbEとかInfinibandでも大してコスト変わらないんじゃないの?という気も。それと障害検知方式は幾つか併用した方がいいのかな?:mkusunok2016-04-12 20:16:23
  • トラップで切り替えるのはガバガバな感じではある:wata882016-04-12 20:04:46
  • 腹筋崩壊したwwwww:UDONCHAN2016-04-12 19:59:37
  • "故障シグナル" とやらだけに頼るのはSPOFだ、というのは正論だけど結果論だよね。24時間で原因究明と完全復旧はすごいよ:kkobayashi2016-04-12 19:30:35
  • わかってしまえばなんとでも言えるけど、この事象のテストパターンを抽出できる、または設計時に見抜けるエンジニアって何人いるんだろうなぁ。:ithijikata2016-04-12 18:59:34
  • 想像通りのSNMPtrap:Cald2016-04-12 18:32:16
  • 例の故障シグナルってSNMPだったのww:moccos_info2016-04-12 18:25:37
  • 世界初のバグって言われて身構えたけど、Ciscoのこの手のスイッチが半死になるってわりとよくあること(なので考える前に被疑系の電源を落としにいこう)って運用皆してると思ってたぞ:konaken2016-04-12 18:10:36
  • catalyst経由のストレージ接続って違和感。性能懸念でNASってことはないだろうけどcatalystでFCoE動くんだっけ。/半死つらい。被疑部位とサービス影響を見極めて障害ノードを落とす判断をどれだけ迅速にやれるかにかかってる:Makots2016-04-12 18:00:17
  • 故障シグナルのSPOFか:japanrock2016-04-12 17:53:36
  • ANAかっけー:htamaaki2016-04-12 17:03:45
  • 障害発生時の手運用での回避まで書かれていて非常に興味深い:celitan2016-04-12 15:45:28
  • ここまでシステム構成から何から書かれると、一般人は叩いても、外部のエンジニアはある程度味味方になってくれるから、ある意味リスク管理ができてるよな。:kenchan32016-04-12 15:29:41
  • trapあてにして系の切り替えとかやって大丈夫なんだろうか:S0R52016-04-12 14:56:47
  • システム構成とか、競合他社に公開したくないだろうに。この辺はANAの上の判断すげーなーと思う。保険としてどこまでアーキに金を掛けるのかは悩ましいなぁ:killerQueen2016-04-12 14:54:08
  • システムの開発担当者も十分頑張って成果も出してると思うが、この記者の問題点分析も的確だな:fukken2016-04-12 14:35:40
  • ラストの提起はもちろんそうである。ただ、それこそこれはこれそれはそれであって。:K-Ono2016-04-12 14:28:24
  • タイムアウトしてるんだからすぐネットワークを疑おうぜ。ping打ちまくってロストするか見ればいいだけ。アプリの問題なのに常に疑われ対応するのがネットワーク屋なんだけどなぁ。ソースは俺。:ryun_ryun2016-04-12 14:28:09
  • 短時間で復旧にあたったエンジニア達の活躍をプロジェクトXで見たい。:pixmap2016-04-12 14:24:47
  • スイッチの故障検知に問題が有りフェイルオーバー失敗。対応として複数種の検知方法を持つこと。:Akaza2016-04-12 14:20:51
  • 「障害対策・障害復旧でANAはよくやったのかそうでないのか。どの程度のコストを掛けて、どの程度の信頼性を、どういったアーキテクチャーで実現するのか。同じケースは一つとしてないが、自分の現場だったらどう振る:estragon2016-04-12 14:19:55
  • 「死にました」通知が飛ばなかったのではなく「生きてます」通知が止まらなかった問題じゃないかとは思うところなんですが...:s-tomo2016-04-12 14:10:38
  • 半死状態ってのは割とポピュラーに「なんだかわからないけど上手く動いてない」原因になるんだけど、今回の件はちょっと監視が足らなかった感じに見えるなあ。:NOV19752016-04-12 13:48:03
  • スイッチの故障をスイッチのSNMPトラップで通知もらうとか頭痛が痛い設計になっとるが、この記事あっとんか?NWの正常性検査をサーバ間でやってなかったわけあるめぇ:iqm2016-04-12 13:37:48
  • なんでL3冗長化してないのかなあ。死んで切り替わるのはありなんだっけ。それともなんか見落としてるのだろうか。:hiby2016-04-12 13:36:13
  • なんてゆるゆるな設計。頑張って復旧したのはユニシスかその下請けなのに、何で情シス賞賛www:jtw2016-04-12 13:35:06
  • サーバからストレージにつないでるスイッチだからFCスイッチかと思った。ブロケード社製にすればいいんじゃんとか、それじゃダメですか。:stantsiya_iriya2016-04-12 13:34:13
  • システム的なトコロはよく分からないんだけど、大事だなと思ったのは、予備ライン(手動運用)の設定と、機械語を話す人間とそれを一般向けに解釈して話す担当、状況を判断する担当。これらの重要さだと思う。 at;判:world_standard2016-04-12 13:30:37
  • 「インターコネクトで使っていた米シスコのスイッチ「Catalyst 4948E」が故障し、最終的にDBサーバーの4台停止につながった」「4台のDBサーバーはオラクルの「Oracle RAC(Real Application Clusters)」を使ってクラスタリング」:nilab2016-04-12 13:21:51
  • HPやOracleに比べてシスコは信頼されてるんだなと思った:bb_river2016-04-12 13:12:27
  • 半死怖いな:goman2016-04-12 12:59:18
  • 最近のミッションクリティカルでの障害って、機器の半落ちが原因ってのが多い気がする:packirara2016-04-12 12:54:18
  • ネットワークの部分に若干疑問がある内容だけど、情報が揃ってるのかは不明。ただ、この感じなら待ってれば詳報出てきそうだな:terurou2016-04-12 12:52:21
  • 5ページ目のアーキテクトなんで匿名なの〜〜。:shag2016-04-12 12:50:21
  • 稼働約3年で(縮退運転までの)ダウンタイム約3時間なら、稼働率99.988%。人命に関わるシステムじゃないけど重要インフラとは言えるので、欲をいえばフォーナイン99.99%は欲しい。でも、個人的にはこれで十分と思う。:tsekine2016-04-12 12:46:06
  • これ説明と構成違ってない?:kinunori2016-04-12 12:44:20
  • よく分からんけど「故障シグナル」のところは何か記事上の解釈の齟齬があるんじゃないか。でないと「故障して動かなくなった機器がシグナルを送ってくる」という矛盾した状態を前提にしてることになるので。。。:t_yano2016-04-12 12:38:30
  • スイッチの不良、未知のアレだったのでsnmp飛ばなかった、サーバからスイッチの監視してなかったのは既報通り、2~4が死んで1系も死んだのは負荷分散もしてたからという感じでしょうか:BoiledEgg2016-04-12 12:34:43
  • SNMP Trapによるパッシブ監視しかしてなかったとのこと。本当にヤバい時は障害検知系のプロトコルに障害の影響が無かったり、そもそも動かなかったりするから、大事なシステムのNWにアクティブ監視は必須ですねー。:yuyarin2016-04-12 12:31:38
  • 原因分析から情報公開まで憧れるレベルの対応です。ほんとすごいと思う。なんでここまで公開できるのか、その重要性を決定者が理解してるってことで:Palantir2016-04-12 12:29:23
  • 超協力的なクライアントで羨ましいと思う人多そう^^;:negi_11262016-04-12 12:28:03
  • これどうやって冗長化してたんだろう。:whiteball222016-04-12 12:24:43
  • "故障シグナルとはANAによれば「SNMP(Simple Network Management Protocol)によるメッセージ通知」という。" それで切り替えってどうなの…。完全に死んだら発砲できなくね?:smbd2016-04-12 12:23:27
  • 普段はweb屋ばかり声がでかいはてブで、珍しく基幹業務システム系の方々が輝いてる:crosscrow2016-04-12 12:19:54
  • 自分が当事者だったらストレスで死んでた:sds-page2016-04-12 12:17:01
  • 要は止めると困るのに、障害がでると安全に止まる設計で運用していたというところ、問題は障害より切り替えが不足してるよね。:solidstatesociety2016-04-12 12:15:11
  • 検討してるだけかもしれんけど、これでユニシスに損害賠償できるの?っていうのはびっくりしたが、味噌汁炊き出ししたら許されるのかな:moons2016-04-12 12:08:30
  • 『大規模システムであれば何度か経験する問題であり…』――ちょ、そんな簡単に言うなよww ミッションクリティカルな大規模システムに関われるチャンス自体そうそうあるわけじゃあるまい。:lwix2016-04-12 12:05:12
  • ANAの穴を自ら公開するとか他山の石とするほかないけどサーバとネットワークのバランスなー(;´Д`)…:longroof2016-04-12 12:00:25
  • "スイッチが故障すると『故障シグナル』を発信し、予備機に自動的に切り替わる設計" ここがガバってますね・・・:oktnzm2016-04-12 12:00:03
  • 記者の眼 - 判明、ANAシステム障害の真相:ITpro -: 大型のシステム障害の詳細が見えてきた。全日本空輸(ANA)が2016年3月22日に起こした国内線旅客システム「ANACore(エーエヌエーコア)」のシ..:toshi196501042016-04-12 11:55:19
  • この構成図合ってるのかなあ。ストレージはSANで繋がってて4948Eはノード間インターコネクト専用とかなんじゃないの?:tagomoris2016-04-12 11:54:24
  • Oracle RAC構成のストレージの足回りが1GbのiSCSI、2台のストレージにミラーしながら書き込み、正副が故障した際の予備機が100Mbの2960...自分ならFCで組まないと怖い(^_^;):cabvm2016-04-12 11:44:15
  • これ、障害切り替え自動化されてないよね:kizuki10102016-04-12 11:42:08
  • スイッチをスタックにして、かつDBのNICをボンディングしておくことで防げなかったかのかな?Act/SbyをJP1が受け取るSNMP Trapを契機に切り替える仕組みだったのかな。RACは難しいって聞くから、そう単純でもないのかなー。:ikedas2016-04-12 11:38:33
  • 記事のとおりなら、フェラーリが軽自動車のタイヤはいてるみたいな構成だなと:kazuhooku2016-04-12 11:31:27
  • “故障シグナルとはANAによれば「SNMP(Simple Network Management Protocol)によるメッセージ通知」”:metroq2016-04-12 11:23:14
  • 「半死」の状態って、本当にやっかい。:kq10002016-04-12 11:10:02
  • ANAの穴:locust01382016-04-12 11:01:51
  • この匿名のアーキテクト氏、名前出したら大炎上だろうなー:sho2016-04-12 10:52:27
  • サーバ構成の割に、ネットワークは少ししょぼい構成と感じる:kaiton2016-04-12 10:44:35
  • 流石にそれはないだろうと思っていた故障シグナル=trapが本当だったとは。しかもそれで切り替えるとか何の冗談なんだ/シスコのsnmpは微妙に信用できない(他社製よりマシ?)/NW機器が死ぬとtrap出す経路も死ぬのを忘れるな:yachimon2016-04-12 10:44:35
  • 巨大システム:digima2016-04-12 10:41:39
  • インフラ素人から見れば十分良くやってると思うけどな。上には上の対策もあるだろうが、その分多くかかったコストは経営や利用者の負担になるわけで…:sawat2016-04-12 10:40:27
  • 日本ユニシスはCatalyst 2960を想定していた?既に販売が終息しておりサポートも終了しているのを当初導入しようと計画してたのか?本当だったなら色々とやばいんじゃないのか?:Lat2016-04-12 10:40:09
  • ここまで対策してたり、原因が究明できてるのは凄いと思うけどなー。:mohno2016-04-12 10:31:56
  • ANAは「よくやった」んじゃなく、「やっちまった」方だろ?:nisisinjuku2016-04-12 10:27:40
  • NW弱いってコメあるけど、こういうシステムって、NWにあまり金かけてもらえないこと多いんだよ。しかもこの症状はきわめて想定しにくいし、検知も切り分けも難しい事案だと思う。だからこそこの対応スピードは賞賛:X-key2016-04-12 10:24:34
  • この解説だとよくわからない点も多いけど、何よりこの障害事例を公開してくれたANAさんは大変素晴らしいと思う。公開したことで色々情報も集まるだろうし、業界全体として次につなげていければ良いよね。:rx72016-04-12 10:14:55
  • スイッチの間欠故障のどのメトリックを読んで上位で切り替えるんだろうか?:onionskin2016-04-12 10:11:00
  • NWだけ設計ごと下請け出してたんじゃないかってぐらい、そこだけ言ってることがおかしいんだよなあ。もったいないお化け事案だと思う。:nekoruri2016-04-12 10:09:56
  • 私はそこまでシビアなのはやってないから判断がつかないが、単一障害点が怖いのと、定期的なハートビート確認を入れるのは費用的に高価じゃないのは分かる。:deep_one2016-04-12 10:07:52
  • めちゃめちゃクソっていう事例ではなかったんだな:dnsystem2016-04-12 10:03:13
  • 受動的にSNMPトラップ受けるだけじゃなく能動的なパフォーマンス監視・問題分析ツール入れにゃあかんやろ……ってウチのエンジニアも言ってた。SolarWindsとか便利なのあるよ?:debabocho2016-04-12 09:52:36
  • from Pocket April 12, 2016 at 12:12AM via IFTTT:matobaa2016-04-12 09:48:39
  • 「足回りが貧弱」の一言。基礎が悪い上に立派な家が建っているイメージ。I/Oはちゃんとしないとね~。:kintoki32016-04-12 09:41:37
  • 冗長化構成が設計通り動かなかった話と、復旧やBCP発動が上手でしたという話はもうわかってるんだけど、きっかけとなった「最初のエラー」がなんなのか気になる。ハード故障なのかユニシス製ソフトのバグなのか。:six132016-04-12 09:22:03
  • 色々問題点も浮かぶだろうが、「この情報公開にGOを出した」という一点だけで、俺はANAを再度信頼出来る。良い対応。:Mu_KuP2016-04-12 09:10:24
  • 面白いなこれ。スイッチが半死状態だったので切り替わらなかったと…:rosedust11922016-04-12 09:10:18
  • 結果だけ見ればなんとでも批判できるんだろうけど、現象が起きたその時にちゃんと原因を突き止められるかというと自信がない。障害が起きた時の指示系統がしっかりしていたのだろうな。:su_zu_ki_10102016-04-12 09:09:31
  • アナコアーってなんかエロい:love0hate2016-04-12 09:08:48
  • 「完全に停止したわけでなく、動作が不安定になった」という“半死”の状態ってのは意外とあって大変困るよね。:Nan_Homewood2016-04-12 09:06:26
  • 共有ストレージがいて4948を選ぶか、FCにしないのはなぜ?トラップでNW切り替えるて普通なの?この記事信頼出来るのかなぁ。:ya--mada2016-04-12 08:44:24
  • 興味深い:kuracom2016-04-12 08:40:54
  • 終わってからならどうとでも非難できるけど、事前に拾えるかと言うと難しいよねぇ。:maxk12016-04-12 08:40:10
  • 多少謎な面が仕方無いか:belgianbeer2016-04-12 08:38:43
  • これほんとなの?NWインフラ側の設計がガバガバにしか見えないんだが、記者の書き方の問題なんだろうか。1000Mbpsで速度が出ないってのはsasquatch CRのバッファが少なくて1000Mbps-100Mbps変換でパケットこぼす現象のことかな:napsucks2016-04-12 08:33:03
  • 「高信頼システムとしては仕組みが足りない」つ費用対効果:Rinta2016-04-12 08:23:46
  • 個人的にはANA凄いと思った。これだけ短期間に収拾できるのは情シスにきちんと人的・資金的リソースを割いてるからに他ならないかと。障害が起きたことは残念だけど、逆に「凄い会社」と思えるようになった。:shaketoba2016-04-12 08:12:24
  • 日本ユニシスの担当者はNWは素人っぽいというのが感想。設計のアンバランスさがすごい。サーバ側の信頼性担保の仕組みに対して、NW側がガバガバじゃねーの、、、:operator2016-04-12 08:05:45
  • 「いくら製品を“叩い”ても、『故障シグナル』の機能だけに死活監視を依存する限り、その機能自体がSPOF(Single Point of Failure:単一障害点)になる」:cloudliner_tweets2016-04-12 07:57:16
  • あれだけの障害で損失4億円って少ない。ブランド毀損もかなりのもの。でも対策が数億で収まらないなら微妙な線。:zakkie2016-04-12 07:36:08
  • ほんと、どこまでやるか、なのだよなぁ:fumisan2016-04-12 07:28:11
  • 痛い:k451152016-04-12 07:23:03
  • 当初の許容リスク内に収まったかどうかで評価すべきだと思う。止まらないシステムはないので、どれだけ止まってよいか、止まってフォールバックした際に要する許容時間はどれだけで、結果としてそのSLAを満たせたのか:masatomo-m2016-04-12 07:02:09
  • 一台での縮退運転可能な本番環境とか本番環境と同じ構成のテスト環境とか、現実世界の話とは思えない:QJV97FCr2016-04-12 05:54:24
  • 昨日、一番読まれた記事は:判明、ANAシステム障害の真相(記者の眼)  全日本空輸(ANA)のシステム障害の詳細が見えてきた。同社は3月22日に国内線旅客システムに不具合を起こし、合計で719便、7万2100人以上に影響を及:minonet2016-04-12 02:12:58
  • ちなみに毎日新聞はインターコネクトを "IC(集積回路)" と書いてた。 http://mainichi.jp/articles/20160331/k00/00m/040/065000c:suginoy2016-04-12 01:45:57
  • 記事がサーバ寄りな見方で肝心のNWはやや遠巻きな表現な希ガス。NIは検証もユニシスが出てるのにCiscoに障害打ち上げするのはANAからって保守そうなの?あとtrap検知して予備機に切り替えるのはサーバ?うーん:dogusare2016-04-12 01:43:18
  • 「完全に停止したわけでなく、動作が不安定になった」これはきっついよ。4948Eのログに何か出てたのか気になるけど、これだけの短時間で原因絞り込みできたのはさすがに褒めるべき。:beerbeerkun2016-04-12 01:29:27
  • "故障シグナルとはANAによれば「SNMPによるメッセージ通知」という":kanai62742016-04-12 01:14:16

関連エントリ