🟦

【運用編】SLI/SLOをチームに定着させ、運用で育てる

に公開
SRE
SLO
tech

【運用編】SLI/SLOをチームに定着させ、運用で育てる

この記事は、SLI/SLOを「定義し、実践し、運用で育てる」までを扱う3部作の3本目・運用編です。

  1. 【概念編】SLI/SLOとは何か——ユーザー体験から信頼性を定義する: SLI/SLOの基本的な考え方と作り方
  2. 【実践編】GitLab Self-hosted(AWS)のSLI/SLOを定義し、CloudWatchで表現する: 実際のインフラ構成に当てはめる
  3. 【運用編】SLI/SLOをチームに定着させ、運用で育てる(この記事): 定義したSLI/SLOをチームに定着させ、育てていく方法

免責事項: 本文中では、一般的なSLI/SLOの考え方に加えて、「コラム」としてPlatform SREがどう向き合うかという筆者個人の見解を時折挟んでいます。唯一の正解を示すものではなく、考え方の一例としてお読みください。

この記事について

概念編・実践編で、SLI/SLOを「どう定義し、どう計測するか」を扱いました。しかし、SLI/SLOは定義して計測できるようになった時点では、まだ半分しか完成していません。

実際に多くの現場で起きるのは、「SLI/SLOを作った」「ダッシュボードもできた」「でも誰も見ていない」「数ヶ月後には数値の意味を誰も説明できない」という状態です。
これは概念編で紹介した[アンチパターン9「作っただけで運用しない」]そのものであり、SLI/SLO導入で最もつまずきやすいポイントです。

SLI/SLOの本来の目的は、サービスの状態をきれいな数値で表すことではなく、ユーザーが受け取っている信頼性を可視化し、機能開発と信頼性改善のどちらに取り組むべきかを組織として判断できるようにすることです。
この記事では、SLI/SLOを一過性のプロジェクトで終わらせず、チームの日常業務に定着させ、継続的に育てていくための運用の型を紹介します。

想定読者

  • SLI/SLOを定義したものの、運用に乗せる段階でつまずいている、あるいはこれからつまずきそうな方
  • SREだけでSLI/SLOを作り、アプリケーションチームを巻き込めずにいる方
  • エラーバジェットをダッシュボードに表示しただけで、実際の意思決定に使えていない方
  • SLI/SLOのレビューを、負担なく継続できる仕組みにしたい方

この記事のゴール

  • SLI/SLOが定着しない典型的な原因を説明できる
  • SLI/SLOのオーナーシップをプロダクトチームに移し、SREと協働する体制を説明できる
  • エラーバジェットを「残量の表示」ではなく「意思決定の材料」として使う方法を説明できる
  • 「定点観測会」を1週間イテレーションで回す設計とその狙いを説明できる
  • SLI/SLOは一度決めて終わりではなく、継続的に見直し育てるものだと説明できる

1.なぜSLI/SLOは「作って終わり」になりやすいのか

SLI/SLOの導入は、多くの場合SREやプラットフォームチームが主導します。ここに定着を妨げる構造的な原因があります。

  • SREが設計・実装のほとんどを担い、アプリケーションチームは「決まったものを見せられる側」になりやすい
  • 定義した時点がゴールになってしまい、その後の運用プロセス(誰が・いつ・何を確認するか)が決まっていない
  • ダッシュボードは作られるが、それを見る会議体や意思決定のフックがない
  • 障害対応のような「待ったなし」の業務ではないため、優先度が下がりやすい

この結果、SLI/SLOは「SREが管理している資料」になり、リリース判断や日々の開発判断には使われなくなります。
これでは、概念編で述べた「SLOを使って、ユーザー体験と向き合い続ける」という本来の目的を果たせません。

優れたSLI/SLO運用では、メトリクスの精度以上に、次の問いに答えられることが重要です。

  • ユーザーにとって重要な体験は何か
  • 現在、その体験を正常に提供できているか
  • 信頼性が低下したとき、誰が何を判断するのか
  • どの程度まで低下したら、機能開発より改善を優先するのか

これらに答えるためには、次に説明するオーナーシップの設計です。

2.SLOのオーナーをプロダクトチームに置く

