6 年の間 SRE がゼロだったプロダクトに Embedded SRE として入って やったこと、感じたこと、これから

Transcript

1. ©MIXI ©MIXI 6 年の間 SRE がゼロだったプロダクト に Embedded SRE として⼊って やったこと、感じたこと、これから 秋のSRE談義 〜現場の知⾒ 収穫祭！〜 2025/09/25 株式会社 MIXI 開発本部 CTO 室 ⼤野⼀樹
2. 22 ©MIXI 自己紹介
 大野一樹
 - 2024 年 株式会社 MIXI 入社
 開発本部 CTO 室 所属
 今は Platform Engineering チーム
 - 普段は関西でリモートで働いています
 - ex サーバ/インフラ本の会社
 - SRE 7 年目
 - X: @i2tsuki_, MIXI2: @itsuki
 最近の⽬標: 10 年先も SRE
 ref: https://gihyo.jp/book/2008/978-4-7741-3566-3 ［24時間365日］サーバ/インフラを支える技術
3. 3 ©MIXI 株式会社 MIXI について 
 「豊かなコミュニケーションを広げ、世界を幸せな驚きで包む。」
 スポーツ ライフスタイル デジタルエンターテインメント
4. 4 ©MIXI スポーツ それぞれのプロダクトに対して SRE として事業を支援する
 バックグラウンドとして SRE を持たない部署がある ので横断組織として⽀援する 
 開発本部 CTO 室 SRE グループ(旧組織) 
 ライフスタイル デジタルエンターテインメント SRE
5. ©MIXI Embedded SRE としてやったこと
6. 6 ©MIXI 共闘ことば RPG コトダマンの SRE 支援 
 入社したタイミングから Embedded SRE として人材派遣
 - ミッション: 10 周年を迎えられるようにサービス信頼性を確保すること
 - 支援の背景: 障害が多く発⽣ & AWS のメンテナンスの対応ノウハウがない
 - 期間: 2024 年 - 2025 年 8 月末まで
 ref: SlideDeck Road to SRE NEXT2024@京都 ref: https://app.famitsu.com/20240527_2235977/
7. 7 ©MIXI まずは全容把握、実態として問題だらけ.. 
 いざチームに入ってみると実態は..
 - Ansible でのプロビジョニングがサーバの状態と⼀致しない
 (サーバは EC2 でお手手でオペレーションされて運用されている)
 - IaC に利用している CloudFormation のドリフトが発生しまくっている
 - ホスト名が RFC1123 に違反(ドットが⼊っている)している
 - リリースするたびにアラートが発⽣している
 - IAM ロールが全インスタンスで共通のものが使われている
 - 退職者や離脱者のアカウントが整理されていない
 - GitHub Actions を使わずに Jenkins を使っていて CI/CD がイケていない - ミドルウェアが 5,6 年以上前のもの(Nginx 1.10.x etc.)が動いている etc..
 ※ オンボーディングのタスクをこなしつつ、ここまで認知するのに 3 ヶ月くらい

8. ©MIXI あれ.. 信頼性とか定義するどころじゃなくない..? 10 年どころかこのまま明⽇が運⽤できなくない..? どうしよう..??
9. ©MIXI とりあえず..悩んでも仕⽅ないので.. ⼿を動かす & 気合いでやる
10. 10 ©MIXI 最大の Toil を撲滅した話(サーバーの IaC 改善) 
 Ansible の changed が大量に出る?!
 
 開発環境と本番環境で Playbook のリポジ トリが別になっている?!(当然差分いっぱい)
 気合いと筋⾁で全部直した!! (AI に正しいサーバの状態を教えての自動化は難しい..)
 冪等性を確保して、⼀つずつ差分を潰してリポジトリを切り替えた!! 開発環境のリポジトリ $ ansible-playbook -t setup ./main.yml --diff (snip) 10.xxx.xxx.xxx : ok=101 changed=84 unreachable=0 failed=2 skipped=56 rescued=0 ignored=1 10.xxx.xxx.xxx : ok=107 changed=82 unreachable=0 
 この changed は無視していいやつ!! (changed を 0 にす るべきでは?) 本番環境のリポジトリ 2 回 PR 作る (作業量 x 2 倍)
11. 11 ©MIXI そのほかの問題も全部解決する (ほとんど一人でやった) 
 - CloudFormation のドリフト 
 → 解消して全部 Terraform に移行、ついでに Amazon Linux 2023 に更新 - ホスト名が RFC1123 に違反(ドットが⼊っている) → Terraform に移行した際にホスト名を全部⼀新 - リリースするたびにアラートが発⽣している
 → システムメトリクスを見るのではなくサービスメトリクスを⾒る - IAM ロールが全インスタンスで共通 → CloudTrail でログ調査、本当に必要な権限だけに IAM ロールを分割 - ミドルウェアが 5,6 年以上前でリリースからアップデートされていない
 → Amazon Linux 2023 にアップデートする障壁になっていたので全部更新 他にも⾊々解決するのに 1 年以上かかった & 障害対応や新規サーバの作成も同時進⾏
12. ©MIXI 問題を解決してどうなった......
13. ©MIXI 疲れた!! 問題を解決してどうなった? (システムはよくなったが..)
14. 14 ©MIXI Embedded SRE としての限界 
 - ⾃分の中の標準レベルのサーバインフラがほど遠い(信頼性を確保する前の段階)
 - ゼロから作り直した方が早い & 同じ改善を繰り返し ている - 根本的に問題が問題として認識されていない(認知負荷の問題) - プロダクトチームが外部組織の SRE にオフロードしている状態になっている
 ※この話は SRE NEXT 2025 のアンカンファレンスでもあった
 - 別のプロダクトに Embedded SRE に移ったとしても何も解決しない 
 Enable SRE としての関わりにシフトしようと考える
 離脱の意向を示す(上に相談する): 離脱の期限を決める、タスクを引き継ぐ プロダクト側のエンジニアリングマネージャーと 1on1: 問題の認識を伝える

15. ©MIXI Enable SRE の役割も終えて そして、これから..
16. 16 ©MIXI そして Central SRE & Platform SRE として 
 - Embedded SRE, Enable SRE の人材派遣型支援のモデルはスケールしない!!
 組織の共通認識としてあった
 - Platform Engineering チームと開発基盤チームの発足(Central SRE の位置付け)
 横軸組織としてノウハウを蓄積して還元して SRE の開発⽣産性を向上する🙌
 - Platform Engineering チームとして共通化できるところからやる!!
 - オブザーバビリティーの普及を支援、各プロダクトの SRE のレベル向上
 ゴールは社内でサービスを超えたシステム間でのオブザーバビリティの確保
 - オブザーバビリティプラットフォームの構築‧提供 - LLM 基盤の提供(ガードレールの役割も) - QA ⾃動化のためのプラットフォームの提供 ちゃんと IaC 運⽤していくためのサーバインフラ基盤の提供もやりたい..