プロダクトのスケールによって顕在化しうるリスクをどう管理するか？

SRE NEXT 2024での登壇資料です
https://sre-next.dev/2024/schedule/#jp040

System Risk Records テンプレートはこちら:
https://docs.google.com/spreadsheets/d/e/2PACX-1vT2LLgmkDfEWsRjspoPAuVdVzmGtDIRSbji-WOBqo8Du3S53IdQu3_dolzgzeDMAYW6A-lg0K2ikFK0/pubhtml

Transcript

1. プロダクトのスケールによって 顕在化しうるリスクを どう管理するか？ 2024/08/04 浦⼭ 裕史 @urahiroshi #srenext_b
2. 自己紹介 2 浦⼭裕史 [@urahiroshi](https://x.com/urahiroshi) - Engineering Manager / Platform team @dinii - セコム => IIJ => メルカリ => dinii - やっていたこと / やっていること - マイクロサービス環境でのWebのリリースフロー - メルカリWebのマイクロサービス化、その4年 - インフラコストの削減ステップ - インシデントの「予防」「対応」「振り返り」を磨き込む！ - 成⻑を加速する組織 - チャット型メモサービス “Duck” を開発‧運⽤
3. 飲⾷店の All in One Cloud “ダイニー”
4. 4 ダイニーが提供しているプロダクト - “注⽂” 機能を提供するモバイルオーダー - “会計” 機能を提供するPOSレジ これらの機能が⽌まると 飲⾷店がまともに営業 できなくなってしまう
5. 5 サービスを導⼊している飲⾷店の売上 >> サービスの売上 だからこそ... 信頼性への投資が不可⽋！！
6. 信頼性を上げるための取り組み 6 - Performance Review: 定期的にメトリクスをモニタリング - System Risk Records: スケールによって顕在化‧悪化するリスクを管理 - On-Call 制度: 開発メンバーがローテーションで⽇々のOn-Call業務にあたる - 緊急事態訓練: ⼤規模インシデント発⽣を全社でシミュレート - スタンドアロン機能: インフラが⽌まっても会計などは実施できるようにする - Postmortem: インシデントや本番環境で出たバグを振り返る インシデントの予防 インシデントの緩和 インシデントの振り返り
7. 信頼性を上げるための取り組み 7 - Performance Review: 定期的にメトリクスをモニタリング - System Risk Records: スケールによって顕在化‧悪化するリスクを管理 - On-Call 制度: 開発メンバーがローテーションで⽇々のOn-Call業務にあたる - 緊急事態訓練: ⼤規模インシデント発⽣を全社でシミュレート - スタンドアロン機能: インフラが⽌まっても会計などは実施できるようにする - Postmortem: インシデントや本番環境で出たバグを振り返る インシデントの予防 インシデントの緩和 インシデントの振り返り 今回のトピック
8. Performance Review 8 各種メトリクスを定期的にモニタリングする場を週1回の頻度で設けている (定常リリースの頻度が週1回のため) - HTTP, GraphQL API のメトリクス - サーバのメトリクス - DBのメトリクス - バッチ処理のメトリクス - etc...
9. 怪しいメトリクスを見つけたときの対処フロー 9 1. 担当者をアサイン 2. 担当者が調査‧対応 3. 次の Performance Review の場で調査結果をレポート (解決 or 様⼦⾒の状態になるまで続く) 運⽤していくなかで、いくつかの課題が⾒えてきた
10. 10 課題1. 潜在的なリスク対応が埋もれがち
11. 課題1. 潜在的なリスク対応が埋もれがち 11 例: 外部APIを呼び出している箇所でエラーが発⽣ 1. 原因を調べると、⼀定時間の外部APIの呼び出し回数が制限を超過していた 2. 1回のリクエストで外部APIを無駄に⼆重に呼び出しているところがあった 3. 外部APIの呼び出しを1回に修正（暫定対策） 4. しばらくは⼤丈夫だが、リクエストが増えると確実にエラーになるので恒久対策 が必要 5. すぐやるのは難しいので開発チケットを作る 6. エラーが発⽣しなくなり、他の開発チケットも多く作られる中でチケットが埋も れ、リスクを忘れかける => 未解決のリスクを可視化したい！
12. 12 課題2. 対応の属⼈化
13. 課題2. 対応の属人化 13 例: メモリ使⽤量が上昇する問題を検出 1. 担当者にアサインされて調査を⾏い、怪しい箇所を発⾒ 2. 修正を適⽤し、メモリ使⽤量の遷移を確認 3. メモリ使⽤量が思ったより減らなかった 4. 改めて調査を⾏い、他の修正を適⽤ 5. 今度はうまくいき、メモリ使⽤量の問題が解消 6. 半年後、メモリ使⽤量の上昇が再発 7. 前回の試⾏錯誤の経験を踏まえて、また⾃分が担当する (以下繰り返し) => 試⾏錯誤のプロセスを共有したい！
14. 14 課題3. 優先度がわからない
15. 課題3. 優先度がわからない 15 1. 怪しい問題を⾒つける 2. 少し調べたが、原因がよくわからない 3. もう少し時間をかけて調査することもできるが、今そんなに時間をかけられない 4. パフォーマンスレビューで報告し、様⼦⾒として対応終了 5. (あれ？実は深刻な問題の予兆だった可能性も...？) => 体系⽴てた⽅法で優先度をつけたい！
16. 16 これらを解決するためのドキュメント‧運⽤フロー => System Risk Records 未解決のリスクがいま どれだけある？ これまでどういう対応 をやってきた？ このリスク対応の 優先度は？
17. System Risk Records の例 17
18. System Risk Records の例 18 リスクの⼀覧、ステータスがわかる
19. System Risk Records の例 19 リスクのインパクト、優先度がわかる
20. System Risk Records の例 20 クリックすると詳細を⾒れる
21. System Risk Record の例 (詳細) 21
22. System Risk Records に書いてあるもの (1) インパクト 22 現在のインパクト - 現時点でエラーやインシデントを発⽣させているかどうか 潜在的なインパクト - 何も対処しないままスケールしていった場合、最悪どれだけのインパクトになりうるか
23. System Risk Records に書いてあるもの (1) インパクト 23 ダイニーの場合: - <影響範囲> * <影響度> でインシデントをスコア付けしている - 影響範囲: どれだけ多くの店舗に影響したか (e.g. 数店舗 => 1, 半数未満 => 2, 半数以上=>3) - 影響度: 店舗に対する影響の重⼤さ (e.g. 店外業務のみ影響=>1, 店内業務に⽀障(代替可) => 3, 店内業務の遂⾏が困難 =>5) - 現在のインパクト、潜在的なインパクトもインシデントスコアをベースに算定 - 10 (score >= 10 のインシデント) - 6 (score >= 6 のインシデント) - 3 (score >= 3 のインシデント) - 1 (score >= 1 のインシデント) - 0 (なし) - 不明
24. System Risk Records に書いてあるもの (2) 発生可能性、優先度 24 発⽣可能性 (潜在インパクト) - 2: いつ発⽣してもおかしくない / スケールするとほぼ確実に発⽣ - 1: 発⽣する可能性がある 優先度スコア (= <潜在的なインパクト> * <発⽣可能性>) - 例: - 潜在的なインパクト=6 (score >= 6 のインシデント) - 影響範囲: 3 (半数以上) - 影響度: 3 (店内業務に⽀障) - 発⽣可能性=2: スケールするとほぼ確実に発⽣ => 優先度スコアは 6 * 2 = 12
25. System Risk Records に書いてあるもの (3) Status, Next Visit 25 Status - 未着⼿: 初期状態 - 対応中: 調査 ~ 対策 ~ 結果確認の最中 - 様⼦⾒: いったんアクティブな対応は⾏っていないもの - 暫定対策済み: 暫定対策を実施したが恒久対策は実施していないもの (暫定対策でインパクトが減った場合は値を更新する) - 完了: 恒久対策実施済み、もしくは対策不要と判断したもの Next Visit - System Risk Records を次に確認するタイミング (⽇付を設定) - 対応中の場合は 1週間 ~ 1ヶ⽉先を設定 - 様⼦⾒や暫定対策済みの場合は 1ヶ⽉ ~ 3ヶ⽉先を設定
26. System Risk Records に書いてあるもの (4) 詳細 26 - 概要 - リスクの概要を記載する - リスクの認知 ~ 原因特定までのログ - リスクを認知したきっかけとなったメトリクスのURLなどを記載する - 原因を特定するための対応の流れも記載していく。SlackのURLなどでもOK - 原因 - リスクの根本原因を書く - 対策⽅針 - 対策⽅針を書く - 代案があれば⽐較し、チーム内でレビューをするのもGood - 対策ログ - 暫定対策‧恒久対策のPR, リスクが収束したと確認できる情報などを記載する - Next Action - 次のアクションまで時間が開く場合などのためにメモを残す
27. どうやって作るのか 27 - ダイニーでは Notion の Database を利⽤して作成 - Google Spreadsheet + Google Document のテンプレートも公開していま す:https://docs.google.com/spreadsheets/d/e/2PACX-1vT2LLgmkDfEWsRjspoPAuV dVzmGtDIRSbji-WOBqo8Du3S53IdQu3_dolzgzeDMAYW6A-lg0K2ikFK0/pubhtml
28. 運用上のポイント: いつ作るか 28 - Performance Review で⾒つかる気になる箇所は毎週何個もある - 特定のサーバでエラーが増えている - 特定のサーバのメモリ使⽤量が増えている - 特定のSQLクエリが重い - etc... - 全部 System Risk Records に記載すると管理しきれなくなるため取捨選択する必要が あるが、その問題のインパクトや発⽣可能性は調べてみないとわからない。主観的に 取捨選択すると System Risk Records の運⽤が属⼈化しがち => 以下の条件でSystem Risk Records に⼊れるようにした - まず Performance Review で検出した問題を1週間調査する - 問題が根本解決できず、潜在的なインパクトが3以上になりうる
29. 運用上のポイント: ポストモーテムとの連携 29 - インシデントのポストモーテムを記載している場合、インシデントとなった事象をポ ストモーテムで扱うか、System Risk Records で扱うか悩ましい時がある - ポストモーテムに書くもの - 原因 - 恒久対応 - 再発防⽌策 - どうやって検知までの時間 (MTTA) や復旧までの時間 (MTTR) を短縮するか => ポストモーテムはポストモーテムとして書くのが良い。そのうえでSystem Risk Records としてウォッチしていく必要があるかが判断基準となる。 例えば、ポストモーテム⾃体は書き終わったものの恒久対応に時間がかかる場合は「ウォッ チすべきリスクがある状態」と⾔えるので System Risk Record を作り、詳細部分にポスト モーテムへのリンクを貼る
30. まとめ 30 - 各種メトリクスを定期的に確認し、異常があれば担当者をアサインして調査を⾏ う運⽤フロー (Performance Review) を回す - 運⽤フローを回していると「潜在的なリスクが埋もれがち」「属⼈化する」「優 先度がわからない」といった課題が出てきた - 潜在的なリスクのインパクトや、調査‧対応の流れを記録した “System Risk Records” を作ることで、未解決のリスクを優先度ごとに⼀覧できるようにし、 リスク対応の流れを組織的な学びにできた
31. ② SREはじめ各エンジニア職種も絶賛採⽤中です。   気軽にカジュアル⾯談にお申し込みください！   https://hrmos.co/pages/dinii/jobs/9999 お知らせ 31 ① 飲⾷店でプロダクトを触りながら話す  「ダイニー体験会」を毎⽉開催しています。  興味があればぜひご参加ください！  次回は 8/19 (⽉)です:  https://dinii.connpass.com/event/325689/