Railsエンジニアが始めるSRE

RailsTokyo#5 ( https://railstokyo.connpass.com/event/393733/ )で発表した内容です。

Transcript

1. Railsエンジニアが始めるSRE 株式会社YOUTRUST 寺井 省吾
2. 自己紹介 • 寺井 省吾 (@krpk1900_dev) • 株式会社YOUTRUST SRE • Kaigi on Rails Organizer • 席替えメーカー • 趣味 • 将棋 / バドミントン / サッカー / バスケ / 釣り / ボードゲーム @krpk1900_dev
3. 今日のテーマ Railsエンジニアが 今のロールのまま始められる取り組み
4. 2026年にやってきたこと 話すこと • ライブラリアップグレード可視化 / 組織化 • ノイズアラートの整備 • 不具合対応の後追い 話さないこと • • • • • • • • • • • • • • • • • React 17→18 MySQL→Redis置換によるパフォーマンス改善 DataDog PrivateLink導入 Privateサブネット移行 Redis 4系→5系 Sidekiq 6系→7系 DoS攻撃対策機能開発 AWS権限整備 MySQL 8.0→8.4 Devise 4系→5系 OpenSearch高速化 Ruby 3.4→4.0 ElastiCache コストカット S3 Gateway VPCエンドポイント導入 Node.js 20系→24系 Rails 7.2→8.0 TypeScript 5系→6系
5. YOUTRUSTでの立ち位置
6. 01 ライブラリアップグレードの 可視化 / 組織化
7. ライブラリアップグレード 自分しかできない状態は不健全 プロダクトエンジニアが取り組む必要性を、 合理的に説明できるようにしたい。
8. まず、スコアで可視化した • ライブラリアップグレードスコアを定義した • 現状がどれくらいなのか、改善していっているのか悪化していっているのかを知る
9. スコアを毎月定点観測
10. 見えてきたこと 「今月はめっちゃアップグレードできた」 と感じた月でも、スコアは若干悪化だった 感覚と数字がズレていることが、可視化して初めて分かった。
11. サービスは増えていく 1人ではもう回らない サービスの数が増えた今、 1人でアップグレードし続けるのは現実的ではない。
12. 興味がある人を募集した • 多くの人が集まった！
13. キックオフでやったこと • 自分がどうやってアップグレードしているかを実際に見せる • 手順だけでなく、どんな心構えでやっているかも伝えた • リスクをゼロにすることはできない • 万が一不具合が起きてしまっても、すぐに対応すれば大丈夫 • それよりも取り組んだことが大事
14. キックオフ後の動き • まずはアサインの動きから始まった • 分からない人にはGood First Issueを選んで渡した
15. たくさんの人が初アップグレード！ 周りの人の挑戦を とにかく喜んだ
16. AIで代替できるかもしれない、けど この成功体験には、大きな価値がある 01 02 03 自分でもできるんだ！ またやりたい！ もっと大きな アップグレードもして みたい！ むしろさらに価値が高くなってきていると思う
17. 人の行動を変えるのは理論ではなく心 • Slackでの言葉選び • 伝え方
18. 活動の結果
19. 明日から取り組めること • パッチバージョンでも良いので、上がっていないライブラリを 1つ上げてみる • ライブラリアップグレード状況をスコアリングして可視化してみる • 「興味がある人で一緒にやりませんか？」と周りを巻き込んで キックオフしてみる • 一緒に取り組んだ人の挑戦を本気で喜んで盛り上げる🔥
20. 02 ノイズアラートの整備
21. みなさんの会社はどうですか？ アプリケーションの監視、 入っていますか？ 「いつも出ているアラートだから、対応しなくていいや」 になっているアラートは、ありませんか？
22. うちは長年ずっと出ていました アプリケーションのエラー対応を プロダクトエンジニアに浸透させたい でも、そもそも見られる状態になっていなかった。
23. 課題 • アラートが多過ぎて、どれを見たらよいか分からない • ノイズアラートが多過ぎて、そもそもやる気が起きない
24. やったこと 丸2日かけて、 全アラートの精査を行った 特別なことは何もしておらず、ひたすら1つずつ見ていった。
25. 通知を切るのは簡単にできる
26. リードするための言い方 NG 「切っても良いですか？」 OK 「不要だと判断したので切ります！ 問題があれば元に戻すので、今日中に教えてください！」
27. 結果 • 初めて、1日アラートが一切鳴らない日ができた • 出たものだけ対応すれば良い状態になり、分かりやすくな った
28. 明日から取り組めること • 対応しないアラートの通知を1つ切ってみる • 不要アラートをすべて消し切らなくても、1つずつ確実に積み上がっていく • 自分の行動を見た隣の人もチャレンジしてくれるかも • 完璧よりも実際の行動
29. 03 不具合対応の後追い
30. 最初はただの投稿ベースだった • 専用のSlackチャンネルに、各自が自由に投稿する運用 • 課題 • 必要な情報が足りない • 他の投稿に埋もれてしまう
31. ワークフロー導入開始 • 入力情報を統一化 • 課題 • (知らなくて)使ってくれない人も一定いた • 担当者のアサインまではできていたが、 対応が完了したか分からない • そのまま流れてしまっているものも一定数あった
32. Slackのフォーム入力を必須化 • デフォルトでメッセージ送信できないようにし、 フォームでの入力を必須化した • チャンネル内の投稿がワークフローによるものだけに なったので、どれが不具合報告か分かりやすくなった • これらの課題は残ったまま • 担当者のアサインまではできていたが、 対応が完了したか分からない • そのまま流れてしまっているものも一定数あった
33. 仕組みを作るだけでなく浸透が大事
34. NotionのDBに連携して蓄積し、隔日で確認 • フォームから投稿されたものは、NotionのDBに自動で蓄積 • 隔日で、未対応の不具合のボールの所在を確認する
35. 解決までチームで確認
36. 機能開発と不具合対応の両立 • 課題：どちらを優先してやったら良いか分からない • 不具合が報告されたら、SREがすぐにSEVを判定する • 会社の実態に合わせてシンプルにしたSEVレベルを定義
37. インシデントポイントで計測する • 不具合の状態を可視化するためにインシデントポイントを定義 • 毎月計測し、目標を設定する • 原因分析も実施
38. ポストモーテム • SEV2以上はポストモーテムを実施 • 最初はSREがファシリテーターをしていた • 今ではプロダクトエンジニアが自発的に実施し始めている
39. 04 まとめ
40. 明日から取り組めること (具体) • パッチバージョンでも良いので、上がっていないライブラリを1つ上げてみる • ライブラリアップグレード状況をスコアリングして可視化してみる • 「興味がある人で一緒にやりませんか？」と周りを巻き込んでキックオフして みる • 一緒に取り組んだ人の挑戦を本気で喜んで盛り上げる • 対応しないアラートの通知を1つ切ってみる • ボールが浮いている不具合対応がないか見てみる • 不具合対応のフローの改善を提案してみる
41. 共通して意識していること 組織に仕組みを浸透させることが一番大事 仕組みは完璧じゃなくても良いのでとにかくシンプルに
42. 共通して意識していること 人の行動を変えるのは、理論ではなく心 伝え方や言葉選び、雰囲気作りなどを軽視しない
43. ご清聴ありがとうございました 寺井 省吾 / @krpk1900_dev