SLI/SLOが測っているのは、インフラの状態ではなくユーザー体験です。ユーザー体験に最も影響を与えるのは、多くの場合インフラの変更ではなく、アプリケーションのリリースです。
したがって、SLI/SLOの運用はSREだけでは完結しません。

SREだけで運用すると起きること

  • SLOが悪化した原因が、アプリケーションのロジックやリリース内容にあっても、SREだけでは特定できない
  • エラーバジェットが減っていても、リリースを止めるかどうかの意思決定権はアプリケーションチーム側にあるため、SREが把握していても止められない
  • 「このSLIで本当にユーザー体験を表せているか」という見直しには、機能仕様を知っているアプリケーションチームの視点が欠かせない
  • 対象サービスが増えるほど、SREが全サービスのSLI/SLOを設計・監視・改善する構造はスケールしない

役割分担の基本形

SREがすべてを担うのではなく、次のように役割を分けると持続しやすくなります。

役割 主な責務
プロダクトチーム ユーザーとプロダクトの理解、CUJの決定、SLO目標値への合意、SLO違反時の調査と改善、プロダクト変更に伴うSLIの更新
SRE / Platformチーム 導入ガイドやテンプレートの提供、計測・可視化基盤の提供、SLI/SLO設計の支援、横断的なレビュー、組織全体への展開支援

SREはSLI/SLOを「代行して運用する」のではなく、「各プロダクトチームが自分たちで運用できるように支援する」立場に回ります。

CUJはSREだけで決めない

Critical User Journeyの選定は、SREだけで完結させるべきではありません。プロダクトを深く理解している開発者、QA、CS、PdMなどと合意して決めることで、実態に即したジャーニーを選べます。
また、複数のマイクロサービスが個別に正常でも、ユーザーが目的を達成できなければサービスは正常とはいえません。

このように、巻き込みの目的は「報告を受けてもらう」ことではなく、「同じ数値を見て一緒に判断する」体制をつくることです。
それを日常的に実現する場が、後述する定点観測会になります。

3.エラーバジェットを実際の意思決定につなげる

SLI/SLOを定着させるうえで、最もつまずきやすいのがエラーバジェットの扱いです。エラーバジェットの残量をダッシュボードに表示しただけでは、運用しているとはいえません。
ここでは、エラーバジェットを実際の意思決定につなげるために大事なことを整理します。

残量ではなく「次に何をするか」を決める指標として使う

Google SREでは、エラーバジェットをSLOの未達を罰するための制度ではなく、信頼性が低下しているときに、機能開発よりも信頼性改善へ集中する許可をチームに与える仕組みとして説明しています。
つまり、エラーバジェットが示しているのは次のような問いに対する判断材料であり、単なる残量ではありません。

  • 現在の信頼性は、ユーザーにとって許容できる状態か
  • 新機能の開発やリリースを継続してよいか
  • 信頼性改善へ優先的にリソースを振り向けるべきか
  • 発生した障害を、どの程度の優先度で再発防止すべきか

バジェット超過時のアクションを先に決める

「エラーバジェットがなくなったら、そのとき考える」という運用では、実際に問題が起きたときに判断できません。
信頼性が低下している状況では、開発チーム・プロダクトオーナー・SRE・マネージャーの間で意見が分かれやすく、事後に議論すると、データではなく立場や声の大きさで判断されてしまいます。

そのため、SLOを定義するタイミングで、エラーバジェットポリシーとして次の項目を明文化しておきます。

  • 適用対象となるサービスとSLI
  • 評価期間
  • バジェット消費時のアクション
  • 判断する責任者
  • 例外として認める変更
  • 通常の開発へ戻す条件
  • 意見が分かれた場合のエスカレーション先

Googleのポリシー例でも、通常リリースの停止、セキュリティ修正などの例外、信頼性改善へ集中する条件、意見が分かれた際のエスカレーション先まで定義されています。
ポリシーの目的は罰則ではなく、繰り返されるSLO違反からユーザーを守り、信頼性と機能開発のバランスを取ることにあります。

リリース停止だけを選択肢にしない

エラーバジェットを使い切ったら、すべてのリリースを停止する。これは分かりやすいルールですが、あらゆる組織やサービスに機械的に適用できるわけではありません。
サービスの成熟度や事業状況によっては、次のような段階的なアクションも選択肢になります。

  • バジェット消費の原因を調査する
  • リスクの高い変更だけを延期する
  • カナリアリリースや段階的リリースを必須にする
  • 信頼性改善タスクの優先度を上げる
  • 開発リソースの一部を改善活動へ割り当てる
  • 一定期間、新規機能よりも障害対策を優先する
  • 必要に応じてリリースを停止する

