日本時間6月13日午前2時52分から約2時間半、CloudflareはキーバリューストアのWorkers KVやCloudflareダッシュボードの一部を含む同社の重要なサービスに影響を与える重大なサービス障害を起こしています。 Cloudflareは今回の障害について、ブログ記事「2025年6月12日、Cloudflareサービス障害」を公開し、その状況や影響範囲、原因などについて次のように説明しました。 2025年6月12日、Cloudflareは、Workers KV、WARP、Access、Gateway、Images、Stream、Workers AI、Turnstile、Challenges、AutoRAG、Zaraz、およびCloudflareダッシュボードの一部を含む重要なサービスに影響を与える重大なサービス障害を経験しました。 この障害は2時間28分間続き、影響を受けたサ
はじめに こんにちは、ニコニコ生放送 バックエンド開発マネージャーの yanagi です。 2024 年 6 月 8 日、ドワンゴはランサムウェアを含む大規模なサイバー攻撃を受け、「ニコニコ」全サービスの停止を余儀なくされました。もちろんニコニコ生放送も例外ではなく、2024 年 8 月 5 日にサービスを再開するまでの約 2 ヶ月もの間、その影響を受ける形となりました。 この記事は、サイバー攻撃を受けたニコニコ生放送がサービスを再開するまでの道のりを記録したものです。 今回の復旧作業から学んだ教訓は、「日頃の実践・鍛錬が重要」ということです。今回のような状況においても、物事への取り組み方は日頃からニコニコ生放送内で実践されているものと大きく変わりありませんでした。 ありのままに言えば、ニコニコ生放送には今回のようなできごとを想定した訓練や対応体制は備わっていませんでした。今までに経験した
長年やろうやろうと思ってできていないことの一つに、障害対応訓練がある。 今回はその訓練をChatGPT上でやってみたという話。 もちろん、Claudeなどの他の対話型生成AIサービスでもできるはず。 障害対応は実際にやらないとできるようにならない #Webサービスなどのシステムを運用している場合、避けては通れないものとして 障害 がある。 負荷の増加やシステムの変更、オペレーションミスなどで発生するこれらの障害は、 程度にもよるが少なからずシステムの運用に支障をきたすため、迅速に解消する必要がある。 いわゆる 「障害対応」 である。 障害発生時には、まず何が起こっているのかを把握する必要がある。 各種ログやメトリクスから原因となっている箇所を特定し、解消・緩和するための変更を行う。 原因は場合によって様々で、アプリケーションの不具合であることもあるし、 ネットワークなどプラットフォームに近
AWS東京リージョンで約1時間続いた障害、原因は主電源と二次電源が遮断されたことが原因。AWSが明らかに 一昨日（2025年4月15日）、Amazon Web Services（AWS）の東京リージョン（AP-NORTHEAST-1リージョン）のアベイラビリティゾーン（apne1-az4）において日本時間午後4時40分頃から約1時間続いた障害は、主電源と二次電源が遮断されたことが原因だとAWSが明らかにしました。 4つのアベイラビリティゾーンの1つで障害発生 AWS東京リージョンは、「アベイラビリティゾーン」と呼ばれる独立した4つのデータセンターを備えています。 各アベイラビリティゾーンはそれぞれが独自の電源とインターネットへの接続を備えつつ、高速なネットワークで相互に接続されています。これにより、万が一あるアベイラビリティゾーンが自然災害や障害などで使用不能になったとしても、その影響を他
先日起きた tj-actions や reviewdog のセキュリティインシデントのレポートを読みました。 その内容を個人的な検証結果や感想を挟みつつかいつまんで書きたいと思います。 詳細は原文を読んでください。 なお、侵害された repository 及び tag は全て修正され、盗まれた Personal Access Token (PAT) も revoke されているはずです。 攻撃の流れ tj-actions/changed-files が侵害されるまでに複数の PAT の流出及びリポジトリの侵害が連鎖的に起こっています。 つまり tj-actions/changed-files が直接的にいきなり侵害されたというより、複数のリポジトリをいわば踏み台のようにして侵害したという感じでしょうか。 攻撃者は PAT が盗まれたりした GitHub Account とは別に複数の Gi
TOPインタビュー障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】 障害対応を属人化させない。「全員インシデントコマンダー」体制を根付かせた、山本五十六の格言【NewsPicks SRE 安藤裕紀】 2024年8月26日 ユーザベース NewsPicks事業 SREチームリーダー 安藤 裕紀 大手SIerで10年半エンジニア/アーキテクトとしてアプリケーション開発、インフラ構築、クラウド活用コンサルティングなど大企業の技術支援を行った後、2021年10月に株式会社ユーザベースに入社。プロダクト開発組織のSREチームでインフラや開発基盤を担当。シニアエンジニア、テックリードを経て、チームリーダーに。2024年からはプラットフォームエンジニアリングのグループマネージャーも兼務。 X Docswell GitHub
GitHubは日本時間8月15日午前8時2分（世界協定時8月14日23時2分）から8時38分までの約30分のあいだ、全てのサービスがアクセス不能となる障害が発生していたことを報告しました。 障害の原因はデータベースの設定変更ミスでした。設定変更に間違いがありGitHub内の重要なサービスがデータベースに接続できなくなったことで障害が発生。設定を元に戻すことで復旧されました。 GitHub.comの全データベースに誤った設定変更 報告の内容を時系列で見ていきましょう。 障害発生の3分前。日本時間8月15日午7時59分に、GitHub.comの全データベースに対して誤った設定変更が行われ、ルーティングサービスから送出されるヘルスチェック用のPingに応答する機能に影響がでました。 その結果、ルーティングサービスはアプリケーショントラフィックのルーティング先とすべき稼働中のデータベースが検出でき
平素よりNatureの商品・サービスをご利用いただき、誠にありがとうございます。 先日、2024年7月8日22:00より発生しましたシステム障害の原因と、再発防止および障害発生時の影響を最小限に抑えるための取り組みについてご報告いたします。 発生した事象と原因 今回のシステム障害は、Natureサーバー上のデータベースに対する書き込みリクエストが一時的に急増し、想定していたキャパシティを超えたため、書き込みリクエストにかかる時間が大幅に延びる事象が発生しました。 この結果、APIサーバーがダウンし、Nature Remoとサーバー間の通信を適切に処理できず、Nature Homeアプリからの操作ができない状態になりました。 その後大量のNature Remoからの再接続が発生しシステム全体に障害の影響が広がったことから、原因の特定と対処に時間がかかり長時間に及ぶ障害となりました。 今後の対
Google Cloudは、同クラウドユーザーであるオーストラリアの年金基金「UniSuper」で発生した大規模障害の原因について報告する記事「Sharing details on a recent incident impacting one of our customers」を公開しました。 今月（2024年5月）初旬、Google Cloud上で稼働していた数百の仮想マシン、データベース、アプリケーションを含むUniSuperのプライベートクラウドが突如として原因不明のまま削除され、復旧されるまでの数日にわたってシステムが利用できなくなるという大規模障害が発生しました。 今回の報告では、実際になぜこのような大規模障害が発生したのか、その原因と復旧の経緯について明らかにされています。その概要を紹介しましょう。 Google Cloud VMware Engineの設定を間違う UniS
Update 7.05.2024 The S3 team is working on a fix: https://twitter.com/jeffbarr/status/1785386554372042890 Imagine you create an empty, private AWS S3 bucket in a region of your preference. What will your AWS bill be the next morning? A few weeks ago, I began working on a PoC of a document indexing system for my client. I created a single S3 bucket in the eu-west-1 region and uploaded some files th
2024年の神奈川県立高校入試出願システムの不具合の影響を受け、@gmail.comのメールアドレス を利用出来なかった一利用者として、 インターネットから参照可能な範囲で、出願システムのメール環境について調査。 被疑箇所の推定と、状況を改善する対策について検討する機会がありましたので、紹介させて頂きます。 神奈川県公立高等学校入学者選抜インターネット出願システムの稼動状況について MX設定 「mail.shutsugankanagawa.jp」のMXレコードを確認しました。 1/18(21時) $ dig mx mail.shutsugankanagawa.jp +short 10 ec2-13-113-157-93.ap-northeast-1.compute.amazonaws.com. 10 ec2-52-193-62-66.ap-northeast-1.compute.amazo
PagerDuty Advent Calendarの8日目！ 今日はOps Guidesのお話です。 うちはこうだけど、他はどうやってるんだろう？ 普段から運用に関わっていると、ふとした瞬間に「そういえば他の会社ではどういう運用をやっているんだろう？」と気になること、ありませんか？ そのきっかけは「本当になんとなく」といったものから「上手くいかない運用にフラストレーションが溜まって」というどす黒いものまで色々あると思いますが、いずれにせよ「他の会社の良いところを取り入れて、自分たちの運用を改善したい」という気持ちから来ているのは間違いないでしょう。 だからこそ、いろんなミートアップに参加して発表を聞いたり、懇親会で話してみたり、Xに垂れ流されているいろんなポストを読んで事例を学ぶわけです。 ベストプラクティスを学びたい! このような取り組みはとても良いことですし、是非とも継続して情報収集し
そもそも「オンコール」とは「オンコール(On-call)」とは、システム障害をもたらしうる「人による緊急対応が必要なインシデント」に即座に対応するために、インシデント対応者と対応時間をあらかじめ指定し管理する仕組みです。まず、インシデント対応とオンコールの基本についてご紹介します。 1. インシデント対応とは現代の私たちの生活は、ITサービスやシステムに大きく依存しています。例えば、医療システムの停止は人命にかかわる問題であり、ITサービスやシステムの安定した稼働や早急な障害対応は社会課題の一つとなっています。そんな「システム障害の予防と対応」において重要なのが、インシデント対応です。PagerDutyでは、インシデントを「システム障害に際して何らかの対応が必要な問題」と定義しています。早期にインシデント対応はシステム障害を未然に防ぐことに繋がります。また、適切なインシデント管理はシステム
Cloudflare、Workers KVの更新に失敗し障害発生。しかも復旧用ツールがWorkers KVに依存しており使えず、手動で緊急対応 Cloudflareは10月30日、同社がキーバリューストアとして提供しているWorkers KVの社内アップデート作業に失敗したことで、Workers KVのみならずCloudflare Pages、Cloudflare Access、Cloudflare Workers、Waiting Room、Cloudflare Dashboardなど各種サービスが世界協定時2023年10月30日19時54分（日本時間10月31日4時54分）頃から約37分間、サービスの一部または全部の機能が使えないなどの障害を起こしました。 幸いにも比較的短時間で復旧した障害でしたが、同社の報告によると、復旧のための社内ツールそのものがWorkers KVに依存していたた
登壇＆参加記事です 今までのあらすじ（ずっとアラートの話してる気がする） 今回の発表まわりの蛇足 セッション ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜 LINEスタンプのSREing事例集：大量のスパイクアクセスを捌くためのSREing エンジニアのためのSRE論文への招待 【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜 ブルームバーグのセントラル・テレメトリー・システムが業務にもたらす価値 開発者とともに作る Site Reliability Engineering 信頼性目標とシステムアーキテクチャー セッション以外 今後について 今までのあらすじ（ずっとアラートの話してる気がする） 2020 dasalog.hatenablog.jp 2022 dasalog.hatenablog.jp 開発者とともに作る
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
30; }, handleResize() { if (window.innerWidth >= 1024) { this.mobileOpen = false; this.dropdownOpen = 'none'; } }, checkAnnouncementBanner() { const announcementBanner = document.querySelector('.announcement-banner') || document.querySelector('.announcement-banner--large'); if (announcementBanner) { this.hasAnnouncementBanner = true; } else { this.hasAnnouncementBanner = false; } } }" x-init="chec
yapcjapan.org YAPC::Kyoto 2023で登壇してきました！これまでオフラインイベントで登壇といえば少人数でのイベントくらいでこの規模で話すのは初だったので緊張してましたが始まってしまえばとても楽しめて話せてとても良い機会になりました！ありがとうございます！ほぼ満席(多分)で発表後の質問やTwitterでも反響があってとても嬉しかったです。トレーニングなどのコスト周りの内容はもう少し補足が必要だったなと思ったのでブログなり資料修正をして追記しようかなと思います。 speakerdeck.com セッションもとても刺さるものが多くて学びや今後のやる気に繋がるものが多くてよかったです。(詳細については会社のテックブログに記載しようかなと思います。)。懇親会ではネットの向こう側だった方と多く話す機会を得ることができ場を作って頂いたHelpfeelさんにはとても感謝です。 その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
