Tweet
Tweet

Slide 1

Slide 1 text

SREのキャリア、 あるいは生態 id:cohalz / @cohalz Ya8 2024 - ヤパチー 令和六年最新版(仮) 1

Slide 2

Slide 2 text

伝えたいこと ● 技術の話はほとんどしません！ ● SREは役割ではなく文化 ○ その文化を支えるためのいろんな人がいる ● SREとしてやっていくには ○ どうやったら成長するのか ○ 何を考えているのか 2

Slide 3

Slide 3 text

免責事項 ● 簡単のためにSRE職のことをSREと呼びます ○ 文化の方のSREはSREingと呼びます ● チームや会社によって変わります ○ 特に事業規模・フェーズによって変わるものです ○ こうでないSREを批判する意図はありません ● 真似して起きた損失の責任を負いません ○ 逆に良くなった場合は教えてください！ 3

Slide 4

Slide 4 text

なんでこんな話をここで？ ● SREの活動って見えにくい ● 社外でも非SREに向けた話があまりない ○ SREのカンファレンスはSREに興味がある人が来る ● いろんな人がいる場で知って欲しい ○ SREに携わる人・概念を正しく知ってほしい 4

Slide 5

Slide 5 text

5 誤解ってたとえば どういうのがあるか？

Slide 6

Slide 6 text

6 一旦ChatGPTに 聞いてみた

Slide 7

Slide 7 text

SREに関する5つの誤解(by ChatGPT) ● SREは単なる運用担当者で、開発には関与していない。 ● SREは主に運用作業であり、プログラミングや開発のスキルは必要ない。 ● SREはあらゆる障害を事前に予測し、防ぐことができる。 ● SREは全ての問題に対して即座に対応でき、サービスをいつも正常に維持できる。 ● SREは新しいツールやテクノロジーを導入するだけの存在。 7

Slide 8

Slide 8 text

8 結構ちゃんとしてた

Slide 9

Slide 9 text

9 なのでこれとは違う 観点で話します

Slide 10

Slide 10 text

ここで自己紹介 ● こはる(@cohalz) ● 株式会社はてな ● SRE6年目 ○ はてなブックマーク ○ はてなブログ 10

Slide 11

Slide 11 text

色々やってます https://developer.hatenastaff.com/archive/author/cohalz 11

Slide 12

Slide 12 text

12 最近はこう思われていそう ● 昔からインフラ・クラウドの達人？ → No ○ 最初から成果を出していた？ → No ● 自宅でサーバを飼ってそう → No ○ これは実際に言われたこともある ● 人の目を気にするタイプではないが... ○ 実は誤解が仕事の妨げになることもある

Slide 13

Slide 13 text

13 SREのキャリア

Slide 14

Slide 14 text

キャリア紹介 ● 2017年はてなインターン参加 ○ Mackerelチームで主にバックエンドの実装をしていた ● その後アルバイトに入社 ○ チームの事情でMackerelではなくインフラチームの部署に 14

Slide 15

Slide 15 text

アルバイト応募当時 ● 実はミドルウェアもクラウドもほぼ未経験 ● SREingと言う概念も当然知らなかった ● 新しいことをやる機会と思って承諾 ○ これが転機 15

Slide 16

Slide 16 text

珍しいキャリア？ ● メンターの人も似たキャリアだった ○ 会社の座談会でも同様の人がいた ● SREingのムーブメントが始まったタイミング ○ 開発スキルも大事になってきた 16

Slide 17

Slide 17 text

そして入社へ... ● 入社時に職種を選べたがそのままSREとして入社 ● そして現在は全社のSREing活動を牽引する立場 ● めでたしめでたし...？ 17

Slide 18

Slide 18 text

18 SREの成長

Slide 19

Slide 19 text

成長の定義 ● 色々な成長があるわけだけど ● ここでは会社に対しての貢献度が増える意味で ○ つまりは給料が増えるには何をすればいいか 19

Slide 20

Slide 20 text

入社時を思い出す ● 当然最初は大変だった ● わからないことだらけなのは当たり前だが ● 全然成果を出せなかった ○ 他の人よりも成長が遅かった 20

Slide 21

Slide 21 text

