slos-and-triggers

Honeycomb の SLO とトリガー

Honeycomb における信頼性の構成と考察に関するガイダンス。get_slos と get_triggers ツールはそれぞれのパラメータを文書化していますが、このスキルは効果的な SLO の_設計_、SLO とトリガーの_選択_、そして数値が何を意味するかの_解釈_に焦点を当てています。

可用性: SLO には Pro または Enterprise プランが必要です。トリガーはすべてのプランで利用できます。

SLO とトリガー — どちらをいつ使うか

質問	SLO	トリガー
「信頼性のコミットメントを達成できているか?」	はい	いいえ
「今何かが壊れているか?」	いいえ	はい
「エラーバジェットをどのくらいの速さで消費しているか?」	はい(バーンアラート)	いいえ
「エラー数がしきい値を超えたか?」	いいえ	はい
「デプロイを減速すべきか?」	はい(残りバジェット)	いいえ

経験則: SLO は長期間にわたるコミットメントに対する信頼性を測定します。トリガーは差し迫った運用上の問題を捕捉します。

効果的な SLO の設計

SLI を定義する

SLI はイベントごとの真偽値です。このイベントは成功したか? 計算フィールドとして実装され、undefined(関連するイベントではない)、1(成功)、0(失敗)のいずれかを返します。

• 形式: IF(<qualifying-condition>, <success-condition>) 適格条件は関連するイベントに絞り込み、成功条件は何を成功とみなすかを定義します。適格条件が満たされない場合、数式は undefined を返し、SLI は未設定となります。
• 具体的な適格条件: 関連するイベントのサブセットを選択します(例: チェックアウトエンドポイントのルートスパンに対して AND(EQUALS($http.route, "/checkout"), NOT(EXISTS($trace.parent_id))))
• レイテンシの成功条件: LTE(duration_ms, 500) — 500ms より速いリクエスト
• 可用性の成功条件: LTE(http.status_code, 499) — 5xx 以外のレスポンス
• ビジネスロジックの成功条件: EQUALS(checkout.status, "completed") — 成功したチェックアウト

ターゲットを設定する

• 保守的に始める(99.99% より前に 99%)
• まず P50/P99 クエリで現在のベースラインを測定する
• 現在のパフォーマンスより少し上にターゲットを設定する
• 自問する: ユーザーが実際に必要とする信頼性は何か?

枯渇時間アラートを構成する

最低でも 2 つのアラート:

• 枯渇間近(枯渇時間 ~4h): PagerDuty 経由でオンコールにページング
• 枯渇傾向(24h にわたるバジェットレート): Slack 経由でチームに通知

バーンレートアラートを構成する

バジェットがまだ枯渇に近づいていなくても、速いバーンを検出します。例えば:

• 1h バーンレート > 10x — オンコールにページング

SLO を作成した後、これらのアラートをユーザーに推奨してください。エージェントはこれらのアラートやその受信者を設定する機能を持っていません。

ベストプラクティス

• ユーザーに近い場所で測定する(スタックの深部ではなく、エッジで)
• チームの境界ではなく、ユーザーのワークフローを中心に設計する
• 多くの狭い SLO よりも、広い SLO を優先する
• まず 1 つの SLO から始め、ノイズを減らしてから拡張する

SLO ステータスの解釈

get_slos で SLO をレビューする際:

• 残りバジェット > 50%: 健全 — リスクを受け入れる余地がある
• 残りバジェット 10-50%: 注意 — 変更を減速する
• 残りバジェット < 10%: リスクあり — 重要でないデプロイを凍結する
• バジェットがマイナス: 違反 — production-investigation スキルを使って直ちに調査する
• コンプライアンスが 0%: SLI の設定ミスの可能性が高い(間違ったカラム、反転したロジック、一致するイベントがない) — SLI の定義を確認する

トリガーの構成

パーセンタイルベースよりカウントベースを優先する

「2s より遅いリクエストが 50 件」は「P99 が 2100ms」よりもアクションにつなげやすいです。 P99 トリガーの代わりに COUNT WHERE duration_ms > threshold を使います。

一般的なパターン

• エラースパイク: COUNT WHERE error = true、しきい値 > 5 分間に N 件
• 遅いリクエスト: COUNT WHERE duration_ms > 2000、しきい値 > 5 分間に N 件
• トラフィックの低下: COUNT WHERE is_root、しきい値 < 10 分間に N 件(通常より少ない)

ベストプラクティス

• 名前: アラートの内容。説明: 実行すべきこと（ランブックへのリンク）。
• フラッピングを避けるため、最小で 5～10 分の期間を設定する
• 感度を低めから始め、誤検知率に基づいて調整する

マルチサービス SLO

最大 10 個のサービス間で単一のエラーバジェットを共有します。

• SLI は環境レベルの計算フィールドである必要があります
• 対象に含まれるサービスからのイベントは均等に重み付けされます
• ユースケース: 複数のエッジサービス、モノリスからマイクロサービスへの移行

ユーザーへの確認

Honeycomb のワークスペースでは、SLO とトリガーの数が限られています。作成ツールを実行する前に、ユーザーに確認してください。すべてのパラメータとその根拠を表示し、確認を求めてください。

SLO へのリンクの構築

利用可能なツールでは、Honeycomb の SLO ページに直接リンクすることはできません。 代わりに、SLO の一覧にリンクできます。

/<team_slug>/environments/<environment_slug>/slos

その他のリソース

参照ファイル

• ${CLAUDE_PLUGIN_ROOT}/skills/slos-and-triggers/references/slo-design-guide.md — 詳細な SLO 設計方法論、マルチサービス SLO、エラーバジェットの計算
• ${CLAUDE_PLUGIN_ROOT}/skills/slos-and-triggers/references/trigger-examples.md — ユースケース別に整理された完全なトリガー例のライブラリ
• ${CLAUDE_PLUGIN_ROOT}/skills/slos-and-triggers/references/alerting-strategy.md — SLO バーンアラートとトリガーを組み合わせて一貫性のあるアラート戦略を構築する方法

相互参照

• SLI クエリと計算フィールドの構築については、query-patterns スキルを参照してください
• SLO バジェットの消費を調査するには、production-investigation スキルを参照してください