すこやかなサービス運営のための PWG (Performance Working Group)

2024-08-10 builderscon 2024

Transcript

1. すこやかなサービス運営の ためのPWG id:onk 2024-08-10 builderscon 2024 1
2. 自己紹介 • 大仲 能史 a.k.a. id:onk • 芸歴20年目 • 株式会社はてな ◦ チーフエンジニア ◦ Mackerel 開発チーム 2
3. 3 今日の話
4. 4 PWG
5. 5 はてなで運用している Performance Working Group の話をします
6. アジェンダ • PWGとは • 何をやっているか • どんな組織になるか • まとめ 6
7. 7 PWGとは
8. PWGとは • Performance Working Groupの略 • 2009年辺りから開催している • プロダクト開発チームとインフラチームが 月に1回改善を検討する会議 8
9. PWGとは 9 https://mackerel.io/ja/blog/entry/advent-calendar2015/day19
10. PWGとは 10 https://x.com/yuuk1t/status/896098691416694786
11. SRE本 31章 11
12. SRE本 31章 12 私たちが行うミーティングの中で、平均以上 に有益なものが一つあります。それはプロダ クションミーティングと呼ばれるもので、 SREチームが自分たちと他の参加者に対し、 担当するサービスの状況について十分に注意 を払って明確に説明をすることによって、す べての関係者の全般的な認識を高め、サービ スの運用を改善するために行われます。
13. SRE本 31章 13 定期的なミーティングにおいて設計上の判断 をサービスのパフォーマンスと合わせて考え てみることは、きわめて強力なフィードバッ クループになります。
14. SRE本 31章 14 • プロダクション環境において予定されてい る変更 • メトリクス • 障害 • ページされたイベント • ページされなかったイベント • これまでのアクションアイテム
15. 2018年頃のPWGの目的 • パフォーマンス等が悪くなっていないか チェックする機会を定期的に設ける • エンジニアリング面で気になっていることを 雑談する場を定期的に設ける • SREチームとコミュニケーションする場を〜 • 直近のイベント等をSREチームにも共有する 15
16. 最近のはてなのプロダクト開発チーム • Embedded SRE ◦ プロダクト開発チームにSREも所属 • 一緒にイテレーションを回す ◦ 一緒にデイリーミーティング ◦ 同じバックログにタスクが並んでいる 16
17. Embedded SREが居るPWG • 同じチームなので「予定されている変更」の 共有は必要なくなっている • Webアプリケーションエンジニアもアラート を一緒に受け取っているので共有目的は薄い • 定点観測とふりかえりの意味合いが強い 17
18. アジェンダ • PWGとは • 何をやっているか • どんな組織になるか • まとめ 18
19. PWGの開催頻度と出席者 • 月次開催、1時間枠 • 出席者 ◦ 必須: SREs ◦ 必須: バックエンドのテックリード ◦ 任意: アプリケーションエンジニア ◦ 任意: プロダクトオーナー 19 必須メンバーが揃わない場合はリスケする
20. PWGでの役割 • 司会 ◦ 画面を写す ◦ 進行 ▪ 話題ごとに適切な人に話 を振る • 書記 ◦ 会話した内容を議事録 (共同編集可) に書き記す 20 • その他みんな ◦ 答えたり質問したり ▪ 初心者大歓迎 ◦ 書記が書き逃したこと を書く ◦ 気になりがあったら書 く ▪ 事前記入大歓迎
21. PWG議事録 21 • 共同編集 ◦ 一人では議事録を書きき れない • 会話内容を残していく • どんどんURLや画像を 貼っていく
22. PWGのアジェンダ • 障害ふりかえり • 作業ログ • アラート • ダッシュボード 22 • 今日話したいこと • 今後の変化共有 • 出たTODOのIssue化 • 感想/雑談
23. 障害ふりかえりコーナー • 最近起きた障害とポストモーテムを眺める • 実施できていない根本対応について会話 • 一部のコンポーネントに障害が偏っていない かを俯瞰できるかも 23
24. 作業ログコーナー • 障害ではないが非定型な作業ログを眺める • 非定型作業はヒヤリハットであることが多い • 同じことを複数回やっているならトイル ◦ 自動化可能か、根絶可能かを考える 24
25. アラート確認コーナー • Mackerelのアラート一覧を眺める ◦ それぞれがなぜ発生しているのかを話す • 対応していないアラートがあったら ◦ そもそも不要なアラートじゃないか会話する ◦ その場で閾値を変えたり、監視ごと消したり • 頻出しているアラートがあったら ◦ 必要なアラートなら根本対応を検討する 25
26. ダッシュボード確認コーナー • Mackerelのカスタムダッシュボードを眺める ◦ PWG用のダッシュボードがある ◦ サービスのメトリックが並んでいるだけではないし、 障害対応用のものとも別 • 気になるグラフの変化についてみんなで話す ◦ Mackerelのグラフアノテーションも活用する 26
27. ダッシュボード確認コーナー 27
28. PWGのアジェンダ • 障害ふりかえり • 作業ログ • アラート • ダッシュボード 28 • 今日話したいこと • 今後の変化共有 • 出たTODOのIssue化 • 感想・雑談
29. PWGのアジェンダ 29 • 今日話したいこと ◦ なんか気になってることが集まってくる ◦ 特に無いこともある • 今後の変化共有 ◦ 大型のキャンペーンがあってアクセスが増えるとか ◦ インフラ構成を変える予定とかEOLとか
30. • 出たTODOのIssue化 ◦ Issueにして終わる ◦ その場で書き切れなかったら書く人をアサインする ◦ Issueの優先度はリファインメント時に相談 • 感想・雑談 ◦ 会のアジェンダ自体もどんどん変えていく ◦ 議事録に置いておくとフンワリした話題を拾いやすい PWGのアジェンダ 30
31. • コスト ◦ コスト変化もメトリック • SLO見直し ◦ 定期的にPOとのミーティングを行う ◦ 月次の会があるなら乗っかるか？ PWGのその他のアジェンダ 31
32. アジェンダ • PWGとは • 何をやっているか • どんな組織になるか • まとめ 32
33. POが参加している • 数字の変動要因をより知っている ◦ サービス内のイベントや変化 ◦ 数字の変化が予期されたものか、一時的か恒久的か ◦ 例: CM放映による新規ユーザー増加とその影響 • 未来の見通しも議論可能 ◦ 利用状況のトレンドや今後の開発予定を共有 ◦ スケールアップ等の対応を判断 33 https://www.minemura-coffee.com/entry/2023/12/06/194050
34. SLOがちゃんと運用される 34 • SLOを達成しているか ◦ PO、SRE、開発チームの全員が居る場で確認 ◦ 違反していたらアクションを取る • SLOは定期的に見直すもの ◦ SLOや違反時のアクションを定めたドキュメントには revisit dateがある
35. • チームの一員とはいえ職種が違うと壁はある • チームメンバーにタスクを振る練習ができる ◦ PWGはSREsがオーナーシップを持ちやすい場なの で、進めていく意識を持ちやすい ◦ その場でIssue化する流れの中で、解決したい時期を 決めたり、完了条件を決めたりしていく SREsのソフトスキル向上 35
36. • PWGを介して解像度が上がる ◦ どんなアーキテクチャで動いているのか ◦ 誰がどんな立場で発言しているか ◦ 障害やアラート、ダッシュボードを一緒に読む機会 オンボーディング 36
37. 感度の高い非インフラエンジニアの育 成 • 何のためにこのメトリックを見ているのか ◦ コンポーネント間の繋がり ◦ 異常系のときにどういう動きをするのか • このメトリックはどう変わると危ないのか ◦ 上限が1000であることを知らないと、 10->100の変化にビビって慌てて調査してしまう 37 https://www.minemura-coffee.com/entry/2023/12/06/194050
38. • 障害時に本来鳴るべきアラートが鳴っていな いならおかしい • 検知できるよう、監視を追加する • ポストモーテム作成時に考えるものだが、 漏れていたらPWGで会話する 必要な監視を増やす 38
39. • 不要なアラートの棚卸し • 一度追加した監視は削除するのが困難である • 「このアラートいつも無視してるよね」 • オオカミ少年アラートを許さない 監視条件をその場で変える 39
40. 意思決定できる監視/ダッシュボード • 「情報」は意思決定と行動を促すものである • この原則に向き合って、監視を設計する ◦ runbookを書けない監視は存在しない • ダッシュボードも同様 ◦ これが分かったら何が言えるのか、を一つずつ確認 ◦ システムメトリックはダッシュボードには不要 40
41. • Embedded SREじゃない場合 ◦ 運用を助けてくれるインフラ組織がプロダクト開発 チームの近くに居るはず • キックオフやデイリーには居ないことが多い ので、PWGで情報を流す インフラ組織と会話する場 41
42. 42 まとめ
43. まとめ 43 • PWGを行うことで、チーム全員の認識が揃う ◦ SLO、各コンポーネントの強弱、最近の傾向 • ダッシュボードをみんなで見る ◦ 継続して見ているだけで解像度が上がっていく • ダッシュボードや監視が、育てていくものに ◦ 特定の人/職種じゃなく、チームで育てていく • チームでSLOや監視と向き合おう