信頼性向上のためのSLI/SLO活用vol.1 - SLI/SLOフレームワークおよびサービス稼働状況確認ツール「LINE Status」開発記

はじめに

こんにちは。SRE（Site Reliability Engineer）として働いているDahee Eoです。私たちのチームは、Media Platform SREをはじめ、グローバルトラフィックの管理業務を担当しています。

これまで「信頼性向上のためのSLI/SLO導入」シリーズを通じてSLI/SLOの概念と必要性を解説し、プラットフォームやサービスへの導入事例を紹介してきました。

信頼性向上のためのSLI/SLO導入vol.1 - 紹介と必要性 信頼性向上のためのSLI/SLO導入vol.2 - プラットフォームへの導入事例信頼性向上のためのSLI/SLO導入vol.3 - サービスへの導入事例（後日公開予定）

今回の「信頼性向上のためのSLI/SLO活用」シリーズでは、SLI（service level indicator）やSLO（service level objective）を導入した後、実際の運用においてどのように活用・拡張していけるかについて、検討を重ねた内容を取り上げていきます。

その第1弾となるこの記事では、SLI/SLOに基づいてSLI/SLOフレームワークを構築し、社内ツール「LINE Status」を開発した背景や、制作の過程で直面した課題について紹介します。単に一つのツールを開発した経験をまとめるというよりは、運用を繰り返す中で得た知見を構造化し、それをもとに自動化・拡張を進めてきた過程を中心にお話ししたいと思います。

SREチームでは、主要なサービスやプラットフォームにSLI/SLOを導入しました。さらに、社内でサービスの信頼性について議論する際の共通言語としてSLI/SLOを活用するために、他のサービスやプラットフォームにも展開を進めました。

このプロセスを3、4回繰り返す中で、SLIを定義し、SLOに合意する手法には、サービスの特性に依存しない共通のパターンが存在することに気づきました。導入から運用指標として定着させるまでのプロセスは、そのほとんどが同様のパターンで繰り返されていたのです。

SLI/SLOフレームワーク

私たちは、見出した共通のフローを再利用するために、全体のプロセスをより明確に整理し、1つのフレームワークとして構築しました。これは、特定のサービスに依存しない共通の基準と流れの中で、SLI/SLOの定義から運用までを行えるようにするためです。

SLI/SLOの導入プロセスを1つのフローとしてまとめると、次のようになります。

以下の表は、SLI/SLOフレームワークを構成する5つのフェーズの役割をより具体的にまとめたものです。

区分説明Define Phase

CUJ（critical user journey）選定とSLI定義フェーズサービスの本質的なユーザー体験の把握主要CUJの選定CUJごとの測定可能で意味のあるSLI定義

Instrument Phase

計測とメトリクス設計フェーズSLI測定のためのメトリクスの設計と実装CUJに適したメトリクスの新規開発の推奨PrometheusまたはOpenTelemetryに基づく標準的な命名規則の適用

Observe Phase

ダッシュボードと記録ルール（recording rules）構成フェーズSLO達成状況を直感的に確認できるGrafanaダッシュボードの構築記録ルールを活用したメトリクスの最適化複雑なPromQL演算の事前処理によるパフォーマンスとクエリ効率の改善

React Phase

SLOとアラート（alerting）設定フェーズ目標SLOの定義と通知設定28日ローリングウィンドウ（rolling window）ベース、99.9%（許容ダウンタイム40分）からの開始を推奨初期段階ではSLOを柔軟に設定し、その後安定したらSLOの目標値を確定アラート対応のためのRunbook定義

Improve Phase

エラーバジェット（error budget）ベースの運用とガバナンス確立フェーズリリース頻度と安定性のバランス調整月次・四半期レビューによる目標チェックと改善必要に応じてSLOの見直しおよびプロセス改善を反映

