サービスレベルのレビューでは、ユーザーがどのようなサービスを受けられたのか、合意した目標と比べてどうだったのか、次に何をすべきかを説明します。達成率が緑色で表示されているだけでは不十分です。何を数えた値なのか、どの期間を対象にしているのか、一部のユーザーが全体の数値からは見えない深刻な影響を受けていないかまで伝える必要があります。

冒頭には、聞き手が検討できる主張を置きましょう。「問い合わせ送信の成功率は目標を達成しました。ただし、失敗の大半は1件の障害に集中しています。目標値を引き上げる前に、この失敗経路を調査することを提案します」。その後に計算と影響を受けた操作を示します。説明のない12個の数値が並ぶダッシュボードの画像から始めるより、議論につながる構成です。

確認済みのレビュー用メモは、Presentiのテキストからプレゼン資料を作成する機能で編集可能な資料にまとめられます。根拠には監視システムやサポートシステムの記録を使ってください。Presentiが支援するのはスライドの整理と編集であり、サービスのテレメトリ収集やSLO達成の判定ではありません。

サービスレベルレビュー資料の作り方：SLOとエラーバジェット

対象サービス、指標、期間を定義する

レビューの範囲は、ユーザーの1つの操作、その操作を支えるサービス、報告対象期間に絞ります。問い合わせの送信しか測っていないのに「プラットフォーム全体の信頼性」と呼ぶのは広すぎます。送信の成功だけでは、ログイン、検索、通知も正常だったとはいえません。

最初の結果スライドか、その横の小さな用語欄で3つの言葉を説明します。Google SREのサービスレベル目標の解説では、測定値、目標、合意を区別しています。

レビューで役割が異なる3つの用語
用語意味示す内容
SLI：サービスレベル指標サービスの動作を定量的に測る指標。測定結果と、その計算方法。
SLO：サービスレベル目標定められた期間における、その指標の目標。合意したしきい値、対象範囲、時間窓。
SLA：サービスレベル合意サービスに関する約束を満たさなかった場合の対応も含む合意。契約上の履行も確認する場合は、適用される合意文書と、その文書で定めた測定条件。

パーセント値が似ているという理由だけで、内部のSLOの結果を「SLA遵守」と表示してはいけません。SLAでは、対象サービス、除外条件、計算期間が異なる場合があります。運用上の測定結果と契約上の評価は分けてください。スライドだけで契約違反やサービスクレジットを受ける権利が確定するわけではありません。

計算例：問い合わせ送信サービス

以下のサービス、記録、数値はすべて架空です。レビュー資料の作り方を示すための例であり、Presentiの稼働実績や実在する顧客の事例ではありません。

あるサポート基盤が、顧客による新規問い合わせの送信状況を確認しています。この例で合意済みの成功率SLOは、固定の28日間で99.90%です。次の測定定義は付録に隠さず、結果の隣に置きます。

レビューで使う測定定義の例
項目この例での定義
ユーザーの操作新しい問い合わせを送信し、利用可能な問い合わせIDを受け取る。
期間9月1日00:00 UTCから9月29日00:00 UTCの直前まで。終了時点を含まない、丸28日間。
集計対象のイベント認証済みで形式が正しく、ゲートウェイが受け付けた本番の送信試行。試行ごとに固有のリクエストIDを持つ。
成功イベント問い合わせが保存され、送信元のクライアントに利用可能な問い合わせIDが返される。
除外するトラフィックヘルスチェック、識別済みのテスト用通信、事前合意した集計条件に該当しないリクエスト。条件はレビュー期間が始まる前に定めている。
根拠変更せず保存したゲートウェイのエクスポートと、リクエストIDで突き合わせた問い合わせサービスの処理結果。資料にはクエリのバージョンと抽出時刻を添える。
測定できない範囲リクエストがゲートウェイに届く前の失敗は、このSLIには含まれない。

分母は顧客数ではなく、送信を試みた回数です。この定義では、再試行も別の1回として数えます。1人の顧客が合計10回の送信を試みた場合、記録されるのは10イベントであって、影響を受けた顧客10人ではありません。グラフのラベルでも発表者ノートでも、この違いを保ちます。

測定できない範囲も重要です。ログイン画面に不具合があれば、顧客はゲートウェイまで到達できないのに、SLIだけは良好に見えることがあります。その不足を結果に併記し、より広い操作の流れには別の証拠を使ってください。期間終了後に失敗リクエストを除外して、達成率をよく見せてはいけません。

色だけでなく、エラーバジェットの計算を示す

GoogleのSLO導入ガイドでは、イベントベースの指標を成功イベント数÷総イベント数で表しています。目標が100%未満なら、その差が許容される失敗イベントの割合です。今回の確定済み期間では、次のように計算します。

架空の成功率とエラーバジェットの計算
項目計算結果
対象となる試行数対象範囲内のリクエストID数2,000,000
成功した試行数成功が確認できた処理結果1,998,600
失敗した試行数2,000,000 − 1,998,6001,400
測定した成功率1,998,600 ÷ 2,000,000 × 10099.93%
許容される失敗数2,000,000 × (1 − 0.9990)2,000
バジェット消費率1,400 ÷ 2,000 × 10070%
この期間の未使用分2,000 − 1,400600回

99.93%は99.90%を上回るため、成功率の目標は達成しています。差は0.03パーセントポイントです。使ったのは許容失敗数の70%であり、全リクエストの70%ではありません。

残り600回の表現にも注意します。これは終了した報告期間の値であって、翌月に600回失敗させてよいという意味ではありません。本番のSLOをローリングウィンドウで管理しているなら、その時点の窓で別途計算が必要です。また、イベント数によるバジェットは、分単位の許容停止時間ではありません。トラフィックが多い1分間と少ない1分間では、失敗回数が大きく異なる可能性があります。

