【CREウィーク月曜日】toC サービスの CRE における SLO の考え方
※こちらの記事は過去のブログから転載したものです。
はじめに
こんにちは。XFLAG スタジオ CRE チームの豊川です。
CRE ウィークと題して、今日から CRE チームのメンバー5名が月曜日から日替わりでそれぞれエントリを書いていきます。
以前、XFLAG スタジオでは CRE (Customer Reliability Engineer) というチームを設立し、サービスに対するユーザの信頼を高めるために取り組んでいるということをご紹介しました 。その背景には、サービスにおける顧客・ユーザの信頼が近頃ますます重要になってきているという実情があります。
本日初日のエントリは、事例がまだまだ少ない toC サービスにおける CRE において、私が考える SLO (Service Level Objective: サービスレベル目標) についてお話ししたいと思います。
CRE と SRE
Google の新しい専門職 : CRE が必要な理由 で、
Google では、お客様に対しても同じようなアプローチが必要だという結論に達しました。SRE の原理や教訓をお客様に適用すると、CRE にたどり着くのです。
と述べられている通り、CRE が生まれた背景には SRE (Site Reliability Engineer) があります。
まず SRE における SLO とは何かを見ていきましょう。
SLO, SLI, SLA
SLO がサービスレベル目標であるのに対し、SLI はサービスレベル指標 (Service Level Indicator)、SLA はサービスレベル契約またはサービスレベル合意 (Service Level Agreement) と呼ばれます。
SLO, SLI, SLA の関係性については、エラー・バジェットによるリスク管理 Managing risk with error budgets で次のように明確に説明されています。
SLI: 指標
SLO: SLI + 目標
SLA: SLO + 罰金
SRE における SLI には可用性、レイテンシ、耐久性等の指標があり、SLO は例えば「99.99% の可用性」というように設定されます。
SLO をそのまま CRE に適用できない理由
SREにおいては、SLO があれば、例えば「どの程度のダウンタイムであれば許容されるのか」といったことが議論できるようになります。
では CRE における SLO はどのように設定されるべきでしょうか？
優れた SLO を策定するには : CRE が現場で学んだこと では次のように述べられています。
ユーザー エクスペリエンスにおいて最も重要な側面を SLO が象徴するようにしなくてはなりません。SLO が満たされるということは、ユーザーにとっても自社にとってもハッピーなことでなくてはならないのです。
具体的な指標についてはここでは述べられていませんが、プラットフォームのような toB サービスであれば、ユーザにとってハッピーなことはインフラの可用性やレイテンシ、問い合わせに対するレスポンスなどが挙げられるでしょう。
一方、私たちのような toC サービスにおける CRE ではどうでしょうか？
これは非常に難しい問題です。
なぜなら一般的に toC サービスでは、私たちエンジニアがユーザ (ここではエンドユーザ) と直接やりとりすることはまずないので、SLO の設定にはまずユーザの定義から考える必要があるためです。
ユーザの定義
CREチームを設立しました！ では私たち CRE にとってのユーザには、エンドユーザだけでなく CS (Customer Support: カスタマーサポート) スタッフも含まれると述べました。
ここで問い合わせの流れを見てみましょう(図1)。
ユーザからの問い合わせは、技術的な調査を要するもののみ CS スタッフからの調査依頼 (ここでは単にエスカレーションと呼ぶことにします) として CRE まで届けられます。
ここで、ユーザと CS スタッフ、CS スタッフと CRE の関係に注目してみましょう。
CRE が CS スタッフからエスカレーションを受けて対応する関係と、CS スタッフがユーザから問い合わせを受けて対応する関係は、見方によっては BtoBtoC と捉えることができます。
そこでここでは toC サービスの CRE における1つの例として、CS スタッフを私たち CRE のユーザであると仮定してみます。
次章では、CS スタッフをユーザとした上で、toC サービスの CRE においてどのように SLO を適用すれば良いか考えていきたいと思います。
toC サービスの CRE における SLO の適用
私たちは CS スタッフからのエスカレーション対応をどのように評価すべきか長年頭を悩ませてきました。
個々の案件ごとに難易度が異なるため、共通の指標を定義することができなかったためです。
この章では、今私たちが検討している SLI, SLO をご紹介し、具体的な参考値まで踏み込んでいきたいと思います。
toC サービスの CRE に適合する SLI は解決時間
SRE ではシステムの SLI として可用性やレイテンシ等が使われると述べました。
私たち toC サービスの CRE では、SRE におけるシステムの代わりに、CS スタッフのエスカレーションをあてはめ、可用性をエスカレーションの解決率、レイテンシをエスカレーションの解決時間に置き換えて考えてみましょう。
エスカレーションの解決率を SLI として SLO を設定することは、エスカレーションが解決しないケースを許容することと同義であることに注意しなければなりません。
なぜなら SLO には、
目標値 100 % というのは、どの時間幅においても不可能ですし、必要性もないでしょう。SRE は SLO を使ってリスクを容認します。
と述べられている通り、リスクを容認するという側面があるからです。
一方でエスカレーションの解決時間はどうでしょうか。
解決時間を SLI として SLO を設定することは、エスカレーションをなるべく短い時間で解決することの表明であり、これは先ほど挙げた「SLO が満たされるということは、ユーザーにとっても自社にとってもハッピーなことでなくてはならない」という SLO の原則にも合致しています。
そこでここでは、SLI をエスカレーションの解決時間とした上で、 次に SLO をどのように設定していけば良いか考えてみましょう。
SLO の値と考え方
SLI をエスカレーションの解決時間としたところで、次は SLO を具体的にどの程度の値に設定すれば良いかという疑問が浮かびます。
そこで私は、2017年10月から12月にかけて私たちが受け取ったエスカレーションを集計し、解決までにかかった日数と件数比率をグラフにしました(図2)。
グラフから、半数以上の案件は3営業日以内に、3分の2の案件が5営業日以内に解決していることがわかります。また、3分の1の案件が2営業日以内に解決していることもわかります。
もしこれらの値を参考に SLO を設定するとすれば「3営業日以内解決率 50%」や「5営業日以内解決率 66.7%」となるでしょうか。
一方で、3分の1の案件が解決までに6営業日以上かかっていることもわかりました。
これらはシステムの不具合や障害に起因した、調査に時間を要するものです。
私たち CRE は、私たちだけで全ての技術的課題を解決できるわけではありません。このような問題に直面したとき、
エスカレーションは敗北を認めることではありません。SRE としては、開発チームの情報を検討し、解決までの時間が大幅に削減できるとある程度確信した段階で、すぐにエスカレーションするべきです。
でも述べられているように、私たち CRE もまた必要に応じて開発チームにエスカレーションします。
重要なのは、私たちの指標は全て私たちだけでコントロールできる性質のものではないと認識することです。
toC サービスの CRE における SLO とは、開発チームなど他部署と共にサービスを運営していることを意識しつつ、コントロール可能な範囲で最善を尽くせるように設定するのが望ましいと私は考えています。
おわりに
このエントリでは、SRE における SLI, SLO, SLA を紹介し、toC サービスの CRE における SLO の考え方についてお話ししました。
また、私たち XFLAG スタジオ CRE の実績をもとに、 SLI をエスカレーションの解決時間とした場合の SLO の参考値を紹介し、その考え方について述べました。
このエントリが toC サービスにおける他の CRE 事例の一助となれば幸いです。
明日火曜は橋本から「Zendeskまもるくんという社内ツールをオープンソース化しました」というタイトルで、私たち CRE 初の OSS に関するお話です。
