手順書の記載ミスで発生したJR東日本のシステム障害についてまとめてみた - piyolog
2023年6月26日、JR東日本は6月24日に発生したシステム障害の原因が電源工事の操作手順に誤りだったと公表しました。システム障害の影響により、Webページの閲覧不可やモバイルSuicaのアプリが利用できないなどが生じました。ここでは関連する情報をまとめます。 4つのシステムに最大半日の影響 システム障害は2023年6月24日0時37分頃発生。電源供給断により各システムのサーバーが停止しシステムの異常を知らせるアラートが相次ぎ発報。*1 夜間処理中に強制的な停止が生じたことで、ハード故障、データ不整合が発生。JR東日本は次の4つのシステムに電源断の影響が及んだとしている。 影響を受けたシステム 障害発生時間 障害発生による具体的な影響 JR東日本Webシステム 2023年6月24日0時37分～6時33分 Webサイトの閲覧不可 ビューカードシステム 2023年6月24日0時37分～9時2
【1月23日追記】12月23日、24日に発生しました障害に関するご報告
いつもSkebをご利用いただき、誠にありがとうございます。 12月23日12時よりskeb.jpにアクセスできない大規模な障害が発生しておりましたが、12月24日07時に復旧いたしました。 12月23日、および12月24日が納品期限のリクエストは納品期限を12月25日23時59分までに延長させていただきます。 みなさまには多大なご迷惑をお掛けしましたことをお詫び申し上げます。 本障害につきまして詳細をご報告させていただきます。 概要日時: 12月23日12時22分〜12月24日7時00分 (JST) ダウンタイム: 18時間38分 内容: skeb.jpにアクセスできない不具合 原因: SkebはすべてのサーバとシステムをHerokuに設置していたが、障害発生時刻より同サービスのアカウントが理由の通知なく利用できなくなった。 解決: Herokuの一切の利用を中止し、すべてのサーバとシステ
みずほに業務改善命令出す方向で最終調整 金融庁 | NHKニュース
金融庁は、みずほフィナンシャルグループと傘下のみずほ銀行に対し、相次ぐシステム障害をめぐり業務改善命令を出す方向で最終的な調整に入りました。障害が頻発している事態を重く見て、システムの点検や改修について緊密に情報を共有しながら金融庁としての監督を強化し、再発防止の徹底をはかりたいとしています。 みずほ銀行では、ことし2月から3月にかけての2週間足らずの間に4件のシステム障害が発生し、最初の障害ではATMからキャッシュカードや通帳を取り出せず、その場で長時間待たされた人も相次ぎました。 さらに8月と今月にも店舗での取り引きやATMなどで一時、障害が発生しました。 こうしたことから関係者によりますと、金融庁はみずほフィナンシャルグループと傘下のみずほ銀行に対して業務改善命令を出す方向で最終的な調整に入りました。 障害が頻発している事態を重く見て、銀行側に対してシステムの点検や改修について詳細な
中田の質問箱です
みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、
スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと | DevelopersIO
スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと セッション管理が必要なWebアプリケーションを使う場合でも､スティッキーセッションを利用しない方法を説明します｡また､ログをインスタンス内に保持しない方法やAuto Scaling化についても触れています｡ はじめに おはようございます､加藤です｡煽り気味なタイトルで申し訳ございません､念の為より詳細に記載しますが､スティッキーセッションを使っていなければApplication Load Balancer障害の影響を受けるのを防げたかもしれないという内容です｡ 今後同様の障害への対処として､このブログの対応は行う価値がありますが､これだけやっておけばOKという事では無い事をご理解ください｡ 2019年8月23日にAWS
Summary of the Amazon EC2 Issues in the Asia Pacific (Tokyo) Region (AP-NORTHEAST-1)
2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご
AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告
AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告 2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めました。 下記は大規模障害の報告ページです。赤枠で囲った部分が、8月28日付けで追記されました。 当初の報告は、障害の原因が空調装置のバグであり、それが引き金となってサーバーのオーバーヒートが発生したことなどが説明されていました。 そして障害の影響範囲は単一のアベイラビリティゾーンに閉じており、 複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。 と説明されていました。 複数のアベイ
AWS大障害、冗長構成でも障害あったと公式に認める
米アマゾン ウェブ サービス（Amazon Web Services）は2019年8月23日に発生したクラウドサービス「Amazon Web Services（AWS）」東京リージョンの大規模障害に関して同月28日、新しい報告をWebサイトに掲示した。障害が発生したサービスを追加したほか、利用企業が複数のアベイラビリティーゾーン（独立性の高いデータセンター群、AZ）横断の冗長構成にしたシステムにも一部で障害（予期せぬ影響）があったと認めた。 障害が発生していたサービスとして追加したのは日経 xTECHの既報の通り、アプリケーションロードバランサーの「Amazon ALB」、インメモリーキャッシュの「Amazon ElastiCache」、データウエアハウスの「Amazon Redshift」、仮想デスクトップの「Amazon Workspaces」などだ。仮想マシンの「Amazon EC2
AWS障害、“マルチAZ”なら大丈夫だったのか？ インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
AWS障害、“マルチAZ”なら大丈夫だったのか？ インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」（1/3 ページ） 8月23日に起きたクラウドサービス「AWS」（Amazon Web Services）の東京リージョンでの障害は、国内のさまざまなサービスに影響を及ぼした。 AWSが同日午後8時ごろに復旧するまで、モバイル決済サービス「PayPay」や、仮想通貨取引所「Zaif」、オンラインゲーム「アズールレーン」などで利用できない、もしくは利用しづらい状況が続いた。PCショップの「ドスパラ」はECサイトの不具合が長引き、翌日の24日には実店舗を臨時休業して対応に当たっていた。 AWSという1つのサービス障害が起きただけで、多くの企業やサービスに影響を及ぼしたため、「クラウドサービスはもろい」という論調も散見された。 しかし、インフラエンジニアたちからは違う意見が聞こえてくる
Google CloudやYouTubeの障害は「数台のサーバへの設定変更のつもりが、誤って複数リージョンの多数のサーバに適用されてしまった」。Googleが説明
Google CloudやYouTubeの障害は「数台のサーバへの設定変更のつもりが、誤って複数リージョンの多数のサーバに適用されてしまった」。Googleが説明 6月2日の午前11時45分（米国太平洋時間。日本時間の6月3日午前3時45分）から15時40分（同日本時間午前7時40分）までの約4時間、Googleの米国内ネットワークで障害が発生し、Google CloudのCompute EngineやCloud Storage、さらにYouTubeやG Suiteなどもその影響を受けて動作が遅くなったり利用できなかったりしました。 幸いなことに、障害の状況および時間帯の関係で日本のユーザーへの影響はそれほど大きなものではありませんでしたが、Googleの24x7担当VPであるBenjamin Treynor Sloss氏がGoogle Cloudのブログに記事「An update on
ソフトバンク大規模通信障害の原因:Geekなぺーじ
2018年12月6日、ソフトバンクのネットワークにおいて、4時間25分にわたり約3060万回線の利用者に影響を及ぼす通信障害が発生しました。 ソフトバンクおよびワイモバイルの4G(LTE)携帯電話サービス、「おうちのでんわ」、Softbank Air、3Gサービスなどが影響を受けました。 この障害は、EricssonのMME内部にハードコーディングされた証明書が期限切れになったため、SGSN-MME(Serving GPRS Support Nodex - Mobility Management Entity)が再起動を繰り返してしまったのが原因です。 ただ、証明書が期限切れになることで、なぜ大規模な通信障害に繋がってしまうのかが良くわかりませんでした。 どのような設計をしたら、証明書が期限切れになったことで通信機器が再起動を繰り返すような状況になるのか、昨年段階では、いまいち理解できなか
Google Cloud Load Balancerの障害、原因は新機能に含まれていたバグ。テスト時も導入時にも発見できず
Google Cloud Load Balancerの障害、原因は新機能に含まれていたバグ。テスト時も導入時にも発見できず Google Cloudのロードバランサーが先週火曜日、7月17日の12時17分（米国太平洋標準時夏時間。日本時間7月18日午前4時17分）から約40分のあいだ障害を起こし、Pokémon GOやSpotifyなどGoogle Cloud上で提供されている多くのサービスが影響を受けた件について、Googleは経緯や原因などの報告を公開しました。 報告によると、原因はロードバランサーに追加された新機能にバグがあったことだとされています。 ロードバランサーがバックエンドと通信できなくなる 前述の通り、障害が発生したのは7月17日の12時17分（米国太平洋標準時夏時間。日本時間7月18日午前4時17分）。 主な現象は、Google HTTP(S) Load Balancer
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickey
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 ファーストサーバが提供しているホスティングサービス「Zenlogic」は、6月下旬から断続的に生じていたストレージ障害に対応するためのメンテナンスが終了の見通しも立たないほど難航し、結局、メンテナンス開始から3日後の夜にようやくサービスが再開されるという事象を起こしました。 参考：ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり） － Publickey サービス再開から約1週間が経過した7月17日、同社はストレージ障害に関する原因およびメンテナンスによるサービス停止が長期化してしまった原因、再発防止策についての報告書を明らかにしました。 報告によると、ストレージ障害の直
ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり）
ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり） ファーストサーバが提供しているホスティングサービス「Zenlogic」で、本日午前8時に終了予定だったメンテナンスが終わらず、月曜日の午前9時を過ぎた記事執筆時点でサービスが停止したまま、終了時間が未定になっています。 （2018/7/9 15:47追記） 同社は障害の調査と平行して、基盤提供元のヤフー株式会社とともに別基盤の構築準備作業を実施していると報告しています。ただし「本日中に目途をお伝えするのは厳しい状況でございます。」とのことで、明日10日火曜日までサービス停止が継続する可能性を示唆しています。 （2018/7/9 22:50追記）同社は一時的にサービスの再開を発表、下記の記事を公開しました。 ファーストサーバの「Zenlo
GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間
GitHubが1月28日のサービス障害の詳細を公開。停電により内部のChatOpsシステムも落ちて初期対応が困難に。Redisクラスタの復旧に時間 報告では、サービス障害はGitHub社内のChatOpsシステムも巻き込んで初期対応に時間がかかってしまったこと、一時的な停電がRedisクラスタの障害を引き起こしたため、その究明と復旧が作業の主な部分だったことなどが説明されています。 報告の要点をまとめました。 内部のChatOpsシステムも障害に GitHubのサービス障害は、すでに報告されているように、自社データセンターにおける一時的な停電が最初の原因でした。 At 00:23am UTC on Thursday, January 28th, 2016 (4:23pm PST, Wednesday, January 27th) our primary data center experi
GitHubが先週木曜日にダウンした原因は、一時的な停電からの連鎖的な障害
日本時間で1月28日木曜日午前9時過ぎから発生したGitHubのサービス障害は、同社のデータセンター内での一時的な停電をきっかけに連鎖的に発生した障害の影響であることが、GitHubのブログに投稿された記事「Update on 1/28 service outage」で説明されています。 GitHubのブログから引用します。 A brief power disruption at our primary data center caused a cascading failure that impacted several services critical to GitHub.com's operation. 主データセンターにおける一時的な停電が連鎖的な障害を引き起こし、GitHub.comの運用にいくつもの深刻な影響を与えてしまった。 GitHubの説明によると、障害が発生したのは協
GMO、先週の24時間にわたるサービス障害時にはデータセンター内の約12％が電源喪失。変圧分電盤故障が原因の可能性。監視体制の強化など対策
先週末、2016年1月16日から17日にかけて、GMOインターネットが提供するレンタルサーバやドメイン名登録などのサービスで管理画面が表示できなくなるなどの障害が約24時間にわたり発生しました。 GMOインターネットはWebサイトで影響の範囲や復旧状況などを報告、それによると障害の影響範囲は、お名前.com、レンサバ.comなどに加え、ConoHa byGMO、GMOアプリクラウドなどクラウドサービスまで広範囲に渡っています。 また、障害の原因は「データセンター内における電源設備の一部故障」とされました。 24時間という長時間かつ広範囲に発生した障害の実態はどうだったのか、また原因とされた電源設備の一部故障とはどのようなものだったのか、GMOインターネットの発表は詳細部分について触れられていなかったため、PublickeyではGMOインターネットに対して取材を申し込みました。 GMOインタ
「天に召されたデータに献杯！」
「お店のWebサイトが見られない」「顧客データ1万件が消えた」――6月20日に起きたファーストサーバの大規模障害にほんろうされた人々が、愚痴をこぼしながら名刺と杯を交換するイベントが行われた。（編集部） 100人近くが「天に召されたデータに献杯！」 「天に召されたデータに献杯！」――6月20日に起きたファーストサーバの大規模障害にほんろうされた人々が、心ゆくまで愚痴をこぼしながら名刺や杯を交換するイベント「ファーストサーバ データ消失オフ『データはどこへ消えた？』」が、7月14日深夜、東京・阿佐ヶ谷のライブハウス「阿佐ヶ谷ロフトA」で開かれた。 土曜の深夜という時間帯にもかかわらず、自社のサーバが被害に遭った人やファーストサーバの同業他社、業界関係者など100人近くが集結。隣人のデータ消失被害に同情を寄せ、復旧の報告に歓声を上げるなど、深夜の阿佐ヶ谷は異様な熱気に包まれた。 障害が起きたの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Zenlogicサポートサイト［IDCフロンティア］