タグ

障害に関するyamadarのブックマーク (14)

  • すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp

    すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ⁠⁠、全銀システム通信障害の詳細を説明 全国銀行資金決済ネットワーク(以下、全銀ネット)とNTTデータは12月1日、2023年10月10日~11日にかけて全国銀行データ通信システム(以下、全銀システム)で発生した通信障害に関する報道関係者向けの説明会を開催しました。件についてはNTTデータが11月6日に行った途中経過報告の内容をもとにレポートしましたが、今回、全銀ネットとNTTデータが揃って会見を行ったことで、より詳細な障害の原因が判明したので、あらためてその内容を検証してみたいと思います。 説明会の登壇者。左から、全銀ネット 企画部長 千葉雄一氏、事務局長兼業務部長 小林健一氏、理事長 辻松雄氏、NTTデータ 代表取締役社長佐々木 裕氏、取締役副社長執行役員 鈴木正範氏 なお、全銀ネットとNTTデータは、今回の障害に関して金融

    すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 | gihyo.jp
  • 全銀システムの大規模障害、「真の原因」明らかに--全銀ネットとNTTデータが発表

    全国銀行資金決済ネットワーク(全銀ネット)とNTTデータは12月1日、10月10日〜11日に発生した全銀システムの大規模障害の真の原因を明らかにした。 全銀システムは、日常の振込や送金をリアルタイムで処理するシステムで、国内のほぼすべての預金取扱金融機関が利用している。10月のシステム障害では三菱UFJ銀行、りそな銀行など10行で、他行宛の振り込みができないなどの障害が丸2日間継続した。 障害は、全銀システムの中継コンピューターを新機種「RC23シリーズ」へ交換し、その後営業運用を開始した直後に発生した。RC23シリーズ内の「銀行間手数料を処理するためのインデックステーブル」が破損しており、同テーブルを参照する際の処理でエラーが生じたためだ。 中継コンピューターは東京と大阪に1台ずつ、冗長化として設置されていたが、2台同時に新機種のRC23シリーズに切り替えたため、2台ともにソフトウェア障

    全銀システムの大規模障害、「真の原因」明らかに--全銀ネットとNTTデータが発表
    yamadar
    yamadar 2023/12/01
    何らかの都合で待機系も同時に入れ替えねばならないものだったのかな。そうならば冗長化がなくなるし切替前は相応のステージングテストが必要だけど、やらなかったんだな
  • 「説明を聞けば聞くほど不穏な空気が漂ってきたよ」全銀ネットの障害、原因説明の会見で謎がさらに深まった模様

    J @j17sf 概要については主に先週の記事で紹介したので、QAになるまではメインのツリー伸ばしません。興味ある方は記事を参照ください watch.impress.co.jp/docs/series/su… 2023-10-18 16:13:29 リンク Impress Watch 全銀システム障害と、同システムが目指す将来像【鈴木淳也のPay Attention】 10月10日から全国銀行資金決済ネットワーク(全銀ネット)が運用する「全国銀行データ通信システム(全銀システム)」で発生していたシステム障害は、12日朝8時半の営業開始時間(コアタイム)をもって解消された。一部、10日と11日に行なわれた“仕向”の取引データに未処理のものが残っていたが、12日午前10時50分をもって全件処理が完了しており、通常状態へと戻っている。 65 users 114

    「説明を聞けば聞くほど不穏な空気が漂ってきたよ」全銀ネットの障害、原因説明の会見で謎がさらに深まった模様
    yamadar
    yamadar 2023/10/19
    記者「サーバはUNIXか?メインフレームか?」 全銀「回答は控えさせていただきます」 記者「プログラム言語はC言語ですか?」 全銀「CとJavaです」 記者「じゃあUNIXですね、ありがとうございます」
  • 富士通Japan、コンビニ交付でまた不具合 抹消したはずの印鑑登録証明書を誤発行

    新潟市は5月15日、マイナンバーカードを利用した証明書のコンビニ交付サービスで不具合が起きたと発表した。抹消済みの印鑑登録証明書を誤交付する不具合が発生し、市は交付サービスの提供を一時全面停止にした。システムの提供事業者は富士通Japan。 12日昼ごろ、住民から「既に廃印処理済である印鑑登録証明書を誤交付された」の指摘を受け、不具合が発覚。市はコンビニ交付システムの提供を全面停止した。その後、原因を特定したところ、他の証明書では不具合が発生しないと判明。同日中に該当する証明以外の交付を再開、16日には印鑑登録証明書の交付も再び始めた。 この件について、富士通Japanが追跡調査を行ったところ、新潟市の他住民で同じ現象が2件起きていることを確認。また、他自治体での影響を調べたところ、一部の政令指定都市でも同様の事象が発生する可能性があると明らかに。該当の自治体にはそれぞれ連絡したという。

    富士通Japan、コンビニ交付でまた不具合 抹消したはずの印鑑登録証明書を誤発行
    yamadar
    yamadar 2023/05/16
    オラわくわくしてきたぞ/受け入れテストの実施とか、テスト項目のチェックとか、どうなってるんだろ
  • 【独自】“違法電波”で通信障害が相次ぐ…飛行機が欠航したことも 取り締まりの瞬間 | MBSニュース

    国内で使用が禁止されている「外国製無線機」による電波で、携帯電話の通信障害などが相次いでいることがわかりました。近畿総合通信局の取り締まりの瞬間をカメラがとらえました。 【取り締まりの様子】 (電波監視官)「これ(無線機)、日製じゃないですよね?」 (業者)「日製の無線機じゃない、中国製」 (電波監視官)「違法だと知らないで使っていた?」 (業者)「知らない、知らない。日製は高いよ」 電波法違反の疑いで近畿総合通信局から行政指導を受けたのは、大阪府の廃棄物処理業者で、国内で使用が禁止されている周波数の電波を発する外国製無線機を使用していました。業者側は「違法とは知らず現場の連絡手段として使っていた」と説明したということです。 外国製の無線機は、使用が認められている無線機と比べて安く、ここ数年多く流通していて、携帯電話の通信障害が全国各地で数十件確認されているほか、航空機にGPSを受信

    【独自】“違法電波”で通信障害が相次ぐ…飛行機が欠航したことも 取り締まりの瞬間 | MBSニュース
  • スーパーコンピュータシステムのファイル消失のお詫び | お知らせ | 京都大学情報環境機構

    京都大学学術情報メディアセンター センター長 岡部 寿男 2021年12月14日 17時32分 から 2021年12月16日 12時43分にかけて,スーパーコンピュータシステムのストレージをバックアップするプログラム(日ヒューレット・パッカード合同会社製)の不具合により,スーパーコンピュータシステムの大容量ストレージ(/LARGE0) の一部データを意図せず削除する事故が発生しました. 皆さまに大変なご迷惑をおかけすることになり,深くお詫び申し上げます. 今後,再びこのような事態の生じることのないよう再発防止に取り組む所存ですので,ご理解をいただきますよう,どうぞよろしくお願いいたします. ファイル消失の影響範囲 ・対象ファイルシステム: /LARGE0 ・ファイル削除期間:2021年12月14日 17時32分 ~ 2021年12月16日 12時43分 ・消失対象ファイル:2021年12

    yamadar
    yamadar 2021/12/29
    スパコンに乗るような情報を77TB消失って。
  • みずほ、海外送金で外為法違反 障害で月内に最終処分へ - 日本経済新聞

    金融庁は今年8件のシステム障害を起こしたみずほ銀行と親会社のみずほフィナンシャルグループ(FG)に対し、月内にも追加の業務改善命令を出す。度重なる障害で企業取引を含め多くの利用者に影響が出たことを重くみた。障害時に海外送金で外為法違反の疑いのある対応をしていたことも新たに判明し、経営責任は一段と重くなる。障害が頻発する異常事態を収束させる再発防止策が問われる。金融庁は近く、今年3月以降、続けて

    みずほ、海外送金で外為法違反 障害で月内に最終処分へ - 日本経済新聞
    yamadar
    yamadar 2021/11/19
    バグってるのはシステムだけじゃなかった
  • 中田の質問箱です

    みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか?」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、

    中田の質問箱です
    yamadar
    yamadar 2021/09/10
    分かりやすい
  • みずほ銀行のシステム障害(2/28~3/12)の調査報告書、経営陣も現場もエンジニアも全てが残念 : 市況かぶ全力2階建

    日刊SPA!に登場の医学生投資家、儲け自慢に熱を入れるあまり「11歳から親の口座で投資を始めた」と借名取引をうっかり告白

    みずほ銀行のシステム障害(2/28~3/12)の調査報告書、経営陣も現場もエンジニアも全てが残念 : 市況かぶ全力2階建
  • [続報]OCNの通信障害、米グーグルによる誤った経路情報の大量送信が原因か

    2017年8月25日、NTTコミュニケーションズ(NTTコム)のインターネット接続サービス「OCN」で発生した通信障害に関して、インターネット通信関連の識者は誤った経路情報が大量に流れたことが原因ではないかとの見方を示した。ここでいう経路情報はルーターがBGP(Border Gateway Protocol)というプロトコルを使って交換するものだ。 日ネットワークインフォメーションセンター(JPNIC)の岡田雅之氏は、NTTコムは複数の組織と対等な関係でネットワークの経路情報をやり取りしているが(これを「ピアリング」という)、そのうちのある組織が誤った経路情報を大量に流したのではないかと話す。その結果、「NTTコムを介してインターネットに接続していた企業のルーターが、大量の経路情報を受け取り高い負荷がかかり、一部はフリーズしたような状態に陥るなどして通信障害につながったのではないか」(岡

    [続報]OCNの通信障害、米グーグルによる誤った経路情報の大量送信が原因か
    yamadar
    yamadar 2017/08/26
    震災という物理破壊でもインターネットは無事だったけど、こういう論理的な破壊には弱いんだな。
  • システム障害で飛行機が欠航&遅延…世界で相次ぐ原因は?

    もはや人間の手を離れた障害? 飛行機の機体には、なんの問題も見当たりません。天候もさして悪くはありません。それなのに飛行機会社のシステム障害で、すべての飛行機の搭乗手続きや離陸が進まず、欠航や遅延に巻き込まれて空港は大混乱というニュースが、世界で相次いでいます。 Bloombergによると先週末、米国内ではデルタ航空の国内線が突如として完全にマヒしてしまいました。その原因は、コンピューターのシステム障害と説明され、復旧までに21時間以上を要したとされています。でも、その1週間前にはユナイテッド航空が、やはりIT関連のトラブルを理由に、すべての国内線の運航を停止せざるを得なくなり、これまた大混乱を引き起こしました。 ちなみに、さすがに2週間続けてというのは異常ですけど、ここ半年間に似たようなシステム障害で飛行機の欠航や遅延が生じた事例は、枚挙にいとまがありません。例えば、昨年9月にブリティッ

    システム障害で飛行機が欠航&遅延…世界で相次ぐ原因は?
    yamadar
    yamadar 2017/02/03
    中央集権をやめてブロックチェーンにすれば良いのでは
  • GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット - Publickey

    果たしてGitLab.comで何が起きたのでしょうか? これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時(世界協定時。日時間2月1日午前8時)、YP氏(Yorick Peterse氏と思われる)はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時

    GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット - Publickey
  • 実践!ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)

    CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障

    実践!ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)
  • 誰も教えてくれなかったMySQLの障害解析方法 - Qiita

    それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'

    誰も教えてくれなかったMySQLの障害解析方法 - Qiita
  • 1