Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ロールが細分化された組織でSREと協働するインフラエンジニアは何をするか? / SRE Lou...

ロールが細分化された組織でSREと協働するインフラエンジニアは何をするか? / SRE Lounge #18

2025年8月5日に開催された「SRE Lounge #18」の登壇資料です。
https://sre-lounge.connpass.com/event/362882/

▼関連資料
ロールが細分化された組織でSREは何をするか? - Speaker Deck, https://speakerdeck.com/tgidgd/rorugaxi-fen-hua-saretazu-zhi-desrehahe-wosuruka

---
KINTOテクノロジーズのSNS

▼KINTO Tech Blog | キントテックブログ
https://blog.kinto-technologies.com/

▼KINTOテクノロジーズ【公式】
https://x.com/KintoTech_Dev

Avatar for Hajime KOSHIRO

Hajime KOSHIRO

August 07, 2025
Tweet

Other Decks in Technology

Transcript

  1. 多くの開発チームと一つのプラットフォーム組織 Platform Team Application Team Account Network Computing Managed Service

    Platform Product Security Service A Service Z 80 SID 4-10 Envs x すべてのプロダクトのインフラを1つの組織で一括管理しているため、バックアップなど非機能に ついての責任範囲も広い。 11
  2. セキュリティ組織 プラットフォーム開発部 開発組織を支援する充実したチーム体制 計30名以上 (/約400名) の体制でプラットフォーム領域を一括でサポート QA Cloud Infrastructure SRE,

    DBRE Managed Service Provider(MSP) Platform Engineering Security Operation SCoE A プロダクトシリーズ B プロダクトシリーズ C プロダクト X プロダクト サービス サービス サービス サービス サービス サービス サービス 12
  3. Service Reliability Hierarchy で見る各チームの業務内容 UX 開発 キャパシティ・スケール テスト/リリース インシデントレスポンス インシデント後のレビュー

    監視/オブザーバビリティ 引用 図14-1:Dickersonの信頼性の階層構造を若干修正したもの, 14.1 Dickersonの信頼性の階層構造, SREをはじめよう ー個人と組織による信頼性獲得への第一歩 p.198 SRE Cloud Infra Platform Engineer ー ー ー △ ー ー △ ◯ △ ◯ △ ◯ ◯ ◯ △ ◯ ◎ △ ◯ ◯ ◎ Dickersonの信頼性の階層構造の下層を中心にプラクティスを SREing と意識せず実行している 13
  4. 15 大きなプラットフォーム組織はユーザーとの距離が遠い 一般ユーザー 業務システム ユーザー 開発チーム プラットフォーム組織 カスタマーサポート プロダクトオーナー 1

    ホップ 2ホップ 3ホップ ユーザーからの距離が遠いほど、信頼性や価値提供との向き合い方が難しくなる 顧客の声が届きづらい 直接価値を提供できない
  5. 16 大きなプラットフォーム組織はユーザーとの距離が遠い 一般ユーザー 業務システム ユーザー 開発チーム プラットフォーム組織 カスタマーサポート プロダクトオーナー 1

    ホップ 2ホップ 3ホップ ユーザーからの距離が遠いほど、信頼性や価値提供との向き合い方が難しくなる 顧客の声が届きづらい 直接価値を提供できない 内部顧客への価値提供
  6. 17 大きなプラットフォーム組織はユーザーとの距離が遠い 一般ユーザー 業務システム ユーザー 開発チーム プラットフォーム組織 カスタマーサポート プロダクトオーナー 1

    ホップ 2ホップ 3ホップ ユーザーからの距離が遠いほど、信頼性や価値提供との向き合い方が難しくなる 顧客の声が届きづらい 直接価値を提供できない 内部顧客への価値提供 「SREのプラクティスは実践してるようだが、 ユーザーへの価値提供には繋がっているのか…?🫠 」 (信頼性の維持向上)
  7. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 22

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理
  8. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 23

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理
  9. SREが「実際には何をするのか」 24 1. インシデント/障害モード 2. インシデント後の学習モード 3. ビルダー/プロジェクト/学習モード 4. アーキテクチャモード

    5. 管理モード 6. 計画モード 7. コラボレーションモード 8. 回復とセルフケアモード 「SREの一日のモード」を見ると、インフラエンジニアにも馴染みのあるモードがある 参考 8章 SREのある一日, SREをはじめよう ー個人と組織による信頼性獲得への第一歩
  10. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 25

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理
  11. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 26

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 インシデント/障害モード
  12. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 27

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 インシデント後の学習モード
  13. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 28

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 ビルダーモード
  14. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 29

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 アーキテクチャモード
  15. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 32

    構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 アーキテクチャモード 基盤運用 インシデント/障害モード 運用管理 インシデント後の学習モード インフラ 設計 構築 ビルダーモード
  16. 業界標準やグループ会社の定める厳しい基準 33 プラットフォームで実現すべき多くの基準やルールが存在する 分類 内容 主な要素 一般的なもの (業界共通の基準) 業界全体で広く共有されて いる品質基準や技術的標準

    非機能要求グレード ・性能、可用性、保守性、セキュリティ 品質標準 信頼性、拡張性、保守性、移植性など 会社レベルのもの (組織方針・統制) 自社で定めた開発・品質に 関する方針や統制ルール 会社の方針 ・品質重視、顧客満足、継続的改善 ルール・ガイドライン ・セキュリティポリシー、情報管理、標準化方針 チームレベルのもの チーム内で共有する開発の 進め方や技術運用 インフラ運用標準 ・監視設定、ログ収集、アクセス権管理 ・環境構築手順、構成管理(IaC) プロジェクトごとのもの (個別ルール) プロジェクト固有のルール や制約事項 プロジェクト固有のインフラ設定 ・環境構成(開発・本番) ・クラウド設定(VPC、セキュリティグループ) ・バックアップ・DR設計、コスト管理、ネットワーク構成
  17. ヒアリングシートでシステム要求を漏れなく確認 40 IaC code Parameter Pack module IaC code Parameter

    IaC code Parameter 開発者 開発者 開発者 ヒアリング シート ヒアリング シート ヒアリング シート 実装 実装 実装 システム設計の早い段階でIaCコードと対応するヒアリングシートを使ったアーキテクチャの設計
  18. フレームワーク化したIaC と Product as a Platform 41 IaC code Parameter

    Pack module IaC code Parameter IaC code Parameter Network Account Product as a Platform Service Service Service Service Service Service Provisioning 組織の基準を満たすシステムを素早く構築し、プラットフォームサービスも利用可能にする 参考: [Japanese] Terraformを抽象化し環境構築の工数を削減する取り組みについて – YouTube, https://youtu.be/4h_0B0QYo2g