村上が SRE に JOIN して 1年が経過したので SRE とは何かをまとめてみる #2

Posted on by Hikaru Murakami

はじめに

SRE (Service Reliability Engineering) 部の村上です！

前回 #1 の記事では「SRE とはなにか？」について、私の現時点での見解をまとめました。

  • SRE は、元々は運用をエンジニアリングするところから始まり、その実装が積み重なったものであること
  • これを拡張・応用することで、ビジネスを意識した適切なリソース配分への貢献が可能になり、以てビジネスや組織全体に貢献していくこと

…という捉え方が、SRE のファーストステップとしては良いのではないか、というところまでお話ししたと思います。

さて、SRE の主要素として「監視・モニタリング」「インシデント対応」「SLO」等が挙げられるかと思います。

運用として行う内容は多岐にわたりますが、その中核をなすのは「システムについて対応すべき問題をいち早く検知し対応するという営み」であると思います。
そして、「システムについて対応すべき問題をいち早く検知し対応するという営み」のためには当然「監視・モニタリング」「インシデント対応」を整理し実装する必要があります。

更に、SRE は「ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの」ということを前回お伝えしました。

これらを踏まえると、「監視・モニタリング」「インシデント対応」という運用のための要素が SRE の主要素たり得るのは自然です。
また、信頼性のトレードオフを担う「SLO」もまた、SRE の主要素であることは間違いありません。

しかし、私は当初、これらをどのように捉えればよいのか掴めないでいました。
特に SLO の扱いが非常に難しく、悩まれている方は少なくないのではないでしょうか。

これに対して、CUJ (Critical User Journey) と UJ (User Journey) という補助線を引き、さらに前回述べたような SRE の捉え方をすることで、「インシデント対応」「監視・モニタリング」「SLO」を1つのストーリーとして捉えることができると感じています。

そこで、ここから数回に渡って、「監視・モニタリング」「インシデント対応」といった運用設計から「SLO（SLI）」の設計までのシナリオを辿ることで、SRE の世界観について私なりに述べていきたいと思います。

本記事では、まず、運用設計について考察し、どのようなコンセプトで臨むかを考えることで、CUJ と UJ という概念の導入に繋げてみたいと思います。

運用設計に想いを馳せる

早速、運用設計をしていきたいと思うのですが、仕組みを設計するにあたってはコンセプトを固めることが重要です。
これをしっかり考えることで、少ない実装でより効率的にやりたいことを実現できます。
ですので、コンセプトを編み出せるかを意識しながら、運用の設計を考えていきましょう。

さて、設計を始めるにあたっては、まず「運用として何をやるべきか、何をやらないといけないか」に想いを馳せるわけですよね。
すると、以下のようなことを考える・決める必要があるということに気付くと思います:

  • 運用チームの体制を定めるべき
    • 決めておかないと
      「この時間のインシデントになんで対応してないの？」
      「業務時間外なので、次の営業開始から対応すれば良いと思っていました」
      といった押し問答に繋がる
  • 運用担当に、必要十分な通知を出すようにするべき
    • 通知が不足すれば対応すべきときに対応できないし、過剰であればノイズによって疲弊する
  • 事象に応じた初動体制を考えるべき
    • 影響範囲に応じて連絡すべき関係者に連絡を行わないと、システムに依存する人達が困ってしまう
    • 重大な問題であれば開発の手を止めたいが、そうでないのに手を止めていたら工数がもったいない
  • etc…

そして、いくつかの疑問が生まれます:

  • 「運用チームの体制を定める」とあるが、どれくらいの規模や体制が必要なのか？
    ベストエフォート？ 営業時間だけで良い？ 24時間365日体制？ そして、それをどう決める？
  • 「必要十分な通知を出すようにする」とあるが、必要十分というのをどう捉え、どう決める？
  • 「事象に応じ、連絡すべき関係者に連絡を行う」とあるが、「事象に応じ」というのをどう捉えるか？

この疑問に対しては当然、

  • ビジネスが要求する対応速度に応じて体制が組まれるべき
  • 重要機能の問題が発生した場合は当然検知されるべきで、そしてその対応に力を注ぐべきであり、広くエスカレーションすることになり、
    そうでない機能はエラーが頻発する状況は検知されるべきで、状況確認は行うべきであり、エスカレーションが必要な際はそれ相応のエスカレーション範囲になる
  • ノイズとなるような通知は作らない

…といったことになるかと思います。

では、これを実現するようなシンプルなルールとはなんでしょうか。

  • 機能を洗い出し、その中でも重要な機能を特定して、体制を考え、通知を出し、初動フローを考えよう
  • エラーが発生しても自動復旧されるようなものについては、ノイズなので通知を出さないようにしよう。
    ただし、自動復旧の頻度が異常に高い場合は通知を出そう

…という考えに行き着くと思います。

これこそが、設計のコンセプトです。

CUJ と UJ 〜設計の核となる概念の導入〜

上述の通り、運用を設計する上で重要なのは「機能」と「その機能の重要性」であることがお分かりいただけたかと思います。

