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

Road to SRE NEXT@京都 の登壇資料
https://sre-lounge.connpass.com/event/339458/

株式会社はてなで、SREの立ち上げから5年以上が経過しました。その中で実践してきたことや経験をもとに、SREというキャリアや必要なスキルについて私の考えを発表します。SREをこれから目指したい人や、現在SREだが今後のキャリアについてどうしようか迷っている方の一助になればと思っています。

Transcript

1. これからSREになる人と、 これからもSREをやっていく人 へ Road to SRE NEXT@京都 2025/02/07 id:masayoshi
2. 自己紹介 • id:masayoshi • 株式会社はてな ◦ Platform SRE 株式会社はてなでSREとして勤務。 自身の可観測性を高めるために、健康診断に行ったところ、高血圧にひっかかり健康に怯えて生 活をしている。 しかし、エラーバジェットポリシーが設定されていなかったため、食生活の改善は見られない。
3. 今日話すこと • SREのキャリアプランについて ◦ 対象 ▪ これからSREを目指す人 ▪ すでにSREだがキャリアについて悩んでいる人 ◦ 内容 ▪ 会社やチームがSREをやるために必要なことではなく、 個人がどういう動きをするかについての話
4. SREイベントから見る傾 向
5. SRE Kaigi 2025 • イベントお疲れ様でした！ • キャリア、組織に関する登壇件数 ◦ 9/27件 ◦ キャリアに関係する話も多くあった ▪ CRE, DBRE, platform engineer, staff engineer
6. SREイベントの登壇傾向 • 以前から組織の話題は多かった • 最近はキャリアについての話題が多くなった • そもそも ◦ 組織の話題が多いのはなぜか ◦ SREに必要なスキルの話題が多いのはなぜか ◦ キャリアの話題が出てくるのはなぜか
7. SREとは?
8. • プロダクトの信頼性に関する課題を解決することを期待される • 課題の例 ◦ 機能開発を高速化して、頻繁にリリースしたい ◦ しかし、リリースによる変更で信頼性は低下する ◦ 機能開発と信頼性向上にトレードオフが発生してしまう • 解決策の例 ◦ SLIという指標とSLOという目標を定義し、 機能開発と信頼性のバランスを定量的に制御する 改めてSREの仕事とは
9. • プロダクトごとに違う要件がある ◦ 何秒以内にこのページを表示したいなど ◦ プロダクトにとって提供したいサービスの質はなにか ◦ プロダクトのことを知らなければ信頼性の定義ができない ▪ 要件のヒアリングが必要、ドメイン知識の理解も必要 プロダクトの信頼性とは
10. • プロダクトの信頼性に関わる要素
11. • アプリケーションやインフラ ◦ バグのないコードを書く技術 ◦ 高可用性を実現する技術 • 障害の検知と素早い障害対応 ◦ 監視、可観測性に関する技術 ◦ 障害対応、調査に関する技術 • インターネット、ユーザー環境 ◦ 自分たちのコントロール下にない環境に関する技術 プロダクトの信頼性に関わる要素
12. • プロダクトの要件を理解し、信頼性を定義できる能力 • 信頼性のあるアプリケーションを作成できる能力 • 信頼性のあるインフラシステムを構築できる能力 • プロダクトの信頼性を観測できるシステムを構築できる能力 • 素早い障害対応と再発防止策の実施ができる能力 1人で達成するには超人である必要がある SREに求められるスキル
13. • 1人では無理なので、協力してもらう必要がある ◦ 全体をカバーできるように違うスキルを持つメンバーが必要 ◦ プロダクトマネージャーや開発エンジニア、運用チームなど 場合によっては、現状では違うチームや職種の人に協力しても らう必要がある ◦ スキル範囲以外にも、障害対応、アプリケーション開発などは チームで動く必要があり、チーム全体の能力向上が必要 ▪ メンバーの育成、連携しやすいチーム構成 必要なスキルを複数人で担保
14. よくある状況と 求められる動き
15. 今からSREに取り組みたい • よくある状況 ◦ SREを始めたけど、結局インフラエンジニアの仕事っぽくなってしまう ◦ SLI/SLOを定義したけど、あまり使われない、有効に機能していない • 何故か ◦ 「インフラの構築、インフラの信頼性を確保する」ことだけが、チームの 目標や期待になってしまっている ◦ 自分のチーム内や知識だけで出来ることだけしか取り組まない(取り組 めない) という状況から脱出する必要がある
16. こういう形にしたい
17. 今からSREに取り組みたい • 最初のSREに求められる動き ◦ 「プロダクトの信頼性駆動の運用設計」を出来るようになる ▪ 一番重要なことは「プロダクトの信頼性」から考えられるようになること ◦ 現場の取り組みレベルから、マネージャーなど意思決定層に影響を与える ▪ SREの原理原則をステークホルダーに説明し、理解を得る ▪ マネージャーがSREに「インフラの構築と運用をしてもらおう」 としか考えてもらえない状況を打破する必要がある ▪ 意思決定層に影響を与えるには組織の変更が必要な場合が多い • 目標はチームごとに決めることが多いのでチーム構成が重要になって くる
18. • プロダクトの信頼性駆動の運用設計がやりやすいようにチーム構成を組み 替えることも必要 組織をリファクタリングする
19. SREの取り組みを社内に広めたい • よくある状況 ◦ 1つのプロダクトでは実現できているが、 他のプロダクトではSREがうまくできていない ◦ DBやk8sなど特定技術領域に詳しい人がチームにいない • 何故か ◦ SREの人数が少なくて、専門家を全チームにくばることができない ▪ 組織を変えられる力を持った人が少ない ▪ 専門的な技術を持った人が少ない
20. SREの取り組みを社内に広めたい • SREを展開するのに求められる動き ◦ 自分がその専門領域のスペシャリストになる ▪ 知らない領域を積極的にキャッチアップしていく ▪ 技術力で解決していくスタイル ◦ 組織構成を変更して技術領域をカバーしやすくする ▪ 共通している箇所をPlatformとして括りだしていく ▪ 組織力で解決飼育スタイル
21. • 組織の人数比率や専門領域を考えて、SREがスケールしやすいように構成する 組織をリファクタリングする
22. SREの難しいところ • 自分が得意な技術領域だけではなく、「プロダクトの信頼性」という 軸で考える、必要なことを考える必要がある ◦ 関わる専門領域が増える ▪ 必要な専門領域を個人で習得していく ▪ 必要な専門領域をチームでカバーできるようにしていく • 結果的に、SREの専門スキル、組織の話が増えてくる
23. • 組織に影響を与えることができる ◦ 他のチームを巻き込む、チーム構成を変える、メンバーの意識を変える • 自分の専門領域を持っている ◦ インフラ、アプリケーション、プロダクト開発、監視、組織 • 自分の専門領域外も積極的にキャッチアップできる ◦ 自分の領域だけでやっていい状況であることは少ない 私が考えるSREに求められるスキル
24. キャリアプラン
25. • 組織に大きな影響を与えられる • 幅広い技術領域をカバーできる • 特定技術の狭く深いスペシャリストにはなりにくい ◦ 自分の好きな技術をとことん極めたいぜ！って人は あんまりSREはおすすめじゃない ▪ 専用ポジションを用意してくれる企業にいくのが良い SREをやっていると
26. • プロダクト開発に関わるアプリケーションエンジニア ◦ エンジニアリングマネージャー ◦ プロダクトマネージャー • 同じように、プロダクトの信頼性に関わるSREも同じようなキャリ アを歩むことが出来る • 組織に影響を与える動きが出来るエンジニア ◦ スタッフエンジニアというポジションも狙いやすい キャリアの方向性(組織を動かす)
27. • 専門領域のカバー率を活かして何でもできる現場の人として生きる ◦ フルスタックエンジニア? • 組織に必要なことを把握し、幅広い技術領域を活かして社内をサ ポート ◦ Individual Contributor ◦ Platform Engineer キャリアの方向性(専門性を活かす)
28. さいごに
29. 最後に • これからSREになる人 ◦ 現在の自分の技術領域での解決策にとらわれず、 「プロダクトの信頼性」に関わる様々な技術に手を広げていこう！ • 現在SREだけどSREができていない気がする人へ ◦ 自分の仕事が「プロダクトの信頼性」と紐付けて出来ているか確認しよう ◦ ときには自分で組織を動かしたり、チームに足りないことを積極的にやってい こう