SRE依存からの脱却運用を開発チームへ移す、フルサイクル開発体制の実践

by joe

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

フルサイクル開発体制とは？開発チームが、設計から開発・デプロイ・運用・改善までを一気通貫で担う体制. 「作る人」と「運用する人」を分けず、作ったチームが運用まで責任を持つ. 設計 → 開発 → デプロイ → 運用・監視 → 改善同じチームがすべてのフェーズを担当当事者意識が生まれる運用の痛みが設計にフィードバックされ、品質が上がる引き継ぎコストの削減チーム間の受け渡しが減り、リードタイムが短縮運用の属人化を防ぐ特定個人ではなくチームで知見を持ち、持続可能に SRE は伴走役へ基盤・ガードレールを整え、開発チームを支える SREの方々には「SRE の民主化」という言い方が馴染みがあるかもしれませんが、 SRE以外のメンバーにとって「フルサイクル開発体制」のほうが直感的に理解しやすい・プロダクトの全体を通してチームで責任を持つというコンセプトに魅力を感じたため、こちらの言い回しを初期から使っています. © dely, Inc. All Rights Reserved. 05

Slide 6

Slide 6 text

運用体制の変遷 ── 4つの時期サービスローンチから約4年. サービスとチームの拡大に合わせて、運用体制は4つの時期を経て変化. 一人運用期一人で運用を担う PRE SRE プラクティス導入期運用の民主化を試みるフェーズ ① 形骸化期拡大によりプラクティスが形骸化フェーズ ② 組織としての仕組み化期仕組みで運用を組織に定着フェーズ ③ © dely, Inc. All Rights Reserved. 06

Slide 7

Slide 7 text

運用体制の変遷 ── 4つの時期サービスローンチから約4年. サービスとチームの拡大に合わせて、運用体制は4つの時期を経て変化. サービスの拡大・複雑化サービスリリース（4年前）自社 ID 基盤統合自社コイン基盤構築派生サービスリリース ×2 ゲーム事業チームの拡大 1 チーム 5 -10チーム一人運用期一人で運用を担う PRE SRE プラクティス導入期運用の民主化を試みるフェーズ ① 形骸化期拡大によりプラクティスが形骸化フェーズ ② 組織としての仕組み化期仕組みで運用を組織に定着フェーズ ③ © dely, Inc. All Rights Reserved. 07

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

なぜフルサイクル開発体制を目指したか Spotify の事例 ── 7.1.2 重要な学びこうした会社の草創期からは次のように重要な学びがありました。最初から運用エンジニアをチームの一員に加えたことが、エンジニアリング文化に影響を及ぼし、成長するにつれて大きなメリットとなることが明らかになりました。運用重視の考え方は、できるだけ早い段階からエンジニアリング文化に取り入れる必要があります。 ── 『SREの探求』よりこの存在は憧れる！属人化やSRE不足の課題解消小さいチームのうちに運用文化を浸透させたいフルサイクル開発体制で開発チームに早くから運用文化を浸透させ、強固な体制にしていきたい © dely, Inc. All Rights Reserved. 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

フェーズ 1 整えたもの運用の民主化を目指してまずは SRE プラクティスを整え、開発者への浸透を試みた. 運用のアラート化 DB コネクション上限・キャパシティ・AWS Health などの通知障害対応・運用作業のRunbook の作成 SLI / SLO の策定、 SLI / SLO のIaCテンプレート化開発者を含むオンコールローテーション／障害対応フローの明文化ポストモーテムの実施 SLI / SLO についての記事 — aws.amazon.com/jp/builders-flash/202601/slo-separation-complecated-service / tech.dely.jp/entry/2024/03/22/164357 © dely, Inc. All Rights Reserved. 14

Slide 15

Slide 15 text

フェーズ 1 徐々に開発者が運用に関わる体制に変化当時の役割イメージ項目 SRE の役割開発者の役割 SLI / SLO 指標設計・目標設定 SLO 達成に向けた改善実施ポストモーテムファシリテート・改善推進原因分析・改善実施モニタリングダッシュボード・アラート整備一部監視結果の確認・活用障害対応メイン担当トリアージ・調査 EOL 対応・システムメンテ計画策定・推進実施・動作確認運用改善・トイル削減推進・リード実施運用メンバーを中心として、開発者も徐々に運用に関わるように © dely, Inc. All Rights Reserved. 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

