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.4k
カンファレンスのボランティアスタッフって何やるの? / DAIMYO Meetup #4
cohalz
0
92
小さなものでも Step Functions / Serverless Meetup Fukuoka Re:boot
cohalz
0
130
ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu
cohalz
8
5.9k
ecspressoへの貢献を振り返る / JAWS-UG コンテナ支部 #24 ecspresso MeetUp
cohalz
1
5.8k
はてなフォトライフをECSに移行した話 / Hatena Engineer Seminar #20
cohalz
1
18k
SREの異動と働き方 〜はてなブログ編〜 / Hatena Engineer Seminar #13
cohalz
0
2.2k
Envoy.なんか / Kyoto.なんか #5
cohalz
0
150
CDKを用いたモダンなECSクラスタの構築と運用 / AWS Cloud Development Kit -CDK- Meetup
cohalz
6
3.2k
Other Decks in Technology
See All in Technology
HashHub会社案内「なぜ今、パブリックブロックチェーンに賭けるのか」
hashhub
3
75k
これはPerl? それともRuby? クイズ〜〜〜〜〜!!!- Perl or Ruby Quiz
moznion
2
1.4k
Pythonを活用したLLMによる構造的データ生成の手法と実践
brainpadpr
3
270
ドメインと向き合う - 旅行予約編
hidenorigoto
4
540
【shownet.conf_】ローカル5Gを活用したウォーキングツアーの体感向上
shownet
PRO
0
310
Oracle Database 23ai 新機能#4 Real Application Clusters
oracle4engineer
PRO
0
130
【shownet.conf_】ネットワークテストの最適化と利便性の追求
shownet
PRO
0
300
KDD2024参加報告
cyberagentdevelopers
PRO
1
240
【インフラエンジニアbooks】30分でわかる「AWS継続的セキュリティ実践ガイド」
hssh2_bin
4
1.5k
Causal Impactを用いたLINE Pay UIの効果検証とABテスト実施への貢献
lycorptech_jp
PRO
3
530
山手線一周のパフォーマンス改善
suzukahr
0
120
MLOpsの「あるある」課題の解決と、そのためのライブラリgokart
mski_iksm
1
160
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Robots, Beer and Maslow
schacon
PRO
157
8.2k
Writing Fast Ruby
sferik
625
60k
Debugging Ruby Performance
tmm1
73
12k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
48k
Become a Pro
speakerdeck
PRO
24
4.9k
How GitHub (no longer) Works
holman
311
140k
Music & Morning Musume
bryan
46
6.1k
BBQ
matthewcrist
84
9.2k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
6
260
GraphQLとの向き合い方2022年版
quramy
43
13k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
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は周りの協力が大事 ◦ 周りから声をかけてあげても良いかも
• みんなで協力して健全な開発生活を!