6年で売上40億に成長したサービスのSREチーム結成〜運営

by isozakisei

Slide 1

Slide 1 text

7年で売上40億に成長したサービスのSREチーム結成〜運営

Slide 2

Slide 2 text

はじめに磯崎勢日立系のSI会社でしばらく働いた後、2015年にミイダスの立ち上げに参画。開発初期から現在までバックエンドエンジニア兼チーム運営としていろいろやってます。

Slide 3

Slide 3 text

ミイダスとは運営7年目の転職サービス

Slide 4

Slide 4 text

ミイダスでは転職希望者の経歴と、性格診断のデータがあります。性格診断では・マネジメント気質、ヴァイタリティ、チームワーク、上司タイプ、部下タイプなどを診断しています。サービス紹介

Slide 5

Slide 5 text

経歴だけでなく、そういうのを使うことで、転職させて終わり、ではなく、「適材適所」を実現するためのサービスになっています。サービス紹介

Slide 6

Slide 6 text

2015/8 にサービス開始 2022現在、ユーザーは累計100万人、企業も40万社ほど登録があります。開発チームとしては70人ほどの体制。デザイナーやインフラチーム、テストエンジニアや、 PMOなども整備して、ちゃんとした会社になりつつあるところ。サービスの状況

Slide 7

Slide 7 text

7年をざっと、3つの時期に分けてSRE ・サービス黎明期(10人弱ほど）・成長期（2-3年目 20人程度）（停滞期（-5年目、40人程度)）・成熟期（5-年目、50人程度時期別に、SREについては、なにそれ？という状態から、いろいろやってきたので、それを紹介できればと思っています。（大体失敗談ではありますが 💦 ＊当時〜現在までの状況をデフォルメしているので、中の人は生暖かい目で 🙏

Slide 8

Slide 8 text

黎明期 (1年目 10人ほどの体制) とりあえずリリースはしたものの、売上はあまりあがらず、機能や課金形態など、ピボットが続々品質もあまり安定していない。

Slide 9

Slide 9 text

黎明期運用の最適化（自動化、システム化、 etc）とかいってる場合じゃない・毎分リリースしていたので、自動化とかは積極的にやっていた（自分が楽するためには、苦労を厭わない）・誰が何をする、というのも明確ではなく、必要なものは誰かが片手間でやる　＝＞廃れるものや、未メンテのツールがころがっている状態

Slide 10

Slide 10 text

黎明期運用の最適化（自動化、システム化、 etc）とかいってる場合じゃない＝＞こういう時期こそちゃんとやったほうが良かったのかもしれないが、・ビジネスの人に「運用を考慮して」といっても通用しづらい・また、SLIがこうなったら対策するために〜、みたいな仮定の話をしなくても、「そろそろヤバいです」で通じることが大事

Slide 11

Slide 11 text

成長期（2ｰ3年目 15人程度の開発チーム）まだまだ、赤字ではあるが、売上がなんとなく上がってきて、毎分HOTFIX、の時期は脱した頃。立ち上げからの技術的負債はたまっているが、新機能要求も激しい。

Slide 12

Slide 12 text

そろそろ。。・保守にコストをさけるようにしなければならないので、このタイミングで SLOなどの目線合わせる必要がありますが、理解があった（というか任されていた）ので、なんとなく保守チームを結成。

Slide 13

Slide 13 text

当初の目論見・大きめの開発案件とは別に、微修正を消化したい・過去に作り込まれたバグの対応は、作り込み者が対応するのをなるべくやめる・各プロセスを工夫したいが、まとまった時間がとれない

Slide 14

Slide 14 text

「SREチーム」と名付ける＝＝＞・開発チームの大部分を新規機能開発に集中するために、その他全部、みたいな位置づけになってしまった・ミッションが曖昧なので、なにを優先するか、というところがコンセンがとれない＝＞やりたいことに作業が流れがち。

Slide 15

Slide 15 text