フェーズ 2 当時の課題 SLI / SLO の改善やポストモーテムはなんとなく続けているものの—— 改善が後回しになり、改善に向けた議論も少ない運用責任が一部メンバーやSREチームに集中機能開発重視で運用面は後から考慮サービス拡大でSREがキャッチアップできていないドメイン固有の障害が増加複数サービスが依存した責任者不在の基盤システム © dely, Inc. All Rights Reserved. 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

解決の方針組織として運用が自然と回る状況をどのようにつくるのか実行の土台: 基準や指針があり、実行責任と権限があり、そのアクションが評価されること文化: 実行を繰り返し、フィードバックを体感し、あたりまえになっていくこと責任・権限誰が決め、動かすか評価結果をどう測るか基準の明文化目指す状態を言葉にする接点・フィードバックサイクル全体をつなぎ、回し続ける実行に必要な仕組みを整え、最終的には開発プロセスにシステムの信頼性が組み込まれる文化を目指す. © dely, Inc. All Rights Reserved. 28

Slide 29

Slide 29 text

フェーズ 3 組織に運用を定着させる、具体的な仕組みの実践各要素で下記のような仕組みを半年ほどかけて策定・段階的に導入責任・権限 1 組織との運用責任・作業割合の合意形成 2 運用責任チーム導入 3 インフラ権限設計評価 4 システム運用評価制度基準の明文化 5 運用できている状態の明文化接点・フィードバックサイクル 6 運用オンボーディング 7 モニタリング・運用定例の実施 8 Enabling SRE によるサポート © dely, Inc. All Rights Reserved. 29

Slide 30

Slide 30 text

フェーズ 3 組織に運用を定着させる、具体的な仕組みの実践それぞれの項目で中心的な取り組みを紹介します責任・権限 1 組織との運用責任・作業割合の合意形成 2 運用責任チーム導入 3 インフラ権限設計評価 4 システム運用評価制度基準の明文化 5 運用できている状態の明文化接点・フィードバックサイクル 6 運用オンボーディング 7 モニタリング・運用定例の実施 8 Enabling SRE によるサポート © dely, Inc. All Rights Reserved. 30

Slide 31

Slide 31 text

Slide 32

Slide 32 text

仕組み 1 組織との責任・作業割合の合意形成合意をとる、というとシンプルだが、 20%とる、みたいな話は開発速度を犠牲にする (特に短期は) ようにうつるため、丁寧な進め方が必要だった組織と合意形成をとったときのアクション 1. 現場の違和感を組織課題として言語化する 2. 同じ課題感を持つ人と協働する 3. 組織と課題・解決策の合意形成 → 現場で危機意識を高めることで、 CTO が中長期的に安定運用する投資と判断約3ヶ月 4. ビジョンと戦略の策定約1か月 5. 継続的なビジョンの発信 1on1 朝会 All Hands ※ 当時知識として持っていたわけではないですが、あらためて当時の流れを整理すると、「ジョン・コッターの変革の8段階」にとても近いなーと感じました. 参考: https://note.com/genda_jp/n/n19941436f36b © dely, Inc. All Rights Reserved. 32

Slide 33

Slide 33 text

仕組み 1 組織との責任・作業割合の合意形成 2 同じ課題感を持つ人と協働するこの中でも特に大事なステップ課題を持つ人: 一人 <<<< 二人. 一人でやるより格段に課題感が伝わりやすい今回のケースでは、属人化を防ぐためにSRE ロールとしてのポジションを一度インフラ経験のあるバックエンドメンバーに交代していたことで、課題意識の冗長化ができていたことが成功の鍵でした. 現在自分だけで課題を抱えている・合意できるかわからない場合、もう一人仲間を作ることや役割をローテーションしてとにかく冗長化するところから始めることがオススメです. © dely, Inc. All Rights Reserved. 33

Slide 34

Slide 34 text

仕組み 1 組織との責任・作業割合の合意形成 3 組織と課題・解決策の合意形成まずはCTO / EMに危機感と解決策を提示 => 上位レイヤーのメンバーにはCTOがFAQ を実施することで合意フルサイクル開発体制移行時によくでそうな質問「今でも動いてるよね？」 → 「動いている」のではなく、「個人の頑張りで支えられている」「開発で忙しい」 → 「新規採用決定のタイミングなどと合わせて段階的に移行する」「評価されない」 → 「評価制度も合わせて変える」「なぜ分業ではない？」 → 「運用を設計に組み込みながらスピード感を持って開発を進めるため」 © dely, Inc. All Rights Reserved. 34

Slide 35

Slide 35 text

