site-reliability-engineering について
本番システムの設計、運用、改善に向けたサイト信頼性エンジニアリング手法です。SLO/SLI、エラーバジェット、インシデント対応、可観測性を扱い、自動緩和後の権限確認と復旧証拠を重視します。
主な機能
- 01SLO・SLI・エラーバジェット管理
- 02インシデント指揮と非難のない事後分析
- 03監視・アラート・可観測性の設計
- 04オンコール・トイル・自動化の手法
- 05信頼性レビューとランブックのテンプレート
- 06本番操作の権限と復旧証拠の要件
活用シーン
- 01サービスの信頼性目標とエラーバジェットの定義
- 02インシデント対応の調整と事後分析の作成
- 03信頼性・容量・依存関係リスクのレビュー
- 04オンコール体制と運用自動化の計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ magnus919/ agent-skills --skill site-reliability-engineeringインストール後、Claude Code で/site-reliability-engineeringを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
README.mdevals/agentic-review-notes.mdevals.jsonreferences/agentic-evidence-and-evals.mdagentic-operations.mdguiding-principles.mdhuman-systems-and-learning.mdincident-command-system.mdmonitoring-alerting.mdoncall-best-practices.mdoperational-documentation.mdpostmortem-culture.mdproduct-focused-reliability.mdrelease-engineering.mdreliability-design-and-change.mdsenior-sre-blueprint.mdslo-implementation-recipe.mdslo-sli-framework.mdsource-index.mdsre-adoption-and-engagement.mdsre-book-chapters.mdsre-communication-guide.mdsre-ecosystem-guide.mdthird-party-dependency-reliability.mdtoil-elimination.mdtroubleshooting.mdtwenty-years-lessons.mdscripts/slo-burn-rate.pytemplates/agentic-action-contract.mdagentic-governance-evidence.md詳細
サイト信頼性エンジニアリング
本番システムの信頼性を高めるための設計、運用、改善に関する包括的な方法論です。Google の SRE 原則を基盤とし、インシデント指揮、オブザーバビリティエンジニアリング、エラーバジェットのガバナンス、運用の卓越性に関する最新の実践を取り入れています。
このスキルを使うタイミング
| トリガー | 意味 |
|---|---|
| 「このシステムに信頼性を組み込みたい」 | SLO/SLI のフレームワーク、エラーバジェットのポリシー、レジリエンスアーキテクチャ |
| 「インシデントのポストモーテムを実施したい」 | タイムライン、5 Whys、アクション追跡を含む、非難しないポストモーテム |
| 「オンコールを改善したい」 | ローテーション設計、アラートの調整、トイルの削減、エスカレーションポリシー |
| 「オブザーバビリティを構築したい」 | 4 つのゴールデンシグナル、ダッシュボード設計、アラートルールのパターン |
| 「信頼性レビューを行いたい」 | SRE 原則に照らしたアーキテクチャレビュー、リスク評価 |
| 「インシデントコマンダーが必要」 | インシデント指揮のフレームワーク、役割カード、コミュニケーション用テンプレート |
| 「この運用タスクを自動化したい」 | トイルの評価、自動化の判断ツリー、ランブックのパターン |
| 「この組織に SRE を導入したい」 | 関与範囲、成熟度、チームモデル、変革の定着 |
| 「この信頼性設計をレビューしたい」 | ユーザージャーニー、依存関係、過負荷、設定、カナリア、耐久性 |
| 「SRE チームに過負荷がかかっている」 | 運用負荷の診断、エンジニアリング時間の確保、回復計画 |
| 「インシデントからの学びや持続可能なオンコール体制を改善したい」 | 認知負荷、心理的安全性、ドキュメント、演習 |
使用しない場合
リリースを計画する、プロモーションやロールバックのゲートを組み立てる、またはリリーストレインを調整するには、release-engineering を使用してください。特定の障害の原因を特定するには、systematic-debugging を使用してください。テレメトリスタック自体の運用、つまり Prometheus のスクレイプ設定、OpenTelemetry Collector のパイプライン、Loki の取り込みと保持、Prometheus のルールファイルは、telemetry の担当範囲です。このスキルが担当するのは、それらのルールで実装する SLI/SLO とアラートの設計です。Grafana のプロダクト関連作業、つまりダッシュボード、パネル、Grafana 側のアラートルール、コンタクトポイント、通知ポリシーは、grafana の担当範囲です。
運用上のクローズ判定ゲート
自動化された緩和、ロールバック、復旧アクション、またはインシデントのクローズ処理を行う場合は、次の手順に従います。
- 開始前にアクションの範囲を定めます。 対象、影響を受ける範囲、最大の影響範囲、成功基準、中止/ロールバック基準、ロールバック先と手順、およびアクションを停止または元に戻す権限を持つ担当者を記録します。最小限の、元に戻せる範囲を優先し、段階的に拡大します。
- ユーザー境界で復旧を確認します。 アクション後、R-01 のクローズ証跡シーケンスに従い、ユーザー向け SLO、重要なユーザージャーニー、関連する依存関係の健全性、データ/状態の正確性を確認します。定義された安定性確認期間を設け、バックログの解消などの二次的な影響も確認します。
- アラートの解消を復旧と同一視しないでください。 アラートが解消されたことやヘルスエンドポイントのチェックに合格したことは証拠であり、解決の判定ではありません。必要な証拠が不足している場合は、
MITIGATINGまたはMONITORINGの状態を維持し、未確認の境界を明示してエスカレーションします。RESOLVEDと宣言してはなりません。 - 証拠を記録します。 アクション、範囲、しきい値、観測された復旧証拠、残る不確実性、ロールバック/フォローアップのトリガーをインシデントまたは変更記録に残します。
デフォルトの承認: 人間のサービスオーナー、インシデントコマンダー、または指定された変更承認者が、現在のインシデント/変更記録において、本番環境への変更とその範囲を個別に承認し、その承認が当該人間によるものであると独立して確認できなければなりません。診断の依頼、恒常的なランブック、エージェントが作成したメモ、自己申告の役割は十分な根拠になりません。
ガバナンス下の例外: 能力ごとにより高度な実行権限を認めるには、ai-governanceを通じて責任を負う人間が独立して権限を付与し、適用されるすべてのホスト/組織ポリシーがそれを許可し、外部のコントロールプレーンが実行時に有効な権限付与を証明して強制する必要があります。権限付与には、能力、環境、アクションの種類、制限、有効期限、取り消し方法、テスト済みの強制適用を明記しなければなりません。スキルの記述やエージェントの役割によって権限が付与されることはありません。証明を確認できない場合、有効期限が切れている場合、取り消されている場合、競合している場合、または古い場合は、人間の承認を必要とするデフォルトを維持し、権限を自己付与してはなりません。診断、変更、ロールバック、ページング、インシデントのクローズ、範囲の拡大には、それぞれ別個の権限判断が必要です。R-01 では引き続き、人間による独立したクローズ確認が必要です。
エージェント型運用
SRE エージェントを運用する場合は、実行を提案する前に references/agentic-operations.md を読み、templates/agentic-action-contract.md に記入します。自律性の証拠やリプレイ設計については、references/agentic-evidence-and-evals.md も読みます。運用上の証拠をガバナンスに引き継ぐ際は、templates/agentic-governance-evidence.md を使用します。
既存の専門家を組み合わせてください。agent-production-operationsは本番環境の契約、制御計画、トレースのフィードバックを担当します。agent-evals-and-observabilityは軌跡の評価と評価器を担当します。incident-learningは検証済みのフォローアップ学習を担当します。ai-governanceは、責任を負う人間が昇格/降格のしきい値を設定し、権限を維持、拡大、縮小、一時停止、または取り消す判断を行えるよう支援します。SRE は証拠を提示し、承認済みの運用上の制限を順守させます。検証済みの復旧と人間によるクローズ確認をもって完了とするか、不足している証拠/権限と引き継ぎ先の担当者を明示した、範囲を限定したエスカレーションを行います。
参考ファイル
| トピック | ファイル | 読み込むタイミング |
|---|---|---|
| SRE ブックの章の要約 | references/sre-book-chapters.md | 設計への取り組み、第一原理のレビュー |
| SLO/SLI フレームワーク | references/slo-sli-framework.md | 信頼性目標の定義 |
| SLO 実装レシピ | references/slo-implementation-recipe.md | エージェントが実行できる SLO 導入手順と関係者によるレビュー |
| エラーバジェットのガバナンス | templates/error-budget-policy.md and references/slo-sli-framework.md | ポリシーの設計、バーンレートアラート |
| インシデントコマンドシステム | references/incident-command-system.md | インシデント発生中・発生後、トレーニング |
| 非難のないポストモーテム | references/postmortem-culture.md | インシデント後、プロセス設計 |
| モニタリングとアラート | references/monitoring-alerting.md | オブザーバビリティの設計、アラートルール |
| オンコールのベストプラクティス | references/oncall-best-practices.md | ローテーションの設計、チーム規模の決定 |
| トイルの削減 | references/toil-elimination.md | 自動化の優先順位付け、運用レビュー |
| リリースエンジニアリング | release-engineering | リリース計画、昇格、段階的デリバリー、ロールバックの設計。SRE 固有の統合コンテキストにはローカルの参考資料のみを使用 |
| 効果的なトラブルシューティング | references/troubleshooting.md | デバッグ手法 |
| シニア SRE の役割の設計図 | references/senior-sre-blueprint.md | 役割の定義、KPI フレームワーク |
| SRE コミュニケーションガイド | references/sre-communication-guide.md | 関係者への状況報告、インシデントコミュニケーション |
| 指針となる原則 | references/guiding-principles.md | 第一原理、哲学 |
| プロダクト重視の信頼性 | references/product-focused-reliability.md | プロダクト中心の SRE、CUJ ベースの SLO、JTBD モデル |
| 20 年にわたる教訓 | references/twenty-years-lessons.md | インシデントから得た実践的な教訓、Prodverbs |
| SRE エコシステムガイド | references/sre-ecosystem-guide.md | SRE リソース全般の厳選ガイド(Workbook、Secure Systems、Classroom、Prodcast、STPA、Video Gallery、Mobaa、基礎、AI 運用) |
| 導入と取り組み | references/sre-adoption-and-engagement.md | SRE の開始、専任・兼任チームのモデル、成熟度、変革の導入 |
| 信頼性の設計と変更 | references/reliability-design-and-change.md | キャパシティ、過負荷、設定、カナリア、データの耐久性、依存関係、設計レビュー |
| 人間のシステムと学習 | references/human-systems-and-learning.md | 認知的な作業、持続可能なオンコール、心理的安全性、ドキュメント、演習 |
| サードパーティ依存関係の信頼性 | references/third-party-dependency-reliability.md | ベンダーとの境界、障害モード、フォールバック、プロバイダーのエビデンス |
| 運用ドキュメント | references/operational-documentation.md | 機能的な品質、オーナーシップ、テスト、陳腐化のライフサイクル |
テンプレート
| テンプレート | ファイル | 目的 |
|---|---|---|
| インシデントコマンダーチェックリスト | templates/incident-command-checklist.md | IC 対応の手順 |
| ポストモーテムテンプレート | templates/postmortem-template.md | 非難のないポストモーテム文書 |
| ランブックテンプレート | templates/runbook-template.md | 運用ランブックの標準 |
| SLO 宣言テンプレート | templates/slo-declaration-template.md | サービスレベル目標の仕様 |
| エラーバジェットポリシー | templates/error-budget-policy.md | チームレベルのエラーバジェット管理 |
| オンコールローテーションテンプレート | templates/oncall-rotation.md | ローテーションスケジュールとエスカレーション |
| サービスレビューチェックリスト | templates/service-review-checklist.md | リリース前の信頼性レビュー |
| インシデントコミュニケーションテンプレート | templates/incident-communication.md | インシデント発生中の状況更新 |
| 信頼性設計レビュー | templates/reliability-design-review.md | ユーザーへの影響、障害モード、キャパシティ、変更、運用に関する証拠に基づくレビュー |
| 運用過負荷からの復旧 | templates/operational-overload-recovery.md | 持続不可能な運用負荷からの復旧を宣言し、保護し、負荷を軽減し、確認する |
| 信頼性オーナーシップ憲章 | templates/reliability-ownership-charter.md | サービス、ページャー、依存関係、連携の境界を明確にする |
スクリプト
| スクリプト | 目的 |
|---|---|
scripts/slo-burn-rate.py | SLI データからエラーバジェットの消費率を計算する |
移植性
このスキルは、特定のホストに依存しないよう意図的に設計されています。ここに記載されているリファレンス、テンプレート、スクリプトの読み込みには、エージェントの通常の仕組みを使用してください。特定のプロファイルシステム、タスクオーケストレーター、メモリーサービス、または応答引き継ぎ形式を前提としないでください。