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

202205SRE next

Transcript

1. 7年で売上40億に成長した サービスのSREチーム結 成〜運営
2. はじめに 磯崎 勢 日立系のSI会社でしばらく働いた後、2015年にミイダスの立ち上げに参画。 開発初期から現在までバックエンドエンジニア兼チーム運営としていろいろやってます。
3. ミイダスとは 運営7年目の転職サービス
4. ミイダスでは転職希望者の経歴と、性格診断のデータがあります。 性格診断では ・マネジメント気質、ヴァイタリティ、チームワーク、上司タイプ、部下タイプ などを診断しています。 サービス紹介
5. 経歴だけでなく、そういうのを使うことで、転職させて終わり、ではなく、「適材適所」を実現するためのサービ スになっています。 サービス紹介
6. 2015/8 にサービス開始 2022現在、ユーザーは累計100万人、企業も40万社ほど登録があります。 開発チームとしては70人ほどの体制。 デザイナーやインフラチーム、テストエンジニアや、 PMOなども整備して、ちゃんとした会社になりつつあるとこ ろ。 サービスの状況
7. 7年をざっと、3つの時期に分けてSRE ・サービス黎明期(10人弱ほど） ・成長期（2-3年目 20人程度）（停滞期（-5年目、40人程度)） ・成熟期（5-年目、50人程度 時期別に、SREについては、なにそれ？ という状態から、いろいろやってきたので、それを紹介できればと思っ ています。（大体失敗談ではありますが 💦 ＊ 当時〜現在までの状況をデフォルメしているので、中の人は生暖かい目で 🙏
8. 黎明期 (1年目 10人ほどの体制) とりあえずリリースはしたものの、 売上はあまりあがらず、 機能や課金形態など、ピボットが続々 品質もあまり安定していない。
9. 黎明期 運用の最適化（自動化、システム化、 etc）とかいってる場合じゃない ・毎分リリースしていたので、自動化とかは積極的にやっていた （自分が楽するためには、苦労を厭わない） ・誰が何をする、というのも明確ではなく、必要なものは誰かが片手間でやる 　＝＞廃れるものや、未メンテのツールがころがっている状態
10. 黎明期 運用の最適化（自動化、システム化、 etc）とかいってる場合じゃない ＝＞こういう時期こそちゃんとやったほうが良かったのかもしれないが、 ・ビジネスの人に「運用を考慮して」といっても通用しづらい ・また、SLIがこうなったら対策するために〜、みたいな仮定の話をしなくても、「そろそろヤバいです」で通じる ことが大事
11. 成長期 （2ｰ3年目 15人程度の開発チーム） まだまだ、赤字ではあるが、売上がなんと なく上がってきて、毎分HOTFIX、の時期は 脱した頃。 立ち上げからの技術的負債はたまっているが、新機能要求も激しい。
12. そろそろ。。 ・保守にコストをさけるようにしなければならないので、このタイミングで SLOなどの目線合わせる必要がありま すが、理解があった（というか任されていた）ので、なんとなく保守チームを結成。
13. 当初の目論見 ・大きめの開発案件とは別に、微修正を消化したい ・過去に作り込まれたバグの対応は、作り込み者が対応するのをなるべくやめる ・各プロセスを工夫したいが、まとまった時間がとれない
14. 「SREチーム」と名付ける ＝＝＞ ・開発チームの大部分を新規機能開発に集中するために、その他全部、みたいな位置づけになってしまった ・ミッションが曖昧なので、なにを優先するか、というところがコンセンがとれない ＝＞やりたいことに作業が流れがち。
15. あるあるを少し
16. リファクタリングしたい えっ、それリリースしたばかりでは。。 ＝＝＞優先度的に「今じゃない」がつづき、そして伝説へ。。
17. メンバーの士気が低くなる ・やらないといけないことをこなしながら、いろいろやってはいるが、新規機能開発にくらべて華やかさがない ・なんかうまく行っている感がうすい。
18. 感謝がほしい ・近くの困っている人の声を 優先してしまう。 ＝＞まあ悪いことではないけど、 10人のサポート部門にめっちゃ感謝されるより、 1万社の企業や、10万人の ユーザーを優先したいが、 （具体的には、課金に関わる機能 ビジネスの取れるリスクと兼ね合い）
19. 自分の仕事を減らすことにフォーカス ・管理画面に月に数回しかしないデータ補正の機能を作る （「悪いわけではないけど。。）
20. ー きちんとした目標が必要だな、とは思ったのですが、 可用性などの指標をもうけようにも、新機能を出すたびにバグがごろごろでてる状態で、保守開発ではコント ロールできない。とりあえずそのままにしておきました 💦
21. 成熟期 （５年目、50人） 売上は2桁億にまで成長し、 複数のチームが並行で開発をすすめられる体制に。 （雰囲気も変わってきた
22. SREチームはほぼ保守開発チーム。 稼働率や性能指標や品質指標を定義し始めたこともあり、 SREチームを再定義することに。
23. ２代目SREチームの目的 ・性能の維持 ・インフラコストの最適化 ・運用の自動化 （それまでのSREチームは開発チームとして再出発。（名前変更が地味にめんどう。。）
24. 目的のものを監視する体制を構築し、 指標を定め、それによってリソースを集中させることができるようにする。 ということにしました。
25. けっこうSREっぽいですよね？ それでもやっぱりいまいちで。。３つほど、困った事例を紹介します。
26. 事例１：事件 半年で稼働率目標をたてましたが、丸１日のシステム停止が発生して、取り戻せないレベルまで落ちる ＝＞しかも原因は本番での単純な作業ミス。。 ＝＞SREリソースを調整するにはあまりにも微妙な事態 ＝＝＞これはどうすればよかったんだろうか。。
27. 事例２：指標の定義 指標がどんどん複雑になっていく。。 ＝＞0.2の重要度の機能が、1時間、10%のユーザーが使えなくなったなら、 月の稼働率低下は0.0027%。。 ＝＞稼働率以外の指標も必要では？ みたいな話になる
28. 無駄なことではないが、あくまで指標は目安。ただ、議論を通して価値観が明確になった気がする。
29. 事例３：大きな問題に引っ張られる 大きな問題に直面すると、それにかかりきりになる （ロードテスト環境が必要、抜本的に改善が必要な APIがある、 とかでそちらに全リソース持っていってしまう） ＝＝＞監視と改善する担当者分けるのがいいんだろうか。。
30. 以上
31. まとめ 概念を勉強しているときには、チーム編成までシステム化される ように思えて、スマートな方法だと思っていたのですが、 まだまだ課題が山積み。。
32. まとめ ・ビジネスとの折衝が必要な場合には有効そう ＝＞保守にかけるコストと、機能開発にかけるコストのバランスは揉めがち ・開発チーム内でも ＝＞セキュリティのリスクと、性能低下によるシステム停止とどっちを優先するの、みたいな不毛な議論はしたくな い。 ＝＞SLIの設定を通じて、チームがなにを重視しているかが明確になるので、「ビジョン」や「ミッション」を補完してくれ るかもしれない。
33. 最後に ミイダスでは、SREエンジニアを募集しています。
34. 以上