仕組み 1 組織との責任・作業割合の合意形成 5 継続的なビジョンの発信一度の合意で終わらせず、複数のチャネルで繰り返し発信し、方針を組織に定着させる必要がある. 合意はただのスタートラインで、浸透はまた別のフェーズ 1on1 個々のメンバーと目線を合わせ、疑問や不安を丁寧に解消する朝会日々の場で方針や進捗に繰り返し触れ、チームの共通認識にする All Hands 組織全体へ向けて意義と成果を発信し、取り組みへの理解を広げる © dely, Inc. All Rights Reserved. 35

Slide 36

Slide 36 text

Slide 37

Slide 37 text

仕組み 2 運用評価制度 ── Tier 定義 Tier 1 〜 4 で役割・権限・期待を言語化し、半期評価 Tier 化するメリット本番環境の実行権限と紐づけることができる SREサポートの厚みをメンバー構成を見るだけで調整しやすい弊社ではTier3 以上は実質 Embedded SRE のような立ち位置 1 運用サポート (Tier1) 本番変更権限：なし役割基礎知識を理解し、運用に協力する障害時速やかに認識し、関係者へ共有・エスカレーション 3 運用自走 (Tier3) 本番変更権限：あり役割課題発見・解決策を策定し、改善を自走して実行する障害時正確な原因調査と、迅速な復旧対応 4 運用管理 (Tier4) 本番変更権限：あり役割運用状況を把握し、改善計画を策定・推進する障害時リーダーシップを発揮し、意思決定と復旧を主導協力自走・管理 ※ 実際の定義を簡略化したもの 2 運用実践 (Tier2) 本番変更権限：あり（Runbook実行限定）役割サポートを受けながら課題を解決する障害時ログ・メトリクス調査、影響範囲確認など初動対応 © dely, Inc. All Rights Reserved. 37

Slide 38

Slide 38 text

仕組み 2 運用評価制度 ── 評価体制運用の評価を、現場任せにせず第三者の視点を入れて公平にまとめる体制を構築し、評価の安定性を担保 1 各運用チームに、担当の Enabling SRE がつく ↓ 2 Enabling SRE が、メンバーの運用評価をセカンドオピニオンという立ち位置でまとめる ↓ 最終判断 EM ＋バックエンドチームリーダー © dely, Inc. All Rights Reserved. 38

Slide 39

Slide 39 text

仕組み 4 PRC の策定今日から「システム運用をやってください！」は難しい——基準を設け、システム品質の属人化を解消と理解促進下記項目ごとに基準を明確化バックアップとリストア定期的なバックアップの取得とリストア手順の整備キャパシティ管理リソース使用状況の把握とスケーリング戦略の明確化監視とアラートシステム全体に対する監視・アラートの整備や管理障害対策・インシデント対応 RunBook の整備、振り返りと再発防止策の運用セキュリティ最小権限設計・脆弱性管理・秘密情報の適切な取り扱い, EOL対応顧客への信頼性の担保 SLI / SLO の策定・依存関係, 影響範囲の明確化リリース CI / CD の構築や開発環境・ロールバック手順の策定作成にあたり、 Atlassian の operational readiness という指標を参考にしながら自分たちのケースを補足 atlassian.com/devops/what-is-devops/operational-readiness 基準を設けある程度均一に、サービスを安全に運用できる状態を目指す. © dely, Inc. All Rights Reserved. 39

Slide 40

Slide 40 text

Slide 41

Slide 41 text

仕組み 4 PRC の浸透 PRCは作って終わりではなく、開発フローに組み込む必要があるが、、弊社はスピード感のある組織そこにPRCの理解度が薄いまま開発フローに入れると… というリスク ⇒ 既存サービスの課題洗い出しに活用して、まずは理解度を高める当時とったアンケート一方で負荷が高かったという意見もあったので、フローを改善中負荷が急に上がる納得感が薄まり、開発者がトレードオフを判断できず板挟みになる設計 → 開発 → デプロイ → → 運用・監視 PRC 改善フルサイクル開発体制: 同じチームがすべてのフェーズを担当 © dely, Inc. All Rights Reserved. 41

Slide 42

Slide 42 text

Slide 43

Slide 43 text

仕組み 6 モニタリング・運用定例の実施やってよかったこと基本デメリットは思いつかず、フルサイクル開発体制をやる・やらないにかかわらず、モニタリング定例は必須開発 ⇄ 運用のフィードバックサイクルができ、改善が進んだ SRE との協働の場ができた意図しない攻撃や不当なリクエストなど、アラートに出ないコスト・セキュリティの不具合に気づけた特定の絵文字を付けると自動的に fullcycle-outcome チャンネルに飛ぶようにして、成果を貯めていっています © dely, Inc. All Rights Reserved. 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