SREに求められるスキル？ ● 色々な技術を使えるようになれば一人前？ ● 技術以外のスキルも必要なことがわかってきた ○ プロダクトやチームワーク ○ 自分と目の前の技術しか見えていなかった 21

Slide 22

Slide 22 text

成長のきっかけ ● はてなブログのチームに異動することに ○ 入社2年目になるタイミング ● 一人目のSREとして配属 ○ ここでどんどん成長していった 22

Slide 23

Slide 23 text

一人目SREになって変わったこと ● 周りに詳しい人がいなくなった ○ 他職種の人とも仕事するようになった ● プロダクト自体に責任を持つ立場に ○ 意思決定を求められる立場になった 23

Slide 24

Slide 24 text

周りに詳しい人がいなくなった ● 改善を期待されて異動しているが... ○ でもプロダクトのことは一番知らない ● メンバーには軽い説明だけでは伝わらない ○ ましてやプロダクトオーナーはもっと伝わらない ● 一人でも無理なく運用を回せる体制を目指す 24

Slide 25

Slide 25 text

チームで運用を回せるように ● 自動化 ○ 人に依存しない仕組み ● チームメンバーの認識・スキルを向上させる ○ SREとは何かを説明して回る ○ 一緒に仕事をする 25

Slide 26

Slide 26 text

早く一人前にならないといけない ● 一人目SREはテックリードのようなもの ● プロダクトオーナーなどに説明する責任がある 26

Slide 27

Slide 27 text

プロダクトが抱える課題に触れる ● システムを良くさせたい ● 障害やアラートもどんどん出てくる ● でもプロダクトを成長させないといけない 27

Slide 28

Slide 28 text

色々やった ● 過去ログを見る ● 周りの振る舞いを真似する ● 首をつっこむ ● 評価制度と向き合う 28

Slide 29

Slide 29 text

過去ログを見る ● Slackなどの過去ログを見ていく ○ アラートや障害対応 ○ 未解決のアクションが見つかることも ● わからないものものは全部調べる ● 技術だけでなく人の動きも見る 29

Slide 30

Slide 30 text

過去からコミュニケーションを学ぶ ● はてなブログという歴史のあるプロダクト ● 歴史を繋げていくための工夫を知る ○ こういえば伝わる、伝わらないがわかってくる ○ 伝える相手は未来の自分やチームメイトも含む 30

Slide 31

Slide 31 text

周りの振る舞いを真似する ● この人はなぜこう言ったのかをよく考える ● 受け売りにしないのに注意 ○ 「この人がこう言ったから...」にしない ○ 自分の言葉で発信し直す ● その際他人と比べないのも大事 ○ ライバル - hitode909の日記 31

Slide 32

Slide 32 text

首を突っ込む ● 最初に全社基盤のチームにいた名残 ● 各チームの様子を見る ● 自分だったらどうする？を考える 32

Slide 33

Slide 33 text

周りの協力もあった ● 異動前後のチームメンバーで作戦会議 ○ 「どうやったら短期間で最強のSREになるか」 ● 挑戦を応援する文化 33

Slide 34

Slide 34 text

開発合宿の参加 ● 他人と密にやり取りしな がら高速に成果を出す体 験 ● 技術的な深掘り、チーム ワーク、チーム外への説 明など色々学ぶことが あった 34 https://developer.hatenastaff.com/entry/2020/09/18/093000

Slide 35

Slide 35 text

これ以降活躍できるようになった ● 仕事の進め方がわかった ○ SREingをやっていく上では仕事のうまさは特に重要 ● うまくいく/いかない姿をイメージできるように 35

Slide 36

Slide 36 text

それまでの経験も無駄にはなってない ● コードの読み書き能力 ● 全社基盤の仕組み ● 他チームとのコミュニケーション 36

Slide 37

Slide 37 text

難しさに立ち向かう ● 難しさ・責任感によって成長したのだろう ● 崖から突き落とすモデルではあるが... ○ やっていくしかない 37

Slide 38

Slide 38 text

立場が人を作る？ ● 意思決定の立場になると実際変わってくる ● メンバーの退職や異動きっかけで成長もある ● 期待に精一杯応える ○ 計画的偶発性理論 38

