-
全日本空輸は7日、3日発生したシステム障害の経緯を発表した。予約管理支援システムに対し同時に複数のデータを抽出しようとした際にエラーが起きたのが原因と結論づけた。加藤恭子執行役員はオンライン説明会で、エラーは「予期していないものだった」と偶発的な現象と強調した。
データ抽出処理のプログラムに問題はなかった。エラーにより二つあるソフトウエアのうち一つの動作が停止。結果としてもう一つのソフトウエアに想定を超える負荷がかかり、監視プログラムが異常と検知してサーバー停止につながった。
全日空は、今後同じようなエラーが起きてもサーバーが停止しないようシステムを改修する。
共同通信 2023/04/07 17:43 (JST)
https://nordot.app/1016992138647552000 -
やっチャイナよ
-
結局NTTの障害とは関係なかったのか？
-
share.exeを常駐させとけ（笑）
-
もう少しわかりやすい説明してくれよ
-
>>5
執行役のおばさん、取材している記者いずれも理解できてないから無駄だよ -
同時を防ぐために排他制御がデータベースに働くんじゃないの？
教えて！SEのキモヲタたち -
同時に複数のデータを抽出が予期していないものなの
-
予想より混んでたんだろうな
これはしゃあない -
予期しとけよ
個人商店のシステムじゃないぞ -
監視プログラムのバグでもあるな
監視プログラムを監視するプログラムが必要 -
想定外のエラーで片系運用になって負荷に耐えられなかったってこと？
-
間違えて変なテーブル結合して
巨大データひっぱろうとしたとか？ -
別々の(あまりそうしないが)ソフトウェアで冗長性を確保してたけど片方止まったんでもう片方に処理が集中して負荷閾値を超えた結果、監視システムがサーバーを止めた(多分サービスを止めたんだろう)
-
>>16
本当に閾値を超えたのかな？
単に急に負荷が増えたから、止めただけのように思える。
つまり、元から片方止まると両方止まるように設計されていたように思えるのだが。 -
>>24
B系がスタンバってるならそれでいいよなA系を片肺運用する必要性はないわな
問題は、A系からB系の切り替えが、思いの外、時間がかかったことかね
-
DBのエラー？嘘くせえ～
-
まぁ監視系のPGが暴走することあるからしょうがないな
-
デッドロックか
-
これを防ぐために、銀行のシステムは
CPU が一個なんですよ複数並列処理をやるからこうなる
-
>>1
前任喰うのシステムはよくやらかすよな -
そもそも1つでも処理が止まらないシステムがあって、それを複数持つことで冗長性持たせる物だろう。ケチりすぎたか？
-
データ抽出処理に問題は無いのに、どうしてデータ抽出方法を改修するんですかねえ
-
全日空だけにANAだらけのシステムとは
-
止めるのはいいけど、切り替え1時間は長い
-
ノーロックしなかったか
-
NTTのせいにできなかったんだな
-
>>1
●
＿(＿ トランザクション処理が、甘かったんだな・・・
( ﾟωﾟ )
' ` -
普通は片肺になってもある程度の動作が出来る様な設計にしておくものだと思っていたが？
片肺での運用テストとかやらなかったのかね？ -
半世紀前から設計の最初に対策立てるところだろうに
-
質問した人も回答した人も記事にした人もたぶん理解してないw
-
チョット前だったらコロナの影響で運用担当が不足してたとかコロナのせいにできたのになw
-
> 予約管理支援システムへのデータ抽出の際に、A系のデータベース1に予期せぬエラー（データ抽出処理のプログラムに問題はなく、複数のデータ抽出処理を並列で同時に実行することによるデータベースの偶発的なエラー。担当者によると非常にまれに起きるエラー）が発生し、データベース1がフリーズした。
いや抽出でDBがフリーズしたらあかんやろ -
ANA「インフラ屋のせい！」
-
フリーズとか何なん？
分散トランザクションとかあるのか？ -
単純な参照ならともかく
更新を前提にロックかけながら参照するならいろいろありそうだが -
>>42
デットロックに対して非常にまれなエラーとは言わんでしょ -
>>46
「デットロック」とも言わんよただ読むだけの処理でないならそこで何かは起きうるだろ
-
パラレルクエリの実行中に、別の処理が入ってコンフリクトが起こった感じ？
DB、何使ってんだよ？ORACLE？MSSQL？ -
で、アクセス負荷がーって言ってるけど
一つの動作が停止したエラーというのは問題ないのかね？失敗じゃない、正常に中断したというJAXA的言い訳かな？
-
インダウトトランザクションがあったのか？
-
>>1
相変わらずデジたんに弱いッシュねぇ -
まれに起こるの知ってたのか
ならこれからも起こるじゃん
コメント