SRE歴2ヶ月でも開発6年の知見を活かして、チームで止まっていた環境改善を前に進めた話

The SRE Backlog: 蔵出し事例共有会
https://layerx.connpass.com/event/394351/

Transcript

1. SRE歴2ヶ月でも開発6年の知見を 活かして、チームで止まっていた 環境改善を前に進めた話 株式会社イノベーション 大野 厚
2. 自己紹介 [やっていること ] Engineering Manager / SRE 最近はインフラコスト最適化に夢中 💰 [趣味] • ピアノ • 作曲 • 坂道 https://my.prairie.cards/u/ono_asagi
3. • はじめに • 事例 • まとめ 目次
4. はじめに
5. これは「あるある」でしょうか？ ここ改善したいけど、アプリの仕様がわから ないから触ると事故るかも。 手をつけられない。でも開発チーム忙しそう だし...。時間がある時に相談しよう。 しかし、誰に聞けばいいんだろうか （気まずい）
6. あるある解消事例を話したい 結論：サービスを長くやっている人を、 SRE業務にアサ インする 新しくSREを採用するよりも、ドメイン知識や開発フロー を知っていて判断ができる開発者を突っ込むと早そう。 ＝＞自分がやってみた
7. • インフラまわり ◦ 2026年4月〜（2ヶ月）。IaCやCI/CDの実装経験 ほぼなし • アプリ開発 ◦ 2020年3月（6年）。機能・仕様や誰が関わるかは 大体わかる スキル
8. 事例① CI移行 事例② DB同期リプレイス 事例③ ポストモーテム 2ヶ月でできた事例紹介
9. 事例
10. 事例① CI移行 やったこと Circle CI → GitHub Actionsへの移行 一週間で6リポジトリ なぜ必要だったか 全社的なGitHubのプラン変更のため。Teamsから Enterpriseになった
11. アプリがわかる自分だからできたこと 一人で十分な動作確認ができる 誰かと連携するコミュニケーションコストが0 事例① CI移行
12. 概要 テストのため、本番環境のデータを検証環境にイン ポートする なぜリプレイスが必要だったか コスト削減：月額$400 → $80 高速化：10時間 → 1時間 事例② DB同期リプレイス
13. 事例② DB同期リプレイス 前提 CodeBuild（10時間） • 本番環境RDSのダンプを取得してS3に保存 • 検証環境RDSにS3からインポート 毎週実行
14. やったこと Step Functions・Lambda（1時間） • 本番環境スナップショットからリストア 必要な時に手動実行 事例② DB同期リプレイス
15. 事例② DB同期リプレイス 選定理由 課金形態を調べて、Step Functions・Lambda に変え た。待ち時間分の課金したくないのでsfnにした CodeBuild：1秒単位で課金 Step Functions：state切り替わり単位で課金
16. 信頼性・運用面でのメリット 1時間になったことで日中にリカバリが可能になった 10時間かかっていた時はエラー時のリトライや確認が 翌日になり運用負荷が高かった。 事例② DB同期リプレイス
17. アプリがわかる自分だからできたこと そもそも毎週同期する必要がない。 DBマイグレーションはリリース前に検証環境でも実行さ れているので、スキーマは揃う。 本番相当のデータが検証環境で必要な時のみ同期で きれば良い。 事例② DB同期リプレイス
18. 概要 hotfixの内容を振り返る なぜ必要だったか hotfixが多く、週一回のリリースサイクルを守れていな い期間があった。振り返りの文化を作って、失敗から次 の開発に活かしたい 事例③ ポストモーテム
19. 背景・起こったこと 原因は、LaravelからGoへの段階的リプレイス。 物理削除から論理削除になったことで、取得対象を正しく絞り込めな くなった • DB（テーブルA）には deleted_at カラムが存在していた。 • しかし、実は物理削除の運用だった。 • Go側で新しく実装した際、このカラムを見て「あ、論理削除のテーブルなんだな」と判 断してしまった。 • 結果、過去のゴミデータをGoが掘り起こした 事例③ ポストモーテム
20. 事例③ ポストモーテム データが何件追加さ れても、この行が取得 されるようになってい た 本来こっち
21. アプリがわかる自分だからできたこと • hotfixの内容・背景を開発リーダーと把握する • 暫定対応だけでなく、システムをあるべき姿を議論 し、改善するきっかけにした ＝＞次の開発時の認知負荷を下げるため deleted_at を削除する判断 事例③ ポストモーテム
22. まとめ
23. 冒頭から再掲 ここ改善したいけど、アプリの仕様がわから ないから触ると事故るかも。 手をつけられない。でも開発チーム忙しそう だし...。時間がある時に相談しよう。 しかし、誰に聞けばいいんだろうか （気まずい）
24. 手応え 結論：サービスを長くやっている人を、 SRE業務にアサ インする インフラ経験が浅くとも、ドメイン知識のある 人間がSREに関わることで、“コミュニケー ションの気まずさ” や “事故る恐怖” が少な く、2ヶ月で改善を進めることができた
25. 完