2026

11

  1. 2026年11月に発生したMicrosoft 365の接続障害についてまとめてみた - piyolog
  2. Software Design 2026年12月号に寄稿しました
  3. SRE ブックの 10 年間:『Site Reliability Engineering』第 2 版のご紹介 | Google Cloud 公式ブログ
  4. Googleが「SREの教科書」を10年ぶりに全面改訂 “システム運用の常識”はどう変わった?
  5. 強いエンジニアになりたくて。20代の大失敗で始まる、夢を掴んでも挑み続ける二刀流というキャリア - Findy Media
  6. TVerインフラアーキテクチャの現在地(2025年)
  7. アンドパッドSREが抱える課題をPlatform Engineering Kaigi 2026の参加者にぶつけてみた結果
  8. Uberはリトライストームからどのように身を守っているのか
  9. サービスレベル設計として捉える非機能の考え方 | フューチャー技術ブログ
  10. IVRyのSREの取り組み 2026冬

10AI 時代の監視・開発基盤と、障害時の容量計画

  1. 非機能はなぜ必要なのか | フューチャー技術ブログ
  2. 読んでいないコードを私たちはどれだけ信頼できるのか - YAMAGUCHI::weblog
  3. 書き手が人でもAIでも正しくなる道、 SREを埋め込んだDeveloper Platform / tech drivers day8
  4. Agentic Monitoring
  5. Buy the SRE ebook and throw it at your work Claude.
  6. リトルの法則で考える障害時のキャパシティプランニング
  7. DeNAにおけるAI時代のネットワーク管理システム [DeNA インフラ SRE] | BLOG - DeNA Engineering
  8. Kubelet watches inodes. Just not until it’s an emergency.
  9. Kubernetesノードが物理障害でNotReadyになってからPodが再スケジュールされるまで

09「手順書は死んだ」と、属人化した知識の喪失

  1. Runbooks Are Dead; Make Operations Executable
  2. Moving from Datadog to Opensource Observability ecosystem
  3. "Redis just froze" — a diagnosis checklist based on why it actually happens
  4. The guy who knew why is gone, what now?
  5. Counted the tools named in 134 DevOps and SRE job postings
  6. Kubernetes disaster recovery: Guidance from three reproducible failure scenarios
  7. SREを組織にする技術
  8. AI handles incidents, engineers lose touch with their systems
  9. クラウドから物理サーバーまでのコストを共通スキーマFOCUSで統一して可視化する
  10. Snowflake's Aug 27 outage was a bad load balancer config which took down private connectivity for an hour

08「戻せる」バックアップ検証と、アラート削減

  1. whats up AT&T's outage dropping a bunch of phones to SOS mode nationwide.
  2. Automating root cause analysis at scale: Multi-signal correlation for cloud native incident response
  3. バックアップが「戻せる」かを 5 段階で測る
  4. Kubernetesのポリシー運用ってどうやるの?既存構成にモヤモヤして、Kyvernoと責任分離の設計を一から調べて整理してみた【前編】
  5. Cut our alert volume way down. The pages that survive are somehow harder to act on at 3am
  6. How we cut our Prometheus / VictoriaMetrics storage bill 60% ($4,900 → $1,950/mo) with a cardinality audit
  7. 障害対応の「優先順位」を仕組みにできないか - Operation Decision Recordsという着想
  8. 復元したことのないバックアップは、バックアップではない
  9. CloudFront VPC Origins障害とトレードオフに向き合うためのアンドパッドの答え

07MTTR の再考と、時間・飽和の落とし穴

  1. 「Saturation(飽和)」──あなたのソフトは規模が大きくなった瞬間に壊れる
  2. 障害対応で最強の問い「何が変わった?」に、熟練チームはどう答えているか
  3. MTTRはもう現場で役に立たなくなったのか?
  4. If a policy changes mid-run, should the worker fail closed?
  5. How do you catch the stuff you never thought to put an alarm on?
  6. 「小さなPRに分ける」ルールをやめた理由
  7. 本番システムの「時間」にまつわる落とし穴
  8. SRE NEXT 2026 参加レポートまとめ