スキル observability-monitoring-slo-implement
📊

observability-monitoring-slo-implement

安全

SLO とエラーバジェットの実装

SLI とエラーバジェットを用いたサービスレベル目標を設計・実装し、機能開発のスピードとバランスを取りながらシステムの信頼性を測定・改善します。

対応: Claude Codex Code(CC)
🥉 72 ブロンズ
1

スキルZIPをダウンロード

2

Claudeでアップロード

設定 → 機能 → スキル → スキルをアップロードへ移動

3

オンにして利用開始

テストする

「observability-monitoring-slo-implement」を使用しています。 新しい e コマースチェックアウトサービスの SLO を設計

期待される結果:

包括的な SLO フレームワーク：ティア分類（重要）、可用性目標（99.95%）、レイテンシ SLI（p95 < 500ms）、エラー率 SLI（< 0.1%）、エラーバジェット計算（月 4.38 時間）、燃焼率アラート閾値。

「observability-monitoring-slo-implement」を使用しています。 SLO 追跡のための Prometheus 記録ルールを作成

期待される結果:

記録ルールの YAML 設定：リクエストレート、複数時間ウィンドウ（5 分、30 分、1 時間）での成功率、レイテンシパーセンタイル（p50、p95、p99）、エラーバジェット燃焼率計算。

セキュリティ監査

安全
v1 • 2/24/2026

Static analysis detected 57 potential issues, but manual review confirms all findings are false positives. The skill contains documentation with Python code examples for SLO implementation - no actual executable code, no network calls, and no cryptographic operations. The placeholder URLs use example.com domain. This is a legitimate DevOps reliability skill.

2
スキャンされたファイル
1,124
解析された行数
5
検出結果
1
総監査数
中リスクの問題 (2)
resources/implementation-playbook.md:40resources/implementation-playbook.md:154-161SKILL.md:36SKILL.md:45
External Commands Detection in Documentation
Static scanner detected 'external_commands' pattern in markdown documentation. This is a false positive - the skill contains Python code examples in markdown blocks, not executable shell commands. The backtick syntax detected is part of Python f-strings and dictionary literals in documentation examples.
resources/implementation-playbook.md:969resources/implementation-playbook.md:970
Hardcoded URLs in Example Configuration
Static scanner detected placeholder URLs in YAML configuration examples. These are example.com domain URLs used as placeholders in documentation, not actual network endpoints.
低リスクの問題 (3)
resources/implementation-playbook.md:7resources/implementation-playbook.md:39SKILL.md:3
Numeric Pattern False Positives
Static scanner detected 'weak cryptographic algorithm' patterns at multiple locations. These are false positives - the numeric values detected (99.9%, 0.001, 14.4) are SLO availability targets and burn rate multipliers, not cryptographic algorithms.
resources/implementation-playbook.md:24SKILL.md:40
Documentation Language False Positive
Static scanner detected 'system reconnaissance' patterns. This is a false positive - words like 'analyze', 'assess', 'identify' are used in the legitimate context of service analysis for SLO design, not reconnaissance.
resources/implementation-playbook.md:1
Code Block Bracket Pattern
Static scanner detected 'obfuscation' pattern with multiple bracket chains. This is a false positive - the pattern detected is legitimate markdown code block formatting with Python dictionary and f-string syntax.
監査者: claude

品質スコア

38
アーキテクチャ
100
保守性
87
コンテンツ
50
コミュニティ
89
セキュリティ
91
仕様準拠

作れるもの

新しい API サービスの SLO 定義

サービスの重要度に基づき、可用性、レイテンシ、エラー率の SLO と適切な目標値を作成

エラーバジェットアラートの設定

高速および低速のエラーバジェット消費を検知するためのマルチウィンドウ燃焼率アラートを設定

SLO レビュープロセスの確立

エンジニアリングチーム向けの週次 SLO レビューテンプレートとガバナンスプロセスを作成

これらのプロンプトを試す

基本 SLO 設計 
決済処理サービスの SLO 設計を手伝ってください。1 分間に 10,000 リクエストを処理し、高い信頼性が必要です。どのような可用性目標を設定すべきか、また SLI をどのように定義すればよいか教えてください。
SLI 実装 
Prometheus を使用した REST API サービスの SLI を実装する必要があります。成功率と 500ms 未満のリクエスト率を追跡する可用性およびレイテンシ SLI クエリの作成方法を示してください。
エラーバジェットアラート 
99.9% の SLO 目標を持つサービスのエラーバジェット燃焼率アラートを設定してください。即時ページング用の高速燃焼とチケット作成用の低速燃焼の両方のアラートルールが必要です。
SLO ガバナンス 
役割と責任、週次レビューテンプレート、ステークホルダーとのコミュニケーションプロセスを含むチームの SLO ガバナンスフレームワークを確立してください。

ベストプラクティス

  • 保守的な SLO 目標から始め、実際のサービスパフォーマンスデータに基づいて調整する
  • 燃焼率アラートでは複数の時間ウィンドウを使用して、高速および低速のバジェット消費の両方を検知する
  • SLO 目標は技術的な都合ではなく、ビジネスの優先順位とユーザーの期待に合わせて設定する

回避

  • 最初に SLO 目標を厳しく設定しすぎて、常にアラートが発生しアラート疲労を引き起こす
  • レイテンシや品質メトリクスを考慮せず、可用性 SLI のみを使用する
  • ステークホルダーとの調整やビジネスコンテキストなしに SLO を作成する

よくある質問

SLO と SLA の違いは何ですか？
SLO（サービスレベル目標）はエンジニアリングチームがコミットする内部目標です。SLA（サービスレベル合意）は顧客との契約上のコミットメントであり、違反した場合の金銭的結果が伴います。
適切な SLO 可用性目標をどのように選択すればよいですか？
過去の可用性データを分析し、ユーザーの期待を理解し、ビジネスへの影響を考慮することから始めます。重要なサービスは通常 99.95% 以上が必要で、標準的なサービスは 99.5% を目標とします。
SLO 測定にはどのような時間ウィンドウを使用すべきですか？
一般的なウィンドウは、ローリング可用性には 30 日間、請求期間にはカレンダー月です。長いウィンドウは安定性を提供しますが、問題に関するフィードバックは遅くなります。
SLO 計算で計画的なメンテナンスをどのように扱えばよいですか？
計画されたメンテナンスウィンドウを SLO 測定から除外するか、予想されるダウンタイムを考慮した可用性式を使用します。アプローチを明確に文書化します。
エラーバジェットが枯渇した場合はどうすればよいですか？
機能開発を一時停止し、信頼性の向上に注力し、ステークホルダーに進捗状況を報告します。エラーバジェットポリシーを使用してリリースの判断を導きます。
サービスはいくつの SLO を持つべきですか？
可用性、レイテンシ、エラー率など、最も重要なユーザー指向の側面をカバーする 2〜4 個の SLO から始めます。必要に応じて追加しますが、アラート疲労を避けてください。

開発者の詳細

作成者

sickn33

ライセンス

MIT

リポジトリ

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/observability-monitoring-slo-implement

参照

main

ファイル構成

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md