chroju.dev/blog

the world as code

Apdexという指標 - State of SRE Report 2022 を読んだ

#sre#slo
State of SRE Report: 2022 Edition | Dynatrace
We asked 450 SREs across a range of industries to share their unfiltered perspective into how site reliability engineering (SRE) is evolving as a discipline.
State of SRE Report: 2022 Edition | Dynatrace favicon https://www.dynatrace.com/info/sre-report/
State of SRE Report: 2022 Edition | Dynatrace

APMなどを提供する Dynatrace が公開している、State of SRE Report 2022を読んだ。Dynatraceがグローバルに450社に対して調査を行った結果をまとめている。なおグローバルとはいえ調査対象の33%がアメリカでほとんどが欧米、日本は対象に入っておらず、偏りはあると考えたほうが良さそうではあった。企業規模でもグローバル企業が中心のためか、3000人未満の会社は1割程度で、3割の会社が20000人を超えており、大企業がほとんどとなっている。

このレポートではSRE発足から2年以上を経過している企業をMaturing、5年以上をAdvancedと定義しているが、前者が42%、後者が20%となっていた。『サイトリライアビリティエンジニアリング』日本語版が発刊されたのが2017年なので、5年以上SREをやっている企業は、本邦だと2割にも及ばないのではないかという感覚がある。そう考えるとSREはやはり、まだまだ探求が続けられている職種であり、こういった実情を調査するレポートがあるのはありがたい。

Apdex

このレポートで初めて知った概念の1つに Apdex があった。ユーザー満足度を示す指標であり、調べたところ2004〜5年頃よりあるものらしい。

ざっくり概要を示すと、こんな指標である。

  • レスポンスタイムの閾値 T を定義し、レスポンスタイムが t のときのユーザーの満足度を以下のように考える
    • T >= t : 満足
    • 4T >= t > T : 許容
    • t >= 4T 、あるいはエラーの場合 : 不満足
  • Apdexスコアは全リクエストに対する割合で0〜1の数値で示される
  • 「満足」だったリクエストは1、「許容」だったリクエストは0.5としてカウントする

レスポンスタイムの閾値を設けるのはよくある話だが、満足度にグラデーションを設けている点と、エラーレスポンスを加味している点がポイントになる。確かに、単にレスポンスタイムだけを元にして考えると、素早く503を返したレスポンスもOKな扱いになってしまう。

このレポートではSLIの例をいくつかピックアップしており、その1つとしてApdexが挙げられていた。2段階の閾値を設けることになるので検討は難しくなるが、よりユーザー中心でレスポンスの満足/不満足を考える上では参考になりそうに思う。調べたところ、New RelicもDatadogもApdexの算出には対応しているらしい。

また、レポートで挙げられているSLIの例は、Business SLOsとPerformance SLOsに分類されていた。どのようなSLOを設けるにせよ、最終的にはビジネス的な価値に結びついていなくてはならないと考えているので、この分類はするっと飲み込めない部分もあった。が、SLOを考える際に、その指標は直接的にビジネス的な、ユーザーと密接にかかわる指標なのか、単なるパフォーマンス指標なのかという観点はあってよさそうに感じた。

その他

その他、気になったところをいくつかピックアップしておく。

  • SREはcultural changeである。
  • セキュリティは信頼性の主軸であり、DevSecOpsへより注力したいと考えているSREが過半。
  • 信頼性に関するKPIを達成した際に、specific bonuses/rewardsが出る企業が76%。
    • SLOではなく KPIs around reliability と書いているので、単純に信頼性を守れたかというより、チャレンジングな指標を達成できたかではないかと思う。
    • いずれにせよ、「信頼性を守っても当たり前品質として扱われてしまう」という不満の解決策としてはアリかなと思う。
  • SLOを設定するにあたり、99%のSREが何らかの困難に直面している。
    • サイロ化したチーム構成によるツールの細分化、複雑化するアプリケーションに適切なSLOを設定することなど。
  • SREを採用すること、育成すること、いずれも困難と感じているSREが多く、またそのことを組織的な共通認識にすることも難しく感じている。
  • 将来的にAIOpsがSREプラクティスにとって大きな鍵になるのではないか。
    • 信頼性劣化に対するプロアクティブなアプローチへの活用、など。