SLOを作ろうとしているのですが、最初の一歩でつまずいています。
プロダクトのどの振る舞いをSLIにすべきか、可用性・レイテンシ・正確性のどれを優先するか、判断軸が定まらず迷っています。
たとえば、今の現場では「サイトは落ちてはいけない」という期待だけが先行していて、ビジネス側・エンジニア側で“信頼性のライン” がバラバラです。
話し合おうとしても、
「この指標は誰のため？」
「その数値にした根拠は？」
「本当にそこまで信頼性を上げる必要があるの？」
と議論が発散しがちで、進め方が見えません。
また、エラーバジェットの話をすると「それは障害を許容するということ？」とネガティブに受け取られることもあり、どう扱うべきか悩んでいます。
最初のSLOをどのように定義し、どの順番でステークホルダーと認識をそろえていくのが良かったか、皆さんの経験や工夫をぜひ聞きたいです。
- SRE見習い が 6か月前 に質問しました
- 最終編集日 6か月前
- コメントを投稿するにはログインする必要があります
正直、この質問めちゃくちゃ気持ちわかります。
SLOって「どの指標？」から入ると必ず迷子になるんですよね。
僕も最初まったく同じところで詰まりました。
■結論
- 最初に決めるのは指標ではなく「守りたいユーザー体験」
- 可用性・レイテンシ・正確性は“体験”と“現場の痛み”を重ねると自動的に絞れる
- 最初のSLOは“数字の確定”ではなく“幅”でOK（99.0〜99.5% みたいな）
- エラーバジェットは“責める”ではなく“優先度の話を円滑にするための仕組み”
- 完璧なSLOは絶対作れないので、“選んだ理由のログ”を残すのが最強
僕も昔、まったく同じように「SLI何にする？可用性？レイテンシ？」みたいな議論から始めてしまい、チーム全体で沼りました。
特に、「この数値の根拠は？」「誰のため？」みたいな話が発散しがちで、会話がぜんぜんまとまらない。
そこでやり方を変えて、技術用語をいったん封印し、「どこが壊れると一番困る？」だけを話す ところから始めました。
すると不思議なことに、「ローディングの最後が遅い」「決済だけは絶対落とせない」「ログインが重いと離脱される」
みたいな“みんなが共通して守りたい体験”がスッと出てくるんですよ。
そこに 現状の観測（実データ） を重ねたら、「じゃあ優先すべきはこれとこれだよね」とSLI候補が自然に1〜3個に絞れて、あの発散がピタッと止まりました。
また、エラーバジェットは当時すごく誤解されましたが、
「障害を許すための仕組みじゃなくて、“優先順位を決めるための会話のルール”です」
と説明したら、一気に通りやすくなった経験もあります。
最後に言うと、最初のSLOは絶対にズレます。
だから一番大事なのは“理由のログ”を残すこと。「なぜこれにしたのか」「あとからズレた理由は何か」。これがあるだけで改善が超ラクになります。
もし僕の経験からひとつだけ言うなら、
最初の一歩は指標選びじゃなくて、「壊れたら困る体験って何？」の言語化からではないでしょうか？
- コメントを投稿するにはログインする必要があります