SLI/SLOフレームワークは現在、Confluence（Wiki）のテンプレート形式で提供されています。各サービスチームはこのテンプレートを複製し、フェーズごとに各項目を埋めていくことでSLI/SLOを設計します。これまでSREが個別に行っていた説明や調整作業を、テンプレートやガイド、FAQの形に整理して提供することで、初期の議論で発生するコミュニケーションコストの削減に繋がっています。まだ1つのサービスに適用しただけの初期段階ですが、今後より多くのサービスへと展開していく中で、フィードバックを得ながら段階的に改善していく予定です。

今、サービスの稼働状況はどうなっていますか？

SLI/SLOを複数のサービスに導入・運用していく中で、私たちのチームが直接担当していない他のサービスの稼働状況も自然と気になり始めました。

すでにLINEのサービスに関して https://api.line-status.info というAPIステータス確認ページは運用されていましたが、そのページは、LINEメッセージングやログイン、LIFF（LINE front-end framework）など、外部のAPI利用者がAPIの稼働状況を確認できる手段を提供することに焦点を当てたものでした。また、重大な障害が発生した際に手動で情報を更新する仕組みとなっていました。

これとは異なり、私たちは社内メンバーがサービスコンポーネントごとの状況を共通の基準で把握できるツールの開発を目指しました。さらに、このツールをSLI/SLOアラートや障害（outage）データと連携させ、稼働状況が自動的に更新される仕組みとして設計したいと考えました。

これに関連してSREチーム内では、稼働状況をどのような基準で表現するかについて詳細な議論を重ねました。オンコールで受信するアラートをそのまま反映するか、あるいはエラー予算に基づいて表現するかといった点を検討しました。私たちがSLI/SLOを定義する際に基準としたのは、個別のサービスで障害が発生しているかどうかではなく、CUJの観点からユーザーがサービスを「快適に利用できているか（user happiness）」という点でした。そのため、サービスの稼働状況についても、単なる障害の発生有無ではなく、CUJに基づいて定義したSLIメトリクスを測定し、SLOを達成できているかという観点から表現することが一貫したアプローチだと判断しました。また、その際はすべてのCUJを網羅して表示するのではなく、サービスのコアエクスペリエンスを代表できる項目に絞り込むことが適切だと考えました。

私たちは実際の運用経験をもとに、ステータス遷移の基準をブラッシュアップしながら初期モデルを具体化していきました。すでに主要サービスへのSLI/SLO導入プロジェクトを進めており、そこでCUJという共通概念が定義されていたため、これをベースにした社内向けサービス稼働状況確認ツール「LINE Status」を開発することにしました。

稼働状況を自動的に管理できるシステムの構成

LINE Statusは、単にアラートを並べるページではなく、収集したイベントに基づいてサービスの現在の稼働状況を一貫した基準で表示し、これにより現在のユーザー体験への影響を最も迅速に把握できる仕組みを目指しました。

そのために、まず各サービスで運用されているSLI/SLOベースのアラートを、Webhook形式で収集するバックエンドサーバーを設計しました。収集したイベントは個別のデータベースに保存し、それをもとに現在の稼働状況と変更履歴を管理できる構成にしました。これにより、特定の時点のステータスだけでなく、イベントの発生履歴まで追跡可能になります。

また、社内メンバーの誰もが直感的に理解できるよう、SLIやSLOといった用語をそのまま表示するのではなく、機能を中心に定義したステータス名を表示することにしました。メッセージサービスを例に挙げると、「メッセージ送信」や「既読表示」のように、実際のユーザーが認識している機能単位でステータスを表現しました。つまり、技術的な詳細指標ではなく、「ユーザー体験に影響が出ているかどうか」を軸に判断できるように構成したのです。

このような設計思想のもと、私たちはLINE Statusが単なる監視ツールにとどまらず、組織全体でサービスの稼働状況を共有できる窓口となることを期待していました。

LINE Statusの実装

開発には約1か月を要し、その後は同僚からのフィードバックを反映させながら、徐々に改善を重ねていきました。

