マクドナルド店舗の端末がマルウェア感染、電子マネー決済に障害 4日経っても復旧できず
マクドナルドの店舗に設置された端末の一部がマルウェアに感染した影響で、全国のマクドナルド店舗で、電子マネー「WAON」などが使えない障害が6月16日に起きた。4日経った20日午後3時時点でも復旧していない。 日本マクドナルドによると、マルウェアに感染したのは、店舗の売り上げなどを管轄するシステムの一部。全国2900店舗のうち、一部で感染を確認した。感染により、システムが外部に大量のパケットを発信して通信を圧迫し、電子マネー決済などに障害を引き起こしたという。 システムのOSには「Windowsなど」を採用しているが、社外ネットワークには接続しておらず、感染ルートは「調査中」としている。ランサムウェア型ワーム「WannaCry」の可能性もあるとしているが、自己増殖するワーム的な動きはみられないという。 この影響で16日から、「dポイント」や「楽天スーパーポイント」、電子マネー「WAON」「i
Azureの東日本リージョンが7時間にわたってダウン。原因はデータセンターの冷房が失われ自動シャットダウン。日本のリージョンはこの1カ月で三回目の障害
Azureの東日本リージョンが7時間にわたってダウン。原因はデータセンターの冷房が失われ自動シャットダウン。日本のリージョンはこの1カ月で三回目の障害 3月31日金曜日の午後11時頃から最大約7時間にわたって、Microsoft Azureの東日本リージョンの仮想マシンやストレージなどを含むほとんどのサービスがダウンするという大規模な障害が発生しました。 「Azure の状態の履歴」によると、マイクロソフトは原因をデータセンターの冷却が正常にできなくなったためだと次のように説明しています。 Engineers have identified the underlying root cause as loss of cooling causing certain Storage and Compute scale units to perform an automated shut down
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日
AWS S3の長時間サービス停止の原因はエンジニアの入力ミス
米Amazon.com傘下のAWSは3月2日（米太平洋時間）、2月28日にクラウドストレージサービス「S3」の北バージニアリージョン（US-EAST-1）で起きた大規模なサービス停止の原因と対策を発表した。 28日午前11時20分ごろ発生したこの問題は復旧までに約4時間かかり、同サービスを利用するIFTTT、Quora、Medium、Imgur、GitHubなど、多数のサービスが影響を受けた。 原因は、エンジニアの入力ミスだった。 同日の午前9時37分、S3の課金システムのデバッグ中、S3のサブシステム用の少数のサーバの接続を解除しようとした際、コマンドの入力を誤り、意図したよりも多数のサーバを解除してしまった。その中の2つのサーバが、同リージョン内のすべてのS3オブジェクトのメタデータと位置情報を管理するインデックスサブシステムと、運営にとって重要な配置用サブシステムだったため問題が大き
Twitterに障害 30分ほどで復旧
11月7日午後2時50分ごろから、Twitterにアクセスや投稿ができない障害が起きたが、3時20分ごろまでに復旧した。
「モバイルSuica」障害、約3時間半で復旧 「通常の10倍のアクセス」 Apple PayのSuica対応が影響か
「モバイルSuica」障害、約3時間半で復旧 「通常の10倍のアクセス」 Apple PayのSuica対応が影響か JR東日本は10月25日、同日朝7時半ごろから起きていた「モバイルSuica」の障害が、午前11時ごろにおおむね復旧したことを明らかにした。 原因は調査中だが、同日からApple PayがSuicaサービスに対応し、iPhoneでSuicaが利用できるようになったことが影響した可能性があるという。モバイルSuicaとApple Pay向けSuicaは共通のサーバを利用しており、25日朝は従来の10倍のアクセスが集中していたという。 モバイルSuicaは、JR東がAndroidやフィーチャーフォン向けに提供しているSuicaサービス。25日午前7時半ごろからアクセス障害が起き、チャージやグリーン券・特急券の購入など、ログインが必要な機能が利用できなくなっていた。 モバイルSu
3割が運用ミスでの障害やトラブルを毎月経験--サーバ台数が多いほど高い頻度
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます IDC Japanは10月20日、国内企業でのシステム運用管理実態に関するユーザー調査結果を発表した。8月に調査し、309社の有効回答を得ている。 システム運用管理での課題は「運用管理担当者のスキルが不足している」が32.0％で最も多く、次いで「運用管理の自動化ができていない」が30.7％、「システムの一元管理ができていない」が30.4％となった。過去4回の調査でも担当者のスキル不足は最も多い回答となっている。 スキル不足から運用管理の自動化や一元管理ができない状況を招いてしまっているということが考えられると説明。運用管理担当者のスキル不足は運用ミスを起こしやすく、障害やトラブルの増加につながっていくことが懸念されるとしている。 運用上
IaaS/PaaSで最も顧客満足が低いのは障害・トラブル対応や復旧時間--J.D.パワー
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます J.D.パワー アジア・パシフィックは9月12日、日本クラウドサービス提供事業者顧客満足度調査の結果を発表した。 本調査は、法人向けのクラウドサービスに関する顧客満足度を調べたもので、IaaS/PaaS型クラウドサービス（ホスティング・レンタルサーバーも含む）に関する調査と、クラウド型グループウェアの販売・導入支援を行うシステムベンダーに関する調査の2つを実施した。 調査は全国の従業員規模50名以上の企業を対象として7月に郵送調査によって行い、IaaS/PaaS型クラウドサービスについては723社から、クラウド型グループウェア導入ベンダーについては585社から回答を得た。なお、IaaS/PaaS型クラウドサービスについては1回答社から最
Amazonクラウドのシドニーリージョン、豪雨による電源障害でEC2などに一部障害。現在は復旧
6月5日にオーストラリア東海岸で発生した大規模な豪雨で、シドニーでは約8万500軒の家やオフィスでの停電や広範囲な通信障害などが発生。AmazonクラウドのシドニーリージョンでもAmazon EC2などに一部障害が発生したことが報告されました。 堅牢に設計されているクラウドのデータセンターといえども、地域的な災害による影響を受けることは避けられないことを示す例といえます。台風や地震の多い日本でもこうした事象が起こりうると想定し、備えておく必要があるでしょう。 Amazon Web Servicesの「Service Health Dashboard」から、障害報告の一部を引用します。 障害報告から一部抜粋 6月4日の午後10時47分（太平洋標準時。シドニーでは6月5日午前3時47分。日本時間6月5日午前2時47分）に、シドニーリージョンでAmazon EC2の接続障害が観測されはじめます。
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン（Google Compute Engineでは「ゾーン」）にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド（IaaS）に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
原因は2つのバグ--グーグル、全リージョンに発生したGCEの障害について説明
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 米国時間4月11日にウェブアプリにアクセスできないトラブルに遭遇したとしたら、それはGoogleが提供しているIaaS（サービスとしてのインフラストラクチャ）である「Google Compute Engine」（GCE）の広域障害が原因だった可能性がある。 Googleが直接提供する「Gmail」や「Googleドライブ」などのサービスに影響が出ると、わずかな障害でも注目を集めるが、11日に障害が起こったのは、Googleが企業やアプリ開発者に提供している仮想サーバの基盤となっているGCEだった。 この障害は18分しか続かなかったが、問題は全リージョンのGCEのインスタンスが影響を受けたことだ。これは、Googleが複数のリージョンでデ
Twitterで障害発生→復旧
正午時点では、都内から「twitter.com」にアクセスすると「技術的な問題が発生しています」と表示される状態だった。Twitterの公式アプリでも最新の投稿が取得できなかった。 米Twitterは日本時間の午後0時37分に障害情報を発表した。「一部のユーザーでtwitter.comやモバイルアプリにアクセスしづらい状態が起きている」とし、復旧に向けて取り組んでいるという。 関連記事 SMAP生出演で投稿殺到？ Twitterが一時接続しにくい状態に SMAPのメンバー5人が生出演した直後からTwitterが一時接続しにくい状態に。 Twitter、アクセス障害の原因はデータセンターのシステムの問題 Twitterが数時間にわたってダウンしたのは、オリンピックのせいではなく、データセンターのシステムの問題だった。 Twitterで大規模障害、原因は「タイムラインキャッシングの強化に失敗」
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月末のダウンの原因はデータセンターでの停電と説明
ソースコード共有ツールを運営する米GitHubは1月29日（現地時間）、日本時間の28日（木曜日）の午前9時ごろから約2時間にわたってサービスがダウンしたことについて謝罪し、原因は自社データセンターでの停電だったと説明した。 GitHubの障害は世界規模のものだった。同サービスの利用者は現在、世界で970万人以上。政府機関や大手企業も利用しており、日本でも日立システムズ、ヤフー、サイバーエージェント、グリーなどが導入している。 GitHubは、同社の一次データセンターでの短い停電が連鎖的障害を引き起こし、GitHub.comの運用にとって重要な多くのサービスに影響を与えてしまったと説明する。障害の発生は世界協定時（UTC）の28日午前0時23分で、同日午前2時32分（日本時間の28日午前11時32分）には復旧したとしている。 同社は「われわれのサービスのいかなる障害でも皆様の仕事に影響を与
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インタ
GMOグループのサービスが24時間停止--データセンター内の電源設備に故障
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます GMOインターネットグループは1月17日、1月16日の14時15分ごろから、1月17日の14時25分まで同社の複数サービスでウェブに接続できない障害が発生し、サービスが停止したことを公表、謝罪した。データセンター内の電源設備の一部に故障があったという。 具体的な事象とし「対象サービスのウェブサイトが表示されない」「ログインできない」「一部メールが受信できない」などが起こっていた。 原因はデータセンター内の電源設備の一部に故障があったためとのこと。再発防止策として、（1）故障した電源設備を利用するサーバを別の電源設備へ切り替えること、（2）電源設備の修理、（3）通電後のサーバ機器などの稼働点検の3点を挙げた。 また、データセンターで使用し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
LINEに不具合 メッセージが送りにくい状態に
Xbox Live、土曜深夜に数時間ダウン（復旧済み）