重要なのは厳しいルールを作ることではなく、組織が実際に守れるルールを作り、信頼性の状態に応じて行動が変わることです。

残量だけでなく消費速度を見る

「概念編」で触れたとおり、エラーバジェットは残量だけでなく消費速度(Burn Rate)も合わせて確認する必要があります。運用の場では、この両方を定点観測会やアラートの基準として実際に使えるようにしておくことが重要です。

アラートについても同様で、瞬間的なエラー率だけで通知すると、月間SLOにはほとんど影響しない事象でも大量のアラートが発生し、対応不要な通知が増えて本当に重要な異常が埋もれてしまいます。
SLOベースのアラートでは、単純なエラー率ではなく、短時間の急激な消費と長時間の緩やかな消費をそれぞれ異なる期間で評価し、エラーバジェットをどの速度で消費しているかを基準にします。

具体的なアラームの組み方は「実践編」で扱ったとおりですが、導入初期から高度なバーンレートアラートを必須にする必要はなく、まず定期レビューを回し、リアルタイム対応が必要なSLOから段階的に導入すれば十分です。

原因とユーザー影響を確認して判断する

エラーバジェットを消費したからといって、すべてのケースで同じ対応を取る必要はありません。次のようなケースがあります。

  • 自チームのリリースによる不具合
  • 手順ミスによる障害
  • 外部サービスや共通基盤の障害
  • 負荷試験や脆弱性診断による意図的なエラー
  • 計測方法の誤り
  • ユーザー影響のないエラーを失敗として計上していた
  • ユーザー影響があったのにSLIへ反映されていなかった

同じバジェット消費でも、取るべきアクションは異なります。エラーバジェットを絶対的な判定装置として扱うのではなく、ユーザー影響と原因を確認するための共通言語として使うことが重要です。
Googleのポリシー例でも、自サービスの不具合や手順ミスと、他チームや全社ネットワークに起因する問題などを分けて扱っています。

4.定点観測会:小さく・高頻度に運用に乗せる

定点観測会とは、SREとアプリケーションチームが定期的に集まり、SLI/SLOの実績とエラーバジェットの消費状況を一緒に確認する場です。
上で整理したエラーバジェットの判断を、実際に「いつ・誰が」行うかを決める仕組みでもあります。

なぜ1週間イテレーションなのか

頻度 起きがちな問題
月次 問題の発生から発覚までが遅い。1ヶ月分の変化が大きすぎて、何が原因か特定しにくい
日次 開催・準備の負荷が高く、継続しにくい。1日単位ではノイズと本質的な劣化の区別がつきにくい
週次 リリースサイクルと合わせやすく、エラーバジェットの消費傾向を捉えるのに十分な粒度。準備負荷も小さく続けやすい

多くの開発チームのリリースサイクルは1〜2週間程度であるため、週次にすることで「先週のリリースがSLOにどう影響したか」をそのまま振り返れます。
これが、定点観測会を1週間イテレーションで回すことを勧める理由です。

進め方の例

所要時間: 15〜30分
参加者: 対象機能のSRE担当 + アプリケーションチーム(開発者・PdMなど)

1. 直近1週間のバジェット残量と消費速度を確認する
2. 主な消費原因を確認する(自チームのリリースか、外部要因か、計測誤りか)
3. ユーザーへの影響を確認する
4. 再発防止策の進捗を確認する
5. 目立った悪化や計測漏れがあれば、その場で原因の当たりをつける
6. 今後のリリース予定とエラーバジェットの残量を照らし合わせ、
   次の1週間で優先する信頼性改善とリリース方針をすり合わせる
7. SLI/SLOの見直しが必要か判断する

重要なのは、この会を「数値の報告会」にしないことです。エラーバジェットが十分残っていれば「今週は新機能のリリースを進めよう」、消費が早ければ「来週は信頼性改善を優先しよう」というように、その場で意思決定につなげます。
「信頼性が低下しています」で終わらせず、次のスプリントや期の計画に、具体的な改善タスクとして反映させるところまでが定点観測会の役割です。

