全日空でシステム障害、4台のサーバーが順にダウン 64
ストーリー by hylom
連鎖 部門より
連鎖 部門より
3月22日、全日本空輸（ANA）のシステムに障害が起き、乗客の搭乗手続きなどが行えなくなるトラブルが発生した。同日午前11時半ごろには復旧したが、この影響で多数の便が欠航・遅延している。さらに、同じシステムを利用するスターフライヤーやエアドゥ、アイベックスエアラインにも影響が及んだとのこと（日経新聞、朝日新聞）。
朝日新聞の別記事によると、搭乗手続きや予約・販売業務関連データを保存しているサーバー4台のうち1台が22日午前3時44分ごろ停止。さらに残り3台も午前8時20分ごろまでに停止したという。復旧作業が行われたが、「2台目を立ち上げると、1台目がダウンする状況が繰り返された」ために復旧に時間がかかったようだ。
詳しいシステム構成 (スコア:4, 参考になる)
www.unisys.co.jp/tec_info/tr118/11807.pdf
2013カットオフのシステムでHP-UX！
Re:詳しいシステム構成 (スコア:2, おもしろおかしい)
そのPDFの11ページ目に意味不明なことが書いてある
>「また，ネットワーク機器のカタログスペックでは，データ処理レート（Mbps）は
>公表されているものの，単位時間のパケット処理能力は公表されていない」
インターコネクトに流れるデータ流量は100Mbps以下に抑えたのでCat2960で大丈夫の筈が
ショートパケットばっかりだったから3750が必要になりましたって話だけど
エンタープライズ向けのネットワーク機器でpps書いてない機材なんかあるか?
Re:詳しいシステム構成 (スコア:1)
少なくとも、Catalyst 2960は公表されてます [cisco.com]ね。
Re:詳しいシステム構成 (スコア:1)
> Cat2960で大丈夫の筈がショートパケットばっかりだったから3750が必要になりました
これ、microburst [wikipedia.org]じゃないのかなぁ。
ググるとバッファを増やせば捌けるようになるようなことが書いてある
文書がみつかるけど、本当にスイッチの変更が必要だったのか。
航空会社のシステムがインターコネクトのLANのmicroburst（ダウンバースト）で
ダウンとかだったら縁起が悪いなぁ。
love && peace && free_software
t-nissie
Re:詳しいシステム構成 (スコア:1)
DB・運用はHP-UX＋HP ServiceGuard、APバッチジョブログはRHEL＋CLUSTERPROだね。
発端はDBだけど、現象はAP側とDB側で稼働待機上げあいってとこかね。
CO後初ディスク物理クラッシュとかでありがちなパターンじゃね？
Re:詳しいシステム構成 (スコア:1)
HP-UX ってそんなに問題あるんですかねぇ？
7～8年前に一度だけ使ったときに「ユーザ名やホスト名は8文字以内にしてね」と言われ、
運用ルールだと思ったら実は OS 自体の制約だと知ったときには、古臭すぎると思ったけど。
Re:詳しいシステム構成 (スコア:1)
Re: (スコア:0)
cadenceとmentorのどっちだ？
＃どう見ても同業者なのでACw
Re: (スコア:0)
GDS2なんて名前を聞いたのは何十年ぶりかなぁ
この手の業界のインフラになってるフォーマットは寿命が長いからな
もう業界人じゃないんだけど、まだ使われてるの？
＃MT抱えて右往左往していた俺はもう老人というのは内緒
Re: (スコア:0)
担当者の顔が、高橋某作画で再生されました
「石崎!」「滝沢!」
どうでもいいけど (スコア:0)
カットオフ? と聞いて不思議に思って調べたらやっぱり自分が知ってた意味以上のことはわからなかったんですが、
(意味的に) 新しい造語ですか?
Re:どうでもいいけど (スコア:1)
IBM系のSIerなんじゃないかな
Re:どうでもいいけど (スコア:3, 参考になる)
最近のIBMは「Cut over」ではなくて「Go live」を使うようになりましたね
何代か前の社長（だったはず）が「システムは入れて終わりじゃなくて入れたとこが始まりなんだ」と叫んで
言い方変えるようにしたとか
Re:どうでもいいけど (スコア:1)
カットオーバーを間違って覚えてるだけじゃないですかね。
Re: (スコア:0)
それだッ！
#ホントそれだけなんでＡＣで。
最近相次ぎますね。 (スコア:3)
「えきねっと」などでシステム障害 ＪＲ東日本
http://www.asahi.com/articles/ASJ256VN4J25UTIL05Z.html [asahi.com]
ＪＲ東日本は５日、インターネットを通じて特急券などを予約できる「えきねっと」と「モバイルＳｕｉｃａ」でシステム障害が起きたと発表した。同社によると、５日午後３時５５分ごろから約４時間にわたって、新幹線や特急の切符購入、予約変更などができない状態が続いた。
【お詫び】特急券システム障害の再発防止について
http://www.seibu-group.co.jp/railways/news/information/__icsFiles/afie... [seibu-group.co.jp]
2016 年 2 月 10 日（水）ならびに 2 月 23 日（火）から 2 月 26 日（金）にかけて一時的に特急券システムの障害が発生いたしました。
Re:最近相次ぎますね。 (スコア:1)
というか、とくにANAがひどい。デジャヴかと思ってぐぐったら出るわ出るわ。
全日空，システム障害の原因はルーター設定ミス。バックアップ処理のバグで追い討ち
http://itpro.nikkeibp.co.jp/free/NCC/NEWS/20030324/6/ [nikkeibp.co.jp]
障害の原因は、データセンターに置いた2つあるスイッチのうち、1つのスイッチ内にある制御回路のメモリが故障したことによるものだった。
http://itpro.nikkeibp.co.jp/article/NEWS/20071029/285786/ [nikkeibp.co.jp]
暗号化認証機能の有効期限が切れる
http://allabout.co.jp/gm/gc/296766/ [allabout.co.jp]
行政処分もんだと思うけど。
Re:最近相次ぎますね。 (スコア:3, おもしろおかしい)
ANAだらけですね
Re: (スコア:0)
それなりに間隔があいてると行政処分にはしずらいんじゃね
Re: (スコア:0)
インフラ系ばかりやって来ましたが、近年期間とコストの圧力を強く感じます。
昔は、汎用機とかの時代を知っている人も多かったですし、特に運輸や金融系のお客様は、安全を考えたら金と時間がかかるのは仕方ないという了解が相互にあった気がします。
※だからといって許してはくれませんが
※アプリは知らないです。あくまでインフラ
今はクラウドだとか持て囃されすぎて、用途にそぐわない、無理な設計を無理な工期で求められる事もままあります。
SEとかはアプリ側が目立つのもあってインフラの技術者が、顧客、ベンダ双方で充分な人材が確保できていないのも問題ですね。
※今無理なプロジェクトでのたうちまわっているのでACで
塞翁が馬 (スコア:1)
これのせい（お陰）でベルギーに行けなかった人とかいたりして。
Re: (スコア:0)
東京モノレールの遅延のお陰で123便の難を逃れた話思い出した
Re: (スコア:0)
寝坊したら地下鉄サリンで電車止まってたの思い出した。
起きてテレビ見たら自分が降りる駅が大変なことになってた。
そろそろ障害のコントロールを考える時期かと (スコア:1, 興味深い)
銀行などシステム障害がニュースになって思った事。
障害はコントロールできない
特にハードはどういう壊れ方をするか予想がつかない。
対して障害対策は単なる二重化など、想定している障害の具体化が不十分
ここからは試案だけど、アクティブなアプローチとかあっても良いかと思う。
例えばハニートラップよろしく、わざと弱い部分を作って置き、
そこで検知されたら広範囲で交換するとか。まぁ、保証期間とか消費期限とか
をうまく使って。
今回の様に、故障が広範囲に及ぶまで耐えるシステムより、
小刻みに不具合を出すけど、全体のダウンタイムは小さく抑える
システムがこれから有効なんではないか、と。
セールス用のバズワードに使えるかな？
NetflixのChaos Monkey (スコア:1)
「アクティブなアプローチ」の例として、Netflixでは、Chaos Monkeyというツールを作って、常時意図的にシステム障害を起こし続けているそうです。
これは、システム障害が起きてもサービス全体が停止しないようなアプリケーションを開発するように、開発者を条件付けるための仕組みといえます。
銀行の基幹系や航空会社の運航システムのように、部分的な誤りも許容できないシステムでは、いくらか異なるアプローチが必要になろうとは思います。ただ、考え方は使えるかもしれません。
Re: (スコア:0)
昔のホストからそんなことやってるでしょ。
それに今だってサポート期間があって壊れる前に更改してるよね？
Re: (スコア:0)
壊れ方が予想がつかないとか言っておきながら
弱いところから異常が起きると仮定しているところが草
Re: (スコア:0)
システムのどの部分がどう壊れるのか予想がつかないんだから、
今回もやったように、アナログ運用でも回せるように準備して
おくのが、一番臨機応変に対応できるよね。
で、どうやって復旧させたの？ (スコア:0)
結局何をどういうふうにして復旧させたんでしょうかね？
サーバーを立ち上げ直してもダウンするとかいう現象だったということですが。
なにかプログラムを変更したのでしょうか？
Re: (スコア:0)
落ちないお札とか貼ります。
Re: (スコア:0)
巫女さん呼んでくるんじゃね？
#それは落とすほう。
Re: (スコア:0)
サーバーを2台以上立ち上げると死ぬので、結局1台だけ立ち上げて負荷を絞って乗り切ったそうです。
根本原因は不明だけど、たぶん今必死になって直してる（汗
# ってもう一個のタレコミ [srad.jp]にはその辺まで書いてあったんだけど、遅かったので見落とされたみたい
まさにラウンドロビンシステム (スコア:0)
対応してた中の人の脇汗は2リットル以上だろうな。
Re:まさにラウンドロビンシステム (スコア:4, 興味深い)
http://it-toranoana.com/2016/03/22/ana-trouble/ [it-toranoana.com]
こういうとき私のようなシステム屋は「ああ、こりゃ現場は大変だろうな」とか思ってしまうのは職業病でしょうね（笑。今頃お祭り騒ぎですよ。システムエンジニアは３日間くらい徹夜で復旧作業でしょうね。ほんと大変なんですよ、復旧したあとも色々とね・・・
実際、その影響よりも裏側のことが気になってしまいます。こういうとき不謹慎かもしれませんが、現場は結構盛り上がっているんですよ。システムエンジニアあるあるなんですが、大障害ほど盛り上がるイベントはありません。（影響が出た方はほんとに大変だと思いますが）
現場の状況は”お祭り騒ぎ”という言葉が一番合ってると思います。コントロールセンターにはたくさんの人が集まっていますし、社内の有識者はほぼ総動員です。こんなにタレントが揃うことはないですよ（笑。そこかしこで大小の会議が行われているし、ホワイトボードには障害の経過が書きこまれ、原因や復旧策についてみんなであーだこーだ言っています。
いつもは静かなオフィスですが、障害のときは異様な盛り上がりを見せるのです。障害を経験するとシステムエンジニアは本当に何段階も成長します。それくらい色んなことが現場で起きています。みんなで一つの目標に向かって、がんばってるわけですからそりゃあ盛り上がりますよね。（後始末はもっと大変なんですけどね・・・）
Re:まさにラウンドロビンシステム (スコア:1)
コンピュータ・ゲームであればリプレイ動画を独習することによって
それなりのキャッチアップも可能でしょうけど、大規模システムだと
現場のライブ感みたいなものがそれの数倍の情報量でしょうから
リプレイなどという学習方法では身に付けられないといったところでしょうか。
Re: (スコア:0)
叱責されたことや始末書を書いてる所、人事異動までリプレイ／(^o^)＼
Re: (スコア:0, 荒らし)
戦争って怖いね。
# と飛躍してみる。
Re: (スコア:0)
ポジティブに考えよう。3連休中じゃなくてよかったと。
Re: (スコア:0)
でも年度末で春休み期間で航空運賃が高くなっている時期なんだよなあ
Re: (スコア:0)
ポジティブに考えよう。3連休中じゃなくてよかったと。
3連休あけて次の日仮病欠して4連休にしちゃった人はたいへんだろうね。
空港にいたらニュースに出ちゃったとか。
Re: (スコア:0)
Oracle RACのローリングシャットダウン（）かね (スコア:0)
4nodeのOracle RAC構成のDBが順繰りに死んだ、って事象みたいですが、よくあることです。
RACは2nodeに限る……。
Re: (スコア:0)
これかな
経験的にいって、OracleRACは1ノードで回せるスペックで多ノード構成による
クラスタじゃないとこういう事になるので完全に設計ミスってる気がする
Re: (スコア:0)
linuxのほうがマシという現実
Re:日経BP ITproに詳報 (スコア:1)
Re: (スコア:0)
リンク先、ちゃんと読んでます？
それとも過去のその事例と同じって情報があるの？
Re: (スコア:0)
ググッてコピペ世代の特徴がよく観察できますな
Re:「世界4例のスイッチ故障がきっかけ、対応も遅れた」 (スコア:1)
それにしても、今回に関係ないにしてもネットワーク機器の「半死に」は稀によくある。
それが世界初の例（ベンダに「同様事例の報告はありません」と言われる）もままある。
うちの会社も10年で3回は踏んでる。
ミッションクリティカルなシステムで「世界4例のスイッチ故障がきっかけ」とか、言い訳にならん。
Re: (スコア:0)
>>稀によくある
稀なのか、よくあるのかどっち？
>>うちの会社も10年で3回は踏んでる。
3年に1回あるんだ・・・・
>>ミッションクリティカルなシステムで「世界4例のスイッチ故障がきっかけ」とか、言い訳にならん。
それ2007年の障害でしょ？
こんなバカモンに基幹管理されてると思ったら空恐ろしいわ
Re:「世界4例のスイッチ故障がきっかけ、対応も遅れた」 (スコア:1)
>>稀によくある
> 稀なのか、よくあるのかどっち？
稀：××○×××××××××○××××××
よくある：○○○×○○×○○○○○○×○××○○
稀によくある：××○○○×××××××○○○○○××
> 3年に1回あるんだ・・・・
世界初のバグを踏んで、ネットワーク機器が半死にになることでしょ。あるよ。
それですぐリカバリできるか（経路切り替えできるか）がNOCの腕の見せどころ。