元データには丸め前の値を残し、スライドでは丸め方を統一します。しきい値に近い結果を丸めて、不達を達成に見せないようにしてください。後から別の人が再計算できるよう、クエリと対象期間を資料と一緒に保管します。

失敗が誰に影響したのかを説明する

架空の記録では、失敗1,400回のうち1,200回が1件の障害に起因しています。この1,200回には、異なる140個のアカウントIDが紐づいています。したがって、この障害だけで期間全体のエラーバジェットの60%を消費しました。計算は1,200÷2,000です。残りの失敗200回が、さらに10%を消費しています。

影響を示すスライドの見出しは、「1件の障害がエラーバジェットの大半を消費し、140アカウントに影響」とできます。ただし、「140人が仕事をできなかった」「問い合わせ1,200件が失われた」とは言えません。1つのアカウントを複数の人が使う場合があり、複数回の試行が同じ問い合わせを送ろうとした記録かもしれず、失敗回数だけでは最終的に問い合わせが作成されたかどうかも分からないためです。

数字の隣には、影響を受けた操作を示します。この例では、障害中に顧客が問い合わせの受付確認を安定して受け取れませんでした。その後の行動を理解するうえでサポート記録は参考になりますが、少数のやり取りを全アカウントに当てはめてはいけません。

影響の欄は、次の3行にまとめられます。

  • 確認できたこと：障害に紐づく失敗試行1,200回と、その記録に含まれる140個の異なるアカウントID。
  • 未確認：後で再送に成功せず、送信自体を諦めた問い合わせの数。
  • 次の調査：離脱件数を報告する前に、試行記録と最終的な問い合わせ作成結果を突き合わせる。

全体の達成率とユーザーへの影響を並べるのは、このためです。目標を達成したかどうかと、特定の操作に被害が集中したかどうかは別の問いです。どちらか一方で、もう一方を打ち消すべきではありません。

実際のPresenti編集画面を枠にした架空のサービスレビュー。成功率99.93%、エラーバジェット消費70%、影響を受けたアカウント数を分けて示す。
実際のPresenti編集画面の枠に、編集部が作成した架空の事例スライドを合成した図です。Presentiが実際に生成した結果を記録した画像ではありません。 画像を拡大して見る

結果を信頼性への投資判断につなげる

レビューは、できるだけ高い目標値を選ぶ競争ではありません。観測した問題にどの対応が有効なのか、何がその根拠なのか、代わりに何の作業を後回しにするのかを問います。99.90%から99.99%への変更を提案するだけでは、サービスは改善しません。

この例では、サービス責任者が次の選択肢を比較できます。

架空のレビューから検討できる選択肢
選択肢対応する問題追加の実施を決める前に必要な根拠
失敗が集中した経路を調査する失敗試行1,200回を発生させた障害。再現可能な不具合と、複数の緩和策を比較する試験。時刻の一致だけで原因を断定しない。
ゲートウェイより手前まで測定を広げる顧客のブラウザと現在のSLIの間にある見えない範囲。測定範囲、データの扱い、実装工数を示した、範囲の明確な提案。
今すぐSLOを厳しくするより高い信頼性へのコミットメント。新しい目標がユーザーのニーズに合うという根拠と、追加の信頼性向上作業について合意した計画。

最初の2案は、今回の具体的な発見に対応しています。3案目には、期待する水準と費用について別の判断が必要です。報告を緑色にするため黙って目標を下げたり、資料を意欲的に見せるだけの理由で引き上げたりしてはいけません。

すでにエラーバジェットの運用方針があるなら、その方針が要求する対応と、例外を承認できる人を示します。方針がない場合は、あくまで提案として提示してください。発表者が自動的なリリース停止ルールを作り、全員が合意済みであるかのように扱うべきではありません。

会議後も使える6枚のレビュー資料にまとめる

詳細を証拠資料に分ければ、発表用のスライドはコンパクトにできます。各スライドの役割を1つに絞ります。

  1. 結果と判断事項：目標99.90%に対して成功率99.93%。失敗が集中した1件の障害と、承認してほしい具体的な作業。
  2. 測定範囲：ユーザーの操作、日付、対象イベントと成功イベント、情報源、測定できない範囲。
  3. バジェット：分子、分母、許容失敗数、消費率70%の計算。
  4. ユーザーへの影響：影響を受けた操作、観測された140個のアカウントID、未確認事項。
  5. 選択肢：候補となる対応、それぞれに必要な根拠、代わりに後回しになる作業。
  6. 決定記録：責任者、承認範囲、次のレビュー時点、その場で確認する証拠。

メトリクスのエクスポートとクエリの詳細は資料と一緒に保管しますが、顧客の個人情報をスライドに転記しないようにします。広い範囲に共有する場合は、識別情報を除いた影響サマリーを使います。定義変更を提案するなら将来のバージョンとして示し、今回の結果には今回使った定義を紐づけたままにします。

架空の会議における決定記録は、次のように書けます。

サービス責任者を担当として、問い合わせの受付確認が失敗する経路の調査に2人日を割り当てる。再現手順、緩和策の候補、試験の結果を提示すること。この時点では、将来の失敗が減るとは主張しない。成功率SLOは99.90%のままとする。次回のレビューでは、ゲートウェイに到達する前の送信失敗を測るための、範囲を明確にした提案も提示する。調査を超える実装には、別途リソース配分の判断が必要となる。

この記録があれば、次の会議を具体的な地点から始められます。同じ緑色の達成率を見せて同じ約束を繰り返すのではなく、定義した作業から得られた証拠を確認できます。