これからSREになる人と、これからもSREをやっていく人へ

Slide 1

Slide 1 text

これからSREになる人と、これからもSREをやっていく人へ Road to SRE NEXT@京都 2025/02/07 id:masayoshi

Slide 2

Slide 2 text

自己紹介 ● id:masayoshi ● 株式会社はてな ○ Platform SRE 株式会社はてなでSREとして勤務。自身の可観測性を高めるために、健康診断に行ったところ、高血圧にひっかかり健康に怯えて生活をしている。しかし、エラーバジェットポリシーが設定されていなかったため、食生活の改善は見られない。

Slide 3

Slide 3 text

今日話すこと ● SREのキャリアプランについて ○ 対象 ■ これからSREを目指す人 ■ すでにSREだがキャリアについて悩んでいる人 ○ 内容 ■ 会社やチームがSREをやるために必要なことではなく、個人がどういう動きをするかについての話

Slide 4

Slide 4 text

SREイベントから見る傾向

Slide 5

Slide 5 text

SRE Kaigi 2025 ● イベントお疲れ様でした！ ● キャリア、組織に関する登壇件数 ○ 9/27件 ○ キャリアに関係する話も多くあった ■ CRE, DBRE, platform engineer, staff engineer

Slide 6

Slide 6 text

SREイベントの登壇傾向 ● 以前から組織の話題は多かった ● 最近はキャリアについての話題が多くなった ● そもそも ○ 組織の話題が多いのはなぜか ○ SREに必要なスキルの話題が多いのはなぜか ○ キャリアの話題が出てくるのはなぜか

Slide 7

Slide 7 text

SREとは?

Slide 8

Slide 8 text

● プロダクトの信頼性に関する課題を解決することを期待される ● 課題の例 ○ 機能開発を高速化して、頻繁にリリースしたい ○ しかし、リリースによる変更で信頼性は低下する ○ 機能開発と信頼性向上にトレードオフが発生してしまう ● 解決策の例 ○ SLIという指標とSLOという目標を定義し、機能開発と信頼性のバランスを定量的に制御する改めてSREの仕事とは

Slide 9

Slide 9 text

● プロダクトごとに違う要件がある ○ 何秒以内にこのページを表示したいなど ○ プロダクトにとって提供したいサービスの質はなにか ○ プロダクトのことを知らなければ信頼性の定義ができない ■ 要件のヒアリングが必要、ドメイン知識の理解も必要プロダクトの信頼性とは

Slide 10

Slide 10 text

● プロダクトの信頼性に関わる要素

Slide 11

Slide 11 text

● アプリケーションやインフラ ○ バグのないコードを書く技術 ○ 高可用性を実現する技術 ● 障害の検知と素早い障害対応 ○ 監視、可観測性に関する技術 ○ 障害対応、調査に関する技術 ● インターネット、ユーザー環境 ○ 自分たちのコントロール下にない環境に関する技術プロダクトの信頼性に関わる要素

Slide 12

Slide 12 text

● プロダクトの要件を理解し、信頼性を定義できる能力 ● 信頼性のあるアプリケーションを作成できる能力 ● 信頼性のあるインフラシステムを構築できる能力 ● プロダクトの信頼性を観測できるシステムを構築できる能力 ● 素早い障害対応と再発防止策の実施ができる能力 1人で達成するには超人である必要がある SREに求められるスキル

Slide 13

Slide 13 text

● 1人では無理なので、協力してもらう必要がある ○ 全体をカバーできるように違うスキルを持つメンバーが必要 ○ プロダクトマネージャーや開発エンジニア、運用チームなど場合によっては、現状では違うチームや職種の人に協力してもらう必要がある ○ スキル範囲以外にも、障害対応、アプリケーション開発などはチームで動く必要があり、チーム全体の能力向上が必要 ■ メンバーの育成、連携しやすいチーム構成必要なスキルを複数人で担保

Slide 14

Slide 14 text

よくある状況と求められる動き

Slide 15

Slide 15 text

今からSREに取り組みたい ● よくある状況 ○ SREを始めたけど、結局インフラエンジニアの仕事っぽくなってしまう ○ SLI/SLOを定義したけど、あまり使われない、有効に機能していない ● 何故か ○ 「インフラの構築、インフラの信頼性を確保する」ことだけが、チームの目標や期待になってしまっている ○ 自分のチーム内や知識だけで出来ることだけしか取り組まない(取り組めない) という状況から脱出する必要がある

