こんにちは、id:onk です。
この記事は、はてなのSREが毎月交代で書いているSRE連載の3月号です。2月の記事はid:s-shiroさんの既存のDeploy Preview環境をmirage-ecsに移行する - 実装編です。
2024 年 8 月 10 日に開催された builderscon 2024 で「すこやかなサービス運営のための PWG」というタイトルで登壇してきました。
YouTube にも上がっています
この記事では、その発表内容をざっくり紹介しつつ、ふりかえりを書いてみようと思います。
PWG とは
Performance Working Group の略で、はてな社内で 10 年以上続いている取り組みです。一言で言うと「サービスの運用状況をチームで見直す月次定例会」です。
- プロダクト開発チームとインフラ / SRE チームの合同ミーティング
- 今は主に Embedded SRE という形に着地しているので、普段の生活が違うチームをまたがった会ではなくなりました
- 直近の障害や、非定型な作業履歴をふりかえる
- アラートを見直す
- ダッシュボードをみんなで眺める
- 気づいていなかった問題点を見つける
- キャパシティプランニング
といったことを、全サービスでそれぞれ月 1 回、1 時間ほどやっています。
Google の SRE 本 31 章で紹介されている「プロダクションミーティング」とも、かなり似た内容です。
PWG で実施している各アジェンダを紹介
- 直近の障害ふりかえり: 対応状況や再発防止策の確認
- 作業ログ: 手作業や臨時作業をふりかえって、根本原因や自動化の機会を探る
- アラート: 発火傾向の分析、閾値の見直し、不要なアラートの削除
- ダッシュボード: サービス状態を俯瞰し、変化を見つける。SLO も確認
- 今日話したいこと: 自由トピック
- 今後の変化共有: アクセス傾向が変わるイベント、リリースや構成変更などの予告
- 出た TODO の Issue 化: 話した内容をその場で Next Action に繋げる
- 感想/雑談: ちょっとした気づきやモヤモヤの解消。このアジェンダ自体の見直しとかも
こういった内容を月次で定点観測することで、チーム全体の運用感度が徐々に底上げされていきます。
「なんとなく気になる」について会話しているので、未然防止や自動化の種も見つかりやすくなりますし、ダッシュボードやアラート発報ルールを育てる役割も属人化しにくくなります。結果として、チームでサービスを守っている感覚が芽生えていきます。
PWG に込めたデザイン
PWG の大きな価値のひとつは、非インフラ職種にも、サービス運用の「感覚」を持ってもらうきっかけになることです。
各メトリックの意味を話す (アラートの閾値や、ダッシュボードで見るべきグラフが合ってるかの確認) ことや、障害対応や作業ログのチームでふりかえることで、サービスのシステム構成や運用背景が分かってない状態からでも徐々に理解を深めていくことができます。 また、SRE にとっては、チームに対してオーナーシップを発揮する場にもなっていて、タスクのアサインや、完了条件の合意といった、チームで進めていく力を磨ける側面もあります。
こうして毎月の定点観測を続けることで、開発チーム全体で「サービスが健全に動いているか」を判断できるようになり、その前提となる SLO にも自然と向き合えるようになります。
誰か一人/特定のロールだけが運用を担うのではなく、「チームでサービスを見て育てる」文化の一歩目として、PWG はうまく機能しているなと感じています。
あとがき
今回のトークは id:Songmu と同じく、プロポーザル落選→前日に代打の打診という形での登壇でした。
私にとって builderscon は、コロナ前からずっと参加している「知らなかった、を聞く」を体現しているイベントであり、「builders」であるヒーローたちのトークを聞きに行く場でした。今回はそんな中で登壇する機会をいただけて、大変嬉しかったです。
「PWG」という、あまり知られていないけど、サービス運用においてはてなが長年取り組んでいる取り組みを紹介しました。明日から取り入れられるテクニックがいくつかあったと思うので、少しでも持ち帰ってもらえていたら嬉しいです。
builderscon 2025 も 2024 と同じ会場で開催されるそうですね。また参加したいなぁ。
おまけ (過去の PWG に関する記事たち)
- 2015-12-19 はてなにおける日々の仕事の中にあらわれるMackerelの活用 - Mackerel ブログ #mackerelio
- これが世に出た初出かな?
- 2017-08-12 yuuk1 / Yuuki TSUBOUCHI on X: "31章"SREにおけるコミュニケーションとコラボレーション"で、平均以上に有益なミーティングの例として、プロダクションミーティングというものが挙げられていてこれははてなでやっているPWG(パフォーマンスワーキンググループ)とだいたい同じでおおってなった" / X
- 2018-03-16 SRE Lounge #2 に登壇してきた 〜Performance Working Group って何だ?〜 | by Kitano Katsuhisa | スタディスト Tech Blog
- スタディストさんに輸入されている
- 2018-06-23 Mackerelチームにおけるインフラオーナーシップ / Hatena Pepabo tech conf 4 DevOps Kyoto - Speaker Deck
- この頃は社内で「インフラオーナーシップ」がテーマになっていた。知識が無くても PWG の司会をやれば理解が深まっていく
- 2019-02-19 突撃!隣のDevOps 【はてな編】 | DevelopersIO
- 「10年ぐらい前からPWG(パフォーマンスワーキンググループ)という、プロダクト開発チームとインフラチームが月に1回改善を検討する会議を設けています。」の記述から、2010年代前半にはやっていたと思われる
- 「メトリクスをきちんと取得していることで、今まで40秒かかっていたものが20秒になった等、開発者の成果が目に見えるようになったそうです。目に見える結果が、エンジニアの評価材料にもなっているとのことでした。」評価材料としての効果があるのは面白い
- 2020-02-05 SREの異動と働き方 〜はてなブログ編〜 / Hatena Engineer Seminar #13 - Speaker Deck
- 「チームメンバーへタスクを渡す練習にもなる」が個人的には興味深い。インフラメンバーはチームに 1 人しか居ないことが多く、この人をどう開発チームに巻き込んでいくか。PWG が必要なものとされているので、PWG からコミュニケーションの形を作っていける
- 2020-10-28 SREはインフラ担当だけでなくチーム全体で取り組んでいくもの | はてなで働く cohalz にアンケート [#9] - Hatena Developer Blog
- 「PWG(Performance Working Group)などのタイミングでチームメンバーが見逃していた課題を見つけるということもやっています。」
- これ面白くて、PWG をチームで運営している中で、ダッシュボードに置いていない他のグラフに何か特徴が出ていないかを探す内職をしている。自分が司会しなくても良い状況を作った上で、専門性を発揮している
- 2021-12-11 Mackerel での Mackerel による Mackerel のための Performance Working Group #Mackerel - Qiita
- 「今では Google Meets の ブレイクアウトルームを利用し, まず全員での情報共有と SLO などを全員で見ておきたいダッシュボードを確認してから各チームに分けています. チームごとにパフォーマンス確認を行う対象が決められており, メンバーは毎回ランダムで決めています. チームごとに確認後, 合流して確認したことの共有をしています.」
- チームやシステムが大きくなっても、PWG は運用できるようになっている
- PWG で「もうちょっと調査しないと分からない」となった内容の調査 Issue を切るのが自然になっている様子も分かる
- 2022-12-02 Mackerelを振り返りやキャパシティプランニングのために毎月眺めている - stefafafan の fa は3つです
- PWG は最初は「Dev と Ops とが会話する場」だったのだけれど、この頃にはインフラのオーナーシップをチームで持てるようになっている。
- アジェンダにある「今回出てきたTODOをissueとして登録」という項目がかなり好きで、定期検診が良い棚卸しになっているなぁと思う。
- 2023-11-15 SRE座談会 - 採用情報 - 株式会社はてな
- PWG はシステムのキャッチアップに効く。ポストモーテム読書会も似た効果がありそう
- 2023-12-06 ノンエンジニアのためのMackerel活用術 - ミネムラ珈琲ブログ
- PO ロールの人間が PWG に参加している効果