あるあるを少し

Slide 16

Slide 16 text

リファクタリングしたいえっ、それリリースしたばかりでは。。＝＝＞優先度的に「今じゃない」がつづき、そして伝説へ。。

Slide 17

Slide 17 text

メンバーの士気が低くなる・やらないといけないことをこなしながら、いろいろやってはいるが、新規機能開発にくらべて華やかさがない・なんかうまく行っている感がうすい。

Slide 18

Slide 18 text

感謝がほしい・近くの困っている人の声を優先してしまう。＝＞まあ悪いことではないけど、 10人のサポート部門にめっちゃ感謝されるより、 1万社の企業や、10万人のユーザーを優先したいが、（具体的には、課金に関わる機能ビジネスの取れるリスクと兼ね合い）

Slide 19

Slide 19 text

自分の仕事を減らすことにフォーカス・管理画面に月に数回しかしないデータ補正の機能を作る（「悪いわけではないけど。。）

Slide 20

Slide 20 text

ーきちんとした目標が必要だな、とは思ったのですが、可用性などの指標をもうけようにも、新機能を出すたびにバグがごろごろでてる状態で、保守開発ではコントロールできない。とりあえずそのままにしておきました 💦

Slide 21

Slide 21 text

成熟期（５年目、50人）売上は2桁億にまで成長し、複数のチームが並行で開発をすすめられる体制に。（雰囲気も変わってきた

Slide 22

Slide 22 text

SREチームはほぼ保守開発チーム。稼働率や性能指標や品質指標を定義し始めたこともあり、 SREチームを再定義することに。

Slide 23

Slide 23 text

２代目SREチームの目的・性能の維持・インフラコストの最適化・運用の自動化（それまでのSREチームは開発チームとして再出発。（名前変更が地味にめんどう。。）

Slide 24

Slide 24 text

目的のものを監視する体制を構築し、指標を定め、それによってリソースを集中させることができるようにする。ということにしました。

Slide 25

Slide 25 text

けっこうSREっぽいですよね？それでもやっぱりいまいちで。。３つほど、困った事例を紹介します。

Slide 26

Slide 26 text

事例１：事件半年で稼働率目標をたてましたが、丸１日のシステム停止が発生して、取り戻せないレベルまで落ちる＝＞しかも原因は本番での単純な作業ミス。。＝＞SREリソースを調整するにはあまりにも微妙な事態＝＝＞これはどうすればよかったんだろうか。。

Slide 27

Slide 27 text

事例２：指標の定義指標がどんどん複雑になっていく。。＝＞0.2の重要度の機能が、1時間、10%のユーザーが使えなくなったなら、月の稼働率低下は0.0027%。。＝＞稼働率以外の指標も必要では？みたいな話になる

Slide 28

Slide 28 text

無駄なことではないが、あくまで指標は目安。ただ、議論を通して価値観が明確になった気がする。

Slide 29

Slide 29 text

事例３：大きな問題に引っ張られる大きな問題に直面すると、それにかかりきりになる（ロードテスト環境が必要、抜本的に改善が必要な APIがある、とかでそちらに全リソース持っていってしまう）＝＝＞監視と改善する担当者分けるのがいいんだろうか。。

Slide 30

Slide 30 text

以上

Slide 31

Slide 31 text

まとめ概念を勉強しているときには、チーム編成までシステム化されるように思えて、スマートな方法だと思っていたのですが、まだまだ課題が山積み。。

Slide 32

Slide 32 text

まとめ・ビジネスとの折衝が必要な場合には有効そう＝＞保守にかけるコストと、機能開発にかけるコストのバランスは揉めがち・開発チーム内でも＝＞セキュリティのリスクと、性能低下によるシステム停止とどっちを優先するの、みたいな不毛な議論はしたくない。＝＞SLIの設定を通じて、チームがなにを重視しているかが明確になるので、「ビジョン」や「ミッション」を補完してくれるかもしれない。