slo-implementation

slo-implementationスキルの概要

slo-implementation スキルは、あいまいな信頼性目標を、具体的な Service Level Indicator（SLI）、Service Level Objective（SLO）、エラーバジェット、アラート設計へ落とし込むためのスキルです。特に、SRE、プラットフォームチーム、バックエンドエンジニア、そして「どこまでが十分に健全なサービス状態なのか」を再現性ある形で定義したいプロダクトオーナーに向いています。

slo-implementationスキルの用途

slo-implementation スキルは、次のような場面で使うと効果的です。

• サービスに対して測定可能な信頼性目標を定義したい
• 可用性やレイテンシなど、適切な SLI の種類を選びたい
• ビジネス影響に見合った SLO ターゲットを設定したい
• そのターゲットからエラーバジェットを導きたい
• burn rate や SLO 消費量に基づくアラートを設計したい

単に「SLO を書いて」と頼む汎用プロンプトより有用なのは、SLI → SLO → SLA という構造を保ちながら、計測ウィンドウや PromQL 風クエリのような実装レベルの論点まで踏み込めるからです。

どんな人に導入が向いているか

slo-implementation skill は、すでにテレメトリがある、または近いうちに取得できるチームに特に適しています。とくに、Prometheus 系のメトリクスを使っていて、SRE に沿った信頼性運用をゼロから独自設計せずに進めたいチームには相性がよいです。

逆に、次のような場合は効果が薄くなります。

• まだ意味のあるサービスメトリクスが存在しない
• 主な課題が信頼性目標の設計ではなくインシデント対応である
• 必要なのが法務・顧客向けの SLA 文書だけである

導入前にユーザーが特に気にする点

slo-implementation install を検討する多くのユーザーが知りたいのは、主に次の点です。

1. 理論だけでなく、実際に使える SLO 設計支援が得られるか
2. クエリやアラートなど実装に踏み込んだ支援があるか
3. 見栄えだけの uptime 目標のような、悪い SLO を避ける助けになるか
4. 実務フローに組み込める程度に簡潔か

その点でこのスキルは実用寄りです。代表的な SLI パターン、ターゲット設定例、目標値とエラーバジェットの関係まで押さえています。

主な強みとトレードオフ

slo-implementation の大きな特徴は、汎用的な observability 論に流れず、信頼性の測定とポリシー設計に焦点を絞っていることです。このフォーカスのおかげで、呼び出し時の使いどころがぶれにくくなります。

一方で、出力品質は与えるサービス文脈に強く依存します。ユーザージャーニー、トラフィック特性、依存関係、しきい値、メトリクス名などを具体的に渡さないと、もっともらしく見えても運用に乗せにくい結果になりがちです。

slo-implementationスキルの使い方

slo-implementationスキルの導入コンテキスト

このスキルは、エージェントがカスタムスキルにアクセスできる環境へ導入します。一般的な流れは次のとおりです。

1. ソースリポジトリを skills のセットアップに追加する
2. slo-implementation スキルを有効化する
3. SLI、SLO、エラーバジェット、または SLO ベースのアラートを定義・見直ししたいタスクで呼び出す

ツールチェーンが直接のスキル導入に対応している場合は、通常の skill loader を使って次のリポジトリを指定します。
https://github.com/wshobson/agents/tree/main/plugins/observability-monitoring/skills/slo-implementation

このスキルについて、リポジトリ上で確認できる実体は SKILL.md のみなので、補助スクリプトや追加資料を期待するより、まずそのファイルを読む前提で進めるのが現実的です。

最初に読むべきファイル

まず確認すべきなのは次です。

• plugins/observability-monitoring/skills/slo-implementation/SKILL.md

このファイルに、slo-implementation guide の中身がまとまっています。用途、使いどころ、SLI/SLO/SLA の階層、代表的な SLI タイプ、ターゲット例、実装パターンまで、実質的な情報はここにあります。

有用な出力に必要な入力情報

質の高い slo-implementation usage にするには、エージェントへ次の情報を渡してください。

• サービス名と、ユーザーがそのサービスで何をしているか
• もっとも重要なユーザー向けジャーニー
• 現在取得できているメトリクスとラベル
• 既存のダッシュボード、アラート、PromQL があればその内容
• トラフィック量と季節変動
• ビジネス上の重要度と障害コスト
• エンドポイントや操作ごとのレイテンシ期待値
• 既知の障害モード
• 内部向け SLO が必要なのか、外部 SLA との整合も必要なのか、その両方なのか