Slide 16

Slide 16 text

こういう形にしたい

Slide 17

Slide 17 text

今からSREに取り組みたい ● 最初のSREに求められる動き ○ 「プロダクトの信頼性駆動の運用設計」を出来るようになる ■ 一番重要なことは「プロダクトの信頼性」から考えられるようになること ○ 現場の取り組みレベルから、マネージャーなど意思決定層に影響を与える ■ SREの原理原則をステークホルダーに説明し、理解を得る ■ マネージャーがSREに「インフラの構築と運用をしてもらおう」としか考えてもらえない状況を打破する必要がある ■ 意思決定層に影響を与えるには組織の変更が必要な場合が多い ● 目標はチームごとに決めることが多いのでチーム構成が重要になってくる

Slide 18

Slide 18 text

● プロダクトの信頼性駆動の運用設計がやりやすいようにチーム構成を組み替えることも必要組織をリファクタリングする

Slide 19

Slide 19 text

SREの取り組みを社内に広めたい ● よくある状況 ○ 1つのプロダクトでは実現できているが、他のプロダクトではSREがうまくできていない ○ DBやk8sなど特定技術領域に詳しい人がチームにいない ● 何故か ○ SREの人数が少なくて、専門家を全チームにくばることができない ■ 組織を変えられる力を持った人が少ない ■ 専門的な技術を持った人が少ない

Slide 20

Slide 20 text

SREの取り組みを社内に広めたい ● SREを展開するのに求められる動き ○ 自分がその専門領域のスペシャリストになる ■ 知らない領域を積極的にキャッチアップしていく ■ 技術力で解決していくスタイル ○ 組織構成を変更して技術領域をカバーしやすくする ■ 共通している箇所をPlatformとして括りだしていく ■ 組織力で解決飼育スタイル

Slide 21

Slide 21 text

● 組織の人数比率や専門領域を考えて、SREがスケールしやすいように構成する組織をリファクタリングする

Slide 22

Slide 22 text

SREの難しいところ ● 自分が得意な技術領域だけではなく、「プロダクトの信頼性」という軸で考える、必要なことを考える必要がある ○ 関わる専門領域が増える ■ 必要な専門領域を個人で習得していく ■ 必要な専門領域をチームでカバーできるようにしていく ● 結果的に、SREの専門スキル、組織の話が増えてくる

Slide 23

Slide 23 text

● 組織に影響を与えることができる ○ 他のチームを巻き込む、チーム構成を変える、メンバーの意識を変える ● 自分の専門領域を持っている ○ インフラ、アプリケーション、プロダクト開発、監視、組織 ● 自分の専門領域外も積極的にキャッチアップできる ○ 自分の領域だけでやっていい状況であることは少ない私が考えるSREに求められるスキル

Slide 24

Slide 24 text

キャリアプラン

Slide 25

Slide 25 text

● 組織に大きな影響を与えられる ● 幅広い技術領域をカバーできる ● 特定技術の狭く深いスペシャリストにはなりにくい ○ 自分の好きな技術をとことん極めたいぜ！って人はあんまりSREはおすすめじゃない ■ 専用ポジションを用意してくれる企業にいくのが良い SREをやっていると

Slide 26

Slide 26 text

● プロダクト開発に関わるアプリケーションエンジニア ○ エンジニアリングマネージャー ○ プロダクトマネージャー ● 同じように、プロダクトの信頼性に関わるSREも同じようなキャリアを歩むことが出来る ● 組織に影響を与える動きが出来るエンジニア ○ スタッフエンジニアというポジションも狙いやすいキャリアの方向性(組織を動かす)

Slide 27

Slide 27 text

● 専門領域のカバー率を活かして何でもできる現場の人として生きる ○ フルスタックエンジニア? ● 組織に必要なことを把握し、幅広い技術領域を活かして社内をサポート ○ Individual Contributor ○ Platform Engineer キャリアの方向性(専門性を活かす)

Slide 28

Slide 28 text

さいごに

Slide 29

Slide 29 text

最後に ● これからSREになる人 ○ 現在の自分の技術領域での解決策にとらわれず、「プロダクトの信頼性」に関わる様々な技術に手を広げていこう！ ● 現在SREだけどSREができていない気がする人へ ○ 自分の仕事が「プロダクトの信頼性」と紐付けて出来ているか確認しよう ○ ときには自分で組織を動かしたり、チームに足りないことを積極的にやっていこう