Customer Reliability Engineering in Action

CRE

What's this?

Customer Reliability Engineering の方法論について考えたことをまとめる。

CREing

Google の提唱した CRE 職の新規性は、SRE の発想を自社プラットフォームのみならずその上で動く顧客アプリケーションにも適用したことにある。 基本的にはその発想に従えば良い。

SRE の方法論は、ざっくり言うと、SLA やエラーバジェットなるもので信頼性を定量的に定義しそれをモニタリングしながら改善可能性を探っていく、みたいなものだ。 それを顧客アプリケーションにも適用するのが CRE だと思えば良いだろう。

つまり、例えば現職の Treasure Data のプラットフォームには、それを取り巻く様々な顧客アプリケーションが存在する（Scheduled Query, Workflow, Source などなど）が、それらコンポーネントについて、顧客ごとまたは全体のエラー率、もしくはそれに準ずるメトリクスを計算して、それらをモニタリングしながら、改善可能性を追求していけば良い。特定の顧客の Scheduled Query のエラー率が極端に高かったら、その原因を調査し、エラーの解消に導く。原因が判明したなかで、プラットフォーム側で対応が不能な場合は、みずから顧客とコミュニケーションをとるか、カスタマーサクセスやサポートチームに協力を仰ぎ、それを解決していく。結果として、顧客側はサービスキャパシティの消費量を減らしたり気づいていない問題を発見したりアプリケーションを正常化することができ、プラットフォーム側は無駄に消費されるリソースコストを削減でき、みなハッピーというわけだ。

基本的には、適切な KPI を決めてそれを改善するという一般的な所作を顧客アプリケーションのエラー率に対してやっていきましょう、という話である。

何を改善していくか

上で述べた CRE の活動がどう実を結ぶかは、選んだメトリクスに大きく依存する。例えば、特定の顧客アプリケーションのエラーが極端に高いことを発見し、それを長時間かけて調査し人々のリソースを使って解消しようとしても、それは顧客にとってエラーが起こっていても問題ない何ら重要ではないアプリケーションかもしれない。つまりそのようなケースでは、エラー率の改善度合いは顧客へのインパクトの大きさと相関しない。

また、SRE 的な発想にこだわると改善対象のメトリックはエラー率かもしれないが、そこは所属するチームの職責やオーナーシップを持つシステム、組織のステージなどに応じて変わってくるだろう。ドキュメントシステムを改善しているなら結果 0 件リターン率がそのメトリックでも良いかもしれないし、会社 OKR が profit margin の改善なら顧客ごとの profit margin がそのメトリックでも良いかもしれない。そして、そのメトリックは一つである必要もない。対象のメトリックに何を選び、何を改善していくかを決定するかは、チームや会社の目標を元に、合意を経て決めるのが良いだろう。

具体例

以下は、現職であった事例である。

Treasure Data のサービスは、顧客のアプリケーションから Treasure Data が用意したエンドポイントに送信されたデータを、プラットフォームに蓄積する。エンドポイントはリージョンごとに存在しており、顧客アカウントは特定のリージョンに属する。

あるとき、たまたまログデータを確認していた同僚が、ある顧客が自身のアカウントの属するリージョンのエンドポイントではなく、異なるリージョンのエンドポイントに対して大量にデータを送信しているのを見つけた。 そのようなリクエストで送信されたデータは破棄されてしまい、結果としてデータは顧客アカウント上に残らない。 一日に数千万レコードが継続的に送信されつづけており、顧客アプリケーションにおいて本来蓄積されるべきそれだけの量のデータが破棄されているのも無視できなかろうということで、対策を講じようという話になった（プラットフォームにとっても意味のないリソースを消費していることになる）。

調べてみると、その他の顧客アカウントでも同様に異なるリージョンのエンドポイントにリクエストを送信していることも分かった。 はじめに、そのようなレコードがどのアカウント、リージョン、ユーザーから送信されているかを可視化してモニタリングできるダッシュボードを作成した。 そして、そのダッシュボードをカスタマーサクセスチームにシェアし、顧客とのコミュニケーション方法について相談した。 そのようなリクエストを送信している特定のユーザーに通知を送る方法も検討したが、最終的に、そのようなリクエストを送信しているアカウントのカスタマーサクセスマネージャー宛に定期的に Slack でリクエスト数などのステータスを通知し、その担当が顧客とコミュニケーションを取り削減に努めるというフローになった。 通知はリクエスト数に適当に閾値を設け自動化することで、今後にそのようなリクエストを送信するユーザーが発生したら担当メンバーまで通知が飛び、詳細をダッシュボードで確認することで顧客とコミュニケーションを取れるフローが構築できた。

以上は、スポット対応によるオペレーションフローの構築の例であり、継続的にメトリック改善施策を行っている例ではないが、ストーリーは同様なものになる思う。 この例の改善対象メトリックとは、アカウントの属するリージョンと異なるリージョンへのリクエスト数（率）だ。 メトリックが改善することで、顧客アプリケーションの瑕疵もなくなり、プラットフォームも無駄なリソース消費がなくなる。

まとめ

以上では、CRE の方法論についてまとめた。

何をしたら顧客のためになるかを考え、計測し、ひとつずつ解決していきましょう。