Re:ゼロからもう一度考えるSLI/SLO |【連載 第0回】

はじめに

Re:ゼロからもう一度考えるSLI/SLO にようこそ。 これは、信頼性に向き合うすべての人に向けた連載企画です。

SLI/SLOとは?

SLI(Service Level Indicator: SLI)とは、サービス全体がどの程度の信頼性をもつかを示す指標であり、SLO(Service Level Objective: SLO)とは、サービス提供者が設けたSLIの基準値よりも、定められた期間の間、高い状態を維持することを目標とするものです。


SLOは、信頼性を向上する取り組み(通称 SREプラクティス)で序盤に登場する概念です。

私の経験上、SLOはくせ者です。今まで在籍した組織での導入を経験してきましたが、一筋縄ではいきません。例えば、SLI/SLOを導入したものの、運用に手こずっている組織も多いのではないでしょうか。

SLI/SLO自体はただの目標管理であるため、導入自体は一見簡単に見えますが、実はその後の運用で問題が発生しがちです。

  • 【SLI/SLOを導入したものの、運用に手こずっているとき】
    • 何を計測して、どう目標値にするかわかりにくい。結果、消滅したりなんとなく運用している
    • 過度に高い目標値が設定されているため、現場とのギャップがあり運用が困難
    • 導入してみたものの、うまく利用できている気がしない。"ただあるだけ"になっている

なぜこのような状況になるのか?その課題はどこにあるだろう?と考えてきました。

その回答のひとつとして「立場によって、SLOについて認識が異なる(or ない)のではないか」と思っています。バズワードとして広く利用されるようになったため、独自の解釈が生まれているでしょう。

導入後における、ばらばらの認識となっている例をあげてみます。

  • (SRE)SLOというものが必要らしいのでまずは設定しよう
  • (開発責任者)SLOをKPIにして99.x%を死守しよう。そうすればシステムはより安定するし、顧客は満足するはずだ
  • (開発者)SLOというのを守るといいらしい。サービスがよりよくなるなら特に反対意見はない。SREの手伝いをすればいいのかな?

認識が異なるケースの一例
認識が異なるケースの一例

お察しの通り、SLOがあればサービスが安定するかは不明です。ただ設定しただけでも、それははじめの一歩を踏み出したに過ぎません。
ただデータが揃っただけであり、その数字が勝手に何かをしてくれるわけではないからです。

このように、各登場人物のSLOに対する認識が異なるために、SLOの運用を複雑化させている一端を担っているのではないかと思います。 もちろんほかにも複雑な要因はありますが、ともあれスタート地点は「合意形成をする範囲内で正しく共通認識が取れていない」のではないかと考えています。
※SRE本人が勘違いしているケースがないとも言い切れません。

関係者間でSLOの存在が薄くなっていく例
関係者間でSLOの存在が薄くなっていく例

そこで、本シリーズではSLOを如何にして導入・運用するのが良いのか、考えをまとめていきたいと思います。

読者対象

  • SLOはなぜ必要なのか知りたい人
  • SLI/SLOを導入しようとしている人
  • SLO/SLOについて理解を深めて自社で展開したい人

このシリーズ記事の読み方

連載企画のため、随時更新していきます。

ゼロからもう一度考えるためにも、単にSLI/SLOを導入・運用するのではなくその手前にあるコミュニケーションといった問題にも切り込んでいければと思います。

⏬️ Topotal Blogの購読ボタンをClick!

blog.hatena.ne.jp

監修: @yuuk1t 氏

このSLI/SLOをもう一度考えるにあたり、Topotalテクノロジーアドバイザーのyuuk1氏に監修いただいております。

SRE (Site Reliability Engineering) の研究者。博士(情報学)。さくらインターネット研究所。Topotalテクノロジアドバイザー。

https://x.com/yuuk1t

インデックス

※随時更新