Tweet
Tweet

Slide 1

Slide 1 text

すこやかなサービス運営の ためのPWG id:onk 2024-08-10 builderscon 2024 1

Slide 2

Slide 2 text

自己紹介 ● 大仲 能史 a.k.a. id:onk ● 芸歴20年目 ● 株式会社はてな ○ チーフエンジニア ○ Mackerel 開発チーム 2

Slide 3

Slide 3 text

3 今日の話

Slide 4

Slide 4 text

4 PWG

Slide 5

Slide 5 text

5 はてなで運用している Performance Working Group の話をします

Slide 6

Slide 6 text

アジェンダ ● PWGとは ● 何をやっているか ● どんな組織になるか ● まとめ 6

Slide 7

Slide 7 text

7 PWGとは

Slide 8

Slide 8 text

PWGとは ● Performance Working Groupの略 ● 2009年辺りから開催している ● プロダクト開発チームとインフラチームが 月に1回改善を検討する会議 8

Slide 9

Slide 9 text

PWGとは 9 https://mackerel.io/ja/blog/entry/advent-calendar2015/day19

Slide 10

Slide 10 text

PWGとは 10 https://x.com/yuuk1t/status/896098691416694786

Slide 11

Slide 11 text

SRE本 31章 11

Slide 12

Slide 12 text

SRE本 31章 12 私たちが行うミーティングの中で、平均以上 に有益なものが一つあります。それはプロダ クションミーティングと呼ばれるもので、 SREチームが自分たちと他の参加者に対し、 担当するサービスの状況について十分に注意 を払って明確に説明をすることによって、す べての関係者の全般的な認識を高め、サービ スの運用を改善するために行われます。

Slide 13

Slide 13 text

SRE本 31章 13 定期的なミーティングにおいて設計上の判断 をサービスのパフォーマンスと合わせて考え てみることは、きわめて強力なフィードバッ クループになります。

Slide 14

Slide 14 text

SRE本 31章 14 ● プロダクション環境において予定されてい る変更 ● メトリクス ● 障害 ● ページされたイベント ● ページされなかったイベント ● これまでのアクションアイテム

Slide 15

Slide 15 text

2018年頃のPWGの目的 ● パフォーマンス等が悪くなっていないか チェックする機会を定期的に設ける ● エンジニアリング面で気になっていることを 雑談する場を定期的に設ける ● SREチームとコミュニケーションする場を〜 ● 直近のイベント等をSREチームにも共有する 15

Slide 16

Slide 16 text

最近のはてなのプロダクト開発チーム ● Embedded SRE ○ プロダクト開発チームにSREも所属 ● 一緒にイテレーションを回す ○ 一緒にデイリーミーティング ○ 同じバックログにタスクが並んでいる 16

Slide 17

Slide 17 text

Embedded SREが居るPWG ● 同じチームなので「予定されている変更」の 共有は必要なくなっている ● Webアプリケーションエンジニアもアラート を一緒に受け取っているので共有目的は薄い ● 定点観測とふりかえりの意味合いが強い 17

Slide 18

Slide 18 text

アジェンダ ● PWGとは ● 何をやっているか ● どんな組織になるか ● まとめ 18

Slide 19

Slide 19 text

PWGの開催頻度と出席者 ● 月次開催、1時間枠 ● 出席者 ○ 必須: SREs ○ 必須: バックエンドのテックリード ○ 任意: アプリケーションエンジニア ○ 任意: プロダクトオーナー 19 必須メンバーが揃わない場合はリスケする

Slide 20

Slide 20 text

PWGでの役割 ● 司会 ○ 画面を写す ○ 進行 ■ 話題ごとに適切な人に話 を振る ● 書記 ○ 会話した内容を議事録 (共同編集可) に書き記す 20 ● その他みんな ○ 答えたり質問したり ■ 初心者大歓迎 ○ 書記が書き逃したこと を書く ○ 気になりがあったら書 く ■ 事前記入大歓迎

Slide 21

Slide 21 text

PWG議事録 21 ● 共同編集 ○ 一人では議事録を書きき れない ● 会話内容を残していく ● どんどんURLや画像を 貼っていく

Slide 22

Slide 22 text

PWGのアジェンダ ● 障害ふりかえり ● 作業ログ ● アラート ● ダッシュボード 22 ● 今日話したいこと ● 今後の変化共有 ● 出たTODOのIssue化 ● 感想/雑談

Slide 23

Slide 23 text

障害ふりかえりコーナー ● 最近起きた障害とポストモーテムを眺める ● 実施できていない根本対応について会話 ● 一部のコンポーネントに障害が偏っていない かを俯瞰できるかも 23

Slide 24

Slide 24 text

作業ログコーナー ● 障害ではないが非定型な作業ログを眺める ● 非定型作業はヒヤリハットであることが多い ● 同じことを複数回やっているならトイル ○ 自動化可能か、根絶可能かを考える 24

Slide 25

Slide 25 text

アラート確認コーナー ● Mackerelのアラート一覧を眺める ○ それぞれがなぜ発生しているのかを話す ● 対応していないアラートがあったら ○ そもそも不要なアラートじゃないか会話する ○ その場で閾値を変えたり、監視ごと消したり ● 頻出しているアラートがあったら ○ 必要なアラートなら根本対応を検討する 25