Slide 39

Slide 39 text

(ちなみに)メンバーを成長させたいが... ● でもどうやったらいいか難しい ○ 同じことをチームメンバーにもやらせられる？ ● 時間を与える？ ● 立場を与える？ ● 最近はこの辺を考えています 39

Slide 40

Slide 40 text

40 SREの楽しみ

Slide 41

Slide 41 text

大変そう？ ● やることも考えることも多い ● その分楽しみもある ○ 様々な改善をしていく楽しみ ○ 障害対応の楽しみ ● モチベーションの維持どうやる？ 41

Slide 42

Slide 42 text

システムだけではない改善 ● 不健全な信頼性や開発速度を改善していく ○ たとえば人に依存した仕組みをなくす ● ユーザも開発メンバーも納得のできる体制に ○ 不幸になる人を減らす仕組みだと自分は思っている 42

Slide 43

Slide 43 text

信頼性を「上げる」のが仕事？ ● 多くのプロダクトはそうかもしれない ○ 運用の手が足りてないケース ● 実は意図的に信頼性を下げることもある ○ 開発速度を優先する ○ ユーザからの期待値コントロール 43

Slide 44

Slide 44 text

障害対応の楽しみ ● 障害対応は好きですか？ ○ SREは好きな人が多いであろう ● 理由なく障害は発生しない ● その理由を探っていかに早く解決できるか ○ システムと自分たちとの知恵比べ 44

Slide 45

Slide 45 text

(ちなみに)経験した障害いろいろ ● キャッシュしたら逆にパフォーマンスが悪化 ● フェイルオーバーが絶対失敗するKeepalived ● 構成変更したら別サービスも巻き込んで全部ダウン ● 切り替えメンテで本番だけ繋がらないデータストア 45

Slide 46

Slide 46 text

コードを書く楽しみ ● みんなコード書きたいし書いている ● コードを書くことがよりメリットになるように ○ 技術の標準化 ○ 社内OSS ● OSSを活用して改善していく ○ トイルの削減！ 46

Slide 47

Slide 47 text

fujiwara-wareにはお世話になっています！ 47

Slide 48

Slide 48 text

モチベーション維持 ● いろんなことやってて楽しい ○ 総合格闘技 ● 燃え尽き症候群(バーンアウト)を回避する ○ 周りとの期待値コントロールを行う ○ 賞賛されたものをいつでも見返せるようにする 48

Slide 49

Slide 49 text

49 大切にしていること

Slide 50

Slide 50 text

自分の中で大切にしてること ● やるべきことをよく考える ● 広く浅くでもいい ● 自分ごと化 ● 脱ヒロイズム 50

Slide 51

Slide 51 text

今やるべきことをよく考える ● 信頼性と開発速度のバランスを取る ● 手段と目的を間違えない ○ クラウドでやミドルウェアは手段 ● 相手の立場になって考える 51

Slide 52

Slide 52 text

広く浅くでもいい ● 様々な課題を解決できるだけでも貢献 ● 深くやらなきゃで動きが止まるのも良くない ● とはいえ、いざという時は深く潜れるように 52

Slide 53

Slide 53 text

自分ごと化 ● SREingはセルフサービス化が大事 ○ 開発者でも主体的に運用を行えるように ○ 開発メンバーとの壁を作らない ● 「専門家はいない。私たちしかいないんだ。」 ○ エラスティックリーダーシップの最初の文 53

Slide 54

Slide 54 text

成長した後は...？ ● 成長すると仕事を任せられるようになる ● それをガンガンやっていくことでも問題が起こる ○ ヒロイズム 54

Slide 55

Slide 55 text

ヒロイズム ● 英雄主義 ● SREingの文脈では主に障害対応などが特定の 人に偏ることを指す 55

Slide 56

Slide 56 text

ヒロイズムなチームの問題点 ● 他の人の成長機会を奪う ● 感度の低下 ○ 「あの人が見てくれるから安心」 ● 結果その人ありきな運用になってしまう ○ 単一障害点 ○ バーンアウトの危機 56

Slide 57

Slide 57 text

