上位ISPで発生したとみられる通信障害についてまとめみた - piyolog
2018年10月4日夜にネットワーク上の障害により、サービス継続に支障が生じたと報告する運営元や、同時間帯にWebサイトなどに接続が出来なかったとするユーザーの報告が出ています。ここではこれら情報をまとめます。 尚、piyokangoはこれら複数の障害を結びつける確定的な情報は確認できていません。 障害発生、あるいはその可能性があるサービス 以下のいずれかの条件に基づき、障害が発生、あるいは発生していた可能性があるサービスを調べました。 (1) 障害発生を報告し、上位ISP、あるいは上位ネットワークで発生した障害を理由としてたサービス (2) 公式発表は確認できないが(1)の障害が発生した同時間帯に接続障害が報告されていたサービス 「同時間帯」として9月27日から10月5日に発生、または報告されたものを対象とした。 運営元 対象時間 ソース ノート セガゲームズ 2018年9月27日 13
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickey
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 ファーストサーバが提供しているホスティングサービス「Zenlogic」は、6月下旬から断続的に生じていたストレージ障害に対応するためのメンテナンスが終了の見通しも立たないほど難航し、結局、メンテナンス開始から3日後の夜にようやくサービスが再開されるという事象を起こしました。 参考：ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり） － Publickey サービス再開から約1週間が経過した7月17日、同社はストレージ障害に関する原因およびメンテナンスによるサービス停止が長期化してしまった原因、再発防止策についての報告書を明らかにしました。 報告によると、ストレージ障害の直
Slack、全ユーザーが接続できなくなった大規模障害の原因はバッチ処理にバグがあったためと報告
チャットサービスを提供するSlackは、太平洋夏時間の6月27日午前6時30分（日本時間6月27日午後10時30分）頃から約3時間、全てのユーザーでSlackが利用できなくなる深刻な障害に見舞われました。 同社はその後、障害についての報告をステータスページに掲載。障害の原因が、データのバッチ処理に含まれていたバグであったことを明らかにしました。 同社の報告の一部を引用します。 On June 27th (yesterday) between 6:33 a.m. and 9:49 a.m. PDT Slack experienced an outage where people could not connect to their workspaces. The network problems were caused by a bug included in an offline batc
【6/22報告】5月30日からの断続的な障害につきまして|ニコニコインフォ
ニコニコ各種サービスにおいて、2018年5月30日から2018年6月12日まで、複数回の障害を発生させてしまいました。ご迷惑をおかけして申し訳ありませんでした。 6月12日までに発生した障害について、障害の内容と再発防止策をお知らせします。 ※社内サービス名などの社内用語は一般的な言葉に置き換えています。 5月30日【ユーザーフォロー】ユーザーフォローに失敗する 等 ■ 障害発生時間 2018年5月30日14時30分ごろ ～ 2018年5月30日19時40分ごろ ■ 障害の発生したシステム リレーションデータベース基盤 ■ 障害の影響が波及したシステム ユーザーフォロー基盤, 通知連携基盤 ■ 障害の内容 特定のユーザーによる攻撃的なアクセス（過剰なユーザーフォロー状態の操作）によって、ユーザーフォロー基盤が利用しているリレーションデータベース基盤が過負荷状態に陥りました。 その結果、ユー
NoOpsへ舵を切れ
帰ってきた インフラ野郎 Azureチーム ～Azure データセンターテクノロジー解体新書2018春～ - de:code2018
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Googleが解説 - 他社のSRE実践はなぜ誤りなのか
Zenlogicサポートサイト［IDCフロンティア］
