みずほフィナンシャルグループ(FG)の木原正裕社長(56)は本紙のインタビューで、顧客に影響の大きいシステム障害が今後発生した場合には、障害を把握してから「1時間以内に連絡が来る。部長レベルの会議もやる」と述べた。昨年2月の障害発生時に前社長らの把握が遅れたことについては、「僕にはメールも来るし重要なものは電話も来る」として、現在は改善したと説明した。(皆川剛)
みずほフィナンシャルグループ(FG)の木原正裕社長(56)は本紙のインタビューで、顧客に影響の大きいシステム障害が今後発生した場合には、障害を把握してから「1時間以内に連絡が来る。部長レベルの会議もやる」と述べた。昨年2月の障害発生時に前社長らの把握が遅れたことについては、「僕にはメールも来るし重要なものは電話も来る」として、現在は改善したと説明した。(皆川剛)
本ブログは、こちらに掲載されている英文ブログの意訳です。万が一内容に相違がある場合は、原文が優先されます。 2022年4月18日 23:57 UTC時点で、サービス停止の影響を受けたお客様サイトの復旧を完了しました。 2022年4月4日(月) PTに、アトラシアンクラウドをご利用の約400社のお客様が、アトラシアン製品全体を通してサービスの停止を経験されました。2022年4月18日現在、影響のあったお客様サイトの復旧を完了し、各サイトの窓口ご担当者宛てにご連絡申し上げました。 当社のサポートチームは現在、個々のお客様に合わせたサイト特有のニーズに対応しています。支援を必要とする事象のあるお客様は、当該サポートチケットへその旨ご返信ください。至急エンジニアリングチームより対応させていただきます。 今回のインシデントはサイバー攻撃や、システムの拡張に問題があったものではありません。また、一部の
みずほ銀行で30日午後、ATM=現金自動預け払い機などでほかの銀行宛ての振り込みが一時、利用できなくなる不具合が発生しました。現在は、復旧しているということです。 発表によりますと、30日午後3時半ごろから午後4時半ごろにかけて、みずほ銀行のATMとインターネットバンキングでほかの銀行宛ての振り込みの一部が利用できない状態になったということです。 銀行によりますと、夜間や休日の時間帯の入金処理に関わるシステムの設定に、人為的なミスがあったことが原因だとみられています。 影響が出た取り引きの件数は分かっていませんが、不具合はすでに復旧し、順次、振込先への入金の手続きを進めているということです。 みずほ銀行は「お客様に多大な迷惑をおかけしたことを深くおわびします」とコメントしています。 みずほ銀行はことし8回のシステム障害が相次いだため金融庁から業務改善命令を出され、1月17日までに改善計画を
みずほ銀行は8月から先月まで4回発生したシステムなどの障害について、ハードディスクの経年劣化などが原因だったと公表しました。 みずほ銀行は8月20日に店頭での取引の一部ができなくなった障害について、データセンターのハードディスクが稼働から6年経って劣化していたことに気付かず、故障したことが原因だと明らかにしました。 この際、バックアップシステムに切り替えようとしましたが、入力すべき追加の指示を飛ばしたため失敗しました。 8月23日や先月8日に100台以上のATMが一時停止したケースではネットワーク機器に静電気などが生じエラーが発生した可能性が高いということです。 再発防止のため、みずほ銀行は6年前のシステム構築に携わった富士通や当時の技術者らとの関係を強化する方針です。
2021年6月8日、fastlyのCDNサービスで障害が発生し、国内外複数のWebサイトやサービスに接続できないなどといった事象が発生しました。ここでは関連する情報をまとめます。 原因はソフトウェアの潜在的な不具合 fastlyより6月8日付で今回の障害の顛末が公開されている。 www.fastly.com 障害原因はソフトウェアの潜在的な不具合で特定状況下かつ顧客構成で発生する可能性があった。このソフトウェアは5月12日に展開が開始されていた。 6月8日早くにこの不具合を発生条件を満たす構成変更が顧客によって行われネットワークの85%がエラーを返す事態が発生した。サイバー攻撃の可能性は否定と報じられている。*1 障害は発生から1分後にfastlyに検知され、49分以内にネットワークの95%が復旧した。 今回の障害を受け、短期的には修正プログラムの早期適用、復旧時間の短縮、テスト時に不具合
ATM=現金自動預け払い機の障害などシステムのトラブルが相次いでいるみずほ銀行の藤原弘治頭取は、午後9時すぎから記者会見し、新たなシステムトラブルが発生し海外送金に遅れが出たことを明らかにしました。このトラブルで主に企業から依頼があった外貨建ての送金、およそ300件に遅れが出たということです。 トラブルは、システム関係の機械の故障で、11日午後11時39分に発生したということです。機械は、12日午前6時38分に復旧し、最終的な送金の処理は12日午後8時前に完了したとしています。このトラブルで、主に企業から依頼があった外貨建ての送金、およそ300件に遅れが出たということです。 藤原頭取は「先月28日のトラブルに加え、今月3日、7日と立て続けにトラブルが起きている。このような事態が続いていることを極めて重く受け止め、心から深くおわびします」と述べ、陳謝しました。 そのうえで藤原頭取は「経営責任
2月28日に発生したみずほ銀行のシステム障害。同行の藤原弘治頭取は3月1日に記者会見を開き、システムの過負荷が原因だったとして謝罪した。この障害の影響で、同行が持つATM約5900台のうち4318台が一時取引できない状態に。ATMに挿入したまま戻ってこなくなった通帳やキャッシュカードは5244枚あったという。 障害の原因となったシステムの過負荷はなぜ起きたのか。そして、なぜATMにトラブルが波及したのか。藤原頭取は、「今回の障害は想定の甘さに起因するもの」と説明する。会見の質疑応答から、システム障害の全貌が垣間見えた。 データ更新と月末処理がバッティング みずほ銀は27日、1年以上動いていない定期預金口座のステータスを「不稼働」に変更するデータ更新作業を行っていた。処理したデータは45万件。この作業を行うにはシステムに十分なデータの空き容量が必要だという。 同行は事前のテスト環境でシステム
Amazon Web Services(AWS)は、開催中のオンラインイベント「AWS re:Invent 2020」で、アプリケーションに対してクラウド障害のシミュレーションを行える新サービス「AWS Fault Injection Simulator」を発表しました。 クラウド上で稼働するアプリケーションの耐障害性などを高めるために実際にクラウド障害をわざと発生させて問題点をあぶりだす手法は、「Chaos Enginieering(カオスエンジニアリング)」と呼ばれています。 Netflixが2012年にカオスエンジニアリングのためのツール「Chaos Monkey」を公開したことで広く知られるようになりました。 参考:サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 今回発表された「AWS Faul
米Googleの「Workspace」を含む同社の多くのサービスが12月14日の午後9時ごろから約45分間使えなくなっていた障害の原因は、各種サービスにログインするための認証ツールのストレージクォータの問題だったと、Googleが同日、英Guardianなどのメディアに声明文を送った。 Googleの広報担当者によると、このダウンの原因は、Googleとサードパーティのサービスへのログイン方法を管理する認証ツールの障害だったという。認証を処理するサービスのためのストレージが不足すると自動的に割当を増やす(ストレージクォータ)ツールが正常に動作しなかった。 この問題により、GmailやGoogleカレンダーなど、利用するためにログインが必要なサービスが利用できなくなった。また、Googleの認証プラットフォームを利用するサードパーティのサービスでも、ユーザーがログインできなくなっていた。Go
ローソンは2020年春、プライベートブランド商品のロゴ・パッケージを刷新した。これまでの「ローソンセレクト」を「L basic(エル ベーシック)」「L marche(エル マルシェ)」の2つのブランドに一新したという。手掛けたのは国内外で幅広いクリエイティブを行うデザインオフィスnendoだ。 確かにデザインは美しい。しかし店頭に並んだ商品を見ると、統一感はあるが何の商品だかわかりづらい。Twitterでも「前のデザインの方がわかりやすかった」という消費者の声が目立つ。 筆者の和久井は、ライターと並行して合同会社ブラインドライターズという、視覚障害者を中心とした会社を運営している。スタッフには、中心視野が欠けていて焦点が合わない人、全体的にぼやけて見える人、トイレットペーパーの芯から物を覗いているように見える視野の狭い人など、さまざまな視覚の状態の人がいる。彼らにも見てもらったが、「非常
NTTデータ子会社のクラウドが壊滅、ストレージのバグで戸籍や税務などのデータ全消失 1 名前:ベスタ(茸) [US]:2019/12/05(木) 17:18:57.47 ID:yztuQHN80 日本電子計算株式会社(通称:JIP)とは、NTTデータの子会社、いわゆる「デー子」である。 概要 1962年に日本証券金融株式会社の電算室が独立し「日本電子計算」として分社化するかたちで設立された。 2012年にNTTデータにより公開買付(TOB)が行われ約100億円で買収された。 この買収は「NTTデータは銀行業には強いが証券業には弱い」というのを補うためだとしている。 2019年12月4日午前11時ごろ、同社が運営するクラウドサービスが吹っ飛び、その上で動く全国の自治体システムも吹っ飛び、全国約50の自治体で戸籍管理や税務処理、医療保険、図書館などのデータが消失した。 2019年12月4日午後
by Bethany Drouin 日本では2019年8月23日(金)、Amazonが提供するクラウドサービス「アマゾン・ウェブ・サービス(AWS)」に大規模な障害が発生し、多数のサービスやウェブサイトなどが影響を受けました。これに引き続き、アメリカでも8月31日(土)に同様の障害が発生し、顧客のデータが損失するという事態が発生していることが分かりました。 AWS celebrates Labor Day weekend by roasting customer data in US-East-1 BBQ • The Register https://www.theregister.co.uk/2019/09/04/aws_power_outage_data_loss/ 2019年8月23日にAWSの東京リージョンで発生した障害についてAmazonは、「空調設備の管理システム障害が原因」だ
米アマゾン ウェブ サービス(Amazon Web Services)は2019年8月23日に発生したクラウドサービス「Amazon Web Services(AWS)」東京リージョンの大規模障害に関して同月28日、新しい報告をWebサイトに掲示した。障害が発生したサービスを追加したほか、利用企業が複数のアベイラビリティーゾーン(独立性の高いデータセンター群、AZ)横断の冗長構成にしたシステムにも一部で障害(予期せぬ影響)があったと認めた。 障害が発生していたサービスとして追加したのは日経 xTECHの既報の通り、アプリケーションロードバランサーの「Amazon ALB」、インメモリーキャッシュの「Amazon ElastiCache」、データウエアハウスの「Amazon Redshift」、仮想デスクトップの「Amazon Workspaces」などだ。仮想マシンの「Amazon EC2
2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご
2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間(EC2) 約6時間 2019年8月23日 12時36分頃~18時30分頃(大部分の復旧) 障害発生時間(RDS) 約9時間半 2019年8月23日 12時36分頃~22時5分頃 障害原因(EC2) 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン(AP-NORTHEAST-1)の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊4データセンター群の内、1つで発生。 日本国内のAWSの契約先は数十万件とみられる。*
Slackが11月1日に起こした大規模障害は、同社内でデプロイしたソフトウェアが原因だと報告された。全ユーザーがSlackに接続できなくなる障害は2時間以上続き、その後復旧された。その概要と時系列を公開された報告書から追う。 オンラインチャットサービスを提供するSlackは、日本時間で11月1日の朝から数時間、全ユーザーが接続できなくなるという大規模な障害を起こしています。 11月4日には、同社のStatusページに障害発生に関するまとめが掲載されました。それによると、障害の原因は同社内で行われていた定期デプロイによってサーバにデプロイされたソフトウェアの障害とのことです。 ただしそれがどのような障害であったのか、詳細については現時点では紹介されていません。 全ユーザーがSlackに接続できなくなり、復旧に向けサーバ増強 障害報告の前半は、概要がまとめられています。後述の詳細によると、同社
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く