ヒロイズム脱却の難しさ ● 悪いことだけでもない ○ 対応した人は成長し、賞賛される ○ 周りの人もすぐ障害が復旧して嬉しい ● 本人の意識だけでは脱却が難しい ○ 認識が揃ってないとただ障害が長引くだけに 57

Slide 58

Slide 58 text

スケールするか？を考える ● 今の倍の数障害が起こったら？ ● 今対応してるメンバーがいなくても大丈夫？ ● 全員で認識を合わせていく 58

Slide 59

Slide 59 text

細かいマイルール ● 社内で自分のことをSREと呼ばない ○ コミュニケーションで職種の壁を作ってしまわない ○ SREはこういうもの、という固定概念を持たせない 59

Slide 60

Slide 60 text

60 どういう人に向いているか

Slide 61

Slide 61 text

インフラエンジニアの転換？ ● 前のめりに、プロダクトを見ていくことが求められる ○ そうしたかった人には動きやすくなった ● 「SREは、ソフトウェアエンジニアに運用チームの 設計を依頼した時にできあがるもの」 ○ SRE本にあるGoogle VPoEの言葉 ○ 実はみんなも向いているのかも？ 61

Slide 62

Slide 62 text

どういう人がSREに向いているか https://hatena.co.jp/recruit/career/sre 62

Slide 63

Slide 63 text

SREに求められる5つのソフトスキル https://www.catchpoint.com/asset/2018-sre-report 63

Slide 64

Slide 64 text

SREの概念に共感できる人 ● 人間に依存したくない ○ 手作業や意思決定をシステム化したい ○ 定量的な判断をしたい ● どうあるべきかは非常にわかりやすい ○ 今何をするべきか逆算できる 64

Slide 65

Slide 65 text

開発者に興味を持ってもらいたい ● 自分が開発出身だったからこそ強く思う ○ 自分以外にも意外とそういう人は多い ● 開発と運用の分断を避ける 65

Slide 66

Slide 66 text

開発と運用の分断を避ける？ ● 分業で一見効率は良さそうに見えるが... ● チーム外に依頼すると、 ○ 意思決定に時間がかかる ○ チーム間の目標のズレで衝突も ● 実は自分のチームでできたら一番早い 66

Slide 67

Slide 67 text

お互いが歩みよる ● 「You build it, you run it」 ○ AmazonのCTOの言葉 ● 自分の仕事を奪われたと感じる人はいない ○ 教えてくださいと言われたら喜んで教えるだろう 67

Slide 68

Slide 68 text

「技術だけやりたいんだが...?」 ● それもわかるしそういう人も当然いる ○ 人数がいれば分担できる ● 特定の技術を求めている会社もあるだろう ● ソフトスキルがいらないというわけではない 68

Slide 69

Slide 69 text

色々なSREがある ● オンプレ or クラウド ● 新規事業 or 老舗 ● toC or toB ● チーム構成 ○ DevOpsトポロジーによる と17種のチーム構成がある 69 https://web.devopstopologies.com/

Slide 70

Slide 70 text

向かう方向 ● 最終的にはSRE職やチームが無くなるのを目指すことも ● プロダクト開発のメンバーがSREingを実施できるように ○ その中で各メンバーが得意なことをやっていく ○ 「越境」という単語がわざわざ出てこない世界に 70

Slide 71

Slide 71 text

リーダーシップ・フォロワーシップ ● どちらも必要 ● つまりはやっていき・のっていき 71

Slide 72

Slide 72 text

プロダクトに沿ったSREをやっていく ● プロダクト・チームの相互理解が必要 ● 強いSREを採用して即なんとかなるわけでもない ○ ヒーローを求めてしまわない ● 周りの協力が大事！ 72

Slide 73

Slide 73 text

技術も当然必要 ● なんだかんだ人手は足りてない！ ● 技術的には変化の遅い部分も多い ○ 必要な技術は見えやすい ○ ただしめちゃくちゃ分野は広い 73

Slide 74

Slide 74 text

74 最後に

Slide 75

Slide 75 text

75 おわり ● SREは難しいけど楽しいこともいっぱい ○ アルバイトのときに違う選択をしたら今どうなっていたか ● SREingは周りの協力が大事 ○ 周りから声をかけてあげても良いかも ● みんなで協力して健全な開発生活を！