ナンモワカランアザラシ

Ringed seal, clueless still

ユーザーからのシグナルを信頼性指標として取り入れる

思考のスケッチ。

SRE、サイト信頼性エンジニアリングのプラクティスにおいては大抵の場合にサービスレベル指標を測定する。サービスレベル指標は、SLI、Service Level Indicatorの和訳である。こう見るとServiceと対応する日本語ってないのだね。

では何のためにSLIを測定するかというと、リリース頻度と信頼性のバランスをとりたい、とかビジネスチーム内での共通言語として使える客観指標がほしい、とか世の中にはいろいろ書かれているが、畢竟、ユーザーに満足してほしいからだ。
「信頼性こそがあらゆるプロダクトの基本的な機能」とGoogleは表現した。基本的な機能が満たされていないのに別の新機能を作ってもユーザーには届かないだろうという意味だ。まず信頼性ありき。
さてこのSLIとしてよく使われるのは、可用性としてエラーレートやパーセンタイルレイテンシ、また完全性としてデータ耐久性である。後者はS3のeleven nine, 99.999999999%が有名だ。
これらSLIに目標を設けてSLOとすれば、SLOを達成することがユーザーが満足することの必要条件であると見なせる。

そう、「必要条件であると見なせる」だけである。十分条件であるかはわからない。必要条件を満たしていると断言することも難しい。
データがクライアントのもとに100%の確率で0.1s以内に届いても、例えばUIデザインの不具合によってユーザーが正しくサービスを使えないがゆえに不満かもしれない。そもそもユーザーはレイテンシを気にしないかもしれない。その測定しているSLIが「正しく測定できている」かどうかもわからない。適当にクエリ書いてみたらそれっぽい数字になったのでこれをSLIとしよう!なんてことはよくあるのではないだろうか。

ここから一歩進んで、ユーザーの満足の十分条件により近い指標条件を見つけたい。
それにはユーザーの生の声を得るのが手っ取り早そうだ。

この考えに沿ったプラクティスとして、CRE、Customer Reliability Engineeringという技法があることを私は知っている。 GoogleGoogle の新しい専門職 : CRE が必要な理由で次のように書いている。

今、この時代において、真に適切なサポート チームのミッションはたった 1 つです。それは、お客様の不安をゼロにすることなのです。 (中略) 不安は 1 を信頼性で割った数値に等しい

私は「ユーザーの満足を高める」と書いたが、Googleは「ユーザーの不安を低める」としている。さらに、GoogleはCREはSREが開発チームに対して厳しい要求をするように、お客様に対して厳しい要求をすることによってお客さまの環境の信頼性を高めて不安を減らすのだと主張している。なかなかに苛烈だと感じる。Cloud Platformならではの考え方かもしれない。サービス提供者として考えるのなら、やはりユーザーが不安を感じないようにシステムを設計することに尽くしたい。その中の一策として、ユーザー環境を監視して信頼性が低まるような事態があればユーザーに対してアラートを出すなどはよい施策かもしれない。CREとSREとはダブりのない集合ではなく、SREがCREを含んでいるように私には思える。Site Reliabilityをどうにかするためにお客様を監視することは自然な考えだと思う。

具体的な方法には、お問い合わせ指標化とクライアントモニタリングが思いつく。

不満を感じている人のn%がお問い合わせをしてくださると仮定する。アクティブユーザー全体に対する、不具合に関するお問い合わせを出したユーザー数の比率を出す。一定期間内のこの比率がo未満であれば、システムは健全であると捉える。実際にはそんなに確実な指標にはならないだろうが、「エラーレート」も同じように不確実なものだろう。とりあえず可視化してみる分には損をしないだろう。

クライアントモニタリングの方が技術的にはやりがいがある。まず想起するのはDatadogのRUM, Realtime User Monitoringだ。クライアントにエージェントを仕込んで、ブラウザやネイティブアプリでの操作履歴を収集する。クライアントでのエラー率や、「不満度合い」を指標として抽出する。「不満度合い」については定義がむずかしそうだが、たとえば、同じページを何度も行き来する行動や、マウスカーソルが荒ぶったりしていたらそのユーザーは不満を抱えている可能性が高いと考えられないだろうか。そのような「不満率」をモニタリングして、システム変更によって上がったり下がったりする様子を眺めるとインサイトが得られると思う。ビジネスとしてそれをやる意義を説得しやすくするために、会員解約率やアカウントのアクティブ率と紐づけるとおもしろいかもしれない。

以上のようにCREとしてやられている作業をSREの領域に持ち込むことでより高度な信頼性エンジニアリングを実現したい。