Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SREのキャリア、 あるいは生態 / #ya8
Search
cohalz
March 15, 2024
Technology
11
1.5k
SREのキャリア、 あるいは生態 / #ya8
https://hachiojipm.connpass.com/event/304403/
の発表資料です
cohalz
March 15, 2024
Tweet
Share
More Decks by cohalz
See All by cohalz
はてなのSRE組織2024 / Road to SRE NEXT@福岡
cohalz
2
1.3k
カンファレンスのボランティアスタッフって何やるの? / DAIMYO Meetup #4
cohalz
0
82
小さなものでも Step Functions / Serverless Meetup Fukuoka Re:boot
cohalz
0
120
ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu
cohalz
8
5.7k
ecspressoへの貢献を振り返る / JAWS-UG コンテナ支部 #24 ecspresso MeetUp
cohalz
1
5.7k
はてなフォトライフをECSに移行した話 / Hatena Engineer Seminar #20
cohalz
1
18k
SREの異動と働き方 〜はてなブログ編〜 / Hatena Engineer Seminar #13
cohalz
0
2.2k
Envoy.なんか / Kyoto.なんか #5
cohalz
0
140
CDKを用いたモダンなECSクラスタの構築と運用 / AWS Cloud Development Kit -CDK- Meetup
cohalz
6
3.1k
Other Decks in Technology
See All in Technology
Eventual Detection Engineering
ken5scal
0
390
PlaywrightによるE2Eテスト入門 / Introduction to E2E Testing with Playwright
rhumie
3
910
Estrategias de escalabilidade para projetos web
jessilyneh
1
150
開発者体験を意識した開発チームの生産性向上の取り組み
ham0215
3
650
データウェアハウス製品のSnowflakeでPythonが動くって知ってました?
foursue
1
150
エンジニアリングマネージャーが紐解く、事業視点から組織文化まで、包括的アプローチの探求 / READYFOR
9ma3r
13
2.2k
20240828_EM_Fest
kzkmaeda
4
360
ことばをそろえる / Bridging the Terminology Gap
amaotone
5
1k
Binary Authorizationと友達になろう / Let's be friends with Binary Authorization
iselegant
2
130
contenteditableと向き合う
kikuchikakeru
2
140
実践的なバグバウンティ入門
scgajge12
4
2.1k
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
160
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
65
9.7k
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
Building Better People: How to give real-time feedback that sticks.
wjessup
359
18k
The World Runs on Bad Software
bkeepers
PRO
64
11k
Agile that works and the tools we love
rasmusluckow
327
20k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
25
1.3k
Typedesign – Prime Four
hannesfritz
38
2.3k
KATA
mclloyd
27
13k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
StorybookのUI Testing Handbookを読んだ
zakiyama
25
5k
4 Signs Your Business is Dying
shpigford
179
21k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
363
22k
Transcript
SREのキャリア、 あるいは生態 id:cohalz / @cohalz Ya8 2024 - ヤパチー 令和六年最新版(仮)
1
伝えたいこと • 技術の話はほとんどしません! • SREは役割ではなく文化 ◦ その文化を支えるためのいろんな人がいる • SREとしてやっていくには ◦
どうやったら成長するのか ◦ 何を考えているのか 2
免責事項 • 簡単のためにSRE職のことをSREと呼びます ◦ 文化の方のSREはSREingと呼びます • チームや会社によって変わります ◦ 特に事業規模・フェーズによって変わるものです ◦
こうでないSREを批判する意図はありません • 真似して起きた損失の責任を負いません ◦ 逆に良くなった場合は教えてください! 3
なんでこんな話をここで? • SREの活動って見えにくい • 社外でも非SREに向けた話があまりない ◦ SREのカンファレンスはSREに興味がある人が来る • いろんな人がいる場で知って欲しい ◦
SREに携わる人・概念を正しく知ってほしい 4
5 誤解ってたとえば どういうのがあるか?
6 一旦ChatGPTに 聞いてみた
SREに関する5つの誤解(by ChatGPT) • SREは単なる運用担当者で、開発には関与していない。 • SREは主に運用作業であり、プログラミングや開発のスキルは必要ない。 • SREはあらゆる障害を事前に予測し、防ぐことができる。 • SREは全ての問題に対して即座に対応でき、サービスをいつも正常に維持できる。
• SREは新しいツールやテクノロジーを導入するだけの存在。 7
8 結構ちゃんとしてた
9 なのでこれとは違う 観点で話します
ここで自己紹介 • こはる(@cohalz) • 株式会社はてな • SRE6年目 ◦ はてなブックマーク ◦
はてなブログ 10
色々やってます https://developer.hatenastaff.com/archive/author/cohalz 11
12 最近はこう思われていそう • 昔からインフラ・クラウドの達人? → No ◦ 最初から成果を出していた? → No
• 自宅でサーバを飼ってそう → No ◦ これは実際に言われたこともある • 人の目を気にするタイプではないが... ◦ 実は誤解が仕事の妨げになることもある
13 SREのキャリア
キャリア紹介 • 2017年はてなインターン参加 ◦ Mackerelチームで主にバックエンドの実装をしていた • その後アルバイトに入社 ◦ チームの事情でMackerelではなくインフラチームの部署に 14
アルバイト応募当時 • 実はミドルウェアもクラウドもほぼ未経験 • SREingと言う概念も当然知らなかった • 新しいことをやる機会と思って承諾 ◦ これが転機 15
珍しいキャリア? • メンターの人も似たキャリアだった ◦ 会社の座談会でも同様の人がいた • SREingのムーブメントが始まったタイミング ◦ 開発スキルも大事になってきた 16
そして入社へ... • 入社時に職種を選べたがそのままSREとして入社 • そして現在は全社のSREing活動を牽引する立場 • めでたしめでたし...? 17
18 SREの成長
成長の定義 • 色々な成長があるわけだけど • ここでは会社に対しての貢献度が増える意味で ◦ つまりは給料が増えるには何をすればいいか 19
入社時を思い出す • 当然最初は大変だった • わからないことだらけなのは当たり前だが • 全然成果を出せなかった ◦ 他の人よりも成長が遅かった 20
SREに求められるスキル? • 色々な技術を使えるようになれば一人前? • 技術以外のスキルも必要なことがわかってきた ◦ プロダクトやチームワーク ◦ 自分と目の前の技術しか見えていなかった 21
成長のきっかけ • はてなブログのチームに異動することに ◦ 入社2年目になるタイミング • 一人目のSREとして配属 ◦ ここでどんどん成長していった 22
一人目SREになって変わったこと • 周りに詳しい人がいなくなった ◦ 他職種の人とも仕事するようになった • プロダクト自体に責任を持つ立場に ◦ 意思決定を求められる立場になった 23
周りに詳しい人がいなくなった • 改善を期待されて異動しているが... ◦ でもプロダクトのことは一番知らない • メンバーには軽い説明だけでは伝わらない ◦ ましてやプロダクトオーナーはもっと伝わらない •
一人でも無理なく運用を回せる体制を目指す 24
チームで運用を回せるように • 自動化 ◦ 人に依存しない仕組み • チームメンバーの認識・スキルを向上させる ◦ SREとは何かを説明して回る ◦
一緒に仕事をする 25
早く一人前にならないといけない • 一人目SREはテックリードのようなもの • プロダクトオーナーなどに説明する責任がある 26
プロダクトが抱える課題に触れる • システムを良くさせたい • 障害やアラートもどんどん出てくる • でもプロダクトを成長させないといけない 27
色々やった • 過去ログを見る • 周りの振る舞いを真似する • 首をつっこむ • 評価制度と向き合う 28
過去ログを見る • Slackなどの過去ログを見ていく ◦ アラートや障害対応 ◦ 未解決のアクションが見つかることも • わからないものものは全部調べる •
技術だけでなく人の動きも見る 29
過去からコミュニケーションを学ぶ • はてなブログという歴史のあるプロダクト • 歴史を繋げていくための工夫を知る ◦ こういえば伝わる、伝わらないがわかってくる ◦ 伝える相手は未来の自分やチームメイトも含む 30
周りの振る舞いを真似する • この人はなぜこう言ったのかをよく考える • 受け売りにしないのに注意 ◦ 「この人がこう言ったから...」にしない ◦ 自分の言葉で発信し直す •
その際他人と比べないのも大事 ◦ ライバル - hitode909の日記 31
首を突っ込む • 最初に全社基盤のチームにいた名残 • 各チームの様子を見る • 自分だったらどうする?を考える 32
周りの協力もあった • 異動前後のチームメンバーで作戦会議 ◦ 「どうやったら短期間で最強のSREになるか」 • 挑戦を応援する文化 33
開発合宿の参加 • 他人と密にやり取りしな がら高速に成果を出す体 験 • 技術的な深掘り、チーム ワーク、チーム外への説 明など色々学ぶことが あった
34 https://developer.hatenastaff.com/entry/2020/09/18/093000
これ以降活躍できるようになった • 仕事の進め方がわかった ◦ SREingをやっていく上では仕事のうまさは特に重要 • うまくいく/いかない姿をイメージできるように 35
それまでの経験も無駄にはなってない • コードの読み書き能力 • 全社基盤の仕組み • 他チームとのコミュニケーション 36
難しさに立ち向かう • 難しさ・責任感によって成長したのだろう • 崖から突き落とすモデルではあるが... ◦ やっていくしかない 37
立場が人を作る? • 意思決定の立場になると実際変わってくる • メンバーの退職や異動きっかけで成長もある • 期待に精一杯応える ◦ 計画的偶発性理論 38
(ちなみに)メンバーを成長させたいが... • でもどうやったらいいか難しい ◦ 同じことをチームメンバーにもやらせられる? • 時間を与える? • 立場を与える? •
最近はこの辺を考えています 39
40 SREの楽しみ
大変そう? • やることも考えることも多い • その分楽しみもある ◦ 様々な改善をしていく楽しみ ◦ 障害対応の楽しみ •
モチベーションの維持どうやる? 41
システムだけではない改善 • 不健全な信頼性や開発速度を改善していく ◦ たとえば人に依存した仕組みをなくす • ユーザも開発メンバーも納得のできる体制に ◦ 不幸になる人を減らす仕組みだと自分は思っている 42
信頼性を「上げる」のが仕事? • 多くのプロダクトはそうかもしれない ◦ 運用の手が足りてないケース • 実は意図的に信頼性を下げることもある ◦ 開発速度を優先する ◦
ユーザからの期待値コントロール 43
障害対応の楽しみ • 障害対応は好きですか? ◦ SREは好きな人が多いであろう • 理由なく障害は発生しない • その理由を探っていかに早く解決できるか ◦
システムと自分たちとの知恵比べ 44
(ちなみに)経験した障害いろいろ • キャッシュしたら逆にパフォーマンスが悪化 • フェイルオーバーが絶対失敗するKeepalived • 構成変更したら別サービスも巻き込んで全部ダウン • 切り替えメンテで本番だけ繋がらないデータストア 45
コードを書く楽しみ • みんなコード書きたいし書いている • コードを書くことがよりメリットになるように ◦ 技術の標準化 ◦ 社内OSS •
OSSを活用して改善していく ◦ トイルの削減! 46
fujiwara-wareにはお世話になっています! 47
モチベーション維持 • いろんなことやってて楽しい ◦ 総合格闘技 • 燃え尽き症候群(バーンアウト)を回避する ◦ 周りとの期待値コントロールを行う ◦
賞賛されたものをいつでも見返せるようにする 48
49 大切にしていること
自分の中で大切にしてること • やるべきことをよく考える • 広く浅くでもいい • 自分ごと化 • 脱ヒロイズム 50
今やるべきことをよく考える • 信頼性と開発速度のバランスを取る • 手段と目的を間違えない ◦ クラウドでやミドルウェアは手段 • 相手の立場になって考える 51
広く浅くでもいい • 様々な課題を解決できるだけでも貢献 • 深くやらなきゃで動きが止まるのも良くない • とはいえ、いざという時は深く潜れるように 52
自分ごと化 • SREingはセルフサービス化が大事 ◦ 開発者でも主体的に運用を行えるように ◦ 開発メンバーとの壁を作らない • 「専門家はいない。私たちしかいないんだ。」 ◦
エラスティックリーダーシップの最初の文 53
成長した後は...? • 成長すると仕事を任せられるようになる • それをガンガンやっていくことでも問題が起こる ◦ ヒロイズム 54
ヒロイズム • 英雄主義 • SREingの文脈では主に障害対応などが特定の 人に偏ることを指す 55
ヒロイズムなチームの問題点 • 他の人の成長機会を奪う • 感度の低下 ◦ 「あの人が見てくれるから安心」 • 結果その人ありきな運用になってしまう ◦
単一障害点 ◦ バーンアウトの危機 56
ヒロイズム脱却の難しさ • 悪いことだけでもない ◦ 対応した人は成長し、賞賛される ◦ 周りの人もすぐ障害が復旧して嬉しい • 本人の意識だけでは脱却が難しい ◦
認識が揃ってないとただ障害が長引くだけに 57
スケールするか?を考える • 今の倍の数障害が起こったら? • 今対応してるメンバーがいなくても大丈夫? • 全員で認識を合わせていく 58
細かいマイルール • 社内で自分のことをSREと呼ばない ◦ コミュニケーションで職種の壁を作ってしまわない ◦ SREはこういうもの、という固定概念を持たせない 59
60 どういう人に向いているか
インフラエンジニアの転換? • 前のめりに、プロダクトを見ていくことが求められる ◦ そうしたかった人には動きやすくなった • 「SREは、ソフトウェアエンジニアに運用チームの 設計を依頼した時にできあがるもの」 ◦ SRE本にあるGoogle
VPoEの言葉 ◦ 実はみんなも向いているのかも? 61
どういう人がSREに向いているか https://hatena.co.jp/recruit/career/sre 62
SREに求められる5つのソフトスキル https://www.catchpoint.com/asset/2018-sre-report 63
SREの概念に共感できる人 • 人間に依存したくない ◦ 手作業や意思決定をシステム化したい ◦ 定量的な判断をしたい • どうあるべきかは非常にわかりやすい ◦
今何をするべきか逆算できる 64
開発者に興味を持ってもらいたい • 自分が開発出身だったからこそ強く思う ◦ 自分以外にも意外とそういう人は多い • 開発と運用の分断を避ける 65
開発と運用の分断を避ける? • 分業で一見効率は良さそうに見えるが... • チーム外に依頼すると、 ◦ 意思決定に時間がかかる ◦ チーム間の目標のズレで衝突も •
実は自分のチームでできたら一番早い 66
お互いが歩みよる • 「You build it, you run it」 ◦ AmazonのCTOの言葉
• 自分の仕事を奪われたと感じる人はいない ◦ 教えてくださいと言われたら喜んで教えるだろう 67
「技術だけやりたいんだが...?」 • それもわかるしそういう人も当然いる ◦ 人数がいれば分担できる • 特定の技術を求めている会社もあるだろう • ソフトスキルがいらないというわけではない 68
色々なSREがある • オンプレ or クラウド • 新規事業 or 老舗 •
toC or toB • チーム構成 ◦ DevOpsトポロジーによる と17種のチーム構成がある 69 https://web.devopstopologies.com/
向かう方向 • 最終的にはSRE職やチームが無くなるのを目指すことも • プロダクト開発のメンバーがSREingを実施できるように ◦ その中で各メンバーが得意なことをやっていく ◦ 「越境」という単語がわざわざ出てこない世界に 70
リーダーシップ・フォロワーシップ • どちらも必要 • つまりはやっていき・のっていき 71
プロダクトに沿ったSREをやっていく • プロダクト・チームの相互理解が必要 • 強いSREを採用して即なんとかなるわけでもない ◦ ヒーローを求めてしまわない • 周りの協力が大事! 72
技術も当然必要 • なんだかんだ人手は足りてない! • 技術的には変化の遅い部分も多い ◦ 必要な技術は見えやすい ◦ ただしめちゃくちゃ分野は広い 73
74 最後に
75 おわり • SREは難しいけど楽しいこともいっぱい ◦ アルバイトのときに違う選択をしたら今どうなっていたか • SREingは周りの協力が大事 ◦ 周りから声をかけてあげても良いかも
• みんなで協力して健全な開発生活を!