小さく始める

いきなり全社的な仕組みにしようとすると、準備や合意形成の負荷が大きくなり、始める前に頓挫しがちです。まずは1つのCritical User Journey、1つのチームから始め、実際にリリース判断に使えることを体感してもらってから、対象を広げていくほうが定着しやすいです。

5.ステークホルダーに合わせてSLOを翻訳する

SLI、SLO、エラーバジェット、Burn Rateといった言葉を、関わる全員が同じレベルで理解する必要はありません。
むしろ、それぞれの役割が判断に必要な情報へ変換して伝えることが大切です。

相手 伝えるべき情報
CS どの機能が使えないか、影響を受けるユーザー、回避策、復旧見込み
プロダクトマネージャー どのユーザー体験が悪化しているか、改善しなかった場合の影響、機能開発と改善の優先順位
経営層 停止時間、影響ユーザー数、売上や契約への影響、信頼性改善に必要な投資、残されているリスク

SRE NEXT 2026の事例では、CSにはSLOの数値ではなくユーザー影響を示し、経営層には達成率だけでなく、停止時間や売上損失、残された障害の許容量として伝えるという使い分けが紹介されています。
CSや営業、経営層にSLI/SLOの用語をそのまま説明しても、「SREはエンジニアだけの話」という認識を強めてしまうだけです。用語を教えるのではなく、各ステークホルダーが判断するために必要な情報へ翻訳することを意識します。

6.SLI/SLOは育てるもの:見直しのタイミング

SLI/SLOは一度決めたら固定するものではありません。実践編で見たように、実際の環境に当てはめてみて初めて気づく計測漏れもありますし、プロダクトの画面・API・依存サービス・ユーザーの利用方法も変化し続けます。定点観測会は、この見直しを継続的に行う場でもあります。

見直しを検討すべき代表的なタイミングは、次のとおりです。

  1. 新しいCritical User Journeyが生まれたとき: 新機能のリリースにより、新たに守るべきユーザー体験が増えた場合
  2. 計測漏れが発覚したとき: 実践編のように、想定していなかった経路(今回でいうSSH経由のアクセスなど)が見つかった場合
  3. アーキテクチャや依存サービスが変わったとき: 実践編のALB/EC2構成のように、SLI Implementationの前提が変わった場合は測定方法自体を見直す必要がある
  4. 目標値が実態と合わなくなったとき: バジェットが常に余り続ける場合は目標が緩すぎる可能性があり、逆に毎回簡単に枯渇する場合は目標が厳しすぎるか、根本的な信頼性課題を抱えている可能性がある
  5. SLOと現実が乖離しているとき: 大きな障害が発生してもバジェットがほとんど消費されない、SLOを達成しているのに問い合わせが増えている、といった場合はSLIがユーザー体験を表せていないサイン
  6. ビジネス上の重要度が変わったとき: 機能の位置づけが変わり、優先すべきCritical User Journeyの順位が変わった場合

「大きな障害があったのにバジェットが減っていない」という状態は、サービスの信頼性が高いのではなく、計測が不十分な可能性があります。

見直しの際は、問い直しを行い、インシデントや問い合わせを振り返って、ユーザー影響がSLIに正しく反映されていたかを確認します。

メルカリの事例では、アプリケーションの変化に伴ってクリティカルなAPIも変わるため、探索とモニタリングへの反映を自動化しています。

SLOと現実が乖離すると意味がなくなるため、更新し続ける仕組みそのものを整えておくことも有効です。

見直しの際は、概念編の型(User Journey → SLI Specification → SLI Implementation → SLO → 計測漏れ確認 → 運用判断)に立ち戻り、どの段階を変えるべきかを整理してから進めると、場当たり的な数値の調整に陥りにくくなります。

7.運用フェーズのアンチパターン

7-1. ダッシュボードを作って満足する

エラーバジェットやSLOの残量をダッシュボードに表示しただけでは、運用とはいえません。減ったときに誰が確認し、何を判断し、どのようなアクションを取るのかが決まっていなければ、単なる観測値です。

改善策: ダッシュボードと同時に、責任者・レビュー頻度・判断基準・具体的なアクションを決めます。スプリントレビューや月次運用会議など、既存の意思決定プロセスにSLO確認を組み込むのも有効です。

