アカウント名:
パスワード:
2月のANAの予約をしてましたが、11月27日にANAから「使用する機材の変更などに伴い、便名、運航スケジュール、座席番号または搭乗クラス に変更が生じましたため、当メールを送信させていただきます。 ご利用のお客様には大変ご迷惑をおかけいたしますことを深くお詫び申し上げます。」なんてメールが届いて「へー？」と思いつつ、座席予約をしなおしてましたが、多分この話だったのでしょう。
このメールが登録データに差異が生じて自動的に送られてきたのか、それとも当初はこういう話で押し通そうとしたのかまではわかりませんが。
ちなみに、機材・時刻は予約時と変わってないように見えました。座席は適当なところに割り振られなおされてました。(ので好みの位置に再指定しました)
このメールが登録データに差異が生じて自動的に送られてきたのか、 それとも当初はこういう話で押し通そうとしたのかまではわかりませんが。
28日になって、「一部の予約」すなわち26日より前になされた全予約が消えた事をアナウンスするあたり、障害を何とか回復させようと試み、当初はごく一部データが消えた事しか認識できなかったものが、調査したら2月全部が復旧できないと判明し、もう隠し切れないと観念したのでしょう。結局、当初は顧客に事実と異なる説明をして誤魔化そうとした位ですから、全日空、10万超の座席指定を取り消し、原因は担当者の操作ミス [nikkeibp.co.jp]の「営業担当者が誤って座席指定の予約情報を消去してしまった」というのは、社外にはこういう事にして発表しよう、と命じたANAの偉い人のIT理解度を反映した物に過ぎず、これも事実ではないでしょう。私は当初、「予約だけ消えた？ データベースの誤操作か」とも思いましたが、 実はANAは国内線予約システムを刷新してたのです。
最後の、業務システムの件は、国内線予約システムと関係ありませんが、急ピッチでシステム全般を刷新したようですね。これは…カットオーバー前のテスト不足でしょう。まだ出来て1年経っていないのでは? それで、「2月は29日まで無いからエラーで消えちゃった。そこまでテストしてなくて。テヘ」なレベル、に一票。いや…これだと、多分また「やってくれる」んじゃないかな。
ANA SKY WEBの刷新って、2011年5月ですよ。1年勘違いしていませんか？
> 最後の、業務システムの件これは、業務システムではありません。
航空系を少し知っている方なら分かると思いますが、月次の処理ってほとんどないのです。その数少ない1つが、運航ダイヤの認可だったりします。ここには、機材の認可も含まれます。ですから、他の方が書かれているように、仮のダイヤ（機材）で受け付けていた座席指定を正式なダイヤ（機材）に反映する処理で起きたと思われますね。
新システムは関係ありません。カットオーバーから１年以上経ってますし。テストは念入りにやってます。というかやりました。
元コメの巻き込まれた方の情報と以下の情報から発生した問題が推測できそうな気がします。
ANAによると、運航ダイヤが決まる前から受け付けていた座席指定情報を、ダイヤ決定後にシステムへ反映する作業がもれたという
http://www.aviationwire.jp/archives/12167 [aviationwire.jp]
まず、機材変更による座席指定のやり直しというのは、頻繁にあることなので、
・ダイヤ上で機材変更を行う ↓・座席指定がシャッフルされる ↓・「座席予約をし直してください」のメール送信
という流れは、システム化されていて、自動的に行われると考えられます。
今回の原因は、正式な運航ダイヤをシステムに入力する際に、「同じ機材なのにシステム上で機材変更として担当者が入力してしまった」といったところではないでしょうか。（正式な運行ダイヤに決まる際の機材変更も通常処理の範囲内だと思われます）その結果、システム上の正常処理として、機材変更による座席のシャッフルと「座席予約をし直してください」のメール送信までが自動的に行われたと推測されます。
で、元コメの巻き込まれた方がすぐに座席予約をしなおしたように、座席変更が取り消されたことを前提として以降の予約や座席の再指定が行われてしまったので、仮にバックアップがあっても元に戻すことができなくなってしまったのだと思います。
この問題が、仮に「データベースのテーブルをとばしてしまった」という問題だったら、システムはその時点で止まるので、バックアップから戻すこともできたかもしれません。
推測ですが、ポイントとしてはシステム上は全て正常処理の範囲内であったために、バックアップから戻すような運用ができなかった、ということでしょうか。
その文面は平時にも来るので、今回のものとは関係ないところで自動送信してるんでは？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
巻き込まれました (スコア:5, 興味深い)
2月のANAの予約をしてましたが、11月27日にANAから
「使用する機材の変更などに伴い、便名、運航スケジュール、座席番号または搭乗クラス
に変更が生じましたため、当メールを送信させていただきます。
ご利用のお客様には大変ご迷惑をおかけいたしますことを深くお詫び申し上げます。」
なんてメールが届いて「へー？」と思いつつ、座席予約をしなおしてましたが、多分この話だったのでしょう。
このメールが登録データに差異が生じて自動的に送られてきたのか、
それとも当初はこういう話で押し通そうとしたのかまではわかりませんが。
ちなみに、機材・時刻は予約時と変わってないように見えました。
座席は適当なところに割り振られなおされてました。(ので好みの位置に再指定しました)
国内線予約システムを刷新してたのか (スコア:5, 興味深い)
このメールが登録データに差異が生じて自動的に送られてきたのか、 それとも当初はこういう話で押し通そうとしたのかまではわかりませんが。
28日になって、「一部の予約」すなわち26日より前になされた全予約が消えた事をアナウンスするあたり、障害を何とか回復させようと試み、当初はごく一部データが消えた事しか認識できなかったものが、調査したら2月全部が復旧できないと判明し、もう隠し切れないと観念したのでしょう。結局、当初は顧客に事実と異なる説明をして誤魔化そうとした位ですから、全日空、10万超の座席指定を取り消し、原因は担当者の操作ミス [nikkeibp.co.jp]の「営業担当者が誤って座席指定の予約情報を消去してしまった」というのは、社外にはこういう事にして発表しよう、と命じたANAの偉い人のIT理解度を反映した物に過ぎず、これも事実ではないでしょう。
私は当初、「予約だけ消えた？ データベースの誤操作か」とも思いましたが、 実はANAは国内線予約システムを刷新してたのです。
最後の、業務システムの件は、国内線予約システムと関係ありませんが、急ピッチでシステム全般を刷新したようですね。これは…カットオーバー前のテスト不足でしょう。まだ出来て1年経っていないのでは? それで、「2月は29日まで無いからエラーで消えちゃった。そこまでテストしてなくて。テヘ」なレベル、に一票。いや…これだと、多分また「やってくれる」んじゃないかな。
Re: (スコア:0)
ANA SKY WEBの刷新って、2011年5月ですよ。1年勘違いしていませんか？
> 最後の、業務システムの件
これは、業務システムではありません。
航空系を少し知っている方なら分かると思いますが、月次の処理ってほとんどないのです。
その数少ない1つが、運航ダイヤの認可だったりします。
ここには、機材の認可も含まれます。
ですから、他の方が書かれているように、仮のダイヤ（機材）で受け付けていた座席指定を正式なダイヤ（機材）に反映する処理で起きたと思われますね。
Re: (スコア:0)
新システムは関係ありません。カットオーバーから１年以上経ってますし。
テストは念入りにやってます。というかやりました。
Re:巻き込まれました (スコア:5, すばらしい洞察)
元コメの巻き込まれた方の情報と以下の情報から発生した問題が推測できそうな気がします。
ANAによると、運航ダイヤが決まる前から受け付けていた座席指定情報を、ダイヤ決定後にシステムへ反映する作業がもれたという
http://www.aviationwire.jp/archives/12167 [aviationwire.jp]
まず、機材変更による座席指定のやり直しというのは、頻繁にあることなので、
・ダイヤ上で機材変更を行う
↓
・座席指定がシャッフルされる
↓
・「座席予約をし直してください」のメール送信
という流れは、システム化されていて、自動的に行われると考えられます。
今回の原因は、正式な運航ダイヤをシステムに入力する際に、「同じ機材なのにシステム上で機材変更として担当者が入力してしまった」といったところではないでしょうか。
（正式な運行ダイヤに決まる際の機材変更も通常処理の範囲内だと思われます）
その結果、システム上の正常処理として、機材変更による座席のシャッフルと「座席予約をし直してください」のメール送信までが自動的に行われたと推測されます。
で、元コメの巻き込まれた方がすぐに座席予約をしなおしたように、座席変更が取り消されたことを前提として以降の予約や座席の再指定が行われてしまったので、仮にバックアップがあっても元に戻すことができなくなってしまったのだと思います。
この問題が、仮に「データベースのテーブルをとばしてしまった」という問題だったら、システムはその時点で止まるので、バックアップから戻すこともできたかもしれません。
推測ですが、ポイントとしてはシステム上は全て正常処理の範囲内であったために、バックアップから戻すような運用ができなかった、ということでしょうか。
Re: (スコア:0)
その文面は平時にも来るので、今回のものとは関係ないところで自動送信してるんでは？