SREチームの肥沼(clover0)です。少し前にSREの取り組みの紹介として、Kubernetesへ移行した基盤刷新を紹介する記事を執筆させていただきました。今回は、基盤刷新を行うにあたって、チームで日々取り組んできたことを紹介します。

SRE

はじめに、SREについて簡単に説明します。

Site Reliability Engineeringの略で、「サイト信頼性エンジニアリング」と訳されることが多いです。数年前に、いわゆるSRE本が出版されたことから、SREが広く知られるようになってきました。

SREとは何か？をめちゃめちゃざっくり説明すると、サービスの信頼性をソフトウェアを書いて担保すること、になりそうです。SREそのもののちゃんとした説明は今回は省きます。

ハウのSREチーム

SREチームという名前で活動していますが、実際のところ、信頼性を担保する部分だけではなく、プロダクト開発のスピードを維持することや、向上させるために必要なことにも取り組んでいます。

ハウのSREチームでは、冒頭にあげたSRE本に書かれていることを意識しつつも、日々改善を続けていけるようにすること、プロダクトの価値を最大化すること、を目標として活動しています。

例えば、Datadogを使った問題の発見や改善がSREチームだけでなく、開発全体としてできるように民主化を行ったり、コストコントロールやアプリケーションのパフォーマンス改善を行なったりもしています。SREがいなくてもできるようにしていくこと、SREが中心となって引っ張ること、も意識しています。

またハウのSREチームは、開発のプロジェクトごとにメンバーをアサインするスタイルではなく、プロダクト横断で担当しています。現状、プロダクトの数が多いわけではないので、SREチームとしてプロダクト開発に関わっています。こうすることで、SREのあるメンバーがプロジェクトに入って担当して終わったら戻るスタイルではなく、常にSREの誰かがやっていることはSREの他の誰かにも見えるように工夫しています。

f:id:yakiniku0:20220207142247p:plain — SREチームの関係

チームの立ち上げ

さて、紹介するSREチームですが、自分がSREチームに入ってからSREチームを再編成しています。以前は、SREを始めたが課題が多くて、チームで取り組むというより、アウトプットの量を重視して個人が諸々のピンポイントの課題に取り組んでいる状態でした。

EC2の運用からKubernetesへ移行する予定があったので、達成するために、まずはチームで取り組んでいけるようにする必要があると考えました。基盤の刷新は、ただやって終わりではなく、今後の土台となるため、通常の機能開発側の連携も必要であり、移行後は滞りなくサービスが稼働すること、移行後も運用を続けられること、が必要です。

そのため、情報共有で効率を上げたりチーム開発のレベルも上げていくことを目指し、チームで取り組んでいけるような体制を構築しました。

f:id:yakiniku0:20220207142327p:plain — 弊社SREの歴史

新生SREチーム

新しく編成し直したSREチームでは、以下のようなことをやってきました。

日々のコミュニケーション

メンバー全員、ほぼリモートだったのでSlackやZoomなどをメインにコミュニケーションを取ってきました。

もともとslackでSREチャンネルがありましたが、チームがメインで活動するチャンネルとして定義し直しました
- SREは常にここで情報を共有したり、他のチームからも依頼や相談があったりします
issueが作られたことや、コメントはslackに流れるようにしているので、だいたいここを見ていれば他のメンバーが何をやっているかが分かるようになっています
- 議論や意見、ナイスな対応など、コメントが飛び交います

slackチャンネルを複数作ったりせず、チームがどこを見ていればよいのか？をシンプルにすることで、リモートでも円滑に進めているのではないかと思います。

振り返り、SREの予定づくり

毎日15分SREチーム全員が同じところに集まること
- やったこと、やることの発表ではなく、チームとして共有しておくべきことを共有する
2週間に一度、振り返りと次の2週間の予定を立てる
- small,medium,largeのような感じで日々issueにラベル付けしているので、ラベルが付いているもので予定する

issue管理

日々、こうしたほうがいいな、こうだったらいいな、と思うことはissueとしてアウトプットする
issueに最低限書くことの簡単なルール化
- どうしてそのissueを書くことになったのか？なにをやったらよさそうか？どういう状態が終わりなのか？
GitHub Issueのラベルを明確にして、ラベル付けを丁寧にやる
- 着手する前にそもそも議論が必要なこと、急ぎの対応が必要なこと、などが分かるようにする

ドキュメンテーション

チームで苦にならず、継続できる方法を模索しながら運用しています。ざっと以下のような感じで、ドキュメントを書いたり、管理したりできるようになってきました。弊社ではドキュメント管理ツールとしてNotionを利用しています。

大事なことは書く、slackで終わりはもったいない
ドキュメントは、それが何のために書かれているのか最初に書くこと
issueに残すもの、Notionに書いておくべきものを分けて残していく
- 調査メモなど、終わったらほとんど見返さないものはissueにそのまま残しておいてもよい
- ある程度情報が多くて、まとめておきたいものはNotionに書く
  - ある時期だけ役目を果たすものと、そうでないものを区別する
  - 永続的に更新、他の人の役に立ちそうなドキュメントの配置は、アクセスしやすいように配置する
あるリポジトリ内だけで済むようなものはそのリポジトリのREADMEに書く

PR、レビュー

弊社では、プルリクエストベースで開発を行なっておりますが、PRを出してからマージできるまでに時間がかかってしまい、予定をコントロールするのが難しい状況でした。改善するために、おもに以下のようなことをやってきました。

レビューする人は、レビュー依頼出している人がなるべく速くマージできるようにしてあげることを意識する
- 直してほしいことはちゃんと指摘する
- 直してほしいけど、別のタイミングでもよければissueを作って対応を促す
レビュー依頼する人は、レビューしやすいようにPRを作る
- 自分しか持っていないと思われる知識は、説明して共有することを意識する
- PRの目的を書く
- PR外で必要なことを明記する
- コミットメッセージを分かりやすくする
  - Angularのコミットメッセージ運用を参考に整備して、運用しています
- PRで議論になりそうなことは、issueを挙げてissueで議論する