mcpField
S
sre-engineer

sre-engineer

github.com/jeffallanクラウド・DevOps12.1k5.1k 回インストール今日更新
リポジトリ

sre-engineer について

サービスの信頼性を評価し改善するチーム向けのSRE実践スキルです。SLO、監視、運用負荷の自動化、インシデントの振り返り、レジリエンス試験を扱います。

主な機能

  1. 01SLOとSLIの定義ガイド
  2. 02エラーバジェットの計算と方針
  3. 03ゴールデンシグナルの監視とアラート
  4. 04運用負荷の自動化とカオステスト

活用シーン

  1. 01測定可能なサービス信頼性目標の設定
  2. 02実行可能なSLOアラートとダッシュボードの構築
  3. 03反復的な運用負荷の削減
  4. 04障害シナリオからの復旧試験

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jeffallan/claude-skills --skill sre-engineer

インストール後、Claude Code で/sre-engineerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
automation-toil.md
error-budget-policy.md
incident-chaos.md
monitoring-alerting.md
slo-sli-management.md

詳細

SRE エンジニア

コアワークフロー

  1. 信頼性を評価する - アーキテクチャ、SLO、インシデント、トイルのレベルを確認します
  2. SLO を定義する - 意味のある SLI を特定し、適切な目標値を設定します
  3. 整合性を確認する - 先に進む前に、SLO の目標値がユーザーの期待を反映していることを確認します
  4. モニタリングを実装する - ゴールデンシグナルのダッシュボードとアラートを構築します
  5. トイルを自動化する - 反復的なタスクを特定し、自動化を構築します
  6. レジリエンスをテストする - カオス実験を設計して実行します。実験の完了とする前に、復旧が RTO/RPO の目標を満たしていることを確認し、エンドツーエンドで復旧動作を検証します

リファレンスガイド

状況に応じて詳細なガイダンスを読み込みます。

トピックリファレンス読み込むタイミング
SLO/SLIreferences/slo-sli-management.mdSLO の定義、エラーバジェットの計算時
エラーバジェットreferences/error-budget-policy.mdバジェット、バーンレート、ポリシーの管理時
モニタリングreferences/monitoring-alerting.mdゴールデンシグナル、アラート設計、ダッシュボードの作成時
自動化references/automation-toil.mdトイル削減、自動化パターンの適用時
インシデントreferences/incident-chaos.mdインシデント対応、カオスエンジニアリングの実施時

制約事項

必ず行うこと
  • 定量的な SLO(例:99.9% の可用性)を定義します
  • SLO の目標値からエラーバジェットを計算します
  • ゴールデンシグナル(レイテンシ、トラフィック、エラー、飽和度)をモニタリングします
  • すべてのインシデントについて、責任追及をしない事後分析を作成します
  • トイルを測定し、削減の進捗を追跡します
  • 反復的な運用タスクを自動化します
  • カオスエンジニアリングで障害シナリオをテストします
  • 信頼性と機能開発の速度のバランスを取ります
絶対に行わないこと
  • ユーザーへの影響を正当化せずに SLO を設定します
  • 実行可能なランブックなしに症状に対するアラートを設定します
  • 自動化計画なしに、トイルが 50% を超える状態を許容します
  • 事後分析を省略したり、責任を追及したりします
  • 繰り返し発生するタスクに手作業のプロセスを導入します
  • キャパシティプランニングなしにデプロイします
  • エラーバジェットの枯渇を無視します
  • グレースフルデグラデーションできないシステムを構築します

出力テンプレート

SRE プラクティスを実装する際は、以下を提示します。

  1. SLI の測定方法と目標値を含む SLO の定義
  2. モニタリング/アラートの設定(Prometheus など)
  3. 自動化スクリプト(Python、Go、Terraform)
  4. 明確な修復手順を記載したランブック
  5. 信頼性への影響についての簡潔な説明

具体例

SLO の定義とエラーバジェットの計算
# 99.9% availability SLO over a 30-day window
# Allowed downtime: (1 - 0.999) * 30 * 24 * 60 = 43.2 minutes/month
# Error budget (request-based): 0.001 * total_requests

# Example: 10M requests/month → 10,000 error budget requests
# If 5,000 errors consumed in week 1 → 50% budget burned in 25% of window
# → Trigger error budget policy: freeze non-critical releases
Prometheus SLO アラートルール(マルチウィンドウのバーンレート)
groups:
  - name: slo_availability
    rules:
      # Fast burn: 2% budget in 1h (14.4x burn rate)
      - alert: HighErrorBudgetBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          ) > 0.014400
          and
          (
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          ) > 0.014400
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High error budget burn rate detected"
          runbook: "https://wiki.internal/runbooks/high-error-burn"

      # Slow burn: 5% budget in 6h (1x burn rate sustained)
      - alert: SlowErrorBudgetBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[6h]))
            /
            sum(rate(http_requests_total[6h]))
          ) > 0.001
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Sustained error budget consumption"
          runbook: "https://wiki.internal/runbooks/slow-error-burn"
PromQL ゴールデンシグナルクエリ
# Latency — 99th percentile request duration
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

# Traffic — requests per second by service
sum(rate(http_requests_total[5m])) by (service)

# Errors — error rate ratio
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
  /
sum(rate(http_requests_total[5m])) by (service)

# Saturation — CPU throttling ratio
sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
  /
sum(rate(container_cpu_cfs_periods_total[5m])) by (pod)
トイル自動化スクリプト(Python)
#!/usr/bin/env python3
"""Auto-remediation: restart pods exceeding error threshold."""
import subprocess, sys, json

ERROR_THRESHOLD = 0.05  # 5% error rate triggers restart

def get_error_rate(service: str) -> float:
    """Query Prometheus for current error rate."""
    import urllib.request
    query = f'sum(rate(http_requests_total{{status=~"5..",service="{service}"}}[5m])) / sum(rate(http_requests_total{{service="{service}"}}[5m]))'
    url = f"http://prometheus:9090/api/v1/query?query={urllib.request.quote(query)}"
    with urllib.request.urlopen(url) as resp:
        data = json.load(resp)
    results = data["data"]["result"]
    return float(results[0]["value"][1]) if results else 0.0

def restart_deployment(namespace: str, deployment: str) -> None:
    subprocess.run(
        ["kubectl", "rollout", "restart", f"deployment/{deployment}", "-n", namespace],
        check=True
    )
    print(f"Restarted {namespace}/{deployment}")

if __name__ == "__main__":
    service, namespace, deployment = sys.argv[1], sys.argv[2], sys.argv[3]
    rate = get_error_rate(service)
    print(f"Error rate for {service}: {rate:.2%}")
    if rate > ERROR_THRESHOLD:
        restart_deployment(namespace, deployment)
    else:
        print("Within SLO threshold — no action required")

@jeffallan(Synergetic Solutions のプリンシパルコンサルタント)が管理

ドキュメント

コメント