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

Transcript

1. 横断的なSRE推進と成熟度評価 SRE Promotion & Maturity Assessment Ryosuke Suto
2. 須藤 涼介/Ryosuke Suto •Service Reliability Group(SRG) - Manager •勤続16年 •CA麻雀部（A1）
3. 今日話すこと 組織改善 プロダクト SRE導入 横断的 SRE推進 • インフラ→SREs変化 • SREsとしての職務 • SREの定義 • SREのススメ方 • SRE成熟度評価 • 今後の展望
4. 1.プロダクトチームとSREs 2.インフラチーム→SREsになるまで 3.SREを組織としてどう捉えるか 4.横断的なSRE推進 5.今後の展望
5. 表記の注意 •SRE Site Reliability Engineering 職種ではなく一連の概念の総称 •SREs 概念ではなく職種 この記事内ではSRGのメンバーや組織を表す
6. プロダクトチームとSREs
7. メディア事業
8. 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名
9. インフラチーム→SREsになるまで
10. インフラチーム時代の関わり方 組織改善 プロダクト SRE導入 横断的 SRE推進
11. インフラチーム時代の関わり方 •メディア全プロダクトの運用を全員が兼務でカバー 認知負荷MAX 運用の差し込みで1日が終了 Joinしているアラート用チャンネルの多さに疲弊or麻痺 •各チームごとに独立した活動 チーム内のプロダクトで手いっぱい 技術的なシナジーが生み出しづらい
12. 担当制の廃止 •基礎的な運用はプロダクトチームにエスカレーション やらなくなったこと（基礎的な運用） ・スケーリングや既存アーキテクチャへの新規構築（専門性Low） ・オンコール やること（ニーズベース） ・アーキテクチャの初期設計やIaCのベース提供 ・運用プラクティスの改善 ・パフォーマンスチューニングや負荷対策 ・SRE導入
13. プロジェクト制の導入 •半年ごとにニーズをヒアリングしプロジェクト化 担当制だと不明瞭だったコミットメントが明確になる システム責任者にも運用面の課題を考えてもらうきっかけになる SREsを流動的に配置できる プロダクト側とのコミュニケーションが希薄にならない
14. プロジェクトライフサイクル プロジェクト 合意 定期的な 進捗報告 プロジェクト 開始 期末報告 プロダクトFB プロジェクト 完了 メンバーアサイン プロジェクト更新 6ヶ月
15. 職務の明確化とワーキンググループ •Embedded SREs 担当プロダクトの信頼性改善におけるリーダーシップの発揮 SRE導入 プロジェクトのミッション遂行 •SRE Center of Practice 横断的事業課題解決における技術的専門性の発揮 ベストプラクティスの開発（手法、ツール含む） ワーキンググループでの横断的課題発見、解決 現在はDBと運用監視のワーキンググループを運用中
16. SREを組織としてどう捉えるか
17. SREを組織としてどう捉えるか 組織改善 プロダクト SRE導入 横断的 SRE推進
18. SREという言葉の曖昧さ •組織内で統一された認識がない Ω「言葉だけは知ってます」 Ω「ソフトウェアエンジニアに運用チームの設計を…？」 Ω「SREsがなんかええ感じにやってくれるやつ」 •何から手を付けていいかわからない（プラクティスが多い） Ω「とりあえずAPIのレイテンシー全部測ればいいんだっけ？」 Ω「最近障害が多いから改善したい…が…？」
19. この組織の「SRE」定義する •SREとは信頼性を機能として扱うためのプラクティスや組織文化 •と信頼性を直接的/間接的に改善していくためのプラクティス •SREsはSREを推進するための役割でSREを実行する役割ではない •SREsはプロダクトチームにSREをインストールする
20. 自分たちの現在地を知る •目標を設定するにはまず現在地を知る必要がある •何から始めるべきか議論がしやすい •各階層の理想状態がわかればアクションが決めやすい
21. 実プロダクトでのSREの始め方 ①プロダクトチーム全体へのコンセプト説明 SREとは？信頼性とは？メリットは？どのように進めるか？ バックエンド→開発チーム→プロダクト全体で抽象度を上げる ②導入ステップの設計 コンセプト理解→プロダクト分析（課題抽出）→優先度設定 ③導入フェーズ 例：インシデントルールの整備、CUJの分析、SLO設定…
22. 横断的なSRE推進
23. 横断的なSRE推進への挑戦 組織改善 プロダクト SRE導入 横断的 SRE推進
24. 横断的なSRE推進への挑戦 •プロジェクト単体で進めていることを横断的に展開したい •物理的に全プロダクトへEmbeddedすることは難しい •全体を俯瞰しデータ化することで力点を見極めたい •プロダクト責任者と現状認識をすり合わせておきたい
25. SRE成熟度評価
26. •能力成熟度モデル統合をベースに作成 •信頼性の階層等を参考にSREに必要な項目をリスト化 •評価しやすくするために極力シンプルにする •Lv.3を定義するためにSREsは情報を集約する必要性が出てくる
27. Lv.3ガイドライン
28. 評価をしてみて •まざまざとウィークポイントが明らかになる •中長期的な計画が立てやすくなる •Lv.3の整備が急務 •評価の間隔は3ヶ月〜6ヶ月が良さそう
29. 今後の展望
30. 続・SRE推進 •Lv.3（ベストプラクティス）の作成/ブラッシュアップ •横断的な成熟度改善計画の実行 •改善目標の定量化 •向こう1年でLv.1がほぼない状態を目指す
31. クラウドネイティブ技術との付き合い方 •CNCFのプロジェクト数は42増えて120に（CNCF Annual Report 2021） •技術選定の自由度とベストプラクティス（標準化）のバランスを 取らないとカオス化が想定される •情報のキャッチアップ速度、精度 •SREsがリードしていける形にしたい
32. ありがとうございました