SREのキャリア、 あるいは生態 / #ya8

https://hachiojipm.connpass.com/event/304403/ の発表資料です

Transcript

1. SREのキャリア、 あるいは生態 id:cohalz / @cohalz Ya8 2024 - ヤパチー 令和六年最新版(仮) 1
2. 伝えたいこと • 技術の話はほとんどしません！ • SREは役割ではなく文化 ◦ その文化を支えるためのいろんな人がいる • SREとしてやっていくには ◦ どうやったら成長するのか ◦ 何を考えているのか 2
3. 免責事項 • 簡単のためにSRE職のことをSREと呼びます ◦ 文化の方のSREはSREingと呼びます • チームや会社によって変わります ◦ 特に事業規模・フェーズによって変わるものです ◦ こうでないSREを批判する意図はありません • 真似して起きた損失の責任を負いません ◦ 逆に良くなった場合は教えてください！ 3
4. なんでこんな話をここで？ • SREの活動って見えにくい • 社外でも非SREに向けた話があまりない ◦ SREのカンファレンスはSREに興味がある人が来る • いろんな人がいる場で知って欲しい ◦ SREに携わる人・概念を正しく知ってほしい 4
5. 5 誤解ってたとえば どういうのがあるか？
6. 6 一旦ChatGPTに 聞いてみた
7. SREに関する5つの誤解(by ChatGPT) • SREは単なる運用担当者で、開発には関与していない。 • SREは主に運用作業であり、プログラミングや開発のスキルは必要ない。 • SREはあらゆる障害を事前に予測し、防ぐことができる。 • SREは全ての問題に対して即座に対応でき、サービスをいつも正常に維持できる。 • SREは新しいツールやテクノロジーを導入するだけの存在。 7
8. 8 結構ちゃんとしてた
9. 9 なのでこれとは違う 観点で話します
10. ここで自己紹介 • こはる(@cohalz) • 株式会社はてな • SRE6年目 ◦ はてなブックマーク ◦ はてなブログ 10
11. 色々やってます https://developer.hatenastaff.com/archive/author/cohalz 11
12. 12 最近はこう思われていそう • 昔からインフラ・クラウドの達人？ → No ◦ 最初から成果を出していた？ → No • 自宅でサーバを飼ってそう → No ◦ これは実際に言われたこともある • 人の目を気にするタイプではないが... ◦ 実は誤解が仕事の妨げになることもある
13. 13 SREのキャリア
14. キャリア紹介 • 2017年はてなインターン参加 ◦ Mackerelチームで主にバックエンドの実装をしていた • その後アルバイトに入社 ◦ チームの事情でMackerelではなくインフラチームの部署に 14
15. アルバイト応募当時 • 実はミドルウェアもクラウドもほぼ未経験 • SREingと言う概念も当然知らなかった • 新しいことをやる機会と思って承諾 ◦ これが転機 15
16. 珍しいキャリア？ • メンターの人も似たキャリアだった ◦ 会社の座談会でも同様の人がいた • SREingのムーブメントが始まったタイミング ◦ 開発スキルも大事になってきた 16
17. そして入社へ... • 入社時に職種を選べたがそのままSREとして入社 • そして現在は全社のSREing活動を牽引する立場 • めでたしめでたし...？ 17
18. 18 SREの成長
19. 成長の定義 • 色々な成長があるわけだけど • ここでは会社に対しての貢献度が増える意味で ◦ つまりは給料が増えるには何をすればいいか 19
20. 入社時を思い出す • 当然最初は大変だった • わからないことだらけなのは当たり前だが • 全然成果を出せなかった ◦ 他の人よりも成長が遅かった 20
21. SREに求められるスキル？ • 色々な技術を使えるようになれば一人前？ • 技術以外のスキルも必要なことがわかってきた ◦ プロダクトやチームワーク ◦ 自分と目の前の技術しか見えていなかった 21
22. 成長のきっかけ • はてなブログのチームに異動することに ◦ 入社2年目になるタイミング • 一人目のSREとして配属 ◦ ここでどんどん成長していった 22
23. 一人目SREになって変わったこと • 周りに詳しい人がいなくなった ◦ 他職種の人とも仕事するようになった • プロダクト自体に責任を持つ立場に ◦ 意思決定を求められる立場になった 23
24. 周りに詳しい人がいなくなった • 改善を期待されて異動しているが... ◦ でもプロダクトのことは一番知らない • メンバーには軽い説明だけでは伝わらない ◦ ましてやプロダクトオーナーはもっと伝わらない • 一人でも無理なく運用を回せる体制を目指す 24
25. チームで運用を回せるように • 自動化 ◦ 人に依存しない仕組み • チームメンバーの認識・スキルを向上させる ◦ SREとは何かを説明して回る ◦ 一緒に仕事をする 25
26. 早く一人前にならないといけない • 一人目SREはテックリードのようなもの • プロダクトオーナーなどに説明する責任がある 26
27. プロダクトが抱える課題に触れる • システムを良くさせたい • 障害やアラートもどんどん出てくる • でもプロダクトを成長させないといけない 27
28. 色々やった • 過去ログを見る • 周りの振る舞いを真似する • 首をつっこむ • 評価制度と向き合う 28
29. 過去ログを見る • Slackなどの過去ログを見ていく ◦ アラートや障害対応 ◦ 未解決のアクションが見つかることも • わからないものものは全部調べる • 技術だけでなく人の動きも見る 29
30. 過去からコミュニケーションを学ぶ • はてなブログという歴史のあるプロダクト • 歴史を繋げていくための工夫を知る ◦ こういえば伝わる、伝わらないがわかってくる ◦ 伝える相手は未来の自分やチームメイトも含む 30
31. 周りの振る舞いを真似する • この人はなぜこう言ったのかをよく考える • 受け売りにしないのに注意 ◦ 「この人がこう言ったから...」にしない ◦ 自分の言葉で発信し直す • その際他人と比べないのも大事 ◦ ライバル - hitode909の日記 31
32. 首を突っ込む • 最初に全社基盤のチームにいた名残 • 各チームの様子を見る • 自分だったらどうする？を考える 32
33. 周りの協力もあった • 異動前後のチームメンバーで作戦会議 ◦ 「どうやったら短期間で最強のSREになるか」 • 挑戦を応援する文化 33
34. 開発合宿の参加 • 他人と密にやり取りしな がら高速に成果を出す体 験 • 技術的な深掘り、チーム ワーク、チーム外への説 明など色々学ぶことが あった 34 https://developer.hatenastaff.com/entry/2020/09/18/093000
35. これ以降活躍できるようになった • 仕事の進め方がわかった ◦ SREingをやっていく上では仕事のうまさは特に重要 • うまくいく/いかない姿をイメージできるように 35
36. それまでの経験も無駄にはなってない • コードの読み書き能力 • 全社基盤の仕組み • 他チームとのコミュニケーション 36
37. 難しさに立ち向かう • 難しさ・責任感によって成長したのだろう • 崖から突き落とすモデルではあるが... ◦ やっていくしかない 37
38. 立場が人を作る？ • 意思決定の立場になると実際変わってくる • メンバーの退職や異動きっかけで成長もある • 期待に精一杯応える ◦ 計画的偶発性理論 38
39. (ちなみに)メンバーを成長させたいが... • でもどうやったらいいか難しい ◦ 同じことをチームメンバーにもやらせられる？ • 時間を与える？ • 立場を与える？ • 最近はこの辺を考えています 39
40. 40 SREの楽しみ
41. 大変そう？ • やることも考えることも多い • その分楽しみもある ◦ 様々な改善をしていく楽しみ ◦ 障害対応の楽しみ • モチベーションの維持どうやる？ 41
42. システムだけではない改善 • 不健全な信頼性や開発速度を改善していく ◦ たとえば人に依存した仕組みをなくす • ユーザも開発メンバーも納得のできる体制に ◦ 不幸になる人を減らす仕組みだと自分は思っている 42
43. 信頼性を「上げる」のが仕事？ • 多くのプロダクトはそうかもしれない ◦ 運用の手が足りてないケース • 実は意図的に信頼性を下げることもある ◦ 開発速度を優先する ◦ ユーザからの期待値コントロール 43
44. 障害対応の楽しみ • 障害対応は好きですか？ ◦ SREは好きな人が多いであろう • 理由なく障害は発生しない • その理由を探っていかに早く解決できるか ◦ システムと自分たちとの知恵比べ 44
45. (ちなみに)経験した障害いろいろ • キャッシュしたら逆にパフォーマンスが悪化 • フェイルオーバーが絶対失敗するKeepalived • 構成変更したら別サービスも巻き込んで全部ダウン • 切り替えメンテで本番だけ繋がらないデータストア 45
46. コードを書く楽しみ • みんなコード書きたいし書いている • コードを書くことがよりメリットになるように ◦ 技術の標準化 ◦ 社内OSS • OSSを活用して改善していく ◦ トイルの削減！ 46
47. fujiwara-wareにはお世話になっています！ 47
48. モチベーション維持 • いろんなことやってて楽しい ◦ 総合格闘技 • 燃え尽き症候群(バーンアウト)を回避する ◦ 周りとの期待値コントロールを行う ◦ 賞賛されたものをいつでも見返せるようにする 48
49. 49 大切にしていること
50. 自分の中で大切にしてること • やるべきことをよく考える • 広く浅くでもいい • 自分ごと化 • 脱ヒロイズム 50
51. 今やるべきことをよく考える • 信頼性と開発速度のバランスを取る • 手段と目的を間違えない ◦ クラウドでやミドルウェアは手段 • 相手の立場になって考える 51
52. 広く浅くでもいい • 様々な課題を解決できるだけでも貢献 • 深くやらなきゃで動きが止まるのも良くない • とはいえ、いざという時は深く潜れるように 52
53. 自分ごと化 • SREingはセルフサービス化が大事 ◦ 開発者でも主体的に運用を行えるように ◦ 開発メンバーとの壁を作らない • 「専門家はいない。私たちしかいないんだ。」 ◦ エラスティックリーダーシップの最初の文 53
54. 成長した後は...？ • 成長すると仕事を任せられるようになる • それをガンガンやっていくことでも問題が起こる ◦ ヒロイズム 54
55. ヒロイズム • 英雄主義 • SREingの文脈では主に障害対応などが特定の 人に偏ることを指す 55
56. ヒロイズムなチームの問題点 • 他の人の成長機会を奪う • 感度の低下 ◦ 「あの人が見てくれるから安心」 • 結果その人ありきな運用になってしまう ◦ 単一障害点 ◦ バーンアウトの危機 56
57. ヒロイズム脱却の難しさ • 悪いことだけでもない ◦ 対応した人は成長し、賞賛される ◦ 周りの人もすぐ障害が復旧して嬉しい • 本人の意識だけでは脱却が難しい ◦ 認識が揃ってないとただ障害が長引くだけに 57
58. スケールするか？を考える • 今の倍の数障害が起こったら？ • 今対応してるメンバーがいなくても大丈夫？ • 全員で認識を合わせていく 58
59. 細かいマイルール • 社内で自分のことをSREと呼ばない ◦ コミュニケーションで職種の壁を作ってしまわない ◦ SREはこういうもの、という固定概念を持たせない 59
60. 60 どういう人に向いているか
61. インフラエンジニアの転換？ • 前のめりに、プロダクトを見ていくことが求められる ◦ そうしたかった人には動きやすくなった • 「SREは、ソフトウェアエンジニアに運用チームの 設計を依頼した時にできあがるもの」 ◦ SRE本にあるGoogle VPoEの言葉 ◦ 実はみんなも向いているのかも？ 61
62. どういう人がSREに向いているか https://hatena.co.jp/recruit/career/sre 62
63. SREに求められる5つのソフトスキル https://www.catchpoint.com/asset/2018-sre-report 63
64. SREの概念に共感できる人 • 人間に依存したくない ◦ 手作業や意思決定をシステム化したい ◦ 定量的な判断をしたい • どうあるべきかは非常にわかりやすい ◦ 今何をするべきか逆算できる 64
65. 開発者に興味を持ってもらいたい • 自分が開発出身だったからこそ強く思う ◦ 自分以外にも意外とそういう人は多い • 開発と運用の分断を避ける 65
66. 開発と運用の分断を避ける？ • 分業で一見効率は良さそうに見えるが... • チーム外に依頼すると、 ◦ 意思決定に時間がかかる ◦ チーム間の目標のズレで衝突も • 実は自分のチームでできたら一番早い 66
67. お互いが歩みよる • 「You build it, you run it」 ◦ AmazonのCTOの言葉 • 自分の仕事を奪われたと感じる人はいない ◦ 教えてくださいと言われたら喜んで教えるだろう 67
68. 「技術だけやりたいんだが...?」 • それもわかるしそういう人も当然いる ◦ 人数がいれば分担できる • 特定の技術を求めている会社もあるだろう • ソフトスキルがいらないというわけではない 68
69. 色々なSREがある • オンプレ or クラウド • 新規事業 or 老舗 • toC or toB • チーム構成 ◦ DevOpsトポロジーによる と17種のチーム構成がある 69 https://web.devopstopologies.com/
70. 向かう方向 • 最終的にはSRE職やチームが無くなるのを目指すことも • プロダクト開発のメンバーがSREingを実施できるように ◦ その中で各メンバーが得意なことをやっていく ◦ 「越境」という単語がわざわざ出てこない世界に 70
71. リーダーシップ・フォロワーシップ • どちらも必要 • つまりはやっていき・のっていき 71
72. プロダクトに沿ったSREをやっていく • プロダクト・チームの相互理解が必要 • 強いSREを採用して即なんとかなるわけでもない ◦ ヒーローを求めてしまわない • 周りの協力が大事！ 72
73. 技術も当然必要 • なんだかんだ人手は足りてない！ • 技術的には変化の遅い部分も多い ◦ 必要な技術は見えやすい ◦ ただしめちゃくちゃ分野は広い 73
74. 74 最後に
75. 75 おわり • SREは難しいけど楽しいこともいっぱい ◦ アルバイトのときに違う選択をしたら今どうなっていたか • SREingは周りの協力が大事 ◦ 周りから声をかけてあげても良いかも • みんなで協力して健全な開発生活を！