一部のMVNOで19日午前に通話発信できない事象、原因は電話中継業者の障害
中田の質問箱です
みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、
「コープデリ」障害で食材配送できず 物流システム切り替えに失敗
食材などを宅配するサービス「コープデリ」の物流システムにトラブルがあり、5月10日～14日配送分がほとんど届けられない問題が発生した。システム切り替え時に複数のエラーが発生し、復旧が間に合わなかったという。顧客には返金する。 コープデリは、顧客が事前に注文した商品を、指定日に届けるサービスだ。 今回障害が起きたのは、コープデリ連合会に所属する「コープみらい」（首都圏）、「コープぐんま」（群馬県）、「コープにいがた」（新潟県）など。 連合会によると、旧来の物流システムが老朽化したため新システムを構築し、テストを繰り返した上で5月10日配送分から本番に移行したが、複数のエラーが発生。改修を急いだが、顧客に届ける商品のリスト作成が配送日までに間に合わず、配送を断念したという。 配送できなかった商品は、次週以降に回したり、店舗で販売したり、フードバンクに寄付したりするという。 【訂正：2021年5
AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい
前にも似たようなこと書いたなと思ったけどもう一年半も前のことになるのか t-cyrill.hatenablog.jp ご存知の通り昨日 2021/02/19 23:20頃 AWSにて東京リージョンの一つ apne-az1 にて大規模な障害が発生。多くのAWSを利用していたサービスで影響があった。 そんな私はいつものように アラストリリィ アサルトリリィ ラストバレット というゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。 どうしたんだろうと思っていたら、社内SlackにてAWSを利用しているサービスがたまに応答しなくなる、Elasticacheが切り替わったなどなどの報告が入り、もしかすると面倒ごとかなと思いながら対応することになった。 起きていたこと 既にAWSからも公開されていることであるが、今回は2019年8月に起きた障害と類似するタイプの障害だっ
RFC7938 - 大規模データセンター内でのルーティングのためのBGPの利用方法 - show log @yuyarin
はじめに この文書は RFC7938 - Use of BGP for Routing in Large-Scale Data Centers の日本語訳です。 翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。 免責 いつものやつ 目次 はじめに 免責 目次 概要 1. 導入 2. ネットワーク設計の要件 2.1 帯域とトラフィックのパターン 2.2 CAPEXの最小化 2.3 OPEXの最小化 2.4 トラフィックエンジニアリング 2.5 要件の要約 3. データセンタートポロジーの概要 3.1 従来のDCトポロジー 3.2 Closネットワークトポロジー
2020年9月26日CloudFront障害中のアクセスログを調査してみた | DevelopersIO
AWSチームのすずきです。 2020年9月26日(土)、 日本時間 PM 5:55 から PM 6:45 の間、日本のCloudFrontのエッジロケーションで断続的にエラーが発生していた件について、 CloudFrontのアクセスログを元に調査する機会がありましたので、紹介させて頂きます。 弊社ポータルのお知らせ 日本時間2020年9月27日(日) 5:47:45 CloudFront お知らせ 日本のエッジロケーションでエラーが上昇しておりました。| Elevated Errors from one of our edge... https://t.co/5qSz7x59vV — AWS障害情報(全リージョン) (@awsstatusjp_all) September 26, 2020 Athena(抽出) 国内に存在するエッジロケーションと推測されるアクセスログを Athenaで抽出
システム障害対応演習を実施した話｜NAVITIME_Tech
こんにちは、ネコ派メタラーです。ナビタイムジャパンで地点検索基盤の開発マネジメントを担当しています。好きなバンドは Arch Enemy です。 システム運用に関わる人であれば、「システム障害」というと耳が痛い方が多いかと思います。システム障害は起こさないに越したことはないですが、万が一システム障害が発生したとき、その行動選択はサービスの信頼性を大きく左右することになります。 迅速に復旧させることはもちろんですが、適切な情報公開によってユーザーの不安を払拭するといったコミュニケーションも重要なポイントです。しかし、緊急事態というプレッシャーを受けながら最適な行動を選択することは容易ではありません。 私が所属しているチームでは、Web API サーバソフトウェアから全文検索ミドルウェアまで含めた開発・運用を行っており、幅広いトラブル対応スキルが必要になります。トラブル対応のスキルを持ったベテ
障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳
先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g
パッチ盤からケーブルを引っこ抜いてしまい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
Google Cloudの主要サービスが10時間ものあいだ障害発生。原因は分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足
Google Cloudの主要サービスが10時間ものあいだ障害発生。原因は分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足 Google Cloudは、米国太平洋時間の3月26日木曜日16時50分（日本時間27日金曜日 午前8時50分）頃から約10時間ほどのあいだ、Google Compute EngineやCloud Storage、Cloud SQLなどをはじめとする主要なサービスで障害を起こしていました。 受けた影響はリージョンごとに異なりますが、ほぼすべてのリージョンで何らかの影響を受けたようです。 Googleはその原因についての調査結果を発表。原因はGoogle Cloud内部でアクセスコントロールを司る部分に障害が発生したことだったと説明しました。 アイデンティティマネジメントへの大量の更新要求がキャッシュサーバの障害に クラウド内部では、APIへのアクセス
EC2 インスタンスの障害調査依頼を受けた時に確認していること | DevelopersIO
記事を書こうと思ったきっかけ サポートへの問い合わせで一番多いのが "EC2 インスタンスの障害調査依頼" だから 「サーバはペットではなく畜牛のように扱え」というフレーズがあるように、クラウドではインフラがいつも変化するという前提でシステムを設計するのがよいとされています。そのため、EC2 インスタンスが障害でホストダウンしてもサービスが継続できるように設計されていればいいのですが、アプリケーションの要件や環境によっては単体の EC2 インスタンスで運用されることもあるようです。 そのため、EC2 インスタンスの障害調査依頼をいただく際は緊急度が高い場合が多くあります。テクニカルサポートとして、私が障害調査依頼があった際に実施している内容を公開することで、迅速な障害の切り分けや復旧につながればと思い書きました。 前提 EC2（Linux）を想定して書いています AWS マネジメントコンソ
無停電機能を外したまま電源設備を更新、楽天などに影響した九電系データセンター障害の原因判明
九州電力の通信子会社QTnet（福岡市）のデータセンターで障害が発生した問題について、2019年11月26日に停電の原因が判明した。11月23日朝、電源設備の更新作業中に通常時の電源が遮断したことで予備電源に切り替わったが、電源の切り替え時に作動する無停電機能を外して作業していた。その結果、7秒間ほど電源が停止し、利用各社のシステム障害につながった。 今回の障害で、事業継続を安定させる目的で使うはずのデータセンターに、想定外の盲点があると明らかになった格好だ。QTnetによると、影響を受けた約260の企業・自治体の中で、2019年11月26日10時時点で22社が復旧できていないという。 今回の障害の影響で、クレジットカードの楽天カードやスマホQR決済の楽天ペイが11月23日朝に利用できなくなった。楽天ペイは11月25日朝に一時的に使えなくなったり、楽天カードは現在も一部機能が利用できなかっ
完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか？ まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
TwilioのRedisによる決済サービスの障害、2つの原因 - unknownplace.org
Twilio というサービスで決済サービスの障害があったらしいが、恐しいことにこのサービス、 決済情報をRedisで管理していたらしい、というのをRedis作者、antirez氏のblogで知った。 Twilio incident and Redis - Antirez weblog この件に関しては、Twilio自体も 調査報告 を出している。簡単にまとめるとこういう感じだ: TwilioではRedisを single-master, multi-slave なレプリケーション環境で使用している ネットワーク障害で一時的に master-slave 間の接続が切れたことにより、master-slave間のデータの再同期が発生 この再同期がすべてのslaveに対して同時に発生したため、masterの負荷が高くなり、結果決済サービスの障害が発生 この負荷を解決するためmasterを再起動する
データセンター移転とDRBD - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。今回は去る 5 月から 6 月にかけて行った、cybozu.com のデータセンター移転作業について、失敗してしまったことを中心に解説します。 失敗と書いたのは、移転作業中に何度か、一部のお客様環境でストレージ高負荷による障害を起こしてしまったためです。移転作業自体はスケジュール通り進行し、6 月第二週に完了しています。障害に関しては、こちら（PDF）でお詫びとご報告をしていますが、この記事では技術面ならびに障害を引き起こすにいたった背景について詳述します。 移転に至った背景 移転方式の検討 ストレージ同期の方法 DRBD による同期の詳細 まずは自社環境を移転、成功 そして障害は発生した なぜ障害につながったのか まとめ 移転に至った背景 まず、なぜデータセンターを移転することにしたかを説明します。 端的に言うと、当時のデータセンターが手狭になり拡張
うるう秒によるjava障害と連動して生じたHDFSメタデータ破損からの復帰手順 - 生物物理計算化学者の雛
※本記事ではうるう秒によるjavaの異常と、それに伴って生じたHadoop 0.21.0 HDFSのメタデータ破損からの復旧手順を説明します。なお、本復旧手順は私の環境で上手くいっただけであり、他の環境で同様の手順を行ったとしても復旧できる保証はありませんので、ご注意ください。 昨日（2012/7/1）Hadoopクラスタの一部マシンでCPU負荷が突然MAXに張り付いていることに気付きました。 今日になってこの現象はうるう秒のあとにjavaに生じた不具合であることが分かりました（参考：http://d.hatena.ne.jp/sh2/20120702、このブログの記述と同様にjavaとksoftirqdプログラムが大きなCPU負荷を占め続けていました）。 この障害が起きていたのはOSがfedora10, 13のマシン群で、他のマシンはCentOSであり不具合無く動作していました。 試行錯
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
図で技術的に何が起きたかを解説 スマホゲーム『偽りのアリス』の不具合報告がやたら丁寧と話題に「BtoBみたいな報告で草」「なんだこの説明量は」