プロダクト専任SREを置かずに 信頼性を追求する

https://topotal.connpass.com/event/402202/

Transcript

1. もう一度考えるSRE #1 プロダクト専任SREを置かずに 信頼性を追求する 2026-07-31 Atsushi Tanaka @bgpat © 2026 Wantedly, Inc.
2. Profile ウォンテッドリー株式会社 Infra Squad Leader ⽥中 篤志 Atsushi Tanaka 2018年ウォンテッドリー株式会社にインフラエンジニアとして新卒で入社し、 Kubernetesの運用や分散トレーシングの導入を担当。インフラ/SRE領域を専門 としつつプロダクト開発やコーポレートエンジニアも兼任し、2024年からはインフ ラ領域のリーダー/マネージャーを担当している。 直近は全社で生成AIの活用を進めるチームのリーダーとしても活動。 bgpat © 2026 Wantedly, Inc. bgpat_
3. 会社概要 社名 ウォンテッドリー株式会社 代表者 代表取締役 仲 暁⼦ 設⽴ 2010年9⽉ 社員 120名 上場区分 東証グロース市場 本社 〒150-6005 東京都渋⾕区恵⽐寿4-20-3 恵⽐寿ガーデンプレイスタワー 5F © 2026 Wantedly, Inc. 3
4. ミッション 究極の適材適所により シゴトでココロオドル ひとをふやす ウォンテッドリーは、⾃律‧共感‧挑戦のある適材適所を、 ⼀時的でも、局所的でもなく、構造的に⽣み出し続けることによって、 あらゆる⼈がシゴトに没頭し成果を上げ、その結果成⻑を実感できるような 「はたらくすべての⼈のインフラ」を構築していきます。 © 2026 Wantedly, Inc. 4
5. 提供サービス 採⽤サービス © 2026 Wantedly, Inc. ATS 福利厚⽣ マネジメントツール 社内報 5
6. ウォンテッドリーの Infra Squad （インフラチーム） 機能とプラクティスをプラットフォームとして提供していく © 2026 Wantedly, Inc.
7. 今⽇話すこと Platform SRE を8年やってきた 取り組みについて紹介します © 2026 Wantedly, Inc.
8. Platform SRE の取り組み例 01 SLO 02 マイクロサービス基盤 03 障害対応フロー © 2026 Wantedly, Inc. 8
9. SLO 運⽤ 取り組み例 ① © 2026 Wantedly, Inc.
10. SLO運⽤の変遷 2021-2022年 : ⽬的とのズレ 2019年 : 運⽤ルール定義 設定したSLOと守りたい機能 未達時の連携や調査⽅法の課題 のズレが⽬⽴ってきた。四半 に対し、インフラチーム主導の 期レビューを試みるも、運⽤ 運⽤ルールを制定。 2018年 : 導⼊ 負荷と組織変更で形骸化。 正常な機能提供を監視すべきと 2020年 : エラーバジェット導⼊ いう理由で導⼊。計測とチーム 意思決定ツールとして導⼊。信 ⽬標化が⽬的。 頼性回復と攻める選択肢を確保 し、バーンレート監視も開始。 © 2026 Wantedly, Inc.
11. 2018年 導⼊ インフラチーム内の指標として SLO を導⼊ • インフラチームの役割として「正常に機能提供できていること は監視すべき」という理由で導⼊ • とりあえず計測できるようにすること、チーム⽬標として使え る状態にすることが⽬的だった © 2026 Wantedly, Inc.
12. 2019年 運⽤ルールの整備 ⽬標未達時の動き⽅が属⼈化 • 課題 ◦ 調査⽅法がわからない、そもそも何を元に計測している？ ◦ チーム外への連携⽅法が決まっていない • SLO/SLI の運⽤ルールを決め当時のリーダーと合意 ◦ インフラチームが責任持って運⽤ ◦ 問題があれば関係チームに連携 © 2026 Wantedly, Inc.
13. 2020年 エラーバジェット導⼊ SLOを下回った時にはもう遅い • エラーバジェットを導⼊し、意思決定のためのツールにする取 り決め • 信頼性回復の判断だけでなく「信頼性を使う」という選択肢も 確保 • バーンレートも監視し、悪化の兆候を検知できるように © 2026 Wantedly, Inc.
14. 2021-2022年 形骸化との戦い 設定したSLOと守りたい機能がずれていった • 新システムへの移⾏で計測クエリが追従できず、プロダクトの 重要度も変化 • 四半期ごとの⾒直し運⽤を作ったが負荷が⾼く数回で廃⽌ ◦ 数回で致命的なズレは解消できた ◦ 営業も含めた責任者にSLOを説明し理解を得たが、リー ダー交代やチーム再編でSLOを知らない責任者が増加 © 2026 Wantedly, Inc.
15. SLO運⽤のまとめ 共通⾔語化はしない選択 • 無理にSREを広めず⽬的に沿っ 運⽤としての Platform SRE • た運⽤ができれば良いと考える 指標を、インフラチームはSLO ように。 • 未達時はプロダクトの⽤語に変 換して連携し対処。 • 社内のチーム紹介などで年1回 程度SLO運⽤について共有。 © 2026 Wantedly, Inc. プロダクトチームはプロダクト を追う体制。 • インフラチームで運⽤するため のダッシュボード刷新やアラー ト整備などで継続的に改善。
16. Kubernetes マイクロサービス基盤 取り組み例 ② © 2026 Wantedly, Inc.
17. マイクロサービス基盤の変遷 2016年 : k8s 導⼊ 2018-2020年 : マイクロサービス化 現在 : 安定性への回帰 需要増により共通ライブラリ 安定性して動くことの重要度が 「servicex」が誕⽣。デバッグ 上昇。 性向上のため分散トレーシング プラットフォーム横断の変更は を導⼊。 控えめに。 インフラ構築のボトルネック解 2020-2024年 : ⽣産性向上への投資 消のためセルフサービス化。 プレビュー環境など開発⽣産性 オートスケールと⾃動監視を実 向上へ投資。既存への機能追加 現。 が中⼼に。 © 2026 Wantedly, Inc.
18. 2016年 Kubernetes 導⼊ インフラ構築のボトルネック解消 • セルフサービス化を進めるためKubernetesを導⼊ • このタイミングでデプロイツールを内製 • 以前の基盤との違い ◦ 負荷によるオートスケール ◦ ⾃動での監視設定 © 2026 Wantedly, Inc.
19. 2018-2020年 マイクロサービス化 成功体験から利⽤が拡⼤ • 画像処理や機械学習の需要でマイクロサービス化が進⾏ ◦ 成功体験からマイクロサービスが頻繁に作られるように ◦ 実装の共通化のため共通ライブラリ「servicex」が誕⽣ • デバッグのしづらさから分散トレーシングを導⼊ © 2026 Wantedly, Inc.
20. 2020-2024年 開発⽣産性の追求 作る時代から使う時代へ • マイクロサービスの新規作成ペースは低下、統廃合も進む ◦ 既存サービスへの機能追加が中⼼に ◦ 「早く試せる」「雑にリリースしても壊れない」仕組みが 求められるように • 開発⽣産性を上げる取り組みがメインに ◦ プレビュー環境「kubefork」 © 2026 Wantedly, Inc.
21. 現在のマイクロサービス基盤 意識しなくても利⽤している世界に • 安定性に対する重要度が上がっている ◦ 正常に動いているのが当たり前 ◦ 開発環境でも不安定になると業務が⽌まって問題に • 共通ライブラリ「servicex」の更新頻度が低下 ◦ 必要な機能がほぼ揃った ◦ 開発が活発なマイクロサービスの数が絞られ、横展開のモ チベーションは低下 © 2026 Wantedly, Inc.
22. Kubernetes マイクロサービス基盤 まとめ ⼀つの基盤を使い倒す プロダクトコードへの介⼊ • 選択肢を減らすことで • Platform SREと⾔いつつ 信頼性も⽣産性も向上。 プロダクトコードに直接⼿ • 改善や洗練を繰り返すこと を⼊れることも多かった。 で当たり前に求められる品 質に。 • 例 ◦ 分散トレーシング導⼊時の全 マイクロサービスへの計装 ◦ © 2026 Wantedly, Inc. SLI計測のためのログ出⼒追加
23. 障害対応フロー 取り組み例 ③ © 2026 Wantedly, Inc.
24. 障害対応の変遷 2020-2021年 : ⽂化醸成 現在 : 継続的な啓蒙活動 「障害対応の⼼構え」が明⽂ SRE以外の参加も定着。定期的 化。ポストモーテムの週次レ な訓練を実施。ポストモーテム ビュー会開始。オンコール⼿当 は「学びが得られるか」を基準 も導⼊。 に運⽤。 2017-2018年 : 体制整備 2023年 : 職種拡⼤ DB起因の障害が多発したこと アプリケーション起因の障害 でインフラチーム中⼼で障害対 増。障害対応訓練を実施し、 応にあたるための体制を整備。 BEエンジニアもオンコール当 番に追加。 © 2026 Wantedly, Inc.
25. 2017-2018年 体制整備 DBの障害多発をきっかけにフローを整備 • DB起因の障害が多発し、障害対応フローを整備 • インフラ起因の障害が多く基本インフラチームで対応 • ポストモーテムもこの時期に提案された ◦ 実施されないことも多かった • オンコールはインフラエンジニアが増えたことで インフラチーム全員での運⽤から週替わり当番制へ © 2026 Wantedly, Inc.
26. 2020-2021年 ⽂化醸成 インフラチームから組織全体に⽂化が広がる • 「障害対応の⼼構え」を明⽂化‧ハンドブックとして公開 • ポストモーテムの週次レビュー会を設定 ◦ どんな観点で書けばいいかをインフラチームでレビュー ◦ 直近のインシデント確認で書かれない課題にも対応 • オンコール当番に⼿当を導⼊し、負担の⾼さによる交代のしづ らさを緩和 © 2026 Wantedly, Inc.
27. 障害対応の⼼構え - Wantedly Engineering Hanbook © 2026 Wantedly, Inc.
28. 2023年 SRE以外への拡⼤ 障害の原因がアプリケーション側へ • 障害の原因がインフラからアプリケーションへ移り始める • SRE以外も障害対応に関われる仕組みを整備 ◦ 障害対応訓練の実施で参加のハードルを低減 ◦ オンコール当番にバックエンドエンジニアも追加 © 2026 Wantedly, Inc.
29. 現在の障害対応 継続的に啓蒙活動を実施 • 研修‧訓練‧ポストモーテム共有を全エンジニア対象に実施 • 障害対応‧オンコールはインフラチーム以外も参加 ◦ 参加率は圧倒的にインフラチームが⾼い ◦ ⼈やチームにも偏りがある • 運⽤を重くしない⼯夫としてポストモーテムは 「学びが得られるか」を基準に書くか判断 © 2026 Wantedly, Inc.
30. 障害対応のまとめ プラットフォームとしての障害対応 • 各チーム単独でこの体制を 作るのは⾮常に困難。 • SREにとっては、アプリ ケーションの実態を深く知 参加者の偏りという現実 • 役割が分かれているチーム ほど参加率が低い傾向があ る。 • とはいえ、当事者は集ま る貴重な機会にもなってい り、必要な⼈を呼べば来る る。 体制にはなっている。 © 2026 Wantedly, Inc.
31. まとめ © 2026 Wantedly, Inc.
32. これまでの取り組みについて思うこと • 全員がSREと同じ視点で信頼性を考えられているわけではないが、 プラットフォームへの投資で意識しなくても信頼性のある開発はで きる状態になっている • Platform SREとしての取り組みはプラットフォームだけ触っている のでは上⼿くいかなかった © 2026 Wantedly, Inc.
33. Platform SRE が合っている組織の条件 組織体制 個⼈のスキル 事業フェーズ プラットフォームによる 全体のことを考えて 攻めと守りの 共通化の恩恵が⼤きい ⾃律的に⾏動できる バランスが取れる 開発チームやシステムが複数あ SREが運⽤を巻き取るのではな 攻めばかりしている環境だと ることが前提。単⼀の巨⼤なモ く開発者が⾃分たちで運⽤する SRE⾃体が成り⽴たない。⼀⽅ ノリスプロダクトしかない場 ことが前提。また、お互いが相 で守るべきものの割合が増えす 合、SREは⾃然と「そのプロダ ⼿の⽴場を考えてコミュニケー ぎると開発チームの中にSREを クト専任のSRE」として振る舞 ションが取れないとプラット 持たないと本来やるべき機能開 うことになる。 フォームが分断してしまう。 発に⼿がつかなくなる。 © 2026 Wantedly, Inc.
34. 今後も Platform SRE を続けるべきか • 守るべきもの (= 運⽤) は増え続けている • 2023年当時のリーダーも似た問いを残していた • 現状に満⾜せず、どうあるべきかを考え続けることが⼤事なの かもしれない © 2026 Wantedly, Inc.
35. 今後も Platform SRE を続けるべきか © 2026 Wantedly, Inc.
36. We are hiring ⼀緒に悩んでくれる⼈を 募集しています ウォンテッドリーでは、現状のアーキテクチャや運⽤体制 に満⾜せず、今後の信頼性のあり⽅を共に考え、プラット フォームを進化させていく仲間を探しています。 https://wantedly.com/projects/522096