「au通信障害」KDDI髙橋社長の会見質疑詳報、なにが起きたのか、「ドコモの教訓」は？
みずほ銀行窓口業務ストップの真相、DC切り替えをためらい障害が長期化
みずほ銀行で2021年8月20日、営業店の窓口業務が全面停止するトラブルが発生した。前日の19日午後8時53分ごろに営業店端末と勘定系システムをつなぐサブシステムで、データベース（DB）サーバーがディスク装置の故障をきっかけに停止したためだ。待機系DBサーバーへの切り替えも失敗、副データセンター（DC）に処理を切り替えた。副DCへの切り替えに着手するまで11時間超を要し、業務開始に間に合わなかった。 みずほ銀行で2021年8月20日、全463店舗で営業店端末や店頭のタブレット端末が使用不能になった。午前9時の開店から午前9時45分までは全ての店頭取引ができなくなり、その後も午前11時58分まで融資や外国為替（外為）の一部取引ができなくなった。営業店端末などと勘定系システム「MINORI」をつなぐサブシステム「業務チャネル統合基盤」が前日の8月19日午後8時53分ごろに停止したためだ。 業務
本番環境のローカルデータを全部吹き飛ばしました
インスタンスのひとつ「S512」には、サービスの中でも特に重要な部内SNS「traQ」と部員管理システム「traPortal」、認証基盤「pipeline」がデプロイされています。 ArchLinuxくん... SysAd班では、これらVPSのOSにArchLinuxを採用しており、当時のカーネルバージョンは5.12.3-arch1-1でした（たぶん）。 ArchLinuxはUbuntuやCentOSと異なり、SimplicityやModernityの思想からパッケージのRolling releaseを採用しています。 Simplicity 不必要な追加や修正がないこと オリジナルの開発者（アップストリーム）によってリリースされたソフトウェアを、ディストリビューション（ダウンストリーム）特有の変更を最小限に抑えた状態で出荷する ディストリビューションのQAは最小限で、アップストリームによる
【保存版】東京リージョンの AWS 障害発生時にクラスメソッドのテクニカルサポートチームがやっていること | DevelopersIO
どのような事前準備をしているか 有事の際は想定外のことが発生しやすく、事前準備をしていないと冷静な対応が難しくなります。 いきなりしっかりした事前準備をすることは難しいので、徐々に成熟度を上げていきます。 本章では以下の観点で、事前準備についてご紹介します。 手順書 自動化 訓練 手順書 フローやチェックリストを含む手順書を準備しています。 手順書の内容は後述します。 分かりやすい手順書を準備することも重要ですが、その手順書への導線づくりも大切にしています。 運用周りのドキュメントは数が多く、目的のドキュメントが埋もれてしまい他のメンバーが見つけられない場合があるからです。 周知に加えて、ドキュメントの階層を見直したり、特定チャンネルに手順書の URL をピン留めしておくなど、手順書に辿り着きやすくする工夫をしています。 分かりやすい手順書の書き方については、以下のブログが参考になります。
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず
パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず CDNプロバイダのCloudflareは、世界協定時4月15日の午後3時31分から午後7時52分（日本時間4月午前0時31分から午前4時52分）まで、ダッシュボードおよびAPIが使えなくなるという障害を発生していました。 Cloudflare Dashboard and API Outage on April 15, 2020https://t.co/zJctsOomVf — Cloudflare | #BuiltForThis (@Cloudflare) April 16, 2020 同社のブログ「Cloudflare Dashboard and API Outage on April 15, 2020」によると、同社の2つのコアデータセンターのうちの1
さくらインターネットの障害でデータが消えた話 - Qiita
伝えたいこと『さくらインターネットのVPSはさくらが原因でデータを消すような状況になっても利用者が期待している程の対応してくれない』 （VPS以外は知らない） ということで言いたいこと 『自分が誤った操作をしなくても、いつでもデータを失うリスクが有る。重要なデータをサーバーに置くならバックアップは毎日でも毎時でも足りない。バックアップするシステムの導入が必要。絶対的な安心はない。技術を持っていそうで信用していてもあっさりと事故は起こる』 例えば、さくらインターネットのVPSを借りるなら、いつOSを再インストールしなければならない状況になってもいいように注意して利用しなければならない。 他社は知らない。 バックアップはお客様でお願いしますと規約に書いてあった気はしていました。（未確認） ですが、実際にさくらインターネット側のミスでOSごと起動しなくなっても、さくらインターネットはその修復さえ
大規模障害から見るAWSのバックエンド #awswakaran_tokyo
# 大規模障害から見るAWSのバックエンド #### 2019/09/25 #awswakaran_tokyo ### 株式会社ドリコム インフラストラクチャー部 中村 昴 (@varu3) --- # 自己紹介 - ばるさん - twitter: varu_3 - github: varusan - Blog: https://varu3.hatenablog.com/ - インフラストラクチャー部 - 弊社で運用しているソーシャルゲーム、WEBサービスの主にインフラ部分を管理している部署です - 社内サービス（GitLabやRPMパッケージ） - AWS, GCP, 国内パブリッククラウド, Kubernetesなど --- # 2019年8月23日.... --- # 止まるインスタンス... # 鳴り止まないアラート... # 流速が増すTwitterのTL... # 加熱する報道
AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告
AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告 2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めました。 下記は大規模障害の報告ページです。赤枠で囲った部分が、8月28日付けで追記されました。 当初の報告は、障害の原因が空調装置のバグであり、それが引き金となってサーバーのオーバーヒートが発生したことなどが説明されていました。 そして障害の影響範囲は単一のアベイラビリティゾーンに閉じており、 複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。 と説明されていました。 複数のアベイ
SingleAZ配置のEC2インスタンスで障害発生時の影響を最小化する | DevelopersIO
SingleAZ配置のEC2インスタンスにおいて、障害発生時にどのような対応が取れるのか整理してみました。 西澤です。8/23(金)に東京リージョンにおいて大規模な障害が発生し、多くのシステムが影響を受けました。この障害に際して、可用性を担保する設計の重要性を考えさせられた一方で、切り捨てるものを決め、迅速に復旧し、障害の影響を最小限に抑えることも大切なことだと痛感しました。シングル構成のシステムを運用されていて、復旧に苦労された方も、運良く被害に遭わずに済んだ方も、一緒に考える機会となればと思い、考えたところを残しておきたいと思います。ご意見大歓迎です。 前提 そもそもAWSのベストプラクティスとしては、すべてのシステムはMultiAZで動作するように設計すべきです。では、SingleAZ構成で本番システムを運用することは論外ですか？果たしてそうでしょうか？ 初期コストも運用コストも無限
8/23東京リージョン障害中の当ブログ稼働を紹介します | DevelopersIO
発生原因 ap-northeast-1a(ID:apne1-az4) に設置されたELBのノードが、5XXのエラー応答を戻していました。 暫定対処 ELB(ALB) で利用していたAWS WAFの保護設定を一時的に解除、ELB_5XXエラーが抑制された事を確認しました。 対応経緯 14:20 チャットの通知より、DevloppersIOのブログ基盤から HTTP 5XX の発生している事を確認 14:30 ElasticBeanstalkのダッシュボードの「WARN」イベントより、HTTP 5xx の発生状況を確認 CloudWatchの ALB ダッシュボードより、HTTP 5XX の発生状況を確認 ALBのCloudWatchメトリックより、ELBに起因する「ELB_5XX」エラーである事と、 AZ別のメトリックより ap-northeast-1a(ID:apne1-az4)、アベイア
AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず
AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず 報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。これにより、緊急時の手動操作にも冷却制御システムの一部が反応しないなどでサーバが過熱し、障害に至ったと説明されています。 8月23日午後に約6時間の障害。EC2だけでなくRDSも 報告によると、障害は日本時間2019年8月23日金曜日の昼過ぎに発生。影響範囲は仮想マシンを提供するAmazon EC2とブロックストレージを提供するAmazon EBSのそれぞれ一部。以下、AWSの報告を引用します。 日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一
ソフトバンク大規模通信障害の原因:Geekなぺーじ
2018年12月6日、ソフトバンクのネットワークにおいて、4時間25分にわたり約3060万回線の利用者に影響を及ぼす通信障害が発生しました。 ソフトバンクおよびワイモバイルの4G(LTE)携帯電話サービス、「おうちのでんわ」、Softbank Air、3Gサービスなどが影響を受けました。 この障害は、EricssonのMME内部にハードコーディングされた証明書が期限切れになったため、SGSN-MME(Serving GPRS Support Nodex - Mobility Management Entity)が再起動を繰り返してしまったのが原因です。 ただ、証明書が期限切れになることで、なぜ大規模な通信障害に繋がってしまうのかが良くわかりませんでした。 どのような設計をしたら、証明書が期限切れになったことで通信機器が再起動を繰り返すような状況になるのか、昨年段階では、いまいち理解できなか
Zenlogicの障害から学ぶべきこと - 業務用iOSアプリのfeedtailor社長ブログ
ネット界隈騒然とした今回のZenlogicの障害、ほぼ復旧したようで良かったです。復旧に全力を向けておられたエンジニアの皆さん、大変お疲れ様でした。連日ホント大変だったと思います。 さて、今回の障害で、 Webサイトが見えなくなった！ サーバからデータを取得できない！ メールも使えない！ など、阿鼻叫喚の声が聞かれましたが、他社に移ってハイ終了！もうZenlogicなんて使わない！とか、今回は長かったけど次は大丈夫だろう…と言って終わりにすべきではないでしょう。 落ちたから引っ越す。復旧したから次回は無いことを祈る。それでは何の学びもありません。アプリに必ずバグがあるように、サーバは必ずトラブルものだからです。 利用者として事前にできることは無かったか いつもこう思うんですよね。 弊社では障害に巻き込まれた時、はらいせに解約とか、サーバ引越して完了とか、復旧まで耐えて次回がないことを祈ると
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日
米国東部（バージニア北部、US-EAST-1）リージョンで発生した Amazon S3 サービス障害について
日本時間3月1日未明に米国東部（バージニア北部、US-EAST-1）リージョンにおいて発生いたしましたサービス障害に関する追加情報についてお伝えいたします。 この度、Amazon Simple Storage Service (S3) チームが S3 の請求システムの処理に通常よりも時間がかかるという問題のデバッグを進めておりました。 その過程におきまして、9:37AM PST(日本時間 2:37AM)に、適切に権限を与えられたS3チームメンバーが確立された手順に従い、S3 の請求システムが利用するS3サブシステムを構成する少数のサーバを削除するコマンドを実行いたしましたが、その際、コマンドへの入力が不適切であったため、想定よりも多くのサーバが削除される結果となりました。 今回誤って削除されたサーバは２つのS3サブシステムに関わるもので、１つは、Index（インデックス） サブシステムであ
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時
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン（Google Compute Engineでは「ゾーン」）にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド（IaaS）に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
判明、ANAシステム障害の真相
大型のシステム障害の詳細が見えてきた。全日本空輸（ANA）が2016年3月22日に起こした国内線旅客システム「able-D（エーブルディ、以下では便宜上開発コード名のANACore：アナコアと称す）」のシステム障害では全国49の空港で搭乗手続きができなくなり、ANAと提携航空会社5社の合計で719便、7万2100人以上に影響を及ぼした。インターネットや予約センターでの予約などもできなかった。 ANAは障害発生から8日後の3月30日に経緯や原因を公表、さらに4月11日に弊誌のメール取材に応じ、一段詳しい真相が判明した。 4台のSuperdomeをRACでクラスタリング 今回のシステム障害の中身は3月20日のニュースで報じた通り、4台のデータベース（DB）サーバーが停止したというもの（関連記事：ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン）。今回、弊誌
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