それまで私は、フロントエンド開発とは縁の薄いエンジニアでした。それでも、最近広く活用されているバイブコーディングを積極的に取り入れ、UIを実装しました。その過程で感じたのは、ツールそのものよりも「企画の明確さ」の方がはるかに重要だということです。詳細機能を実装するたびに、要件をMarkdown形式で整理してAIに伝えましたが、ドキュメントが具体的で文脈が十分であればあるほど、成果物の完成度も高まりました。やみくもに依頼するのではなく、どのようなステータスをどのように表示するかという意図を明確に整理して伝えることで、初めて望む結果を得られたのです。

このようなプロセスを経て完成したLINE Statusの主要な画面を紹介します（社内専用ツールであるため、実際のサービス名やデータではなく、例として加工したものです）。

まず、メインページは、全サービスの現在の稼働状況を一目で確認できるよう、以下のように構成しました。

メインページの特徴は以下のとおりです。

AIを活用した一行分析サマリーの提供サービスカードごとのCUJ項目を一覧表示することで主要な機能を確認可能直感的な色分け（緑：正常、黄色：イベント発生、赤：障害発生）

次に、特定サービスのCUJ（アイテム）単位の稼働状況を確認できるサービス詳細ページです。

サービス詳細ページの特徴は以下のとおりです。

単純な降順ソートではなく、直近の発生イベントを優先する順序で表示タイムライン形式による最新イベントの表示「Past Events」セクションで今月のイベント履歴を確認可能

以下は、全サービスの履歴を一括で確認できる履歴ページです。

履歴ページの特徴は以下のとおりです。

イベント発生時に、サービスごとの影響範囲を確認可能月単位で区分することで、過去の履歴を確認可能

SLI/SLOフレームワークとLINE Statusの連携

LINE Statusを実装する過程で、SLI/SLOフレームワークとの連携構造が自然と明らかになりました。SLI/SLOフレームワークを用いてサービスにSLI/SLOを導入した後、そのサービスをLINE Statusに登録することで、組織全体が同一の基準で稼働状況を確認できるようになります。つまり、SLI/SLOを定義するフェーズと、その結果を組織全体で共有するフェーズが、一つの流れとしてつながるのです。

この際、LINE Statusの役割は、単に稼働状況を可視化するだけにとどまりません。開発者と運用担当者が同一の基準でサービスの稼働状況を把握できる共通の窓口を提供することが重要です。各チームがそれぞれの視点で個別にモニタリングダッシュボードを確認するのではなく、CUJベースのSLIとSLOの達成状況を中心に、「現在、ユーザー体験に影響が出ているか」を共に判断できる必要があるためです。特にイベントが発生した際、ユーザー体験の観点から状況を迅速に把握できる仕組みが求められます。

LINE Statusは、上記のような点を念頭に置いて設計されました。今後は運用経験を積み重ね、CUJとSLI/SLOの基準をさらに精緻化していく予定です。これにより、ユーザーは個々のアラートを解釈する代わりに、LINE Statusを基準としてコンポーネント全体の観点から、現在どのようなサービス体験に影響が出ているかを迅速に把握できるようになるでしょう。これは単にモニタリングの利便性を向上させるにとどまらず、意思決定のスピードやコミュニケーション方法の変化にもつながると考えています。

まだ初期段階ではありますが、長期的にはSLI/SLOフレームワークとLINE Statusを通じて、SLI/SLOを組織全体で共有する「サービスの稼働状況を表現する共通言語」として普及させていく方針です。これにより、特定のチームや役割に過度に依存することなく、SLI/SLOに基づく運用を段階的に拡大できる基盤を整えることが目標です。

おわりに

SLI/SLOフレームワークの構築やLINE Statusの開発は、一人では決して成し遂げられなかったと思います。共に試行錯誤を重ね、さまざまな意見を交わしてくださった多くの方々に、この場を借りて心より感謝申し上げます。

2026年も、LINEサービスの信頼性向上に向けたSLI/SLOの活用と拡張を引き続き進めていく予定です。その過程での試行錯誤や成果物を、「信頼性向上のためのSLI/SLO活用」シリーズを通じて一歩ずつ紹介していきたいと思います。どうぞご期待ください。長文でしたが、お読みいただきありがとうございました。