この記事はSRE Advent Calendar 11日目のエントリです。

プロダクト SREとしてどんな業務をしているのか

あまりインターネットでプロダクトSREの記事が出てこないので、今日はこのことについて改めてまとめておこうと思います。

SREというと、基盤開発や自動化、パフォーマンスチューニングなどが想像しやすいので、プロダクトSREはちょっとわかりづらいです。特にPlatform SREが別にいる場合、じゃあ一体何をするんだという感覚にもなりやすいかもしれないです。

この内容はあくまで筆者が所属する組織での例です。SREは各組織で独自発達するものであり、必ずしもすべての組織には当てはまりません。

あなた誰

VTRyoです。初めてましての人はこんにちは。

これまでインフラエンジニアだったりPlatform SREをやってきました。今の会社ではプロダクトSREとして、基盤ではなくプロダクトの信頼性にフォーカスして業務をしています。

Platformもやっていた時の話はこちらです。※本題からそれる

プロダクトSREになってからはこちらです。

筆者が所属する組織に関する前提

SREと呼ばれる職種が3種類あります。その時点で人材が潤沢であることは否めません。
なお僕自身も、これほどSREの役割が分かれている組織は初めてです。

よって、このようにSREの役割を細かく分業できない場合は「ひとつの役割側面」として読み替えていただければ幸いです。この考え方は分業していないSRE組織でも当てはまる部分はあるはずです。

プロダクトチームとの関わり方

自部署でのSREミッションは「ソフトウェアエンジニア自身がSREプラクティスを実施できるように支援と先導をする」ことです。これは、SREが運用作業のすべてを巻き取ったりしないことを意味しています。弊社の開発文化はスモールチーム開発であり、今後もたくさんのプロダクト開発チームが部署内でも生まれることが予測できるため、確実にSREの人数は足りません。常にプロダクト数がSREの人数を上回ると推測しています。

そのような状態で信頼性を担保し続けるには、プロダクトを開発しリリースした本人がSREプラクティスを自然と実施できている状態をつくることだと考えています。人が入れ替わってもそのチームの文化として存在していれば人に依存する確率は下がります*1。

ところがSRE自体にも役割分担がされていて、なおかつプロダクトチームの運用を全て巻き取るという体制でもないとなると、ではどのような立ち位置にいるのか疑問だと思います。

これはGoogle SREがブログで書いていた内容を踏襲する形で運用しています。

Google SRE’s mission is to:

Ensure that Google’s products and infrastructure meet their availability targets.

Subject to (1), maximize long-term feature velocity.

Use software rather than human toil to accomplish (1) and (2).

Engage only when (1) through (3) are accomplished more efficiently by SRE than developers.

How Google SRE and Developers Collaborate - IT Revolution

プロダクトSREもプロダクトチームも、信頼性目標を達成するために業務をします。その際、SREが担当したほうが効率がよいと判断した場合に関与する体制にしました。

役割が分かれているからといって、ある分野の知識が不要かというとそうでもない

例えば弊組織では、EKS Cluster自体の構築はPlatform SREが作り上げました。プロダクトチームはそのPlatform上にアプリケーションを構築する（k8s manifestを書くあたりの作業）だけです。しかし、ではEKSの知識がなくてもいいのかというとそうでもない（アプリケーションエンジニアはまだヨシとしても、そこに配属するプロダクトSREは知っておいたほうが良い）でしょう。

プロダクトに適用するk8s manifestをコピペするならまだしも、コピペするだけなら誰でもできるので専門家である必要はないです。

当然ですが、プロダクトにとって最適であるかを判断するためにPlatform系の知識も総動員することになります。また、Platform SREとの橋渡し役になる場合もあるため共通の知識があったほうが活躍はしやすい状態です。

今の主なスタック。徐々に抽象的に。

AWS（Webサービス運用に関連する主要なリソース）
Kubernetes
Terraform
Monitoring tool（Datadog, Rollbar, etc）
CI/CD（CircleCI, GitHub Actions）
Application関連（使用されている言語, フレームワーク, etc）
障害対応経験

というわけで、ここまでが弊組織での話でした。以降は分業制がなくても、役割として持てる内容についてです。

以下、優先度は順不同です。

Monitoring

監視はサービスがユーザに届いている以上は、終わりも完成もない業務といえます。
サービス監視体制が整っていない場合は次のことをやったりします。

SLOの策定はSREが先導した方が効率的でした。概念の解説やワークショップを通じて共に設定していきました。

SLO/SLIの策定・改定
- 信頼性の可視化。数値ベースで意思決定するための準備
システムリソース
- アプリケーションが何にどれくらいリソースを使用しているのか（この場合、コンテナリソースやRDBのリソース）可視化
サービス状況
- アプリケーションパフォーマンスの可視化。レイテンシやエラーレートといったWork Metircs
エラー通知整備
- 異変を察知するために設定したはずのエラーが無駄に飛んできて集中力を阻害している場合、どう通知するかを再検討する
Datadogを使ってサービス状況をふりかえる
- 週イチでプロダクトチームメンバーがふりかえっています。最初は私も参加していましたが、徐々にプロダクトチーム主導となりました。SREチームは別途、Datadogを見るMTGを実施しています