Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
すこやかなサービス運営のための PWG (Performance Working Group)
Search
Takafumi ONAKA
PRO
August 10, 2024
Technology
0
42
すこやかなサービス運営のための PWG (Performance Working Group)
2024-08-10 builderscon 2024
Takafumi ONAKA
PRO
August 10, 2024
Tweet
Share
More Decks by Takafumi ONAKA
See All by Takafumi ONAKA
強いチームと開発生産性
onk
PRO
39
13k
ADRを運用して3年経った僕らの現在地
onk
PRO
19
7.8k
オブザーバビリティの Primary Signals
onk
PRO
2
3.7k
Cache Stampede
onk
PRO
1
1.9k
ORM - Object-relational mapping
onk
PRO
2
3.4k
デュアルトラックアジャイルとの向き合い方
onk
PRO
4
11k
技術記事を書く&楽しむチームの作り方
onk
PRO
0
120
グルーミングしながら進めるプロダクト開発
onk
PRO
0
350
エンジニアの個人ブランディングと技術組織
onk
PRO
0
110
Other Decks in Technology
See All in Technology
もし大規模障害が、10分で解決できたら?
masaaki_k
0
130
RDRAとLLM
kanzaki
4
460
Postman Flowsで作るAPI連携LINE Bot
miura55
0
210
大規模トラフィックを支える ゲームバックエンドの課題と構成の変遷 ~安定したゲーム体験を実現するために~
colopl
0
430
241130紅白ぺぱ合戦LT「編集の技術」
toya524287
3
480
Behind the scenes of 24-hour global online event “JAWS PANKRATION 2024”
syoshie
0
110
ヤプリのデータカタログ整備 1年間の歩み / Progress of Building a Data Catalog at Yappli
yamamotoyuta
3
540
プルリクが全てじゃない!実は喜ばれるOSS貢献の方法8選
tkikuc
12
1.5k
Continuous Integration! Raising the Bar
tdpauw
2
120
CDCL による厳密解法を採用した MILP ソルバー
imai448
5
430
Flutterによる 効率的なAndroid・iOS・Webアプリケーション開発の事例
recruitengineers
PRO
0
220
GDGoC開発体験談 - Gemini生成AI活用ハッカソン / GASとFirebaseで挑むパン屋のフードロス解決 -
hotekagi
1
270
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
400
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
How STYLIGHT went responsive
nonsquared
95
5.2k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
GitHub's CSS Performance
jonrohan
1030
460k
Faster Mobile Websites
deanohume
305
30k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Designing the Hi-DPI Web
ddemaree
280
34k
Transcript
すこやかなサービス運営の ためのPWG id:onk 2024-08-10 builderscon 2024 1
自己紹介 • 大仲 能史 a.k.a. id:onk • 芸歴20年目 • 株式会社はてな
◦ チーフエンジニア ◦ Mackerel 開発チーム 2
3 今日の話
4 PWG
5 はてなで運用している Performance Working Group の話をします
アジェンダ • PWGとは • 何をやっているか • どんな組織になるか • まとめ 6
7 PWGとは
PWGとは • Performance Working Groupの略 • 2009年辺りから開催している • プロダクト開発チームとインフラチームが 月に1回改善を検討する会議
8
PWGとは 9 https://mackerel.io/ja/blog/entry/advent-calendar2015/day19
PWGとは 10 https://x.com/yuuk1t/status/896098691416694786
SRE本 31章 11
SRE本 31章 12 私たちが行うミーティングの中で、平均以上 に有益なものが一つあります。それはプロダ クションミーティングと呼ばれるもので、 SREチームが自分たちと他の参加者に対し、 担当するサービスの状況について十分に注意 を払って明確に説明をすることによって、す べての関係者の全般的な認識を高め、サービ
スの運用を改善するために行われます。
SRE本 31章 13 定期的なミーティングにおいて設計上の判断 をサービスのパフォーマンスと合わせて考え てみることは、きわめて強力なフィードバッ クループになります。
SRE本 31章 14 • プロダクション環境において予定されてい る変更 • メトリクス • 障害
• ページされたイベント • ページされなかったイベント • これまでのアクションアイテム
2018年頃のPWGの目的 • パフォーマンス等が悪くなっていないか チェックする機会を定期的に設ける • エンジニアリング面で気になっていることを 雑談する場を定期的に設ける • SREチームとコミュニケーションする場を〜 •
直近のイベント等をSREチームにも共有する 15
最近のはてなのプロダクト開発チーム • Embedded SRE ◦ プロダクト開発チームにSREも所属 • 一緒にイテレーションを回す ◦ 一緒にデイリーミーティング
◦ 同じバックログにタスクが並んでいる 16
Embedded SREが居るPWG • 同じチームなので「予定されている変更」の 共有は必要なくなっている • Webアプリケーションエンジニアもアラート を一緒に受け取っているので共有目的は薄い • 定点観測とふりかえりの意味合いが強い
17
アジェンダ • PWGとは • 何をやっているか • どんな組織になるか • まとめ 18
PWGの開催頻度と出席者 • 月次開催、1時間枠 • 出席者 ◦ 必須: SREs ◦ 必須:
バックエンドのテックリード ◦ 任意: アプリケーションエンジニア ◦ 任意: プロダクトオーナー 19 必須メンバーが揃わない場合はリスケする
PWGでの役割 • 司会 ◦ 画面を写す ◦ 進行 ▪ 話題ごとに適切な人に話 を振る
• 書記 ◦ 会話した内容を議事録 (共同編集可) に書き記す 20 • その他みんな ◦ 答えたり質問したり ▪ 初心者大歓迎 ◦ 書記が書き逃したこと を書く ◦ 気になりがあったら書 く ▪ 事前記入大歓迎
PWG議事録 21 • 共同編集 ◦ 一人では議事録を書きき れない • 会話内容を残していく •
どんどんURLや画像を 貼っていく
PWGのアジェンダ • 障害ふりかえり • 作業ログ • アラート • ダッシュボード 22
• 今日話したいこと • 今後の変化共有 • 出たTODOのIssue化 • 感想/雑談
障害ふりかえりコーナー • 最近起きた障害とポストモーテムを眺める • 実施できていない根本対応について会話 • 一部のコンポーネントに障害が偏っていない かを俯瞰できるかも 23
作業ログコーナー • 障害ではないが非定型な作業ログを眺める • 非定型作業はヒヤリハットであることが多い • 同じことを複数回やっているならトイル ◦ 自動化可能か、根絶可能かを考える 24
アラート確認コーナー • Mackerelのアラート一覧を眺める ◦ それぞれがなぜ発生しているのかを話す • 対応していないアラートがあったら ◦ そもそも不要なアラートじゃないか会話する ◦
その場で閾値を変えたり、監視ごと消したり • 頻出しているアラートがあったら ◦ 必要なアラートなら根本対応を検討する 25
ダッシュボード確認コーナー • Mackerelのカスタムダッシュボードを眺める ◦ PWG用のダッシュボードがある ◦ サービスのメトリックが並んでいるだけではないし、 障害対応用のものとも別 • 気になるグラフの変化についてみんなで話す
◦ Mackerelのグラフアノテーションも活用する 26
ダッシュボード確認コーナー 27
PWGのアジェンダ • 障害ふりかえり • 作業ログ • アラート • ダッシュボード 28
• 今日話したいこと • 今後の変化共有 • 出たTODOのIssue化 • 感想・雑談
PWGのアジェンダ 29 • 今日話したいこと ◦ なんか気になってることが集まってくる ◦ 特に無いこともある • 今後の変化共有
◦ 大型のキャンペーンがあってアクセスが増えるとか ◦ インフラ構成を変える予定とかEOLとか
• 出たTODOのIssue化 ◦ Issueにして終わる ◦ その場で書き切れなかったら書く人をアサインする ◦ Issueの優先度はリファインメント時に相談 • 感想・雑談
◦ 会のアジェンダ自体もどんどん変えていく ◦ 議事録に置いておくとフンワリした話題を拾いやすい PWGのアジェンダ 30
• コスト ◦ コスト変化もメトリック • SLO見直し ◦ 定期的にPOとのミーティングを行う ◦ 月次の会があるなら乗っかるか?
PWGのその他のアジェンダ 31
アジェンダ • PWGとは • 何をやっているか • どんな組織になるか • まとめ 32
POが参加している • 数字の変動要因をより知っている ◦ サービス内のイベントや変化 ◦ 数字の変化が予期されたものか、一時的か恒久的か ◦ 例: CM放映による新規ユーザー増加とその影響
• 未来の見通しも議論可能 ◦ 利用状況のトレンドや今後の開発予定を共有 ◦ スケールアップ等の対応を判断 33 https://www.minemura-coffee.com/entry/2023/12/06/194050
SLOがちゃんと運用される 34 • SLOを達成しているか ◦ PO、SRE、開発チームの全員が居る場で確認 ◦ 違反していたらアクションを取る • SLOは定期的に見直すもの
◦ SLOや違反時のアクションを定めたドキュメントには revisit dateがある
• チームの一員とはいえ職種が違うと壁はある • チームメンバーにタスクを振る練習ができる ◦ PWGはSREsがオーナーシップを持ちやすい場なの で、進めていく意識を持ちやすい ◦ その場でIssue化する流れの中で、解決したい時期を 決めたり、完了条件を決めたりしていく
SREsのソフトスキル向上 35
• PWGを介して解像度が上がる ◦ どんなアーキテクチャで動いているのか ◦ 誰がどんな立場で発言しているか ◦ 障害やアラート、ダッシュボードを一緒に読む機会 オンボーディング 36
感度の高い非インフラエンジニアの育 成 • 何のためにこのメトリックを見ているのか ◦ コンポーネント間の繋がり ◦ 異常系のときにどういう動きをするのか • このメトリックはどう変わると危ないのか
◦ 上限が1000であることを知らないと、 10->100の変化にビビって慌てて調査してしまう 37 https://www.minemura-coffee.com/entry/2023/12/06/194050
• 障害時に本来鳴るべきアラートが鳴っていな いならおかしい • 検知できるよう、監視を追加する • ポストモーテム作成時に考えるものだが、 漏れていたらPWGで会話する 必要な監視を増やす 38
• 不要なアラートの棚卸し • 一度追加した監視は削除するのが困難である • 「このアラートいつも無視してるよね」 • オオカミ少年アラートを許さない 監視条件をその場で変える 39
意思決定できる監視/ダッシュボード • 「情報」は意思決定と行動を促すものである • この原則に向き合って、監視を設計する ◦ runbookを書けない監視は存在しない • ダッシュボードも同様 ◦
これが分かったら何が言えるのか、を一つずつ確認 ◦ システムメトリックはダッシュボードには不要 40
• Embedded SREじゃない場合 ◦ 運用を助けてくれるインフラ組織がプロダクト開発 チームの近くに居るはず • キックオフやデイリーには居ないことが多い ので、PWGで情報を流す インフラ組織と会話する場
41
42 まとめ
まとめ 43 • PWGを行うことで、チーム全員の認識が揃う ◦ SLO、各コンポーネントの強弱、最近の傾向 • ダッシュボードをみんなで見る ◦ 継続して見ているだけで解像度が上がっていく
• ダッシュボードや監視が、育てていくものに ◦ 特定の人/職種じゃなく、チームで育てていく • チームでSLOや監視と向き合おう