感覚値体感としていろいろな改善が見られてきたダッシュボードにドメイン固有の必要な指標が組み込まれていく着手できていなかったコスト削減に着手できる SREが見えていないドメイン固有の知見が必要な領域にアプローチ可能に例) 無駄なリクエスト減により、 ECSの台数が半分にメトリクス異常の因果関係の結びつけが速い設計段階でWAFやアラートなどの運用が考慮される開発・運用が同じ方向を向いて会話できるようになった例) 開発者がSREの席に来てオートスケールについて熱く議論していたり、 PRC について議論したり ◎ チーム全体で運用に対する理解度や実行力が上がり、徐々に自走できる体制に © dely, Inc. All Rights Reserved. 45

Slide 46

Slide 46 text

具体の成果「開発チームで運用が回る」を実現する、多くの項目が改善された領域形骸化期仕組みを導入して1年半（開発者が担当）パフォーマンス改善改善が後回しになりがち 1年弱でパフォーマンス改善 20件以上実施, 先月ワーニングチャンネルのレスポンス率が95% (AI調べ) コスト効率化 SREが優先順位をつけて対応開発者によるインフラコスト削減額年間 1500万円以上キャパシティプランニング SREが検知・対応 - スパイク時のスケールアウトの自律的な調整・改善 - 自律的なTV負荷対策 SLI / SLO 策定 SREが作成サービスの SLO / SLI を定義・実装・改善が実行されるダッシュボード構築 SREが作成自律的に重要指標をダッシュボード化、インシデント調査の起点として常用障害対応 SREがオンコールメイン担当開発者のみでオンコールが回るチームがでてきた © dely, Inc. All Rights Reserved. 46

Slide 47

Slide 47 text

具体の成果 SREチームはEmbeddedの割合が減少し、 Enablingやセキュリティのガードレール整備やチーム共通の生産性課題の解消に時間を使えるように 3つのモード Embedded チームに入り込み、共に運用する Enabling チームが自走できるよう支援する Platform / Security ガードレール設計などの基盤づくり BEFORE Embedded 60% Enabling 40% AFTER Embedded 10% Enabling 20% Platform / Security 70% Embedded の比重が下がり、 Enabling・Platform・Securityへシフト © dely, Inc. All Rights Reserved. 47

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

今後の展望: 運用固定から開発と運用のバランスをとる 1 指標の強化開発と運用のバランスをとるための指標の強化 2 個人の運用解像度・合意形成力開発者一人ひとりが事業・運用を理解し、チームで適切に判断・合意形成する 3 戦時モード・平時モードの可視化最優先事業なのか、運用改善に時間を割ける時期なのかを可視化する ※ 「戦時／平時モード」という言葉は『ソフトウェアエンジニアガイドブック』第5章「多様な環境で成功を収める」を参照しました — oreilly.co.jp/books/9784814401215 指標だけですべてを補うのは難しい. 最終的には、次の3つの柱でバランスを支える © dely, Inc. All Rights Reserved. 54

Slide 55

Slide 55 text

今後の展望: 運用考慮のシフトレフト運用・改善で得た知見を、より前段の設計・開発フェーズへ前倒しし、開発プロセスの一部にするただし、開発スタイルに合わないプロセス化は危険設計 → 開発 → デプロイ → → 運用・信頼性考慮のシフトレフト運用・監視 ✓ PRC 改善 ✓ フルサイクル開発体制: 同じチームがすべてのフェーズを担当シフトレフトにより、改善フェーズの負荷を削減することができ開発速度が早くなる © dely, Inc. All Rights Reserved. 55

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

バックエンドエンジニア採用強化中実際にフルサイクル開発体制で開発しているエンジニアのインタビュー記事もあるので、ぜひ参考にしてください！「クラシルリテールネットワーク」立ち上げから1年半 ─ 急成長の裏側と開発チームの現在地 note.com/kurashiru_jp/n/nab448faa67f5 AI時代に淘汰されないエンジニアに。「フルサイクル開発」と「新規立ち上げ」の両軸を担う note.com/kurashiru_jp/n/nf08a54264806 「レシチャレ」 1,000万DLを支えてきた開発のリアル ─ スケールの舞台裏とこれから note.com/kurashiru_jp/n/n94b206bf668d © dely, Inc. All Rights Reserved. 58