7-2. SREだけで運用する

SLI/SLOは、SREチームだけで完結する仕組みではありません。機能開発を続けるか信頼性改善を優先するかという判断には、開発チームやプロダクトオーナー、事業責任者も関係します。SREだけが数値を確認し改善を依頼する形では、信頼性が「SREの仕事」になってしまいます。

改善策: SLOとエラーバジェットポリシーの策定段階から、開発チームとプロダクト側を巻き込みます。プロダクトチームが信頼性のオーナーとなり、SREは基盤提供とイネイブリングに徹します。

7-3. バジェット超過やSLO違反を罰として扱う

超過や違反をチームや個人の失敗として評価すると、正確な計測や障害報告が行われにくくなります。リリース停止が懲罰のように受け取られると、SLOそのものへの反発も生まれ、目標値を不自然に緩めたり都合の悪いデータを除外したりする動きにつながります。

改善策: エラーバジェットは、誰かを責めるためではなく、信頼性改善へ集中するための根拠として扱います。「開発を止めさせられた」ではなく「信頼性へ投資することが組織として認められた」と捉えられる状態を目指します。

7-4. 重要度に関係なくすべてにSLOを設定する、または一律のポリシーを適用する

すべてのAPI・バッチ・画面にSLOを作ると、どれを見ればよいのか分からなくなり、レビューや改善が回らなくなります。
また、実験段階のサービスと決済などの重要サービスに同じSLOやリリース停止ルールを適用すると、過剰な運用負荷や事業状況と合わない判断につながります。

改善策: ユーザーにとって失敗すると特に困る体験から優先します。サービスのライフサイクル・ユーザー影響・事業上の重要度・運用体制に応じてポリシーを変えます。

7-5. 根拠のない目標値、または100%を目指す

「業界でよく見る数値だから」という理由だけで99.9%や99.99%を設定すると、高すぎれば常に違反し、低すぎればユーザーの不満を捉えられません。
また、バジェットを減らさないこと自体が目標になると、変更やリリースを過度に避けるようになります。

改善策: 現在の実績値・ユーザーの期待・ビジネス上の影響・改善コスト・依存サービスの信頼性をもとに暫定値として設定し、運用後に調整します。目指すのは「バジェットを使わない」ことではなく「ユーザーが許容できる範囲で適切に使う」ことです。

7-6. 枯渇するまで何もしない

残量がゼロになってから対策を始めると、改善が間に合いません。特に短時間で大量に消費している場合、期間全体の残量だけを見ていては検知が遅れます。

改善策: Burn Rateや消費傾向を確認し、枯渇前に調査や改善を開始する段階的なルールを設けます。

7-7. ポリシーの例外が増え続ける

「リリースを止められない」「納期が近い」「重要な機能だから」という理由で毎回例外を認めると、ポリシーは形骸化します。守れないルールは、ルールが厳しすぎるか、組織として信頼性を優先する合意ができていないサインです。

改善策: 例外を認めた場合は理由・承認者・リスク・期限を記録します。例外が繰り返される場合は、個別判断で済ませずポリシー自体を見直します。

7-8. SLIの妥当性を疑わない、SLO達成そのものを目的にする

計測が正確でも、SLIがユーザー体験を表していなければ意味がありません。SLOを達成するために計測対象から失敗を除外したり、目標値を恣意的に下げたりすると、達成していてもユーザーが困っている状態を見逃します。

改善策: 「SLOを達成したか」だけでなく、問い合わせ・解約・ユーザーの声・インシデントと照合し、指標が現実を表しているかを定期的に確認します。

7-9. 全員に同じレベルでSRE用語を理解させようとする

CSや営業、経営層に対してSLI・SLO・Burn Rate・MTTRなどをそのまま説明すると、相手の業務に必要でない知識を押し付けることになり、「SREはエンジニアだけの話」という認識を強めてしまいます。

改善策: 用語を教えるのではなく、前述の「ステークホルダーに合わせてSLOを翻訳する」のとおり、各ステークホルダーが判断するために必要な情報へ変換して伝えます。

8.小さく始める運用

最初から完璧な仕組みを作る必要はありません。初回からすべての機能を対象にし、精密なエラーバジェット、バーンレートアラート、リリース制御まで導入しようとすると、運用開始までの負担が大きくなります。

