プロダクションミーティングをやってみた

これは CAMPFIRE Advent Calendar 2021 2日目の記事です。

お久しぶりです、CAMPFIRE VPoE兼SREチームマネージャーの岩崎です。今年の初めに一度はSREチームを離れたのですが、その後紆余曲折あり、VPoEとしてSREチームに戻ってくることになりました。改めてまたよろしくお願いします！

プロダクションミーティングとは

皆さんはプロダクションミーティングという言葉をご存知でしょうか。プロダクションミーティングはSRE本の後半に少しだけ出てくるのですが、開発者とSREが集まってサービスの状態を議論するミーティングを指し、ポストモーテムと並んで重要な学習プロセスの一つと考えられています。

以下はSRE本からの引用です。

しかし、私たちが行うミーティングの中で、平均以上に有益なものが一つあります。それはプロダクションミーティングと呼ばれるもので、SREチームが自分たちと他の参加者に対し、担当するサービスの状況について十分に注意を払って明確に説明をすることによって、すべての関係者の全般的な認識を高め、サービスの運用を改善するために行われます。概して、これらのミーティングはサービス指向で行われるもので、直接的に個人の状況のアップデートに関するものではありません。このミーティングが目標とするのは、ミーティングが終わった後に、進行中のことに関する全員の認識が同じになることです。プロダクションミーティングには他にも大きな目標があります。それは、サービスに対するプロダクションの知恵を持ち寄ることによって、サービスを改善することです。すなわち、サービスの運用パフォーマンスの詳細について話し合い、それを設計や設定、実装と関連づけて考え、問題解決の方法を推奨するということです。定期的なミーティングにおいて設計上の判断をサービスのパフォーマンスと合わせて考えてみることは、きわめて強力なフィードバックループになります。
（SRE サイトリライアビリティエンジニアリング 448ページ）

どうやらプロダクションミーティングでは、サービス指向であることや、サービスを改善することがポイントのようです。フィードバックループはDevOpsにおける3つの道の中の第2の道、フィードバックの原則にも通じる重要なテーマです。

CAMPFIREにおけるプロダクションミーティングの実例

これまでのCAMPFIREでは、プロダクションミーティングのような、開発チームとSREチームが同じ時間を共有して交流する場がありませんでした。これは元々両チームの距離が近く、Slack上で気軽に相談できる環境だったため、特にミーティングの場を必要としていなかったという背景があります。

個人的にもミーティングは少なければ少ないほうがいいという立場なので、そこまでプロダクションミーティングの必要性は感じていませんでした。しかし、サービスの成長に伴って様々な課題が表出するにつれ、しだいに定期的に集まって議論した方が良いという機運が高まってきました。

SREの探求でも書かれている通り、SRE本をそのまま実践することが必ずしも全ての組織にとって正解というわけではありません。SREはあくまでGoogleにおけるベストプラクティスであり、Google SREを消化した上で、それぞれの組織で独自に文化を作っていくことが大切です。

このプロダクションミーティングもSRE本の記述をベースにしつつ、CAMPFIRE独自にアレンジして運用しています。

プロダクションミーティングのアジェンダ

SRE本によると、プロダクションミーティングのアジェンダは以下になります。

・プロダクション環境において予定されている変更
・メトリクス
・障害
・ページされたイベント
・ページされなかったイベント
    - おそらくはページされるべきだったにもかかわらず、ページされなかった問題
    - ページすべきではないものの、注意を引く必要がある問題
    - ページすべきではなく、注意を引く必要もない問題
・これまでのアクションアイテム

CAMPFIREでは、上記を参考に以下のテーマでプロダクションミーティングを行なっています。

・リリース情報
・メトリクス
・不具合報告
・アラート
・話したいこと

リリース情報
「プロダクション環境において予定されている変更」同様、開発チームのリリース情報について共有します。同時にSREチームでもリリース情報があればここで共有します。

メトリクス
SRE本と同様です。CAMPFIREではモニタリングにDatadogを利用しているため、Datadogのダッシュボードを眺めています。開発チームとSREチームが一同に集まってメトリクスを確認することにより、SREチームにとっては「最近5xxエラーが増えているが何か心当たりはあるか」など開発チームも巻き込んだ深いモニタリングが可能になります。一方で、開発チームにとっては「このスロークエリを出しているメソッドを知りたい」など、アプリケーション関係のモニタリングについて気軽にSREチームに聞くことができるメリットがあります。

不具合報告
「障害」は不具合報告にしました。障害までいかない不具合や、ちょっと気になったヒヤリハットも共有したかったからです。

アラート
「ページされたイベント」と「ページされなかったイベント」はまとめてアラートとしました。Datadogのアラートや、Rollbar（アプリケーション）のアラート、バッチのアラート、スロークエリなどSlackに通知されている各種アラートについて議論します。

話したいこと
上記を踏まえた「これまでのアクションアイテム」、および他にも何か話したいことがあれば、この「話したいこと」セクションで自由に話してもらうことにしています。ここでは「これまでのアクションアイテム」以外にも幅を持たせることで、気軽に発言しやすくしています。

CAMPFIREのプロダクションミーティングは、今のところ、隔週で1時間時間を取って行っています。出席者はまだ人数が少ないこともあり、SREチームと開発チームの全員です。

SRE本にもあるように、リアルタイムかつボトムアップでアジェンダを用意できるように、CAMPFIREではnotionを活用しています（もちろん本家はGoogle Docsです！）。その意味では「リリース情報」や「話したいこと」は事前に埋めてきてもらうことが多いかもしれません。

プロダクションミーティングをやってみて

これまで数回に渡ってプロダクションミーティングをやってみた感想は、とてもワークしているということです。プロダクションミーティングを行う以前も開発チームとSREチームのコミュニケーションは円滑でしたが、今振り返ると意識していないところに見えない壁があったように思います。この見えない壁は定期的に集まって顔を合わせることで徐々に氷解し、今では様々な課題やアクションアイテムがこれまで以上に活発に議論されるようになりました。

また、当初予想していなかった嬉しい誤算の一つは、開発チームからの発言が思った以上に多いということです。SRE本からもわかるように、プロダクションミーティングの主役はあくまでSREチームです。しかし、実際にプロダクションミーティングのような開発チームとSREチームの交流の場を設けてみると、開発チームが実に様々な課題を抱えていたことがわかりました。これらの課題に対してSREチームだけが取り組むのではなく、SREチームと開発チームが相互に連携し合うことでお互いの苦手な領域を補完し、チームとしてのアフィニティ（親近感、一体感）をより高めることができました。

おわりに

以上、CAMPFIREにおけるプロダクションミーティングの取り組みでした。プロダクションミーティングはまだそれほど一般的ではありませんが、とても役に立つミーティングです。興味を持たれた方はぜひ試してみてください。

最近は忙しくてあまりこのnoteを書けていないのですが、これからも定期的にSRE関係の話題を発信していけたらと思っています。

3日目は sunada_sunada さんです！