タグ

システム障害に関するTensorのブックマーク (25)

  • 「うるう秒」障害がネットで頻発

  • 「うるう秒」で複数サービスに障害

    地球の自転速度に合わせて標準時刻を調整するため、日時間の2012年7月1日午前8時59分59秒と午前9時00分00秒の間に「8時59分60秒」を挿入する、「うるう秒」の調整が実施された。この影響で、MozillaやLinkedIn、foursquare、Yelp、Redditなどが影響を受けたと米Wiredが伝えている。 Redditは公式Twitterで、「米太平洋時間午後5時に実施されたうるう秒に関連し、Java/Cassandraに障害が発生しました。現在復旧作業中です」とツイートした。 「うるう秒」の調整は、地球の回転の観測を行う国際機関である「国際地球回転・基準系事業(IERS)」が決定しており、これを受けて世界で一斉に実施される(日ではNICT(情報通信研究機構)が行う)。1972年7月1日の第1回から数えて今回は3年半ぶりの25回目に当たる。 今回のうるう秒挿入については

    「うるう秒」で複数サービスに障害
  • ファーストサーバ障害問題:原因はファイル削除コマンド停止の記述漏れ

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます レンタルサーバ事業者のファーストサーバが障害で顧客のメールおよびウェブデータを消失した問題で、同社は「データの復旧が困難」であると発表した。ファーストサーバはさらに中間報告として、障害の概要と原因を明らかにした。主な原因として、サーバに適用する更新プログラムに、ファイルを削除するコマンドを停止させるための記述が漏れていたことを挙げた。 同社は6月20日午後5時ごろ、脆弱性対策を特定のサーバ群に対して実施していた。対策は対象サーバ群に対して更新プログラムを一括して適用するもので、以前から実施してい手続きだったという。だが、今回は更新プログラム自体に不具合があったことに加え、検証環境下での確認による防止機能が十分に働かなかったことと、メンテ

    ファーストサーバ障害問題:原因はファイル削除コマンド停止の記述漏れ
  • ファーストサーバで大規模なデータ障害 顧客データが消失

    サーバホスティング事業者のファーストサーバで大規模なデータ障害が発生し、顧客のデータが消失したことが明らかになった。 サーバホスティング事業を手掛けるファーストサーバは、提供中の一部のサービスで大規模なデータ障害が発生し、顧客のデータが消失したことを明らかにした。 対象サービスは「ビズ」「ビズ2」「エントリービズ」「EC-CUBEクラウドサーバ マネージドクラウド」および、これらのサービスを利用したオプションサービス。(1)サーバ上にアップロードされたデータ(FTP、ファイルマネジャーなど)、(2)コンフィグレータ設定を含むデータ、(3)メールボックス内のデータ――が消失し、サーバを随時初期化して提供しているという。 同社は6月20日午後5時50分ごろに障害の発生を認識し、翌21日未明にメンテナンスに用いる管理プログラムにバグがあったことを確認。同時に顧客データが消失したことも確認した。現

    ファーストサーバで大規模なデータ障害 顧客データが消失
  • ファーストサーバ障害問題:「顧客のデータ消失は前代未聞」--ITR内山氏

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます レンタルサーバ事業者のファーストサーバが障害で顧客のメールおよびウェブデータを消失した問題で、ユーザー企業への影響や今後の展開などを、IT専門の調査会社ITRの内山悟志代表取締役が以下のようにコメントした。 障害はともかく、データセンター事業者によるデータの消失というのは前代未聞だ。バックアップを取っていなかったとすれば、利用企業としてはどうしようもない状況といえる。事業者としては、信用を失うことになるだろう。 だが、これをユーザー企業が法的手段に訴えても、満足できるような補償は受けられないだろう。一般に、契約内容は障害時に「利用料を全額もしくは半額返還する」といったものであり、あくまでも企業が支払った金額が対象になる。 契約書に規定が

    ファーストサーバ障害問題:「顧客のデータ消失は前代未聞」--ITR内山氏
  • 東証がはまった、冗長構成に潜むリスク

    今週2月2日、東京証券取引所の株式売買システム「arrowhead」に障害が発生し、計300銘柄以上が3時間半にわたって売買できなくなった。arrowheadは、東証が満を持して2010年1月に稼働させたシステムで、旧システムと比べて処理速度が最大で600倍に高速化した。取引に影響を与えるようなトラブルは今回が初めて。 障害の原因は、株価情報を証券会社などに配信する「情報配信システム」のハードウエア故障だ。信頼性を高めるため、情報配信システムは3重の冗長構成になっているが、故障発生時の切り替えが正常に動作していなかった。 東証のシステム障害、原因はハードウエア故障後の切り替えミス 東証と札証、12時30分から売買を再開 札証が全銘柄の売買を停止、東証のシステム障害が影響 東証システム障害、発生箇所はarrowhead 東証、システム障害で241銘柄の取引を中止 しばしば起こる「冗長構成の機

    東証がはまった、冗長構成に潜むリスク
  • 今年3度目…国会図書館でシステムトラブル 蔵書貸し出しなど手作業で対応 - MSN産経ニュース

    国立国会図書館で16日、利用者の入館状況や、蔵書を管理するコンピューターシステムにトラブルが発生、書籍の貸し出しを手作業で行うなど業務に支障が出た。今年に入り、新システムに切り替えたための不具合とみられ、同館で原因を調べている。 新システムは6日に導入。7日、14日にも同種のトラブルがあり、これで3度目となる。 同館によると、16日はの貸し出しを行うシステムが一部ダウン。利用者は通常、館内に設置されたパソコン端末でを検索し、貸し出しを申請するが、この日は読みたいのタイトルを紙に書き、職員に手渡すなどして対応したという。 新システムは利用者の入退館状況をより具体的に管理するため、カードの発行手続きなどを一部改変。昨年から準備を進め、6日に導入したばかり。 7日にはの貸し出しや検索に関する記録(ログ)が肥大化、サーバーに負荷がかかり検索機能が一時利用できなくなった。14日にはサーバーの

  • みずほ銀行トラブル、発端は人為的ミスの可能性

    みずほ銀行の西堀利頭取は2011年3月18日夜、15日から断続的に続いているシステムトラブルの発端が、人為的ミスである可能性を示した。同行のトラブルは、特定の口座に対して上限を超える振り込みがあったことに端を発する。西堀頭取は会見で、「一部の口座で上限が適切ではなかった」と述べた。 みずほ銀行では、システム処理能力の制約から、一つの口座に対して振り込みができる件数に上限を設けている。この上限は、口座の種類/用途によって異なり、一般の利用者の口座は小さく、大量の振り込みが行われる口座は大きく設定されている。これらの上限は、口座を開設する際に、顧客から口座の用途を聞いて決めている。西堀頭取は、「口座の用途を聞くプロセスが、十分でなかった」と述べ、発端が人為的ミスに起因するとの見方を示した。 特定の口座に対して上限を超える振り込みが発生した理由や、口座の上限を上回る振り込みによってシステム全体ま

    みずほ銀行トラブル、発端は人為的ミスの可能性
    Tensor
    Tensor 2011/03/19
    利用制限を設けておいて上限を超えたらシステムが止まるっておかしくない?しかもなんで上限超える件数の振込が出来るのかが不思議。
  • JR東日本の新幹線トラブル、原因はシステムの処理容量オーバー

    JR東日は2011年1月18日、前日に発生した新幹線の運行トラブル(関連記事1、関連記事2、関連記事3)について、運行管理システム「COSMOS」が処理容量の限界を超えたことが原因だったと発表した。 JR東日によると、17日午前7時過ぎに新白河駅と福島駅でポイント故障が発生。駅と駅との間で列車が止まるのを防ぐため、24の列車を各駅に停止させるようCOSMOSに指示を出した。この指示を受けて、COSMOSはダイヤ変更を計算するとともに、後続列車についてデータ変更が必要な箇所をチェックした。 来であれば、COSMOSはダイヤとデータ変更が必要な箇所を、東京の運行部にあるパソコンに表示する(写真)。 この表示に基づき、運行部の司令員がデータを変更する。その変更指示を反映した形で、COSMOSがダイヤ変更を完了させる。 ところが、17日はこのように作業を進めることができなかった。という

    JR東日本の新幹線トラブル、原因はシステムの処理容量オーバー
  • 三つの障害が連続発生、気象データ配信システムのダウンの経緯が判明

    2009年3月9日にダウンした気象データの配信システムが正常稼働までに17時間20分かかったのは、三つの障害が連続発生したからであることが分かった。ハードの二重化といった信頼性向上策を講じていたが、三つの障害が続いたことで、ダウンを回避できなかった。 一つめの障害は富士通製UNIXサーバー(OSはSolaris)のCPUボードの故障だ。電文形式データ配信システムでは、2台のサーバーによるホットスタンバイ構成を採用している。このうち番系サーバーが故障した。 すぐに待機系が稼働するはずが動かなかった。引き継ぎ情報を格納した制御系ファイルが壊れていた。これが二つめの障害だ。制御系ファイルは富士通製の共用ディスク上にあり、番系と待機系の双方からアクセスできる。サーバーの起動に不可欠だが壊れていたために引き継ぎ情報が読み込めなかった。 「電文形式データ配信システム」を管理する気象業務支援センター

    三つの障害が連続発生、気象データ配信システムのダウンの経緯が判明
  • NTTデータのブログサービス「Doblog」がハードディスク障害で停止してから1週間以上が経過、一体何が起きているのか?

    先日のヘッドラインでも書いたように、NTTデータが運営しているブログサービス「Doblog」に障害が発生したのが2月8日の午前10時過ぎなので、かれこれ1週間以上が経過してしまうわけですが、いまだに復旧していません。アクティブユーザー数は約2000~3000とされており、それなりの規模のブログのはずなのですが、一体何が起きたのでしょうか? RAIDは組んでいなかったのか、バックアップ体制はどうなっていたのか、100%復旧は可能なのか、そもそも復旧がこれだけ遅れているが復旧の目処すらまともに立たない理由は何なのか?これだけの長期間障害が続いているにもかかわらず、NTTデータ自体から障害の報告が出たのは2月8日の障害発生から1週間以上が経過した2月16日。もはやDoblogはNTTデータから見捨てられてしまっているサービスなのでしょうか? というわけで、今回の障害についてのまとめ、NTTデータ

    NTTデータのブログサービス「Doblog」がハードディスク障害で停止してから1週間以上が経過、一体何が起きているのか?
  • 5月の連休明けに「ソフトのバグ」が表面化

    2009年に注意したいシステムダウンを取り上げる特集では、前回までにうっかりミスと不慮の事故、性能不足を紹介してきた。4回めの今回は、ソフトの不具合について取り上げる。 ソフトの不具合によるシステムダウンは、OSやミドルウエア、アプリケーションソフトに潜むプログラムの「バグ」がきっかけになる。バグとはプログラムの記述ミスやロジックの矛盾、条件分岐の実装漏れなどによって、ソフトウエアが作成者の意図と異なる振る舞いをするときに、その原因となる部分を指す。アプリケーションの不具合とOS・ミドルウエアの不具合に分けて、それぞれ注意したいポイントを展望してみる。 切り替え直後の障害は「バグ」を疑う まずアプリケーションの不具合によるシステムダウンだ。大半はJavaCOBOLなどで個別に開発したプログラムに含まれるバグが表面化するケースである。 アプリケーションの不具合によるシステムダウンには、二

    5月の連休明けに「ソフトのバグ」が表面化
  • [続報]JR東の新幹線がシステム障害から復旧、前日データの反映に問題か

    2008年12月29日の始発からシステム障害で運行できない状態となっていたJR東日の東北・上越・山形、秋田の全新幹線が復旧した(写真)。システムの問題を解消し確認後の午前8時55分、やっと東京駅から始発電車が出発した。 JR東はトラブル原因について「詳細を究明しているところ」(午前9時45分時点)としているが、障害は新幹線の運行を管理する情報システムで発生した。車両やダイヤなど運行の根幹を管理するCOSMOS(COmputerized Safety Maintenance and Operation systems of Shinkansen)と呼ばれているものだ。 29日早朝、COSMOSのコンピュータは稼働しているものの、営業運行に向け列車が割り付けられなかった。調査したところ、前日までの処理の問題によって、当日の運転ができるシステム状態になかったという。JR東の新幹線では前日12月

    [続報]JR東の新幹線がシステム障害から復旧、前日データの反映に問題か
  • [速報]JR東の新幹線がシステム障害で始発から全面停止、復旧は午前8時に延期

    JR東日の東北・上越・山形、秋田の全新幹線が2008年12月29日の始発からシステム障害の影響で運行できない状態となっている。当初午前6時30分としていた復旧は、同日午前7時の段階で午前8時に延期した。 JR東によるとトラブルが発生したのは新幹線の運行管理システム。コンピュータは起動しているものの、新幹線の列車情報を実運行に向けてシステム上で割り付けられない状態になっている。 今年9月にもJR東の新幹線ではシステム障害が発生している。原因は列車の進路を自動制御する装置のハードウエア故障だった。今回は運行管理システムのより上位の全体を司る部分で発生している状況だという。

    [速報]JR東の新幹線がシステム障害で始発から全面停止、復旧は午前8時に延期
  • さくらインターネットのデータセンターで電源障害、グリーやソネットなどが停止

    データセンター運営のさくらインターネットの西新宿センターで2008年12月19日昼、電源設備の発煙事故が発生し、サーバーなどへの電源供給が停止。さくらのセンターを利用していると見られる、SNSのグリーやソネットエンタテインメントのブログなどがサービスを停止している(写真)。 トラブルが発生したのは19日午後0時35分頃。西新宿センターの6階の一部エリアへの電源供給が停止した。さくらインターネットによると「ご迷惑をおかけして申し訳ない。日中にはすべての電源供給を回復させる見通しだが、詳しい影響範囲と原因は現在調査しているところ」という。 なお、グリーとソネットの両サービスとも、同日午後7時30分現在で復旧していない。

    さくらインターネットのデータセンターで電源障害、グリーやソネットなどが停止
  • 【続報】電源設備が復旧も,GREEやSo-netやSeesaaは停止中

    さくらインターネットは,「西新宿データセンター」で19日午後0時35分に発生した電源設備の故障が午後7時30分に復旧したと発表した(写真)。電源設備を復旧させる前に,電力供給が停止していたサーバーに対し,故障していない電源設備から延長コードを使って電力を供給。電源設備の復旧により,元の電源装置からの供給に戻した。 ただし,西新宿データセンターを利用しているグリーのSNSGREE」やソネットエンタテインメントの「So-net blog」,シーサーの「Seesaaブログ」は午後9時30分現在,まだ復旧していない。グリーの広報担当者は,「現在はシステムの稼働検証中。終わり次第サービスを再開する」と語る。

    【続報】電源設備が復旧も,GREEやSo-netやSeesaaは停止中
  • さくらインターネットのデータセンターに障害、GREEなどのサービスが停止中

    さくらインターネットのデータセンターに12月19日、障害が起き、データセンター収容ラック内への電源供給が一部で停止している。この影響を受け、ソーシャルネットワーキングサービス「GREE」やブログサービス「Seesaaブログ」「So-net blog」など、同社を利用したサービスが利用できない状態になっている。 さくらインターネットによると、東京都新宿区にある西新宿データセンター内の電源設備から煙が出ていたという。発生時間は12時35分頃。具体的には、6階Aゾーンの配電盤3台、6階Bゾーンの配電盤2台の片系統もしくは両系統の電源供給が停止しているとのことだ。 復旧に向けて対応をしている状況で、19日中にすべての供給が回復する見通しとしている。 12月20日追記: さくらインターネットによると、19日午後7時30分、すべての電源供給が復旧したという。その後も同社を利用しているサービスに障害が出

    さくらインターネットのデータセンターに障害、GREEなどのサービスが停止中
  • JALの運航業務システム障害で30便が遅延、原因はデータ量の見積もりミス

    11月30日午前、日航空の運航業務システムでトラブルが発生。羽田空港の国内線と成田空港の国際線、計30便が最大で49分遅延し約4500人の足に影響が出た。トラブルを起こしたのは、運航業務システム「JALFOS」のうち航空機の重心を計算する機能。旅客や貨物の状況によって異なる重心を算出し、離陸時などの参考データにする。 システムは30日午前8時35分にダウンし、復旧までの2時間は担当者が手作業で計算した。さらに通常ジャンボ機であれば無線で計算後のデータを送信しているが、これも不能に。係員が広い空港内を駆け回り、データを手渡しすることになったため出発便が遅延した。 原因は26日に実施した同システムの更新で作り込まれた。具体的には、より詳しい情報が得られるよう、新たなデータを追加で扱うように機能を拡張。30日になってデータの処理に予想以上の負荷がかかりダウンした。「システムの領域を拡張すること

    JALの運航業務システム障害で30便が遅延、原因はデータ量の見積もりミス
  • 大和証券の夜間取引でシステム障害、故障HDDがバックアップに切り替わらず

    大和証券グループ社は2008年9月19日、18日夜に発生したシステム障害の原因に関して説明した。トラブルが生じたのは18日17時30分ころから22時40分ころまで。障害発生中は夜間に株式を売買できるPTS(私設取引システム)の取引、個人向け国債の予約注文、取引コースの変更、ATMでの入出金ができなくなった。 大和証券グループ社広報によると、原因はハードディスクドライブ(HDD)の破損。来ならHDDの故障時にはバックアップに切り替わるはずが切り替わらなかった。HDDの破損が複数のシステム障害に波及した原因、バックアップが正常動作しなかった原因などの詳細については、現在調査中とする。 同社は9月12日にも株式注文システムで障害を起こしている(関連記事)。ただし、今回のシステム障害とは原因が異なる。 9月12日の障害は、株式注文の受注データを発注処理に引き渡す「制御系プログラム」が停止した

    大和証券の夜間取引でシステム障害、故障HDDがバックアップに切り替わらず
  • [速報]全日空が搭乗システム障害の原因特定、接続の有効期限を設定ミス

    全日空輸は9月14日に発生した搭乗システムの障害原因を特定し修正した。問題を起こしたのは、各空港に設置した搭乗手続きや荷物の登録を行うチェックイン端末。14日の始発便から利用できなくなった。 原因はチェックイン端末を管理するサーバー側の設定ミスだった。接続してくるチェックイン端末が正当かどうかを認証するための設定値のうち、暗号化機能の有効期限が「2008年9月14日1時44分まで」となっていた。これによって14日の始発便から、全国にある51空港のチェックイン端末が認証エラーとなって利用できなくなった。認証を通過することで、チェックイン端末の内蔵ハードディスクのデータが暗号化できるようになる。個人情報保護などの観点から実装したものだ。 全日空は16日に原因を特定し、17日までに修正して正常動作を確認した。問題となった管理サーバーは05年に導入したが、昨年導入したチェックイン端末まで暗号化認

    [速報]全日空が搭乗システム障害の原因特定、接続の有効期限を設定ミス