これらがなくても SLO の草案自体は作れますが、可用性偏重の汎用ターゲットや、単純なリクエストベース SLI に寄りやすくなります。

ラフな目標を良いプロンプトに変える

弱いプロンプト:

• “Create SLOs for my API.”

より良いプロンプト:

• “Use the slo-implementation skill to define SLIs and SLOs for a multi-tenant payments API. Our critical user journeys are charge creation and webhook delivery. We use Prometheus. Available metrics include http_requests_total, http_request_duration_seconds_bucket, and queue retry counters. Propose 2 to 3 SLIs, recommend SLO targets, calculate monthly error budgets, and suggest burn-rate alerts. Exclude admin endpoints and health checks.”

このプロンプトが有効な理由:

• サービス境界が明確
• 実在するメトリクスを示している
• 意味のあるユーザージャーニーにスコープを絞っている
• スキルが得意とする出力を明示している

初回利用におすすめのワークフロー

実務的な slo-implementation usage の流れは次のとおりです。

1. プラットフォーム全体ではなく、まず 1 サービスに絞る
2. 重要なユーザージャーニーを 1〜3 個挙げる
3. 各ジャーニーを既存シグナルに対応づける
4. スキルに候補 SLI を出させる
5. その SLI がシステム内部ではなくユーザー体験を反映しているか確認する
6. 初期 SLO ターゲットとエラーバジェットを設定する
7. アラートロジックを草案化する
8. 実際にその設計をメトリクスで支えられるか検証する
9. 本番導入前にしきい値や除外条件を見直す

こう進めると、企業全体の信頼性ポリシーを一度に定義しようとして破綻する、よくある失敗を避けられます。

このスキルが特に得意な出力

slo-implementation skill が強いのは次のような領域です。

• 可用性やレイテンシなど、定番の SLI パターン提案
• SLI / SLO / SLA の関係整理
• 信頼性目標を測定可能な比率へ変換すること
• ターゲット範囲の提案とエラーバジェットの考え方の整理
• SLO 消費量に基づくアラートのたたき台作成

とくに、最初の運用可能なドラフトを素早く作りたい、かつ標準的な SRE 用語に沿って進めたいときに役立ちます。

チームが詰まりやすいポイント

導入が止まりやすい理由は、たいてい次のいずれかです。

• ユーザー向けサービス境界についてチーム内で合意できない
• インフラメトリクスしかなく、ユーザージャーニーに紐づくメトリクスがない
• レイテンシヒストグラムがなく、しきい値型 SLI が弱い
• bot トラフィック、内部ジョブ、health check がメトリクスに混ざり、分子・分母を歪めている
• ターゲットがリスクやコストではなく政治的判断で決まっている

このスキルは議論を構造化する助けにはなりますが、テレメトリがない状態から信頼できる計測を作り出すことはできません。

出力品質を上げる実践的なプロンプトパターン

抽象論ではなく、意思決定に使える形で出力させるには、たとえば次のように依頼します。

• “List candidate SLIs with rationale and tradeoffs.”
• “Recommend one primary SLO and one secondary guardrail SLO.”
• “Show PromQL-style formulas for each SLI.”
• “Identify exclusions that should not count against the SLO.”
• “Suggest alerting windows for fast and slow burn.”

こうしたプロンプトにすると、一般論の信頼性アドバイスではなく、実装に近いレベルの出力になりやすくなります。

信頼性業務でslo-implementationを使う場面

Reliability 向けの slo-implementation は、次のタイミングで使うと効果的です。

• 新しいサービスをリリースする前
• observability 改善の取り組み中
• 繰り返し起きるインシデントから、現行アラートのノイズが明らかになったとき
• 経営層から、顧客影響と結びついた信頼性目標を求められたとき
• 開発速度とエラーバジェット運用を結び付けたいとき

とくに、「全部監視する」から「ユーザーにとって重要なものを測る」へ移行するチームにとって価値が高いです。

slo-implementationスキル FAQ

slo-implementationは普通のプロンプトより良いですか？

はい。タスクが SLI / SLO 設計に特化しているなら、その価値はあります。普通のプロンプトでもそれらしい定義は出せますが、slo-implementation のほうが階層構造を保ちやすく、測定可能な式を含め、ターゲットをエラーバジェットやアラートまでつなげやすい傾向があります。

slo-implementationスキルは初心者向けですか？

