SREとしてSLI_SLOをどう普及してきたか、CTOとしてSLI_SLOをどう活用しているか

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

• https://cloud.google.com/blog/ja/products/gcp/consequences-of-slo-violations-cre-life-lessons

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

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

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

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

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

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

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

• https://www.theiia.org/globalassets/documents/resources/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense-july-2020/three-lines-model-updated-english.pdf

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

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

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

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

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