たとえば、次のような段階から始められます。

  1. 可視化する: 重要なプロダクトを一つ選び、CUJを一つから数個に絞り、AvailabilityまたはLatencyから、既に取得できるメトリクスを使って始める
  2. 定期的に会話する: 週次や月次で、開発チームとプロダクトオーナーを交えてSLOレビュー(定点観測会)を行う
  3. 軽いアクションを決める: バジェット消費時には、まず原因調査・改善タスクの登録・リスクの高い変更の確認などを行う
  4. 開発計画へ反映する: 運用実績をもとに、一定の消費量を超えた場合は信頼性改善へリソースを割り当てる
  5. 必要に応じて強い制約を設ける: 組織内で合意できるようになった段階で、リリース制限や信頼性改善の優先ルールを導入する

多数のチームへ展開する場合は、当初はエラーバジェットやバーンレートアラートを省き、「SLOに違反しているか」「次のスプリントで対応するか」というシンプルな運用から開始するのもありでしょう。

一方で、SLO違反に対するチケットは作成されても機能開発が優先され、改善がスプリントに入らないという問題も発生します。

理念を理解するだけでなく、計画や優先順位の決定方法まで合意する必要があります。

GoogleのSRE Workbookでも、最初は対象アプリケーションとユーザーを明確にし、重要な操作を整理したうえで、関連性があり計測しやすい指標から始め、後から改善することが推奨されています。重要なのは、最初から高度な仕組みを完成させることではなく、信頼性を定期的に確認し、意思決定する習慣を作ることです。

9.推奨する運用サイクル

ここまでの内容は、実際には次のサイクルとして繰り返すことになります。

1. ユーザーとCUJを定義する
2. CUJの成功を表すSLIを選ぶ
3. 実績値とビジネス要件から暫定SLOを設定する
4. オーナーとSLO違反時の行動を決める(エラーバジェットポリシー)
5. ダッシュボードと必要最小限のアラートを整備する
6. 定点観測会でSLOを確認する(週次目安)
7. 違反時は原因とユーザー影響を分析する
8. 改善を開発計画へ反映する
9. SLI、SLO、CUJ自体の妥当性を見直す

このサイクルは1周で終わるものではなく、9から1へ戻って回り続けるものだと捉えてください。図にすると次のようになります。

10.まとめ

SLI/SLOは、定義して計測できるようになった時点ではまだ半分しか完成していません。運用に定着させ、育て続けて初めて価値を発揮します。よいSLI/SLO運用には、次の特徴があります。

  • ユーザー体験を起点としている
  • SLO違反・バジェット超過時の行動が事前に決まっている
  • プロダクトチームがオーナーシップを持っている
  • 残量だけでなく消費速度と原因・ユーザー影響を踏まえて判断している
  • 定期的な意思決定(定点観測会)に使われている
  • ステークホルダーごとに適切な言葉へ翻訳されている
  • プロダクトの変化に合わせてSLI・SLO・ポリシーが更新されている
  • 最初から完璧を求めず、段階的に成熟させている

SLI/SLOは監視の仕組みではなく、信頼性について組織で意思決定するための仕組みとして運用することが重要です。概念編・実践編・運用編を通じて共通しているメッセージは、SLI/SLOは「正しい数値を作ること」がゴールではなく、ユーザー体験と向き合い続けるための仕組みだということです。

コラム:Platform SREがOSSを運用するときの違い

ここまでの「プロダクトチームにオーナーシップを置く」という話は、自社で開発しているサービスや内製で開発していれば素直に当てはまります。
しかし、実践編で扱ったSelf-hosted GitLabのように、自分たちが開発していないOSSを運用するPlatform SREの立場では、いくつか事情が変わります。

「プロダクトチーム」に相当する相手がいない

自社サービスなら、CUJの言語化や「何を成功とするか」の判断を、機能を作った開発チームと一緒に詰められます。
しかしGitLabのようなOSSでは、本来の開発元はGitLab Inc.やコミュニティであり、自社の定点観測会に呼んで一緒に判断してもらうことはできません。

