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

Posted on by Hikaru Murakami

はじめに

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

#2 から「監視・モニタリング」「インシデント対応」といった運用設計から 「SLO（SLI）」 の設計までのシナリオを辿ることで、SRE の世界観を掴む試みをしています。

そして、前回 #2 の記事では、運用の設計を開始し、CUJ (Critical User Journey) と UJ (User Journey) という概念を導入しました。

本記事は、この概念に基づいて、具体的な運用設計を行っていきます。

CUJ / UJ を使って運用を設計する

前回までで、運用設計として以下を考え、決めたり実装したりする必要があると述べました:

  • 運用チームの体制
  • 必要十分な通知
  • 事象に応じた初動体制

そして、そのために CUJ / UJ という概念を導入し、UJ という「ユーザー体験」が定義され、さらに CUJ という「最も重要なユーザー体験」の定義ができました。

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

それでは実際に設計してみましょう。

運用体制の設計

まず、「運用にどれくらいの規模・体制が必要か？」という問いを考えます。

24時間365日の体制が必要なのか、営業時間内だけで良いのか。
これは「なんとなく」で決めてしまいがちですが、CUJ を使うことで根拠を持って設計できます。

考え方としては、

  • CUJ に影響があるインシデントが発生した際に、どのくらいのビジネスインパクトがあるか
  • どれくらいの速度で対応が必要か

この2点を明らかにすることで、取るべき体制が決まってきます。

例えば「CUJ『購入手続きを完了する』が1時間止まると、日中では売上にx円、夜間ではy円の影響がある」と試算されたとします。
この試算があれば、様々な議論が可能になります。

例えば、
「この損失であれば日中は15分以内に初動が必要」
「休日夜間でも体制を組むことでペイする」
「だから24時間365日でも対応可能な体制（オンコール）が必要」
…といった議論になるかもしれません。

あるいは、
「この損失であれば、営業時間内に対応すれば十分」
…という議論に落ち着くかもしれません。

このように、CUJ のビジネスインパクトを起点に、運用体制を設計することができます。
「なんとなく24/365が必要そう」ではなく、
「CUJ のインパクトがこれくらいだから、この体制が必要」と説明できるわけです。

ここで、ビジネスインパクトの試算について、金額で説明できれば経営層に対して最も容易に伝えることができますが、KPI 等への影響でも勿論問題ありません。

インシデントレベルの設計

次に、「必要十分な通知」や「事象に応じた初動体制」を設計していくのですが、これらの設計を行う上では基準が必要になってきます。

この基準として、インシデントレベルを定義し、それに基づいて設計を行います。

そして、 CUJ / UJ という概念が、このやはりインシデントレベルの設計に役立ちます。

なぜレベル分けが必要なのでしょうか？
それは、すべてのインシデントを同じ緊急度で扱うと、本当に重要な問題への対応が遅れてしまうからです。
「決済ができない」と「管理画面のレポートが表示されない」を同じ優先度で対応していては、ビジネスへの影響を最小化できません。

CUJ / UJ を使えば、このレベル分けをシンプルに行えます:

インシデントレベル対象説明
SEV-High（重大）CUJ に影響があるビジネス上最も重要なユーザー体験が損なわれている状態
SEV-Mid（中程度）CUJ ではない UJ に影響がある何らかの問題によってユーザー体験が損なわれているが、ビジネスへの影響は相対的に小さい
SEV-Low（軽微）上記以外ユーザー体験への直接的な影響が限定的

（注: 弊社ではインシデントレベルを5段階に分けていますが、ここでは説明を簡単にするために3段階としています）

EC サイトの例で考えると:

  • 決済処理でエラーが発生している → SEV-High（CUJ「購入手続きを完了する」に影響）
  • お気に入り機能が動かない → SEV-Mid（UJ「お気に入りリストを表示する」に影響）
  • 管理画面の一部レポートが表示されない → SEV-Low（ユーザー体験への直接影響なし）

このように、CUJ / UJ という軸があることで、インシデントの重大度を客観的に判断できるようになります。
「なんとなく重要そう」ではなく、「この機能は CUJ に紐づいているから SEV-High」と説明できるわけですね。

通知の設計

ここまでで CUJ / UJ と、それに基づくインシデントレベルの定義を行いました。

「必要十分な通知」はこれらをベースに設計すれば非常に容易です。

インシデントレベル通知ルールの例
SEV-High即座に通知。
検知したら即運用担当者に連絡が飛ぶ
SEV-Mid即時対応ではなく一定の猶予を持たせる
（例: 営業時間内に対応）
SEV-Low通知は抑えめに。
ダッシュボードで確認できれば十分、あるいは一定期間継続した場合のみ通知

ここで重要なのは、「重要な通知が埋もれないようにする」ことです。

SEV-Low の通知がたくさん飛んでいると、本当に重要な SEV-High の通知を見逃してしまうリスクがあります。
CUJ / UJ で重要度を階層化することで、「この通知は本当に今すぐ見るべきか」が明確になります。

エスカレーションの設計

「事象に応じた連絡先」も、インシデントレベルに基づいて設計できます。

インシデントレベルエスカレーション範囲の例
SEV-High運用担当者 → チームリード → 必要に応じてマネージャー・関係部署
SEV-Mid運用担当者 → チームリード
SEV-Low運用担当者（翌営業日対応でも可）

SEV-High の場合は、ビジネスへの影響が大きいため、早期に意思決定者を巻き込む必要があります。
一方、SEV-Low まで毎回マネージャーにエスカレーションしていては、関係者が疲弊してしまいます。

このように、インシデントレベルに応じたエスカレーションフローを設計することで、「過剰な連絡」と「連絡不足」の両方を防ぐことができます。

本記事では、CUJ / UJ という概念を導入し、ビジネス視点で機能とその重要性を整理し、その重要性をベースに運用を設計するアプローチについてまとめました。

改めてですが、

  • UJ (User Journey): ユーザーがサービスを利用する際の体験の流れ
  • CUJ (Critical User Journey): UJ の中でも特にビジネス上重要なもの

であり、この CUJ / UJ を軸にすることで、

  • 運用体制をビジネスインパクトに基づいて設計する
  • インシデントレベルを客観的に設定する
  • 通知を必要十分に絞り込む
  • エスカレーションを適切な範囲に設計する

…といったことがシステマチックに実現できるようになります。
そして、「なんとなく」ではなく「ビジネス上の重要度」を軸に運用を設計できるようになります。

そしてこれは、これまで述べてきた「ビジネスを意識した適切なリソース配分への貢献」に繋がる考え方です。

このように整理していくと、SRE の活動がビジネスとどう繋がっているのかを少しでも感じていただけたのではないでしょうか。

最終回となる次回は、この CUJ / UJ の考え方を SLO に応用し、まとめを行います。

（#4 に続く）