2022年7月2日に発生した通信障害について
KDDI株式会社 2022年7月29日 KDDIは、2022年7月2日午前1時35分から発生した通信障害 (以下 本障害) に際し、KDDIの通信サービスをご利用の全国のお客さまに、長時間にわたり多大なご不便とご迷惑をお掛けしましたことを、深くお詫び申し上げます。 社会インフラを支え安定したサービスを提供しなければならない通信事業者として、今回このような事象を発生させたことを重く受け止めています。 KDDIは、再発防止策の徹底を図り、サービスの安定的な運用に向けて全力をあげて取り組んでいきます。 なお、2022年7月28日に総務省へ本障害に関して報告しています。 2022年7月29日に発表しました本障害の原因や再発防止策などについては、こちら (1.2MB) からご覧いただけます。 ニュースリリースに記載された情報は、発表日現在のものです。 商品・サービスの料金、サービス内容・仕様、お問い
KDDIの通話・通信障害メモ - show log @yuyarin
この記事は7/3午前中に記載したもので、まだKDDI社長の会見内容を反映していません。 今回のKDDIの障害が具体的にどういうサービスに影響が出るのものか、モバイルネットワーク初心者としてLTE/EPC/IMS周りの挙動の勉強のためにまとめてみた。 はじめにまとめ モバイルの通信には音声通話とデータ通信があり、今回主に長時間の障害を受けたのは音声通話(IMS)の方だった。 7/2(土)の日中帯はデータ通信はできるが音声通話やそれに付属するサービスが利用できない状態が継続していた。データ通信も不安定な状態になっていた。 端末の実装(主にAndroid端末)によっては音声通話ができないとデータ通信も止めてしまう挙動があった。これによりLTEを回線として使用しAndroidベースで構築された決済システムなどが利用不可能な状態が継続した。 音声通話(IMS)が利用できないと、通常の電話はもちろん、
もしあなたが東証のCIOだったらどうした？ 〜あの記者会見から学ぶインシデントレスポンスのスキル〜 - 一般社団法人 日本CTO協会
日本CTO協会は「技術」を軸に規模や業種の異なる様々な人や組織が集まっているコミュニティです。会員は本社団の活動内容、調査テーマについて参加、提案し、他の技術者・技術組織とともに成長する機会が得られます。ご興味のある方は法人会員向け申し込みフォームからお問い合わせください。 2020年10月1日夕方に行われた東京証券取引所の記者会見（フル動画）を皆さんはご覧になりましたか？記者会見には宮原幸一郎社長、日本取引所グループ（JPX）の横山隆介・最高情報責任者（CIO）、東証の川井洋毅執行役員、田村康彦IT開発部トレーディングシステム部長が出席し、システム障害による同日の終日売買停止について説明がされました（公式記者会見要旨・資料）。この記者会見に関してエンジニアから称賛の声が多く上がっており、今回は特別に日本CTO協会理事兼GMOペパボ株式会社取締役CTOの栗林健太郎さん（@kentaro）に
Webアプリケーションの障害対応について改めて意識すべき点ややれると良いことをまとめる - stefafafan の fa は3つです
Webアプリケーションエンジニアをやっていると時たま障害が発生し復旧作業にあたるのだが、人によって「障害対応が得意」だったり「苦手」だったりする。ただ、障害対応時の「良い動き」というのが実際どういうものなのかというのが自分の中でふんわりしていたので、ざっくりはてブで「障害対応」で検索していくつかのエントリーを読んでみたり、自分の仕事での経験を振り返ってみたりして考えたことをまとめてみた。 障害にはフェーズがある 障害対応には複数の役割がある 障害対応をスムーズに進めるための目的は複数ある スキルも必要なので練習していけると良い 初心者でもやれることはある 実際やってみると良さそうなこと 障害対応時にやることをテンプレート化する スムーズに対応に入れる仕組みを整える 障害対応避難訓練 おわり 障害にはフェーズがある 障害対応したことないと、障害には「障害中」「障害中でない」の二つの状態しかな
Webサービスの障害対応のときの思考過程 - ぱいぱいにっき
起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター
NTTデータ子会社のクラウドが壊滅、ストレージのバグで戸籍や税務などのデータ全消失 : 痛いニュース(ﾉ∀`)
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日午後
さよなら本番サーバー - Qiita
とあるSESの現場では本番リリースの時期が近づいてきており、僕を含めた数人のエンジニアは間に合いそうもない残作業の開発を進めたり、本番で使うためのデータの整備を本番サーバー内で行ったりしていた。ほとんどがその案件のために集められたメンバーだったため特に和気あいあいとするでもなく、エアコンの風の音が響く小さなオフィスの片隅で静かに作業をしていた。 業務上のやりとりもRedmineで行われており、声を発するのもたまにメンバー同士で話をしたり、クライアントから電話がかかってきた時だけ。その日もメールで通知が届いてきており、確認してみるとRedmineで僕が関係しているチケットにコメントが届いているという通知だった。 通知のURLをクリックしてRedmineのチケットを確認してみる。 それによると一旦本番サーバー上に存在するデータの中の一部の主要データをCSV形式で送ってほしいという依頼だった。無
いつものように本番作業してたはずなのに - Qiita
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景（前提条件） いっていに昔の話です ETL（データ加工）サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた 性能や本番相当データのテストが安全に行えるような環境
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) の単一のアベイラビリティゾーンで、オーバーヒートにより一
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告
SREによる構成変更がGmailなど広範囲な障害の引き金に。3月13日に発生した障害についてGoogleが報告 3月13日の11時53分から15時13分（いずれも日本時間）までの3時間20分のあいだ、GmailやGoogle Drive、Google Photos、Google Storage、App EngineのBlobstore APIなどGoogleの広範囲なサービスで一部の機能が利用できなくなる、あるいは遅延が発生するなどの障害が発生しました。 その原因と対策について、Googleが「Google Cloud Status Dashboardのインシデント#19002」として報告しています。 報告では障害の原因が、ストレージ内のリソースを削減しようとしたSRE（Site Reliability Engineer）による構成変更にあったと説明。 SRE（Site Reliabili
システム障害との向き合い方 @sinamon129 #tokyogirlsrb
これまで大小様々なシステム障害に遭遇してきましたが、障害対応から学ぶことは沢山あります。 いろんな習熟度のフェーズで障害発生を学びに変えるための行動事例や、webアプリケーション開発において障害対応を減らすためにできることなどをお話しできればと思います。 TokyoGirls.rb Meetup vol.1 https://techplay.jp/event/716251
ソフトバンク大規模通信障害の原因:Geekなぺーじ
2018年12月6日、ソフトバンクのネットワークにおいて、4時間25分にわたり約3060万回線の利用者に影響を及ぼす通信障害が発生しました。 ソフトバンクおよびワイモバイルの4G(LTE)携帯電話サービス、「おうちのでんわ」、Softbank Air、3Gサービスなどが影響を受けました。 この障害は、EricssonのMME内部にハードコーディングされた証明書が期限切れになったため、SGSN-MME(Serving GPRS Support Nodex - Mobility Management Entity)が再起動を繰り返してしまったのが原因です。 ただ、証明書が期限切れになることで、なぜ大規模な通信障害に繋がってしまうのかが良くわかりませんでした。 どのような設計をしたら、証明書が期限切れになったことで通信機器が再起動を繰り返すような状況になるのか、昨年段階では、いまいち理解できなか
Slack、11月1日に発生した大規模障害の原因は、定期デプロイによるソフトウェア障害が原因
Slackが11月1日に起こした大規模障害は、同社内でデプロイしたソフトウェアが原因だと報告された。全ユーザーがSlackに接続できなくなる障害は2時間以上続き、その後復旧された。その概要と時系列を公開された報告書から追う。 オンラインチャットサービスを提供するSlackは、日本時間で11月1日の朝から数時間、全ユーザーが接続できなくなるという大規模な障害を起こしています。 11月4日には、同社のStatusページに障害発生に関するまとめが掲載されました。それによると、障害の原因は同社内で行われていた定期デプロイによってサーバにデプロイされたソフトウェアの障害とのことです。 ただしそれがどのような障害であったのか、詳細については現時点では紹介されていません。 全ユーザーがSlackに接続できなくなり、復旧に向けサーバ増強 障害報告の前半は、概要がまとめられています。後述の詳細によると、同社
システム移行メンテナンスにおける一部時間帯に更新されたデータが消失した原因のご報告 - Mackerel お知らせ #mackerelio
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
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サーバーがダウン）。今回、弊誌
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート
Google App Engine、全データセンターを巻き込む連鎖的障害で能力半減、復旧のためフルリスタート 「2011年1月にHigh Replication Datastoreを立ち上げて以来、App Engineでこれだけ大規模なシステム障害を経験したことはなかった」。グーグルのGoogle App Engine Blogは10月26日付けのエントリ「About today's App Engine outage」でこう書き、同日発生したApp Engineの障害について報告しました。 この障害は10月26日のおおよそ午前7時半から11時30分までの約4時間、 App Engineのリクエストの約半分が失敗するという大規模なものでした。同社は以下のように経緯を説明しています。 ルータへの負荷が全データセンターへ拡大 4:00 am - Load begins increasing o
株式会社IDCフロンティア
IDCフロンティアのクラウドサービスが政府情報システムのためのセキュリティ評価制度（ISMAP... データセンター 2024年01月10日 【接続先追加】「バーチャルブリッジ」に主要IX事業者などの他事業者接続が追加 データセンター 2024年01月10日 令和6年能登半島地震の影響により、被災された地域のお客さまがご利用中のサービスについて支援措置を実施します。 サービス 2024年01月05日 新年のご挨拶 代表取締役社長 鈴木 勝久 その他 2024年01月04日 1月17日～19日に福岡で開催される「JANOG53 in Hakata」にブース出展します その他 2023年12月20日 ZDNET Japan Business＆IT ClassWork supported by ... その他 2023年12月15日 IDCフロンティア、「AIサービスのためのデジタルインフラ」を
トラブル☆しゅーたーず - ドMな演技派インフラエンジニアたちによる障害対応ごっこ -
＿・） @tsukaman というのは間違いで600でOKだそうです。 RT @tsukaman: Macな人はSSHキーのパーミッションを400にしないとダメだそうです（ニフクラ） #トラしゅ 2012-04-07 11:37:38
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