その代わりになるのは、社内でGitLabを日常的に使っている開発者です。彼らは仕様を作った当事者ではありませんが、「push/pullが遅いと何が困るか」「CI/CDが詰まると開発がどれだけ止まるか」を最も具体的に語れるヘビーユーザーであり、CUJの選定やSLOの目標値合意はこうしたヘビーユーザーを巻き込んで進めます。
実践編の環境で、Platform SREチームが「プロダクトチーム」の役割も兼ねているのはこのためです。

仕様書ではなく、実装とコミュニティの一次情報を頼りにする

自社サービスであれば、仕様書やコードオーナーに直接確認しながらSLI Implementationを詰められます。
OSSの場合、公式ドキュメント・ソースコード・Issue Tracker・リリースノートを自分たちで読み解いて、「何が成功で、何が失敗か」を定義する必要があります。
実践編で、gitlab-shellのログ内容やRunnerのジョブステータスをSLI Implementationの根拠にしたのはこのためです。

ログ・メトリクスの形式を自由に変えられない

自社サービスであれば、SLIを計測しやすいようにログ出力自体を変更できます。OSSでは基本的にアップストリームの出力形式に従うしかなく、独自の情報を追加したい場合はフォークやパッチという選択肢になります。
ただしその分、アップストリームの変更に追従し続けるメンテナンスコストが発生するため、パッチを当ててまで計測精度を上げるかどうかは、運用コストとのトレードオフで判断します。

バージョンアップでSLI Implementationの前提が崩れることがある

アップストリームのリリースで、ログのフィールド名やメトリクス名、内部の挙動が変わることがあります。
自社サービスであれば変更を事前に把握できますが、OSSでは変更履歴やリリースノートを継続的にウォッチする役割が別途必要になります。
バージョンアップの前には、SLI Implementationが前提にしているログ形式やAPIの挙動に変更がないかを確認しておくと安心です。

障害原因の切り分けに「アップストリーム起因」という第三のカテゴリが加わる

後述する「原因とユーザー影響を確認して判断する」で挙げた原因の分類(自チームのリリース、手順ミス、外部要因など)に加えて、OSSの運用では「OSS自体のバグで、自チームでは直せない」というカテゴリが加わります。この場合、修正はアップストリームへの報告と取り込み待ちになるため、エラーバジェットポリシーの「例外として認める変更」や「通常運用へ戻す条件」に、「アップストリームでの修正リリースを待つ」状態をあらかじめ想定しておくと、原因が分かってから対応方針で迷うことが減ります。

OSSのエラーバジェットが枯渇したときの扱い

自社サービスであれば、バジェットを使い切ったときの標準的な選択肢は「リスクの高い変更を延期する」「新機能より信頼性改善を優先する」といった、自分たちの開発行為を止める・絞るという形を取れます。
しかしOSSを運用している場合、そもそも枯渇の原因が自チームの変更ではなく、OSS自体のバグであることが珍しくありません。この場合、原因がどちらにあるかで打ち手を分けて考えます。

原因が自分たちの運用・設定にある場合

Runner ASGのスケーリング設定、EBSのスループット、CloudWatchの計測設定など、自分たちがコントロールできる部分が原因であれば、通常のエラーバジェットポリシーと同じように、変更の延期や改善タスクの優先度引き上げで対応します。

原因がOSS自体のバグにある場合

自チームでは直接修正できないため、「リリースを止める」に相当する打ち手がありません。代わりに、次のような段階的な対応を取ります。

  • 当面の緩和策(ワークアラウンド、リトライ設定、タイムアウト延長、既知の問題として社内へ周知)を先に打ち、ユーザー影響を小さくする
  • 影響のあるバージョンへのアップグレードを見送り、現行の安定版に留める(まだ上げていない場合)
  • 有償サポート契約があれば、そのサポート窓口をエスカレーション先として使う
  • コミュニティのIssue Trackerへの報告状況を確認し、修正の見込み時期を追跡する
  • どうしても影響が大きい場合は、フォークして独自にパッチを当てるかどうかを、その分発生するメンテナンスコストと天秤にかけて判断する

この状態では、「通常運用へ戻す条件」を「エラーバジェットが回復すること」ではなく「アップストリームの修正がリリースされ、動作確認が完了すること」のように、自チームの外側に依存する条件として定義しておく必要があります。
これを事前に決めておかないと、バジェットが消費され続けているのに誰も手を打てない状態が長期化してしまいます。

ここまでの判断の流れを図にすると、次のようになります。

関連記事

Discussion