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

by a_ono

Embed

Start on current slide

Slide 1

Slide 1 text

SRE歴2ヶ月でも開発6年の知見を活かして、チームで止まっていた環境改善を前に進めた話株式会社イノベーション大野厚

Slide 2

Slide 2 text

自己紹介 [やっていること ] Engineering Manager / SRE 最近はインフラコスト最適化に夢中 💰 [趣味] ● ピアノ ● 作曲 ● 坂道 https://my.prairie.cards/u/ono_asagi

Slide 3

Slide 3 text

● はじめに ● 事例 ● まとめ目次

Slide 4

Slide 4 text

はじめに

Slide 5

Slide 5 text

これは「あるある」でしょうか？ここ改善したいけど、アプリの仕様がわからないから触ると事故るかも。手をつけられない。でも開発チーム忙しそうだし...。時間がある時に相談しよう。しかし、誰に聞けばいいんだろうか（気まずい）

Slide 6

Slide 6 text

あるある解消事例を話したい結論：サービスを長くやっている人を、 SRE業務にアサインする新しくSREを採用するよりも、ドメイン知識や開発フローを知っていて判断ができる開発者を突っ込むと早そう。＝＞自分がやってみた

Slide 7

Slide 7 text

● インフラまわり ○ 2026年4月〜（2ヶ月）。IaCやCI/CDの実装経験ほぼなし ● アプリ開発 ○ 2020年3月（6年）。機能・仕様や誰が関わるかは大体わかるスキル

Slide 8

Slide 8 text

事例① CI移行事例② DB同期リプレイス事例③ ポストモーテム 2ヶ月でできた事例紹介

Slide 9

Slide 9 text

事例

Slide 10

Slide 10 text

事例① CI移行やったこと Circle CI → GitHub Actionsへの移行一週間で6リポジトリなぜ必要だったか全社的なGitHubのプラン変更のため。Teamsから Enterpriseになった

Slide 11

Slide 11 text

アプリがわかる自分だからできたこと一人で十分な動作確認ができる誰かと連携するコミュニケーションコストが0 事例① CI移行

Slide 12

Slide 12 text

概要テストのため、本番環境のデータを検証環境にインポートするなぜリプレイスが必要だったかコスト削減：月額$400 → $80 高速化：10時間 → 1時間事例② DB同期リプレイス

Slide 13

Slide 13 text

事例② DB同期リプレイス前提 CodeBuild（10時間） ● 本番環境RDSのダンプを取得してS3に保存 ● 検証環境RDSにS3からインポート毎週実行

Slide 14

Slide 14 text

やったこと Step Functions・Lambda（1時間） ● 本番環境スナップショットからリストア必要な時に手動実行事例② DB同期リプレイス

Slide 15

Slide 15 text

事例② DB同期リプレイス選定理由課金形態を調べて、Step Functions・Lambda に変えた。待ち時間分の課金したくないのでsfnにした CodeBuild：1秒単位で課金 Step Functions：state切り替わり単位で課金

Slide 16

Slide 16 text

信頼性・運用面でのメリット 1時間になったことで日中にリカバリが可能になった 10時間かかっていた時はエラー時のリトライや確認が翌日になり運用負荷が高かった。事例② DB同期リプレイス

Slide 17

Slide 17 text

アプリがわかる自分だからできたことそもそも毎週同期する必要がない。 DBマイグレーションはリリース前に検証環境でも実行されているので、スキーマは揃う。本番相当のデータが検証環境で必要な時のみ同期できれば良い。事例② DB同期リプレイス

Slide 18

Slide 18 text

概要 hotﬁxの内容を振り返るなぜ必要だったか hotﬁxが多く、週一回のリリースサイクルを守れていない期間があった。振り返りの文化を作って、失敗から次の開発に活かしたい事例③ ポストモーテム

Slide 19

Slide 19 text

背景・起こったこと原因は、LaravelからGoへの段階的リプレイス。物理削除から論理削除になったことで、取得対象を正しく絞り込めなくなった ● DB（テーブルA）には deleted_at カラムが存在していた。 ● しかし、実は物理削除の運用だった。 ● Go側で新しく実装した際、このカラムを見て「あ、論理削除のテーブルなんだな」と判断してしまった。 ● 結果、過去のゴミデータをGoが掘り起こした事例③ ポストモーテム

Slide 20

Slide 20 text

事例③ ポストモーテムデータが何件追加されても、この行が取得されるようになっていた本来こっち

Slide 21

Slide 21 text

アプリがわかる自分だからできたこと ● hotﬁxの内容・背景を開発リーダーと把握する ● 暫定対応だけでなく、システムをあるべき姿を議論し、改善するきっかけにした＝＞次の開発時の認知負荷を下げるため deleted_at を削除する判断事例③ ポストモーテム

Slide 22

Slide 22 text

まとめ

Slide 23

Slide 23 text

冒頭から再掲ここ改善したいけど、アプリの仕様がわからないから触ると事故るかも。手をつけられない。でも開発チーム忙しそうだし...。時間がある時に相談しよう。しかし、誰に聞けばいいんだろうか（気まずい）

Slide 24

Slide 24 text

手応え結論：サービスを長くやっている人を、 SRE業務にアサインするインフラ経験が浅くとも、ドメイン知識のある人間がSREに関わることで、“コミュニケーションの気まずさ” や “事故る恐怖” が少なく、2ヶ月で改善を進めることができた

Slide 25

Slide 25 text

完