Slide 26

Slide 26 text

ダッシュボード確認コーナー ● Mackerelのカスタムダッシュボードを眺める ○ PWG用のダッシュボードがある ○ サービスのメトリックが並んでいるだけではないし、 障害対応用のものとも別 ● 気になるグラフの変化についてみんなで話す ○ Mackerelのグラフアノテーションも活用する 26

Slide 27

Slide 27 text

ダッシュボード確認コーナー 27

Slide 28

Slide 28 text

PWGのアジェンダ ● 障害ふりかえり ● 作業ログ ● アラート ● ダッシュボード 28 ● 今日話したいこと ● 今後の変化共有 ● 出たTODOのIssue化 ● 感想・雑談

Slide 29

Slide 29 text

PWGのアジェンダ 29 ● 今日話したいこと ○ なんか気になってることが集まってくる ○ 特に無いこともある ● 今後の変化共有 ○ 大型のキャンペーンがあってアクセスが増えるとか ○ インフラ構成を変える予定とかEOLとか

Slide 30

Slide 30 text

● 出たTODOのIssue化 ○ Issueにして終わる ○ その場で書き切れなかったら書く人をアサインする ○ Issueの優先度はリファインメント時に相談 ● 感想・雑談 ○ 会のアジェンダ自体もどんどん変えていく ○ 議事録に置いておくとフンワリした話題を拾いやすい PWGのアジェンダ 30

Slide 31

Slide 31 text

● コスト ○ コスト変化もメトリック ● SLO見直し ○ 定期的にPOとのミーティングを行う ○ 月次の会があるなら乗っかるか？ PWGのその他のアジェンダ 31

Slide 32

Slide 32 text

アジェンダ ● PWGとは ● 何をやっているか ● どんな組織になるか ● まとめ 32

Slide 33

Slide 33 text

POが参加している ● 数字の変動要因をより知っている ○ サービス内のイベントや変化 ○ 数字の変化が予期されたものか、一時的か恒久的か ○ 例: CM放映による新規ユーザー増加とその影響 ● 未来の見通しも議論可能 ○ 利用状況のトレンドや今後の開発予定を共有 ○ スケールアップ等の対応を判断 33 https://www.minemura-coffee.com/entry/2023/12/06/194050

Slide 34

Slide 34 text

SLOがちゃんと運用される 34 ● SLOを達成しているか ○ PO、SRE、開発チームの全員が居る場で確認 ○ 違反していたらアクションを取る ● SLOは定期的に見直すもの ○ SLOや違反時のアクションを定めたドキュメントには revisit dateがある

Slide 35

Slide 35 text

● チームの一員とはいえ職種が違うと壁はある ● チームメンバーにタスクを振る練習ができる ○ PWGはSREsがオーナーシップを持ちやすい場なの で、進めていく意識を持ちやすい ○ その場でIssue化する流れの中で、解決したい時期を 決めたり、完了条件を決めたりしていく SREsのソフトスキル向上 35

Slide 36

Slide 36 text

● PWGを介して解像度が上がる ○ どんなアーキテクチャで動いているのか ○ 誰がどんな立場で発言しているか ○ 障害やアラート、ダッシュボードを一緒に読む機会 オンボーディング 36

Slide 37

Slide 37 text

感度の高い非インフラエンジニアの育 成 ● 何のためにこのメトリックを見ているのか ○ コンポーネント間の繋がり ○ 異常系のときにどういう動きをするのか ● このメトリックはどう変わると危ないのか ○ 上限が1000であることを知らないと、 10->100の変化にビビって慌てて調査してしまう 37 https://www.minemura-coffee.com/entry/2023/12/06/194050

Slide 38

Slide 38 text

● 障害時に本来鳴るべきアラートが鳴っていな いならおかしい ● 検知できるよう、監視を追加する ● ポストモーテム作成時に考えるものだが、 漏れていたらPWGで会話する 必要な監視を増やす 38

Slide 39

Slide 39 text

● 不要なアラートの棚卸し ● 一度追加した監視は削除するのが困難である ● 「このアラートいつも無視してるよね」 ● オオカミ少年アラートを許さない 監視条件をその場で変える 39

Slide 40

Slide 40 text

意思決定できる監視/ダッシュボード ● 「情報」は意思決定と行動を促すものである ● この原則に向き合って、監視を設計する ○ runbookを書けない監視は存在しない ● ダッシュボードも同様 ○ これが分かったら何が言えるのか、を一つずつ確認 ○ システムメトリックはダッシュボードには不要 40

Slide 41

Slide 41 text

● Embedded SREじゃない場合 ○ 運用を助けてくれるインフラ組織がプロダクト開発 チームの近くに居るはず ● キックオフやデイリーには居ないことが多い ので、PWGで情報を流す インフラ組織と会話する場 41

Slide 42

Slide 42 text

42 まとめ

Slide 43

Slide 43 text

まとめ 43 ● PWGを行うことで、チーム全員の認識が揃う ○ SLO、各コンポーネントの強弱、最近の傾向 ● ダッシュボードをみんなで見る ○ 継続して見ているだけで解像度が上がっていく ● ダッシュボードや監視が、育てていくものに ○ 特定の人/職種じゃなく、チームで育てていく ● チームでSLOや監視と向き合おう