インフラ寄りSREの生存戦略

by SansanTech

Slide 1

Slide 1 text

インフラ寄りSREの⽣存戦略 Sansan株式会社上司陽平（じょーし） Sansan株式会社

Slide 2

Slide 2 text

2 © Sansan, Inc. ⾃⼰紹介じょーし Sansan株式会社 @paper2parasol - 経理DXサービス「Bill One」のソフトウェアエンジニア兼SRE - 負荷試験による性能改善、IaC化と⽂化醸成、機能開発などを担当 - 有志メンバによるCI/CD改善チームを運営し、⽇々の開発者体験の向上に取り組む - GitHub Actionsの実⾏時間を可視化するOSS 「GitHub Actions OpenTelemetry」を個⼈開発 - 好きなものはラーメンとCloud Run

Slide 3

Slide 3 text

まず、前提として

Slide 4

Slide 4 text

信頼性に関する問題は複数の観点にまたがって存在する

Slide 5

Slide 5 text

5 © Sansan, Inc. 信頼性に関する問題は複数の観点にまたがって存在するアプリ観点機能仕様観点インフラ観点 ※他の観点もありますが、本発表では上記3点に焦点を当てています。ユーザ視点の問題例：検索が遅い問題例：デフォルトの検索範囲が広すぎる...etc 問題例：クエリが⾮効率、アプリ上の⾮効率なデータ結合...etc 問題例：DBのスペック不⾜...etc

Slide 6

Slide 6 text

インフラ観点の問題解決しかできないと局所最適になりやすい

Slide 7

Slide 7 text

信頼性を向上するためにはユーザに近い機能仕様・アプリ観点での問題も解決できる必要がある

Slide 8

Slide 8 text

⾃分だけでできる必要はないが基本が出来るだけでコミュニケーションの質は格段に上がる

Slide 9

Slide 9 text

次に、難易度と量を表現してみる

Slide 10

Slide 10 text

10 © Sansan, Inc. 問題の散布図難易問題を点にした散布図で表現してみるアプリ観点機能仕様観点インフラ観点難易度

Slide 11

Slide 11 text

クラウドの進化でインフラ⾯の問題は⼤幅に削減されたコンテナをホストしてくれるCloud Run（Google Cloud）の⾃動スケーリングやマネージド運⽤は⾮常に有⽤。ARR100億円規模のBill Oneを⽀えている。

Slide 12

Slide 12 text

12 © Sansan, Inc. これが、、、問題の散布図難易アプリ観点機能仕様観点インフラ観点難易度

Slide 13

Slide 13 text

13 © Sansan, Inc. 問題の散布図難易アプリ観点機能仕様観点インフラ観点難易度こうじゃ（イメージ）

Slide 14

Slide 14 text

14 © Sansan, Inc. 今後もインフラ観点の問題の絶対量は減ると予想される問題の散布図難易アプリ観点機能仕様観点インフラ観点難易度 ※ ⽣成AIによりアプリ観点などの問題量も減ると予想されますが本発表では着⽬しません。

Slide 15

Slide 15 text

信頼性を向上するためにはユーザに近い機能仕様・アプリ観点での問題も解決できる必要がある今後もインフラ観点の問題の絶対量は減ると予想される

Slide 16

Slide 16 text

インフラ以外もある程度できた⽅が SREとしての⽣存確率が⼤幅に増える（という仮説）

Slide 17

Slide 17 text

17 © Sansan, Inc. 問題の散布図難易アプリ観点機能仕様観点インフラ観点難易度このあたりが多かった⾃分のキャリア（インフラ寄りSRE） - 決済サービスのインフラ設計・構築や、レスポンス遅延原因となるDB性能問題の解決など - Terraform、オブザーバビリティツールの導⼊など - CI/CDやインフラのセキュリティ周りの改善など

Slide 18

Slide 18 text

Slide 19

Slide 19 text

今年3⽉からアプリ開発メンバとして異動開発めっちゃ楽しんでる😎

Slide 20

Slide 20 text

インフラ寄りSREの時よりも⾃組織で解決できる問題が多くなっている実感がある

Slide 21

Slide 21 text

21 © Sansan, Inc. 解決できる問題が多くなったと実感できた例 - 開発グループの課題を⾃ら仕組み化して改善できた - SREとしての過去の知⾒を活かして、開発グループ内の属⼈化の回避やトイル削減に向けた仕組み作りを主導。 - 特に仕組みを作って組織を改善するスキルは汎⽤性が⾼くSREとして培ったものを活かせている感覚がある。 - テストを通じてサービス仕様を把握し、品質を⾼められるようになった - コアロジックに対するテストケースを⾃ら整理、追加。 - ユーザへの悪影響が発⽣しづらい状態を開発者として作っていけている。 - サービス間の共通課題を⾃分で⾒つけ、改善を提案・実⾏できた - 複数のサービスで不具合に繋がるJSONシリアライズの設定差異を発⾒。 - 特定チームに閉じた問題ではなく、組織横断的な課題として扱うよう提案し、全体修正が進⾏中。