オライリーのレポート「Training Site Reliability Engineers」を読んだ要点まとめ。組織の成熟度に応じたSREトレーニング手法（Sink or Swim〜体系的プログラム）、TMRプロトコルによる障害対応、心理的安全性とインポスター症候群への配慮、Sandbox環境やティーチバックを使った実践的学習、アンドラゴジー・ADDIEモデルに基づく設計原則、そしてトレーニングプログラム自体をSREの階層構造で継続的に改善していく考え方を紹介している。
Anthropic の AI 信頼性エンジニアが、Claude を含む LLM をインシデント対応に使った実体験を語る講演。OODA ループに沿って評価すると、ログ・メトリクス横断の異常検知（Observe）では人間を凌駕する一方、根本原因の因果推論（Orient）では相関と因果を混同するなど脆さが残ると説明。AI が完全に on-call を代替する段階ではなく、定型的な緩和策を AI に任せ人間は再発防止の構造的対策に集中するのが現実的な役割分担だと結論づけている。
LegalOn TechnologiesのSREチームが、220個のマイクロサービスを運用する中で発生するTerraform/Kubernetes管理、レビュー、問い合わせ対応、Production Readiness CheckにAIエージェント（Codex、Claude等）を組み込み運用負荷を削減した事例。HPAからKEDAへの大規模移行をLinearとCodexの連携で自動化、Notion上のガイドラインをAIレビューに活用、入社退社対応の定型問い合わせをLinear Asksで自動化、PRCのEvidence確認をAIで整理した。AI活用の鍵は「AIに任せる領域の見極め」と「社内ナレッジの文書化・整理」にあると結論づけている。
オンコール手当の金額相場を5チャネル・約50社で調査したが、金額を明記した事例は1件も見つからなかった。求人票は「手当あり」まで書いても金額は非公開というパターンが複数社で共通していた。金額の代わりに輪番人数・交代周期・対応時間帯などの設計変数は多く公開されており、Atlassianの指摘する「出来高制は改善意欲を削ぐ逆インセンティブになる」という論点も紹介。結論として、実額が取れない前提でテンプレートから自社基準を作るのが現実的だとしている。
GitHubで2024年8月17日に発生した大規模障害の公式ポストモーテムを解説する記事。データベースの過負荷が接続プールの枯渇を招き、依存サービスへカスケード的にダウンタイムが拡散した経緯を整理し、サーキットブレーカーパターンのPython実装例と、自社の障害分析にLLMを活用するプロンプト例を紹介している。
vLLMをKubernetes上で本番運用するための最小構成を整理した記事。DaemonSetではなくDeploymentで構成し、KEDAでキューの深さ（待機リクエスト数）を基準にオートスケーリングする設計、レプリカ数とノード数を分離する2層スケーリング、TTFTやKVキャッシュ使用率などのSRE監視指標とアラート設計、モデルキャッシュ戦略、カナリアデプロイ、複数モデルのルーティング、コスト監視、障害対応runbook、Graceful Shutdown、本番投入前の負荷テスト、マルチGPUノードでのトポロジー考慮スケジューリングまでを、良い例・悪い例のマニフェストやコードとともに解説している。
監視の目的を「検知」ではなく「意思決定」と再定義し、ツール非依存の設計手順（全体像→設計原則→ユーザー影響シナリオの洗い出し→SLI定義）を解説する記事。OpenTelemetryのシグナル分類、Google SREのブラックボックス/ホワイトボックスやfour golden signals、ITIL 4・ISO/IEC 27002などの標準用語に位置づけながら、症状ベースの計測を優先する3原則、ECサイトの注文機能を例にしたシナリオ→SLI対応表、GQM(Goal-Question-Metric)アプローチとの対応関係を示す。