---
title: SREとしてSLI_SLOをどう普及してきたか、CTOとしてSLI_SLOをどう活用しているか
tags: 
author: [Yuki Ando](https://convert.docswell.com/user/integrated1453)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/87DLNQ63EG.jpg?width=480
description: 『信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～』の発表資料です https://findy.connpass.com/event/345990/
published: March 21, 25
canonical: https://convert.docswell.com/s/integrated1453/KL1RRP-sli-slo-cto
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/87DLNQ63EG.jpg)

SREとしてSLI/SLOをどう普及してきたか、
CTOとしてSLI/SLOをどう活用しているか
株式会社ユーザベース
安藤裕紀
2025.3.21 信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～


# Page. 2

![Page Image](https://bcdn.docswell.com/page/VJP25LYPJ8.jpg)

00
自己紹介
安藤裕紀 / Yuki Ando
株式会社ユーザベース
執行役員 NewsPicks CTO
NewsPicksの技術責任者 兼 広告事業の開発チームリーダー
2022/7〜2025/2までの約3年間はSREチームリーダーをやっていました
特技：AWSコスト削減や障害対応を愚直に100本ノックすること
好きなSREのプラクティス：非難なきポストモーテム文化
Incident Response Meetupという障害対応のイベントを運営しています
©Uzabase, Inc. All Rights Reserved.


# Page. 3

![Page Image](https://bcdn.docswell.com/page/2EVDPQGVEQ.jpg)

01
ソーシャル経済メディア NewsPicksについて
©Uzabase, Inc. All Rights Reserved.


# Page. 4

![Page Image](https://bcdn.docswell.com/page/57GYPW817L.jpg)

00
本日のアジェンダ
1. NewsPicksの開発体制と運用状況
2. SREとしてSLI/SLOをどう普及してきたか
3. CTOとしてSLI/SLOをどう活用しているか
4. まとめ
©Uzabase, Inc. All Rights Reserved.


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4EQM239NJP.jpg)

01
NewsPicksの開発体制と運用状況
©Uzabase, Inc. All Rights Reserved.


# Page. 6

![Page Image](https://bcdn.docswell.com/page/KJ4VL1X3E1.jpg)

01
NewsPicksのプロダクト開発組織とエンジニアの体制
ユーザベースグループ内にNewsPicks独自のプロダクト開発組織があり、70名ほどのエンジニアが在籍している
ユーザベースグループ(約1,200名※業務委託含む)
NewsPicks事業
プロダクトチーム
(約100名)
プロダクト開発エンジニア (約70名)
XXX事業 開発チーム
YYY事業 開発チーム
ZZZ事業 開発チーム
プロダクト
マネージャー
デザイナー
カスタマー
サポート
©Uzabase, Inc. All Rights Reserved.
横断チーム
Platformチーム
アルゴリズムチーム
モバイルチーム
SREチーム
SREチームを含め
10チームそれぞれで
担当サービスを運用


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LE13LGNZJG.jpg)

01
NewsPicksのシステム構成（エンドユーザー向け）
エンドユーザー向けサービスは共通バックエンドに責務が集中している
課金や広告配信など特定チームがメンテナンスするサーバーはマイクロサービス化されている
課金
スマホアプリ
共通
バックエンド
(Spring)
Web
Web(Next.js)
検索
BFF(GraphQL)
全10チーム中8〜9チームは
newspicks-serverというモノリスを修正
©Uzabase, Inc. All Rights Reserved.
広告配信
推薦


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GEWPVK46J2.jpg)

01
チームが分かれていても、全員で同じオンコールシフトに入る
● ユーザーから見たら一つのアプリ、一社のサービス運営会社。障害対応はエンジニア全員の仕事
○ もしニュースが配信できない障害になったら「チームが違うから」とか言ってる場合ではない
● 経済ニュースのサービスなので、24h/365dのオンコールシフトを組んでいる (PagerDutyで管理)
○ 運用当番は、障害が発生した際の一次切り分けとエスカレーション、状況報告を推進する
24d/365d常時モバイルアプリ担当1名と
サーバー担当2名の3名が『運用当番』
©Uzabase, Inc. All Rights Reserved.


# Page. 9

![Page Image](https://bcdn.docswell.com/page/47ZK4Z2R73.jpg)

01
継続的な開発者体験の改善によってデプロイは高頻度に行われる
左は2025/01末のリリースカレンダー。
この週は50回リリース※があった。
それぞれの事業で複数の施策が並行してリリースさ
れている。みんなで同じサーバーを修正しているの
で、当然デプロイ起因の障害も発生する。
オンコール担当が 開発の全体像が把握できない状
況で、自チーム以外の障害を解決するのは難しい
結果、SREチームがボールを拾う状況も多く発生して
いた
※iOS/AndroidアプリのリリースやA/Bテストの開始終了は含まない。
©Uzabase Inc. All Rights Reserved.


# Page. 10

![Page Image](https://bcdn.docswell.com/page/YJ6Q3ZV1JV.jpg)

02
SREとしてSLI/SLOをどう普及してきたか
©Uzabase, Inc. All Rights Reserved.


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GJ5RLWDL74.jpg)

02
SREの一丁目一番地といえばサービスレベル目標(SLO)
顧客体験(CUJ)からSLI/SLOを決め、SLOを基準にサイトの信頼性を維持していく
©Uzabase, Inc. All Rights Reserved.


# Page. 12

![Page Image](https://bcdn.docswell.com/page/9E2DLQ83ER.jpg)

02
SLOモニタリングするぞ〜〜〜
ひとまずアクセスログからSLIの現状をもとに教科書的なサービス全体のSLOを設定
SLIの種類
SLI
ユーザーのタイプ
SLO
可用性
リクエスト成功率
モバイルアプリ
99.9%以上
Web
99.8%以上
モバイルアプリ
90%以上
Web
80%以上
モバイルアプリ
99%以上
Web
95%以上
レイテンシー
100ms以内のレスポンス
1000ms以内のレスポンス
©Uzabase, Inc. All Rights Reserved.


# Page. 13

![Page Image](https://bcdn.docswell.com/page/D7Y2QW687M.jpg)

02
SLOの準拠／違反の状況を週次でモニタリングしていくと…
Webのレイテンシーが問題ということしかわからない。この状態からどうする？
SLIの種類
SLI
ユーザーのタイプ
SLO
可用性
リクエスト成功率
モバイルアプリ
99.9%以上
Web
99.8%以上
モバイルアプリ
90%以上
Web
80%以上
モバイルアプリ
99%以上
Web
95%以上
レイテンシー
100ms以内のレスポンス
1000ms以内のレスポンス
©Uzabase, Inc. All Rights Reserved.


# Page. 14

![Page Image](https://bcdn.docswell.com/page/VEN8K9Z9J8.jpg)

02
教科書的なエラーバジェットポリシーでは
「サイトリライアビリティワークブック 付録B エラーバジェットポリシー」より
SLO違反のポリシー
以下の場合、チームは機能の開発作業の代わりに信頼性に関する作業をしなければならない。
○
○
○
コードのバグあるいは手続き的なエラーがサービスそのもののエラーバジェット超過を引き起こした。
ポストモーテムによって強い依存性を和らげる必要が明らかになった。
分類を間違えられたエラーが、サービスのSLO違反の原因となるようにエラーバジェットを
きちんと消費しなかった。
「信頼性こそが、あらゆるプロダクトの基本的な機能である」というSREの発想のもと、
SLO/エラーバジェットポリシーが信頼性の門番として機能するようにみえる
©Uzabase, Inc. All Rights Reserved.


# Page. 15

![Page Image](https://bcdn.docswell.com/page/Y79KV2Z373.jpg)

02
現実はこうはならない
SLOをモニタリングして、SREが信頼性の門番になる？
©Uzabase, Inc. All Rights Reserved.


# Page. 16

![Page Image](https://bcdn.docswell.com/page/G78RP51LED.jpg)

02
現実はこうはならない
SLOをモニタリングして、SREが信頼性の門番になる？
©Uzabase, Inc. All Rights Reserved.


# Page. 17

![Page Image](https://bcdn.docswell.com/page/L7LK1YQQER.jpg)

02
SRE実施のフェーズ
「SREの探求 22章 成功の文化としてのSRE」より
○ フェーズ1 : 消火活動/事後対応
「システムを何とか動かし続ける」と同時に、自動化を通じて新たなアプローチを構築
○ フェーズ2 : 門番
プロダクションシステムに対する変更は必ず承認を受けて通過しなければならない唯一の関門として機能する
○ フェーズ3 : 支持者/パートナー
合意したターゲットをパートナーが達成し、その後も引き続き満足していけるように支援する
○ フェーズ4 : 触媒
あらゆるサービスの構想から廃止までに関与して、適切なツールを提供できるように支援する
©Uzabase, Inc. All Rights Reserved.


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4EM2WDKKEW.jpg)

02
SRE実施のフェーズ
「SREの探求 22章 成功の文化としてのSRE」より
○ フェーズ1 : 消火活動/事後対応
「システムを何とか動かし続ける」と同時に、自動化を通じて新たなアプローチを構築
○ フェーズ2 : 門番
プロダクションシステムに対する変更は必ず承認を受けて通過しなければならない唯一の関門として機能する
○ フェーズ3 : 支持者/パートナー
門番フェーズを超えて
支持者 /パートナーを目指す
合意したターゲットをパートナーが達成し、その後も引き続き満足していけるように支援する
○ フェーズ4 : 触媒
あらゆるサービスの構想から廃止までに関与して、適切なツールを提供できるように支援する
©Uzabase, Inc. All Rights Reserved.


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PERMY4X679.jpg)

02
「門番」から「支持者/パートナー」へ
Google CloudのBlogにも同様のことが書いてあります
SLO の規定内でサービスが稼働していたとしても、積極的に信頼性を向上させることは、
障害の将来的なリスクを抑え、効率性を改善し、そしてコスト削減につながります。
一方、SLO を満たしていないからといって、すぐに内部での機能開発を完全にやめてしまう
組織はほとんどありません。
(中略)
関連する開発チームにも知らせましょう。このプロセスは手動でもかまいません。
SRE チームは違反をフィルターにかけて集約し、意味のあるコンテキストを提供するなど
価値を付け加えることも可能です。
https://cloud.google.com/blog/ja/products/gcp/consequences-of-slo-violations-cre-life-lessons
©Uzabase, Inc. All Rights Reserved.


# Page. 20

![Page Image](https://bcdn.docswell.com/page/P7XVG26DJX.jpg)

02
つまりこうなりたい
開発チームがSLOのモニタリングと改善を自走できるまで、サポートをする
©Uzabase, Inc. All Rights Reserved.


# Page. 21

![Page Image](https://bcdn.docswell.com/page/37KQ4M1D7D.jpg)

02
SREチームでエスカレーション100本ノックをした
エラーバジェットを消費する原因となった機能と担当チームを素早く特定して、
信頼性を回復するための情報提供をし続けた
©Uzabase, Inc. All Rights Reserved.


# Page. 22

![Page Image](https://bcdn.docswell.com/page/LJ3PLYQP75.jpg)

02
開発チームがセルフサービスでモニタリングできる仕組みを作った
開発チームがオーナーとなるAPIエンドポイントごとのSLOモニタリング
リポジトリ
(GitHub)
SLO DB
(Notion)
開発チーム
設定
Export&amp;PR
CDK
for Terraform
反映
cdktf deploy
チームチャンネル
に通知
ダッシュボード
確認
Slack
アラート
©Uzabase, Inc.
©NewsPicks
Inc.All
AllRights
RightsReserved.
Reserved.
New Relic
● Service Levels
● Dashboard
● AlertPolicy
● AlertConﬁtion
● Workﬂow


# Page. 23

![Page Image](https://bcdn.docswell.com/page/8JDLN5937G.jpg)

02
SLO違反のエスカレーションが民主化した（ここまで3年くらい）
担当しているチーム自身でSLO違反の性能劣化原因を調査＆変更したチームに共有
SREチームを介さずオンコール担当者起点や担当チーム間で問題を解決する動きが習慣化している
©Uzabase Inc. All Rights Reserved.


# Page. 24

![Page Image](https://bcdn.docswell.com/page/VEP25GZPE8.jpg)

03
CTOとしてSLI/SLOをどう活用しているか
©Uzabase, Inc. All Rights Reserved.


# Page. 25

![Page Image](https://bcdn.docswell.com/page/27VDP6WV7Q.jpg)

03
今年からCTOになって意識していること
「エンジニアのためのマネジメントキャリアパス」より
CTOとは、その会社が現在の成長段階で必要としてい
る戦略的技術系幹部
まず何よりも、CTOは会社のためを思い、事業を理解
し、技術というレンズを通して事業戦略を立てられる
ようでなければなりません。
CTOは第一に経営幹部たるべきで、エンジニアであるこ
とは二の次です。
©Uzabase, Inc. All Rights Reserved.


# Page. 26

![Page Image](https://bcdn.docswell.com/page/5JGYPND1JL.jpg)

03
CTOは三線モデルにおける一線の最終責任者
三線モデル（Three Lines Model）
事業リスク、リーガルリスク、レピュテーションリスクなど
経営上のリスクと内部統制を管理するためのフレームワーク
CTOはサイバーセキュリティやシステム障害など、
プロダクトに関するリスクを担当する経営者にあたる
一線：
事業執行部門の
経営者
©Uzabase, Inc. All Rights Reserved.
二線：
リスク管理部門
三線：
内部監査部門
https://www.theiia.org/globalassets/documents/resources/
the-iias-three-lines-model-an-update-of-the-three-lines-ofdefense-july-2020/three-lines-model-updated-english.pdf


# Page. 27

![Page Image](https://bcdn.docswell.com/page/47QM2Q1NEP.jpg)

03
SLOドキュメントは経営者として事業のリスクを捉えるツール
CUJ、担当チーム、システム対象エンドポイント、SLI/SLOがNotionデータベース化さ
れており、二線へのエスカレーション基準も定められている
©Uzabase, Inc. All Rights Reserved.


# Page. 28

![Page Image](https://bcdn.docswell.com/page/KE4VLNR371.jpg)

03
SLOの運用が適切に行われないと経営判断を間違う可能性がある
SLOドキュメントが健全に機能する状況＝正しい経営判断ができる状況と考え、
SLOの運用についてCTOとして現場の開発メンバーにプレッシャーをかけるようになった
©Uzabase, Inc. All Rights Reserved.


# Page. 29

![Page Image](https://bcdn.docswell.com/page/L713L5QZEG.jpg)

04
まとめ
©Uzabase, Inc. All Rights Reserved.


# Page. 30

![Page Image](https://bcdn.docswell.com/page/G7WPV5M6E2.jpg)

04
まとめ
SRE時代から育てたSLOの運用がCTOになっても役立っている
● SREチームのエスカレーション100本ノック時代から民主化まで3年かかった
👉
オブザーバビリティを高める→SREチームで効率化する→自動化・セルフサービス化する
→SLO文化を醸成する という流れは長い道のり
● SLOが経営のリスクを捉え、現場とコミュニケーションするためのツールになっている
👉
CTOとしてSLOドキュメントの運用が適切に行われていることに強度を持って取り組むこと
で、事業の経営者の一人として責任を全うできる
©Uzabase, Inc. All Rights Reserved.


# Page. 31

![Page Image](https://bcdn.docswell.com/page/4JZK4NQRJ3.jpg)

ご清聴ありがとうございました！
©Uzabase, Inc. All Rights Reserved.


