Team operations that are not burdened by SRE

SREが抱え込まないチーム運用
PHP開発チームと築く共通基盤づくり

2025/06/28 PHPカンファレンス2025

Transcript

1. SREが抱え込まないチーム運用 PHP開発チームと築く共通基盤づく り 2025/06/28 PHPカンファレンス2025 @zosokh
2. ヒエイカザト 株式会社ウエディングパーク エグゼクティブエンジニア +Creation本部 TECH戦略室・SRE 　 @zosokh　#野球観戦 #ちなヤク #三児の父
3. 運営メディア 結婚の各領域に特化した専門メディアを運営。ITを活用し、カップルと 様々なウエディングサービスのベストマッチを実現します。 海外挙式の日本最大級クチコミ& フォトサイト フォトウエディングの決め手が見つか るクチコミサイト 指輪選びの決め手が見つかるクチ コミサイト 経営理念：「結婚を、もっと幸せにしよう。」 ビジョン：「21世紀を代表するブライダル会社を創る」
4. 運営メディア ノーコードツール デジタル広告 オンラインスクール DX推進 結婚式費用試算サービス
5. 今日の話 SREであり、PHPを扱うプロダクトエンジニアの私から 開発体験をよくするために「任せる仕組み」を整えた話をします SREの課題と意思決定 共通基盤作りとプロトタイピング 組織アクション結果と課題
6. SREの課題と意思決定 SREの課題と意思決定 共通基盤作りとプロトタイピング 組織アクション結果と課題
7. 【今まで】SREとプロダクトエンジニアの関係性 SREチーム ・各事業のインフラ構築サポート ・SRE領域のリード・監視 ・変化に強いプラットフォームづくり プロダクトA アプリケーション開発 ・・・・・ プロダクトB アプリケーション開発 プロダクトC アプリケーション開発
8. 【今まで】SREとプロダクトエンジニアの関係性 SREチーム ・各事業のインフラ構築サポート ・SRE領域のリード ・品質、スピード担保の環境作成 プロダクトA アプリケーション開発 ・・・・・ プロダクトB アプリケーション開発 プロダクトC アプリケーション開発 インフラ環境対応（例：AWSのリソース対応）に責務を持つ 主にアプリケーション開発（インフラ以外）に責務を持つ
9. 【今まで】インフラ対応の相関図 SREチーム 依頼されたインフラ案件を遂行 プロダクトA SREに対応依頼 ・・・・・ プロダクトB SREに対応依頼 プロダクトC SREに対応依頼
10. • インフラ対応はSREの仕事 • プロダクト側エンジニアはSREへインフラ対応依頼を出す 現場あるある：SRE依存の開発体制
11. プロダクトエンジニア 📩「WAFのIPブロックリストを更新したい」👉 Slack 👉 待つだけ SRE 「パススルーの設定を変えて」👉 🫡 Slack受け取り 👉 SREが良きタイミングで対応 典型的なやり取り
12. 図解と課題 PHPプロダクトA PHPプロダクトB PHPプロダクトC チケット依頼 Slack依頼 SRE
13. 課題まとめ PHPプロダクトA PHPプロダクトB PHPプロダクトC チケット依頼 Slack依頼 SRE • インフラ対応の属人化・ブラックボックス化 • 依頼待ちによる開発停滞 • SREが「長期的改善」に時間を避けない構造的問題 👇👇👇 SREがすべての処理のハブになっていて「待ち」が発生 🔥 プロダクト側には操作手段がなく、すべて「依頼」で処理するしかない構造 ⌛
14. 「やらない」「やれる人を増やす」ではなく 「任せる」状態を作る 【意思決定】プロダクトエンジニアの裁量を広げ、インフラ対応も 行なってもらうようにする 改善のために戦略を作り、意思決定 本日の主題
15. 「任せる」ために 目指したのは • 自走できる開発チーム • 守られたインフラ対応環境 SREがやるべきことは • 「仕組みで支える」こと
16. 戦術：プロダクト側へ、インフラ対応の環境づくり • プロダクトエンジニアへのIaCを活用した安全にインフラ実行で きるワークフローづくり • ドキュメント化・レビューのガイドライン設計 👉 SRE・プロダクトエンジニアの開発効率化と世へのデリバリース ピードを上げていく
17. • プロダクトエンジニアへのIaCを活用した安全にインフラ実行で きるワークフローづくり • ドキュメント化・レビューのガイドライン設計 👉 SRE・プロダクトエンジニアの開発効率化と世へのデリバリース ピードを上げていく プラットフォームエンジニアリング **プラットフォームエンジニアリング（Platform Engineering）とは、開発者がアプリケーションを効率的に開発 ・デプロイ・運用できるようにするための内部開発プラットフォーム（IDP: Internal Developer Platform）**を構 築・管理するエンジニアリング分野です。 目的 プラットフォームエンジニアリングの目的は、開発チームの生産性向上と、インフラ管理の複雑さを軽減すること です。これにより、開発者は本来の業務であるアプリケーション開発に集中できるようになります。 戦術：プロダクト側へ、インフラ対応の環境づくり
18. • プロダクトエンジニアへのIaCを活用した安全にインフラ実行で きるワークフローづくり • ドキュメント化・レビューのガイドライン設計 👉 SRE・プロダクトエンジニアの開発効率化と世へのデリバリース ピードを上げていく 裏背景：私自身もプロダクトエンジニア 今はSREメインで仕事していますが、アプリケーションエンジニア（PHPer）でもあります。 プロダクト・PHPer・アプリケーションなど「枠組み」を無視して、イチ開発者として具現化力を上げ世へのリリー スを多く行なっていくために、課題点だったインフラ裁量がなかった環境は当時開発とリリースへの煩わしさを感 じていた。 より開発体験を良くしてデリバリー多く・素早く届けていきたい 戦術：プロダクト側へ、インフラ対応の環境づくり
19. 共通基盤作りとプロトタイ ピング SREの課題と意思決定 共通基盤作りとプロトタイピング 組織アクション結果と課題
20. 共通基盤作りとプロトタイピング｜ 基盤編
21. プロダクトエンジニアが自走を支える仕組み作りをした • IaCのプロダクト単位分業 • 安全に実行できるワークフロー（CI/CD整備） • ドキュメント化・レビューのガイドライン設計 基盤づくり
22. 単一リポジトリをプロダクト毎に分割 IaCのプロダクト単位分業 プロダクト毎のワークフロー実行を可能にした • terraform-プロダクトA • terraform-プロダクトB • terraform-プロダクトC • terraform-プロダクトD 〜〜
23. Gitフローに基づいた、Terraform実行確認と反映を自動化設計 安全に実行できるワークフロー（CI/CD編） develop ブランチ release ブランチ main ブランチ featureなどの ブランチ PR 自動 PR 自動 PR merge merge merge PR
24. 安全に実行できるワークフロー（CI/CD編） develop ブランチ release ブランチ main ブランチ featureなどの ブランチ PR 自動 PR 自動 PR merge merge merge PR dev環境 stg環境 prd環境 Gitフローに基づいた、Terraform実行確認と反映を自動化設計
25. 安全に実行できるワークフロー（CI/CD編） develop ブランチ release ブランチ main ブランチ featureなどの ブランチ PR 自動 PR 自動 PR merge merge merge PR dev環境 stg環境 prd環境 plan apply apply plan plan plan Gitフローに基づいた、Terraform実行確認と反映を自動化設計 apply
26. 安全に実行できるワークフロー（CI/CD編） develop ブランチ release ブランチ main ブランチ featureなどの ブランチ PR 自動 PR 自動 PR merge merge merge PR dev環境 stg環境 prd環境 plan apply apply plan plan plan Gitフローに基づいた、Terraform実行確認と反映を自動化設計 apply
27. レビューとapply権限制限による、フロー明確さと安心づくり ドキュメント化・レビューのガイドライン設計 develop ブランチ release ブランチ main ブランチ featureなどの ブランチ PR 自動 PR 自動 PR merge merge merge PR PR時に、Terraformコードの修正内容をレ ビュー • レビュアー（主にSRE）はplan実行内 容を確認できる 👉 誰が書いたコードでもレビューと実行内 容確認ができるフロー merge権限の限定 • applyさせるタイミング・人をコント ロールできる 👉 事故防止のため権限を制限させたapply 環境
28. レビューとapply権限制限による、フロー明確さと安心づくり ドキュメント化・レビューのガイドライン設計 develop ブランチ release ブランチ main ブランチ featureなどの ブランチ PR 自動 PR 自動 PR merge merge merge PR PR時に、Terraformコードの修正内容をレ ビュー • レビュアー（主にSRE）はplan実行内 容を確認できる 👉 誰が書いたコードでもレビューと実行内 容確認ができるフロー merge権限の限定 • applyさせるタイミング・人をコント ロールできる 👉 事故防止のため権限を制限させたapply 環境 〜〜権限の制限による安心~~ 安心と思えるように、前提として、開発しやすい環境もセットで整備した • ローカル開発で簡単にTerraformコマンド実行環境が立ち上がる • ローカル開発時はplan実行はできるがapplyできない状態の権限を渡す（状況による） ◦ 実行確認が手元で行え、確認・修正を繰り返せる環境 という環境から 開発体験に極力弊害を抑え、尚且つ事故を起こさせない予防線による安心状態を作った
29. IaCテンプレート戦略 • 良くあるユースケースに対応したTerrafomモジュールを共通モ ジュール化 • 「変数を1つ変えるだけ」の体験設計 • ドキュメント化 👉テンプレート倉庫としてPRで使う流れにする ドキュメント化・レビューのガイドライン設計
30. プロダクトエンジニアへの不安への共感+対策提案 プロダクトエンジニアの声 対策・伝え方 インフラの知識や構造理解が乏しく、何をどうしたら良い か分からない IaCテンプレートや過去PRからやり方を踏襲できる環境を与 え、段階的に徐々にスキルと知識を取得していけるように する インフラ環境を壊さないか不安 何かあったときの責任が怖い • GitHub Actionsのみからインフラ反映できるように する • plan 👉 review 👉 approve 👉 merge・applyの構 造で、誤ってインフラを壊すなどの事故防御。レ ビューを経てインフラ反映させる構造へ • PRレビュー＋実行者ログ＋監視でトレーサビリティ を確保 制限が多いとローカル開発（Terraformコード拡張）がし にくそう ローカル環境の立ち上げやすさと、planを実行できる権限 を付与。時にはapply確認した開発を行いたい場合は、状況 に応じて権限を付与
31. プロダクトエンジニアへの不安への共感+対策提案 プロダクトエンジニアの声 対策・伝え方 インフラの知識や構造理解が乏しく、何をどうしたら良い か分からない IaCテンプレートや過去PRからやり方を踏襲できる環境を与 え、段階的に徐々にスキルと知識を取得していけるように する インフラ環境を壊さないか不安 何かあったときの責任が怖い • GitHub Actionsのみからインフラ反映できるように する • plan 👉 review 👉 approve 👉 merge・applyの構 造で、誤ってインフラを壊せないようにし、レ ビューを経てインフラ反映させる構造へ • PRレビュー＋実行者ログ＋自動監視でトレーサビリ ティを確保 制限が多いとローカル開発（Terraformコード拡張）がし にくそう ローカル環境の立ち上げやすさと、planを実行できる権限 を付与。時にはapply確認した開発を行いたい場合は、状況 に応じて権限を付与 自由な実行や検証を行える環境 制限された実行環境 SRE側のレビューやチェックを行うなど 品質担保した環境
32. 共通基盤作りとプロトタイピング｜ プロトタイピング編
33. 「小さく早く」を方針に、少ない人数で試して👉成功したら広げる、と いう形で取り組みの検証を行なった 一部のプロダクトエンジニアに、一部のインフラ対応をお願いするプロ トタイピングを行う プロトタイピング
34. • 比較的対応が簡単な対応を任せる ◦ WAFやパススルーの対応のみ対応してもらう • SREから修正するソースコード箇所指定や、参考になる過去のPR例 を見せる • フローをドキュメント化 上記を行いながら、基盤もビルドアップを繰り返す 一部のインフラ対応を任せる
35. ターゲット • プロダクトエンジニア2年目以降の人 ◦ インフラ対応経験のある人・ない人 ◦ Terraformを扱ったことがある人・ない人 👉 プロダクト開発経験がある人が前提（全員PHPer） 👉 インフラ・Terraform開発経験や理解がある人・ない人両者での事例 出しと開発体験をヒアリングしていく
36. SRE・プロダクトエンジニア SRE・プロダクトエンジニア SRE 進め方 共通基盤作成 Terraform PJ整備 ドキュメント整備 オリエン開始 インフラ教育 実行 レビュー対応 基盤修正 都度ヒアリング プロトタイピング
37. SRE・プロダクトエンジニア SRE・プロダクトエンジニア SRE 進め方 共通基盤作成 Terraform PJ整備 ドキュメント整備 オリエン開始 インフラ教育 実行 レビュー対応 基盤修正 都度ヒアリング プロトタイピングのこの部分を繰り返す 実行する中で、 • ローカル環境の権限種別 • PR時の terraform planを全環境分確認できるようにする • apply実行の通知 • リリースPRの自動化 などの修正とビルドアップを同時進行で行なっていく また、この期間にプロダクトエンジニア側に対応ナレッジも溜まって いく プロトタイピング
38. 簡単な作業はプロダクトサイドで対応できる状態が生まれていく • 経験値に応じて、任せる対応物のレベル感を上げていく • 他のプロダクトメンバーへも同対応をしてもらうようにする ポツポツ対応事例が出始める この部分が 徐々に減少 傾向へ
39. 組織アクション結果と課題 SREの課題と意思決定 共通基盤作りとプロトタイピング 組織アクション結果と課題
40. プロトタイピング開始前6ヶ月と開始後6ヶ月の対応件数比較 SREの対応依頼件数の減少 開始前 開始後 143件 122件 季節的要因で、まだ引き継ぎできていない対応物が増えてしまったが・・ が、プロトタイピング対象のWAFのIPリスト更新やパススルー対応は 開始前 開始後 30件 5件 変わらん・・・・ 減ってきてる 最初3ヶ月は対応 フォローに手間とリ ソースが発生
41. インフラ対応の相関図が変化 SREチーム ・依頼されたインフラ案件を遂行 ・プロダクトエンジニア対応のコードレビュー プロダクトA アプリEnがインフラ対 応 ・・・・・ プロダクトB アプリEnが インフラ対応 プロダクトC SREがインフラ対応 SREがインフ ラ対応 SREじゃないと対応 できない状態が減少 傾向
42. • 全社レベルで行うセキュリティ対応 • 生産性向上に向けた基盤づくり • 生成AI基盤や土壌づくり 目の前の改善や解消対応だけでなく、長期的な基盤づくりへの対応 を行い始めている SREの長期的対応にも着手し始める
43. • インフラ対応の待ち時間の減少からリードタイムの変化 • 対応者のスキル面の変化 数値に表すほど大きな変化は起きていないが、プロダクト側のイン フラ裁量がさらに増えていくことで、より大きな効率化が生まれて いく プロダクト側の変化
44. • インフラ対応の待ち時間の減少からリードタイムの変化 • 対応者のスキル面の変化 開発担当のアプリケーションだけじゃなく、アプリケーションイン フラ理解につながる。障害対応スピードや今後の設計変化・技術 チャレンジに期待 また、SREへのキャリアを考えるきっかけづくりにも期待 プロダクト側の変化
45. • インフラに手を出していても、インフラ・Terraformについて 本質的な理解が出来ている対応者はまだ少数 （マネコンどこ見れば良いんですか、、の質問もまだ出る） 👉 より経験を積み、裁量やスキルレベルをあげられるよう にする 👉プロダクト側によりインフラ裁量を大きくしていくプラ ンを構想中 課題面
46. • インフラに手を出していても、インフラ・Terraformについて 本質的な理解をしながらの対応者はまだ少数 （マネコンどこ見れば良いんですか、、の質問も出る） 👉 より経験を積み、裁量やスキルレベルをあげられるよう にする 👉プロダクト側によりインフラ裁量を大きくしていくプラ ンを構想中 課題面 まだまだ走り始めた序盤ですが、 変化に強いプラットフォームに向けて、スケールアップに対応できるよ うにしていきたい
47. プロダクトエンジニアの裁量変化によるメリット 分野 具体例（PHP開発と関連付け） 📌ログ設計 Laravel Auditingのログ出力先のS3バケット作成・またはFluentdで のログ転送先作成 📌 データベース運用・改善 AuroraやRead Replica追加を自分で試せる。DBマイグレーションで 扱うワンショットタスク用のECS環境を作る 📌 監視・モニタリング CloudWatchダッシュボード作成やアラート対応 📌 マネージドサービスとの連携 アプリケーションからAWSリソースアクセスの権限付与 📌 コンテナ環境構築 AWS App RunnerやFargateへのLaravelデプロイ、Docker化環境を 自分で試作可能 📌 セキュリティ改善 AWS Secrets ManagerやSSMをLaravelと組み合わせて安全に.env管 理
48. プロダクトエンジニアの裁量変化によるメリット 分野 具体例（PHP開発と関連付け） 📌ログ設計 Laravel Auditingのログ出力先のS3バケット作成・またはFluentdで のログ転送先作成 📌 データベース運用・改善 AuroraやRead Replica追加を自分で試せる。DBマイグレーションで 扱うワンショットタスク用のECS環境を作る 📌 監視・モニタリング CloudWatchダッシュボード作成やアラート対応 📌 マネージドサービスとの連携 アプリケーションからAWSリソースアクセスの権限付与 📌 コンテナ環境構築 AWS App RunnerやFargateへのLaravelデプロイ、Docker化環境を 自分で試作可能 📌 セキュリティ改善 AWS Secrets ManagerやSSMをLaravelと組み合わせて安全に.env管 理 アプリと運用の両面を見通し、サービス全体を俯瞰する視点を持てるようになる 📌 長期的な視野でのサービス設計力アップ • サービスを拡張する際のインフラコストや運用負荷を意識するようになる • アプリケーションの機能設計とスケーラブルなインフラ構成を同時に検討していけるようになる。リファクタ リングのコストが低下 📌 トラブルシュート能力向上 • 障害発生時、アプリ・インフラ両面の知識があると迅速な原因特定・復旧が可能になる • 運用視点を持つことで、アプリケーションのコード段階で運用リスクを減らせる 📌 サービス全体への責任感と当事者意識の強化 • アプリケーションだけでなく、インフラや運用も「自分たちのもの」と捉えられるようになる • 開発者がサービスの将来を考え、自ら改善やコスト削減を提案するような文化が醸成される
49. まとめ
50. SREとプロダクトエンジニアの 裁量変更を意思決定した話 まとめ プロダクトエンジニアにもイン フラ対応を行える共通基盤作成 と、インフラ対応実行への検証 を「小さく早く」対応実績を 作って行った SRE以外からインフラ対応実績が も出てきている。SRE自身も長期 的な改善対応に手が出し始めてい る。プロダクトエンジニアの裁量 が広がることで今後技術チャレン ジへの幅を広げていきたい SREの課題と意思決定 共通基盤作りとプロトタイピング 組織アクション結果と課題
51. ご清聴ありがとうございました