プロダクションミーティングをはじめた話
shigwataはじめに
こんにちは。株式会社 Belong で SRE をしている shigwata です。
今回は、チーム間のコミュニケーション改善のためにはじめた、プロダクションミーティングという取り組みについて紹介します。
プロダクションミーティングとは
プロダクションミーティングは、プロダクションの状況と運用に関する情報共有を目的としたミーティングです。 通常、エンジニアや SRE など、サービスに深く関わるメンバーが参加します。 このミーティングは、サービス指向で情報を共有し、サービスの問題の発見、改善、協力する場を提供します。 定期的にミーティングを行うことで、フィードバックループを作り、サービスの改善を促します。
プロダクションミーティングについては SRE 本1に詳しく書かれています。
プロダクションミーティングのアジェンダ
以下に、プロダクションミーティングの基本的なアジェンダについて紹介します。 こちらのアジェンダは、SRE 本から引用させて頂いております。
- プロダクション環境において予定されている変更
- メトリクス
- 障害
- ページ2されたイベント
- ページされなかったイベント
- おそらくはページされるべきだったにもかかわらず、ページされなかった問題
- ページすべきではないものの、注意を引く必要がある問題
- ページすべきではなく、注意を引く必要もない問題
- これまでのアクションアイテム
1. プロダクション環境において予定されている変更
予定されている変更について、プロダクションミーティングで共有することで、変更による影響を事前に知ることができます。
2. メトリクス
SLI などの主要なメトリクスを用いてシステムのパフォーマンスを評価し、時間の経過とともに変化する負荷を監視することが重要です。また、リソースの使用状況と効率を追跡することもシステム変更の評価に役立ちます。
3. 障害
過去の障害やエラーについて分析し、原因と対策について議論します。これにより、将来の障害を予防し、信頼性を向上させる方策が練られます。
4. ページされたイベント
ページのされ方は適切だったのか、そもそもページされるべきだったのかを議論します。
5. ページされなかったイベント
-
おそらくはページされるべきだったにもかかわらず、ページされなかった問題
この場合は、モニタリングシステムを修正します。
-
ページすべきではないものの、注意を引く必要がある問題
ユーザに直接影響はないが、将来的に問題になる可能性がある場合は、モニタリングシステムを修正します。
-
ページすべきではなく、注意を引く必要もない問題
この場合は、ノイズになるため、モニタリングシステムを修正します。
6. これまでのアクションアイテム
これまでのプロダクションミーティングで議論されたアクションアイテムやタスクの進捗状況を確認し、責任を明確化します。
なぜプロダクションミーティングをはじめたのか
もともと Belong では、毎週エンジニア全員参加のミーティングでリリース情報の共有を行っています。 このミーティングのリリース情報の共有は、すでに決まっている直近のリリースに関しての情報共有のみにフォーカスしていました。 この情報をもとに、SRE チームは各プロダクトのメトリクスに関してモニタリングしていましたが、プロダクトで将来予定されている変更を事前に知ることができないため、変更による影響を事前に発見することができませんでした。 そこで、SRE 本に記載のあるプロダクションミーティングを導入し、プロダクト開発チームと SRE チームが定期的なコミュニケーションをする場を作ることで、上記のことを改善することができるのではないかと考えました。
また、メトリクスの確認は、SRE チームのみで行っているため、プロダクト開発チーム全員がメトリクスについて詳細を知っているわけではありませんでした。 こちらもプロダクションミーティングを行うことで、システムのパフォーマンスや運用状況を示すメトリクスについてプロダクト開発チームと議論することができ、システムの健全性に関する共通認識を得ることができるのではないかと考えました。
プロダクションミーティングの実施
現在 Belong では、プロダクトごとに隔週で 30 分間プロダクションミーティングを実施しています。
参加者は、プロダクト開発チームの代表数人と SRE チームです。
ミーティングノートには Google Docs を利用しています。 事前にアジェンダを共有し、アジェンダに追加したい項目があれば追加してもらっています。 上記のアジェンダ以外にも SRE への相談やトイルの収集なども行っています。
やってみて
Belong のエンジニアチームの距離は近く、 Slack 上でも情報共有ができていたため、プロダクションミーティングをはじめても有効な効果が得られるのか確信が得られませんでした。 しかし、プロダクションミーティングという場を作りはじめてから 2 ヶ月ほど経過しましたが下記のようなメリットがありました。
- Slack では、わざわざ話題にしないレベルだが困っていることを吸い出すことができた
- 早期に変更予定を知ることにより設計へのフィードバックができた
- 予定されている変更を知ることで、将来を見据えたメトリクスやアラートの見直しができた
- プロダクト開発チームにもメトリクスを意識した開発ができるようになった
- プロダクト開発チームと SRE チームの距離が近くなった
- 共通認識が増え、サービスへの理解が深まった
- ページされたイベントを確認することで運用手順の改善に繋がった
ただ、チームによっては受け持つサービスが多く、プロダクションミーティングが時間内で終わらないこともありました。 その場合、チームを分割したり、時間を延長するなどの工夫が必要になってくると思います。 アジェンダもチームに合うように調整が必要になってくるかもしれません。
おわりに
今回は、Belong がはじめたプロダクションミーティングという取り組みについて紹介しました。 SRE チームとプロダクト開発チームの距離が遠い場合は、プロダクションミーティングをはじめることで、コミュニケーションのきっかけになるのではないかと思います。
まだまだ改善の余地はありますが、今後も継続していきたいと思います。
また弊社 Belong では SRE の実践に興味のある方を募集しています。 もし弊社に興味を持っていただけたら <エンジニアリングチーム紹介ページ> をご覧いただけたら幸いです。