そして、SRE ではビジネス視点でこの整理を行うために、CUJ (Critical User Journey) と UJ (User Journey) という概念を導入します。
聞き慣れない言葉かも知れませんが、これらは何でしょうか。

UJ (User Journey) とは

まず UJ から説明していきましょう。

UJ とは、ユーザーがサービスを利用する際の体験の流れのことです。…と言われてもピンとこないかもしれません。
その場合は「ユーザーがそのサービスで達成・到達したいゴール」くらいに解釈するのが、特に最初のうちは良いのではと考えています。

それでは、ゴールとは何でしょうか？

EC サイトを例にとって考えてみましょう。

皆さんは EC サイトに何のためにアクセスしますか？
勿論「欲しい商品を購入するため」ですよね。

または、欲しいものがあって（例えば最近は私はとあるイヤホンが欲しいんですが）、ある EC サイトと 別の EC サイトで値段や決済手段がどう違うかなども調べたりしますよね。

あるいは、「イヤホンは欲しいんだけど、どのモデルにするか迷っている」と言った場合は、そのレビューを見るために EC サイトを巡回することがあるかも知れません。

…といったように、ユーザーはある目的を持ってサービスを利用します。その目的＝ゴールを列挙すれば UJ となります。

ここで、UJ を定義する際によくある落とし穴として、「ゴール（達成したい状態）」と「そのための手段（画面操作や確認等）」が混ざってしまうということがあります。

例えば、EC サイトにおいて「商品を検索する」や「商品詳細を見る」といった行動は、確かにユーザーが行う操作ですが、これらは「欲しい商品を見つける」や「商品について納得する」というゴールに至るための手段に過ぎません。

これらを区別せず並列に扱ってしまうと、「粒度がバラバラで整理しにくい」「どれが重要かわからない」という状態に陥りがちです。

UJ はあくまで「ユーザーにとってのゴール」という粒度で捉えるのがポイントです。

EC サイトにおける UJ（ゴール）の例

では、EC サイトの UJ を「ゴール」として整理してみましょう。

試しに列挙してみます:

  1. 欲しい商品を発見する （手段: 検索、カテゴリ一覧、レコメンド、ランキング閲覧 など）
  2. 商品を比較・検討して納得する （手段: 詳細閲覧、価格・在庫確認、レビュー閲覧 など）
  3. 注文を確定する（購入完了） （手段: カート追加、配送先指定、決済 など）
  4. 注文内容・配送状況を確認する （手段: 購入履歴確認、配送追跡 など）
  5. 返品・キャンセル・交換をする （手段: 問い合わせ、返品手続き など）
  6. 体験を共有する （手段: レビュー投稿、SNS シェア など）

こうして「ゴール」を軸に整理すると、ユーザーがサービスを通じて何を実現したいのかがはっきりと見えてきます。

運用監視の観点でも、「検索機能が動いているか（手段）」だけでなく、「ユーザーが商品に出会えているか（ゴール）」という視点を持つことができます。

CUJ (Critical User Journey) とは

次に、CUJ についてです。

CUJ (Critical User Journey) とは、先ほど挙げた UJ の中でも特にビジネス上重要なもの（Critical なもの）を指します。

では、何をもって「重要」と判断するのでしょうか。

EC サイトの場合、以下のような軸で判断することが多いです。

  • 売上直結度: 止まると即座に売上が落ちるか
  • 信用の毀損・失墜: 誤請求や「買えたかわからない」といった、ユーザーの不信感を招く致命的な事象か
  • 代替可能性: 他の手段で回避できるか
  • 法令・契約: 法律や契約上、守らなければならない領域か

EC サイトにおける CUJ の選定例

この軸で先ほどの UJ を見てみると、特に以下のものが CUJ として浮かび上がってきます。

  • 注文を確定する（購入完了）
    • これは明らかに EC サイトにおける最重要ゴールです。止まれば売上がゼロになってしまいます。
  • 注文内容・配送状況を確認する / 返品・キャンセル
    • 「お金を払ったのに商品が届かない」「キャンセルしたいのにできない」といった状況は、ユーザーの不安を煽り、サービスの信頼を著しく損ないます。

一方で、「欲しい商品を発見する（検索など）」や「体験を共有する（レビュー）」も重要ではありますが、仮に一時的に検索が使えなくてもカテゴリから探せたり、レビューが書けなくても購入自体は可能だったりと、「致命的（Critical）」という観点では一段下がるかもしれません（もちろん、サービスの特性によっては検索が CUJ になることもあります）。

このように、CUJ / UJ という階層を持つことで、「どの体験が、どれくらいビジネス上重要か」を明確にすることができます。

そして、この区分けに応じて運用の濃淡をつけるというのが、運用設計の肝となります。

ここまでで、設計のコンセプトと、それを支える概念が導入されました。
CUJ / UJ の概念を導入したことで、「インシデント対応」「監視・モニタリング」は勿論、「SLO」まで一本の線で表現できます。

次の記事では「インシデント対応」「監視・モニタリング」の設計を行いたいと思います。

（#3 に続く）