Hirosaji Tech Blog 🍙

Web開発の記事が多め。絵師支援の記事も少し。

トップ > その他 > SREではないけど SRE NEXT 2022 を観て

SREではないけど SRE NEXT 2022 を観て

その他

先週末、オンライン開催のSRE NEXT 2022に視聴者として参加しました。

今回は、参加した動機と全体を通しての学びをまとめました。

イベント概要

  • 概要：SRE Practiceに関心を持つ人のためのカンファレンス
  • 日時：2022年5月14日（土）～ 2022年5月15日（日）
  • 会場：オンライン（ZOOM）
  • テーマ：SRE DIVERSITY
  • 公式 HP：https://sre-next.dev/2022/

参加した動機＆全体を通しての学び

私はSREではなく、SREからサポートを受ける開発チームに所属するサーバサイドエンジニアです。
ここ最近、SREが請け負ってくれる仕事の線引きが曖昧に感じたので、今回はその境界線を判断できるようになるため、各セッションを視聴しました。

全体のセッションを通してみると、SREはサポートする開発チームに常駐すべきではなく、そのチームが自律的に信頼性を高める行動を取れるようになるまで一時的に支援すべき、という一つの結論を述べるプラクティスが多かったと感じます。

例えばメルカリ社は、開発チームがSREチームに依存しすぎないよう、サポート先をローテーションしているそうです。

ただ、期間内に十分なサポートをすることができなかったこともあり、その際はサポート期間を延長するといった対応が必要だったとのこと。

また、サポート不足に関連した別の失敗例もあります。
例えば、スタディサプリの事例を紹介した @chaspy さんのセッションにて。

SLI/SLOを策定したが、SLO違反の際に開発チームが適切な行動ができなかった、との失敗例をあげていました。
これは取るべき意思決定に必要な権限や予算、そして関係者の理解が足りなかったために起こってしまったと述べていました。

この対策として、 @chaspy さんは信頼性を重要な事業戦略の一つに組み込むべく組織改革をしたり、草の根活動で文化醸成をしたりしているそうです。

つまり、ここで私が得たかった結論として、
「いつまでも、あると思うな、SREサポート」（字余り）
ということをサポートを受ける側は胸に刻んでおかないといけないなぁ、と思いました。

特にSLO違反やインシデント発生時のトリアージ、エスカレーション、アサインは開発チーム内で自律的にできるようにならなければと思います。
そのための基盤づくりや指標選びの相談はSREに頼ってもいいが、それらを運用で使うのは俺たちだぞ、というマインドでSREと付き合っていくのが健全だろうと、私は結論付けました。

SRE NEXT 2022、参加してよかったです。
むしろ、私のような開発チームに身を置くエンジニアこそ参加すべきだなぁ、と今になって思います。

おまけ

現時点で、各セッションの動画は公開されていないようです。 ただ個別に共有されたスライドを、こちらの方がまとめてくれていました。

もし参加できなかった、または観たいセッションを見逃したという方がいたら、こちらからスライドだけでも覗きにいくと良いと思います。