©2024 10X, Inc. スタートアップの急成長に寄り添う On-Call体制構築とその変遷 SRE NEXT 2024 2024/08/04 (Sun)

©2024 10X, Inc. 目次 ● 自己紹介 ● 弊社について ● 発表のねらい ● フェーズごとに事例を紹介 ○ プロダクトや組織の状況 ○ 起きた課題 ○ それに対する取り組み ● 振り返り ● まとめ 2

©2024 10X, Inc. 自己紹介 ● 堀見 宗一郎 (@horimislime ) ● 株式会社10X Reliabilty & Security部 SREチーム ● メガベンチャー・スタートアップでiOS開発 → バックエンドや信頼性周り 🔰 3

©2024 10X, Inc. 4 弊社について

©2024 10X, Inc. 5 チェーンストアECに特化した EC/DXプラットフォーム

©2024 10X, Inc. 6 株式会社10X概要 2017 AI献立アプリから創業し、 食や買い物の課題と向き合う 創業 献立推薦アプリ「タベリー」リリース 2019 タベリー オンライン注文機能リリース 自社ネットスーパー「タベクル」の検証 2018 2.5億円の資金調達を実施 2020 ネットスーパー・ネットドラッグストアの立ち上げと成長を支援する 「Stailer」をローンチ 2021 シリーズBで15億円の資金調達を実施 2024 Stailer導入企業が増加中 (13社)

©2024 10X, Inc. 発表のねらい ● 立ち上がり期からゼロベースでの構築、どういった課題があったか ● 何を、どの順番で解いていったのか ● 振り返りつつ何が良かったか、次に繋げられるか考察 7 💭 On-Callって意外と始めるのが大変... ● 何から手をつけるべきか悩ましい ● 運用寄りな面も多く体系的なノウハウが乏しい 📝 実際にやってみての気づきを共有

©2024 10X, Inc. 8 黎明期

©2024 10X, Inc. プロダクトや組織も黎明期 ● UXの提供からECを包括するプロダクトへ ● 機能が足りず開発は全速力。開発 13人、全員SWE ● モニタリングは一通りあるが簡素な構成 ○ Cloud Monitoring (GKE) ○ Sentry、Crashlytics（アプリケーション） 9

©2024 10X, Inc. 起きていたこと ● 機能やユーザ数とともにエラー数も激増 ● アラートは仕掛けてはいるが、運用整備が追いつかず ○ オペレーションの手順化 ○ 対応ステータス管理 ● 誰がOwnershipを持つかが不明瞭 10

©2024 10X, Inc. 初手の取り組み ● PagerDutyも整備しまずは全てここを通すように ● 誰かが必ずアラートを拾える状態を優先 ○ 各機能毎に、詳しいSWEメンバー2人以上に通知 ● Ownerが不明なものも多くcatch-allでSREが受け皿に🔥 11 💡 振り返ると初手として重要だった

©2024 10X, Inc. 初期を振り返って ● 対応漏れなどの危機的な状況をまずは防ぐ ● アラートの氾濫や一旦Pager入れましょう、もありきたり感あるが... ● 💡振り返ると初手として重要だった 12

©2024 10X, Inc. 13 種まき期

©2024 10X, Inc. 1チームからミッション毎のチームへ ● 機能の増加でチームもミッション単位で組成 ● ここで信頼性にフォーカスする部門（ SREチーム）も発足 ● プロダクト / 組織 どちらも一人が全てを把握できない領域へ 14

©2024 10X, Inc. ● 複雑さを扱っているチームへの負荷偏り ● 機能とともに増え続ける認知負荷 ● Ownership問題 起きていたこと 15 負荷分散や認知負荷軽減が必須 →On-Callと呼べる体制へ

©2024 10X, Inc. まず小さく始める ● 輪番体制やチーム単位の負荷分散が急務に ● On-Call体制をSREチーム内でdogfooding ● ドキュメント作成・労務サイドと待機制度を整備 ○ メンタルモデル / オペレーション別々に言語化 ○ PagerDuty Incident Response Guide 社内向けVer ○ 受け入れやすさと納得感のある仕組みに 16

©2024 10X, Inc. On-Callを下支えする仕組み作り ● Runbookの運用開始 ○ GitHub Markdownで管理、k8sへの変更時等に自動チェック ○ 実装担当者・リカバリフロー・エスカレ先などを記載 ● この辺りからTerraformによるIaCも活発化 17

