ニンテンドーシステムズ株式会社のプロジェクト事例「GitHub Actions runnerの運用から見るニンテンドーシステムズのチーム体制」についてご案内しています。
SRE NEXT 2026 発表資料 https://sre-next.dev/2026/schedule/#slot074
しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 / Shibui SRE
SRE Next 2026の登壇資料です
Road to SRE NEXT 2026 @神戸 の登壇資料です。 https://sre-lounge.connpass.com/event/390064/
AnthropicがAI SREの限界を公式認定。「相関関係を因果関係と誤認し続ける」
Anthropicは2026年3月19日のQCon Londonで、ClaudeをSRE（サイト信頼性エンジニア）として活用する試みの限界を公式に報告しました。「相関関係を因果関係と誤認し続ける」という根本的な問題が残存しており、SREの完全代替には至らないと自社が認めた形です。AIにエラーログやアラートを読ませて原因を特定しようとしたことがある方には、直接関係する話です。 何を試みて、何が分かったか AnthropicはClaudeを使ってClaudeのインフラ障害を修復する、いわば「AIがAIを管理する」構成を試みていました。ログやメトリクスを読ませ、警告アラートの原因を特定させ、修復アクションを実行させるという流れです。 結果として明らかになった問題は、警告の表面パターンは認識できるが、障害の根本原因を特定できないという点でした。たとえば「メモリ使用量が急増した後にレスポンスタイムが
こうした領域の相当部分は「観察 → 判断 → アクション」であり、人間が実施すると非常に技術力と経験が求められ、各社 SRE を担当する方に業務が属人化するという現象が発生します。 ここで考えられているのが、AI Agent による支援・自動化と親和性が極めて高いということです。 AI Agent 活用の潮流と SRE 昨今の AI エージェントは、運用データ（メトリック／ログ／イベント）を LLM ベースで要約・推論し、自然言語で対話しながら修復アクションを提案・実行する方向に急速進化しています。Microsoft は Build 2025 で Azure SRE Agent を発表し、インシデント検出から診断、協働復旧に至るプロセスの高速化を狙うソリューションを提示しました。 この発表を見た筆者は、「これでトイルが減る」「SRE の仕事が変わる」「AI が SRE を全部やる時代？」と
長年やろうやろうと思ってできていないことの一つに、障害対応訓練がある。 今回はその訓練をChatGPT上でやってみたという話。 もちろん、Claudeなどの他の対話型生成AIサービスでもできるはず。 障害対応は実際にやらないとできるようにならない #Webサービスなどのシステムを運用している場合、避けては通れないものとして 障害 がある。 負荷の増加やシステムの変更、オペレーションミスなどで発生するこれらの障害は、 程度にもよるが少なからずシステムの運用に支障をきたすため、迅速に解消する必要がある。 いわゆる 「障害対応」 である。 障害発生時には、まず何が起こっているのかを把握する必要がある。 各種ログやメトリクスから原因となっている箇所を特定し、解消・緩和するための変更を行う。 原因は場合によって様々で、アプリケーションの不具合であることもあるし、 ネットワークなどプラットフォームに近
全世界で登録ユーザー数6000万人を超えるカレンダーシェアアプリを展開するTimeTree。同社ではそれら大量のデータを管理するデータベースをAmazon Aurora（以下、Aurora）からGoogle CloudのCloud Spanner（以下、Spanner）に移行した。Spannerを選択した背景、移行プロジェクトがうまくいった秘訣などを、同プロジェクトの立ち上げから携わった技術本部SREチーム マネージャーの金井栄喜（miu）氏とSREチーム バックエンドエンジニアのGreg氏に話を聞いた。 ローンチから10年、世界6000万ユーザーを抱える「TimeTree」 ──自己紹介をお願いします。 金井栄喜氏（以下、金井）：TimeTreeのSREチームのマネージャーとして、チームの醸成やメンバーの育成を担当しています。またスタッフエンジニアという役割も担っており、主にパブリックク
SRE Kaigi 2025で発表した資料です
SRE Kaigi2025のスライドをまとめます。 Hall Re:Define 可用性を支えるモニタリング、パフォーマンス最適化、そしてセキュリティ 可用性とコストのリバランス：テレビ砲の過負荷へ対応した話と増強したリソースを適正化した話 サービスローンチを成功させろ！〜SREが教える30日間の攻略ガイド〜 ブロックチェーンR&D企業におけるSREの実態 信頼性を支えるテレメトリーパイプラインの構築 横断SREの立ち上げと、AWSセキュリティへの取り組みの軌跡 ガバメントクラウドに向けた開発と変化するSRE組織のあり方 2週に1度のビッグバンリリースをデイリーリリース化するまでの苦悩 ~急成長するスタートアップのリアルな裏側~ SREとしてスタッフエンジニアを目指す SplunkとObservabilityを活用したSREの未来：データドリブンなシステム運用 Room A Site Re
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
巻頭言：SRE Magazineを始めました 書いた人：しょっさん（ @syossan27 ） SRE Magazineの発刊についての想いなどを書いてます。 ばばさんがお勧めする「SRE入門」と「SRE入門の入門」に効く書籍や文章 書いた人：ばば/netmarkjp さん（ @netmarkjp ） SRE入門に効く書籍や文章を紹介しています。 非常時の可用性をフィーチャーフラグで保つアイディア 書いた人：iwamot さん（ @iwamot ） アクセス急増などの非常時でも可用性を保つ手法に「緊急レバー」があります。この記事では、緊急レバーの実装にフィーチャーフラグを用いるアイディアを提示します。 SIEMってサイトの信頼性向上に寄与するの？ 書いた人：Yuta Kawasaki（ゆーた）さん（ @yuta_k0911 ） SIEM on Amazon OpenSearch Servi
https://hachiojipm.connpass.com/event/304403/ の発表資料です
問題を解決する能力は確かに重要ですが、それ以上に、何が本当に重要な問題なのかを見極め、それを明確に設定する能力が不可欠です。問いを適切に定義できなければ、どんなに高度な解決技術を持っていても、その力は十分に発揮されません。また、誰にとって適切な問いなのかも考える必要があります。問題解決の過程において、問題そのものの本質を正確に把握し、適切な問いを立てることは重要です。 イシューからはじめよ――知的生産の「シンプルな本質」 作者:安宅和人英治出版Amazon 概要 SREたちの廊下〜あなたの現場での悩み、あの本にヒントがあるかも〜にて「書を捨てよ、現場へ出よう - このSRE本がすごい！2024年 LT版」 というテーマで登壇しました。のイベントは2024年1月末に注目を集めた『このSRE本がすごい！2024年版』をテーマにしたもので、多くの参加者とパネルディスカッションのスピーカーであるT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
