横断的なSRE推進と成熟度評価

by Ryosuke Suto

Slide 1

Slide 1 text

横断的なSRE推進と成熟度評価 SRE Promotion & Maturity Assessment Ryosuke Suto

Slide 2

Slide 2 text

須藤涼介/Ryosuke Suto •Service Reliability Group(SRG) - Manager •勤続16年 •CA麻雀部（A1）

Slide 3

Slide 3 text

今日話すこと組織改善プロダクト SRE導入横断的 SRE推進 ● インフラ→SREs変化 ● SREsとしての職務 ● SREの定義 ● SREのススメ方 ● SRE成熟度評価 ● 今後の展望

Slide 4

Slide 4 text

1.プロダクトチームとSREs 2.インフラチーム→SREsになるまで 3.SREを組織としてどう捉えるか 4.横断的なSRE推進 5.今後の展望

Slide 5

Slide 5 text

表記の注意 •SRE Site Reliability Engineering 職種ではなく一連の概念の総称 •SREs 概念ではなく職種この記事内ではSRGのメンバーや組織を表す

Slide 6

Slide 6 text

プロダクトチームとSREs

Slide 7

Slide 7 text

メディア事業

Slide 8

Slide 8 text

Ameba Product A Product B Product C AWA Pigg CL Hayabusa SREs ・DC移設・負荷対策・アラート改善・SLI/SLO設定・インシデント対応の改善・アラート改善・ベストプラクティスの開発と展開　・SRE 　・クラウドネイティブ　・DB、監視、その他… Embedded SRE Embedded SRE SRE Center of Practice Project Project ※一部の例であり、実際はこれと異なる部分もあります。 Project : 半期ごとに各開発チームと対話し更新するプロダクトチームとの関わり方 12名

Slide 9

Slide 9 text

インフラチーム→SREsになるまで

Slide 10

Slide 10 text

インフラチーム時代の関わり方組織改善プロダクト SRE導入横断的 SRE推進

Slide 11

Slide 11 text

インフラチーム時代の関わり方 •メディア全プロダクトの運用を全員が兼務でカバー認知負荷MAX 運用の差し込みで1日が終了 Joinしているアラート用チャンネルの多さに疲弊or麻痺 •各チームごとに独立した活動チーム内のプロダクトで手いっぱい技術的なシナジーが生み出しづらい

Slide 12

Slide 12 text

担当制の廃止 •基礎的な運用はプロダクトチームにエスカレーションやらなくなったこと（基礎的な運用）・スケーリングや既存アーキテクチャへの新規構築（専門性Low）・オンコールやること（ニーズベース）・アーキテクチャの初期設計やIaCのベース提供・運用プラクティスの改善・パフォーマンスチューニングや負荷対策・SRE導入

Slide 13

Slide 13 text

プロジェクト制の導入 •半年ごとにニーズをヒアリングしプロジェクト化担当制だと不明瞭だったコミットメントが明確になるシステム責任者にも運用面の課題を考えてもらうきっかけになる SREsを流動的に配置できるプロダクト側とのコミュニケーションが希薄にならない

Slide 14

Slide 14 text

プロジェクトライフサイクルプロジェクト合意定期的な進捗報告プロジェクト開始期末報告プロダクトFB プロジェクト完了メンバーアサインプロジェクト更新 6ヶ月

Slide 15

Slide 15 text

職務の明確化とワーキンググループ •Embedded SREs 担当プロダクトの信頼性改善におけるリーダーシップの発揮 SRE導入プロジェクトのミッション遂行 •SRE Center of Practice 横断的事業課題解決における技術的専門性の発揮ベストプラクティスの開発（手法、ツール含む）ワーキンググループでの横断的課題発見、解決現在はDBと運用監視のワーキンググループを運用中

Slide 16

Slide 16 text

SREを組織としてどう捉えるか

Slide 17

Slide 17 text

SREを組織としてどう捉えるか組織改善プロダクト SRE導入横断的 SRE推進

Slide 18

Slide 18 text

SREという言葉の曖昧さ •組織内で統一された認識がない Ω「言葉だけは知ってます」 Ω「ソフトウェアエンジニアに運用チームの設計を…？」 Ω「SREsがなんかええ感じにやってくれるやつ」 •何から手を付けていいかわからない（プラクティスが多い） Ω「とりあえずAPIのレイテンシー全部測ればいいんだっけ？」 Ω「最近障害が多いから改善したい…が…？」

Slide 19

Slide 19 text

この組織の「SRE」定義する •SREとは信頼性を機能として扱うためのプラクティスや組織文化 •と信頼性を直接的/間接的に改善していくためのプラクティス •SREsはSREを推進するための役割でSREを実行する役割ではない •SREsはプロダクトチームにSREをインストールする

Slide 20

Slide 20 text

自分たちの現在地を知る •目標を設定するにはまず現在地を知る必要がある •何から始めるべきか議論がしやすい •各階層の理想状態がわかればアクションが決めやすい

Slide 21

Slide 21 text

実プロダクトでのSREの始め方 ①プロダクトチーム全体へのコンセプト説明 SREとは？信頼性とは？メリットは？どのように進めるか？バックエンド→開発チーム→プロダクト全体で抽象度を上げる ②導入ステップの設計コンセプト理解→プロダクト分析（課題抽出）→優先度設定 ③導入フェーズ例：インシデントルールの整備、CUJの分析、SLO設定…

Slide 22

Slide 22 text

横断的なSRE推進

Slide 23

Slide 23 text

横断的なSRE推進への挑戦組織改善プロダクト SRE導入横断的 SRE推進

Slide 24

Slide 24 text

横断的なSRE推進への挑戦 •プロジェクト単体で進めていることを横断的に展開したい •物理的に全プロダクトへEmbeddedすることは難しい •全体を俯瞰しデータ化することで力点を見極めたい •プロダクト責任者と現状認識をすり合わせておきたい

Slide 25

Slide 25 text

SRE成熟度評価

Slide 26

Slide 26 text

•能力成熟度モデル統合をベースに作成 •信頼性の階層等を参考にSREに必要な項目をリスト化 •評価しやすくするために極力シンプルにする •Lv.3を定義するためにSREsは情報を集約する必要性が出てくる

Slide 27

Slide 27 text

Lv.3ガイドライン

Slide 28

Slide 28 text

評価をしてみて •まざまざとウィークポイントが明らかになる •中長期的な計画が立てやすくなる •Lv.3の整備が急務 •評価の間隔は3ヶ月〜6ヶ月が良さそう

Slide 29

Slide 29 text

今後の展望

Slide 30

Slide 30 text

続・SRE推進 •Lv.3（ベストプラクティス）の作成/ブラッシュアップ •横断的な成熟度改善計画の実行 •改善目標の定量化 •向こう1年でLv.1がほぼない状態を目指す

Slide 31

Slide 31 text

クラウドネイティブ技術との付き合い方 •CNCFのプロジェクト数は42増えて120に（CNCF Annual Report 2021） •技術選定の自由度とベストプラクティス（標準化）のバランスを取らないとカオス化が想定される •情報のキャッチアップ速度、精度 •SREsがリードしていける形にしたい

Slide 32

Slide 32 text

ありがとうございました