難易度は中程度です。初心者でも使えますが、良い結果を得るには基本的な SRE 概念と、ある程度のテレメトリ文脈を理解しているほうが有利です。SLO に不慣れなら、まず 1 サービスだけで試し、提案された各メトリクスを採用前にきちんとレビューするのが安全です。

Prometheusは必須ですか？

いいえ、必須ではありません。ただし、スキル内容は Prometheus や PromQL 的な考え方とかなり相性が良いのは明らかです。Datadog、CloudWatch、Grafana、その他のスタックを使っていても、ロジック自体は活用でき、メトリクス式を自分の基盤に合わせて読み替えられます。

どんな場合はslo-implementationを使わないほうがいいですか？

次のような場合、主力ツールとして slo-implementation を使うのは避けたほうがよいです。

• 法務向けの SLA 文言が必要
• 使えるサービステレメトリがほとんどない
• 本当の問題が計測ではなくオーナーシップにある
• まだサービスが未成熟で、安定したユーザージャーニーを定義できない

こうしたケースでは、SLO を形式化する前に、まず計測基盤を整えるか、運用モデルの問題を解くべきです。

アラート設計にも役立ちますか？

はい。これはターゲット定義だけのスキルではなく、エラーバジェット運用や SLO ベースのアラートという運用面にも踏み込みます。単にパーセンテージ目標を並べて終わるテンプレートより実務向きです。

slo-implementationスキルを改善するには

技術メトリクスだけでなくビジネス文脈も渡す

slo-implementation の結果を良くしたいなら、信頼性がビジネス上何を意味するのかをエージェントに伝えてください。

• どのワークフローが劣化すると売上に響くのか
• どのユーザーがプレミアム顧客、あるいはレイテンシに敏感なのか
• どの程度の影響時間なら許容されるのか

これにより、99.99% のような理想先行の数字へ安易に寄るのではなく、現実的なターゲットを選びやすくなります。

サービス境界を明示する

より良い slo-implementation guide 入力では、「何を含めて、何を含めないか」をはっきり書きます。たとえば次のような形です。

• 公開 API の write request は含める
• /healthz、admin routes、内部 batch jobs は除外する
• 単なる request acceptance ではなく、ユーザーから見て成功した完了のみを測る

SLO が信頼されるかどうかは、この境界定義の明確さに大きく左右されます。

メトリクス名とサンプルクエリを渡す

実際のテレメトリを共有すると、このスキルは一気に実用的になります。良い入力の例は次のとおりです。

• metric names
• label dimensions
• histogram buckets
• current alert queries
• dashboard links or copied snippets

これがあると、概念的な SLO 提案から、ほぼ実装可能な定義にまで出力を進めやすくなります。

見栄えだけのSLIを避ける

ありがちな失敗は、集めやすいがユーザー体験との結び付きが弱いメトリクスを選ぶことです。たとえば次のようなものです。

• pod restarts
• CPU saturation alone
• raw uptime of a dependency with no service impact mapping

各 SLI が「なぜユーザーが感じる信頼性を表しているのか」を、スキルに説明させてください。説明できないなら、その SLI は差し替えるべきです。

最初のドラフト後に必ず反復する

slo-implementation の最初の出力は、完成版ではなく草案として扱うべきです。次のように問い返すと、設計がかなり改善します。

• “Which SLI is most representative of user harm?”
• “What would make this SLO impossible to measure accurately?”
• “Which exclusions are risky or easy to abuse?”
• “How would this change for low-traffic services?”
• “What alerting would reduce noise while protecting the error budget?”

最初のターゲット案をそのまま採用するより、この 2 周目で運用設計の質が大きく上がることが多いです。

過去インシデントでslo-implementationを検証する

​slo-implementation skill の出力改善で特に有効なのは、提案された SLI やアラートを実際の障害事例に照らして検証することです。たとえば次を確認します。

• この SLO ならその問題を検知できたか
• 害のない失敗まで過剰にカウントしていないか
• burn-rate policy は早すぎず遅すぎずページできたか

この検証を入れることで、見栄えのよい文書が、実際にチームで回せる設計に変わります。

一度に扱うのは1サービスずつにする

結果が抽象的すぎると感じるなら、たいていスコープが広すぎます。このスキルは、1 つのサービス、または 1 つのユーザージャーニーに絞ったときに最も力を発揮します。大きなシステムは複数回に分けて扱い、パターンの標準化はその後で行うのが得策です。