©2024 10X, Inc. Feedbackを集めつつ体制を広げていく 18

©2024 10X, Inc. ● 部門全体に段階リリースする過程で制度自体もアップデート ● チーム内で一定期間の試験導入や報酬体系を用意できたのもポイント 結果として 19 💡 粗い状態のスタート地点で課題意識が揃った状態に ● 輪番体制が整わずにPagerを使い始めたので一定ストレスはかかったが... ● On-Callのメリットの理解・各チームでの自律的な運用が促進 ● 「アラートが多すぎる」等の問題も、早い段階でOwnership委譲に 🚀 小さく始めて改善しながら全体展開へ

©2024 10X, Inc. 20 成熟期

©2024 10X, Inc. 更なる複雑性を扱うプロダクト・組織へ ● 一気に提供先パートナー拡大。大小様々な規模・異なる事業モデルなど ● 更なる複雑化にともない機能ごとのドメインチームに移行 ● 事業 x 組織で大きく変化 21 現在提供中のパートナー様 マトリクス型組織図

©2024 10X, Inc. 元々あった課題と新たな問題 ● 組織拡大による人の入れ替わり ● モニタリングやOn-CallのSRE属人性 ● アラートの更なる精緻化 ● 改めて「この機能のオーナーは ?」問題 22

©2024 10X, Inc. ● SEV1〜SEV4の緊急度レベルと夜間対応要不要、通知手段などを整理 ● 全コンポーネントに気合いでOwnershipを割り振り ● 緊急度レベル・Ownerチームをk8s manifestで識別可能に レベル定義 即時性 通知経路 重大(SEV-1) システム全体や金 銭、個人情報に関す る実害 24/7で対応 検知した時点で社内 外へ報告 PagerDuty (電話・アプリ通知) 大(SEV-2) お客さまのサービス を利用に影響あり 24/7で対応 検知した時点で社内 報告必須 PagerDuty (電話・アプリ通知) 中(SEV-3) お客さまの一部に影 響あり 対応が遅れると SEV-2相当 翌朝始業後のリカバ リが可能 PagerDuty (アプリ通知) 小(SEV-4) ユーザ影響の少ない 軽微な不具合 翌営業日中までの対 応でOK PagerDuty (翌営業日通知) Slack Channelへ通知 対応緊急度やOwnershipを明確に 23

©2024 10X, Inc. ● モニタリング関連の設定をチームごとのTerraform resourceとして管理 ○ DataDog Monitor、PagerDuty（Service, Schedule）、Slack Channelなど ● チーム組成時のOn-Callメンバー追加から専用Slackチャンネルまで一気通貫で生成 ● 現在SREからほぼ手離れし、非エンジニアでもセルフオンボーディング可能 Terraformによる自動化の恩恵 24 💡 On-Callと組織構造/Ownershipは密接 = IaCの効果大

©2024 10X, Inc. 25 取り組みを通じた振り返り

©2024 10X, Inc. よりスマートにできるだろうか ● On-Callが必要になる=良くも悪くも大変な時期 ● アラート量 = システムが未発達な面もある ● Ownershipは組織の成熟度による部分も大きい ○ 結局割と最後まで悩まされていた部分（まだ残っているところも） ○ チームが綺麗に割れれば持ち主も決まる 26

©2024 10X, Inc. 正しい順番で取り組むのが重要 ● Progressiveにやればフィットするとも言えない ● 対応漏れがない状態を最速で実現することがお客様目線で何より大切 ● そのためにまず粗い状態でも組織全員で向き合い、負担を分散していくべき ● 「アラートが多すぎる」「受け手が不明瞭」といった目につく問題は後から解決しやすい 27

©2024 10X, Inc. まとめ ● 立ち上がり〜成長過程における現場課題とOn-Call体制づくりを紹介 ● 理想も大事だが、まずは大切なことを優先しつつみんなで体制を育てていくのが大事 ○ 最低限の信頼性担保が先決 ○ 粗い状態でも全員で課題に向き合い、体制を改善していく ● 痛みや時間も伴うが、様々な物事が成熟していくことで解決しやすい部分もある 28 🏁 信頼性を高めつつプロダクト・組織の成長に寄り添いながら理想形へ